标签：
双11大促，发现大部分测试人员只能做做功能测试。
但其实我们能做的很多，但是都是要求有一定权威性和执行力，我们所缺乏：
1、针对免测情况的各业务风险评估
--mike：目前的EOS权限控制在开发，RPM根本没有权限控制系统，所以测试环境部署确实，业务免测测试也经常不知道。
这个问题已经在沟通解决了，会让运维开发RPM的权限管理系统，慢慢地把权限从开发人员收回，免测试发布一定要经过测试人员（部署测试环境这一环节，部署的时候由对应测试人员评估风险）
--me：其实这个也不解决根本问题，就算把权限从开发收回，免测走测试人员，测试人员也可能会直接评审通过；只做到了责任分配，但不没有做到任务落实；最好的方法，能够从技术手段评估风险；
扫描所有接口，根据各接口上报的监控key，从监控系统找出免测业务各接口统计调用次数，分析各接口在ao/db/redis各层的放大效应，进而对各层进行调用数预估。
2、各业务性能全面压测，详细报告；
--mike：后面会越来越多的业务提出压测需求，但全面目前暂时还不会做。
--me：基础业务组件的摸底性能测试；关键业务的压力测试；平时各业务的定期性能摸底；底层函数迭代性能（函数级别，性能执行统计，每版本）
3、各业务对依赖接口的容灾测试
--mike：大促都一直有做这样的测试的，不过大部分是开发那边在做。
基础业务依赖的外部服务比较多，他们那边测试验证工作的相对比较多。促销和app相对很少
--me：测试应该有自己的容灾评估；
4、针对上下游合作伙伴的回访
--me：直接跟对口合作的开发进行访问，了解痛点，和自身做的不好的点；不要问他们的ld，他们的ld通常很少干活，不会有具体的感知；
标签：
原文地址：http://www.cnblogs.com/carterzhang/p/5026599.html
