好像所有带有‘管理’字样的东西都变得不那么具体了。
一般这个东西就要对症下药了，所以首先得知道有什么样的风险。在实际的工作中主要遇到过以下的风险类型：
1、需求变更，这个是最大的风险，因为最后期限是不变的，需求变了，就意味着更多的工作要在已计划好的日程表中做完。风险可排老大
2、人员变动，在一个可以持续2，3个月的项目中，中途可能有人离职
3、需求理解问题，由于缺少行业知识，业务背景，有可能对需求的认识不够透彻
4、复查工作没做好
5、需求覆盖率不高
6、测试用例执行没有达到100%
7、测试环境和实际环境有偏差
8、测试缺陷很难重现，导致无法定位根源从而没有修复
针对第一条：估计每个公司都在这上面吃过亏吧。所以才有那么多的软件开发模型。我所经历过的一些比较大的项目，采用的都是增量迭代的开发模式，所以在每一个小的阶段，需求是相对稳定的。但是也有变更的时候，这种时候，我们一般是要求走需求变更流程，根据变更的大小来确定策略：如果变更造成的工作量小于3天/人，作为一个ADHOC项目，如果大于3天/人，就作为另一个新的项目。这个当然要和客户达成一致。
针对第2条：最好是每个岗位培养备份的人员
3，4，5条其实可以归结为一条，我们尽量在需求分析阶段就把自己所有不明白，不清晰的问题提出来，整理成一个文档，先内部回答，这个内部可以包含开发，然后发给需求方请求答案。测试用例评审会要组织好，在开始之前，要求每个人所设计的用例至少被2个不同级别的人员评审过，然后再评审会上确定最终的问题和解决方案，会后跟踪这些评审会上出现问题的状态。
第6条是完全可以避免的。如果时间确实很紧，按优先级别选择最重要的CASE去跑。
第7条嘛，一般是在搭建测试环境之前，列出一些需要检查的项，搭好后，让人按这个检查项一项一项的去检验。
第8条，还真没什么好办法，如果你有，麻烦告诉我下。我们一般遵循的是只要是出现过的，哪怕一次也是缺陷，都要记录在案的。也可以在交付客户时说明并一同交付。
说在最后的，做测试肯定要得到老大的支持和重视，否则风险控制都是空谈啦。尽量每个阶段都要文档化，规范化。
做任何事情都有风险，风险管理无非就是消除，消除不了就减少，减少不了就降低。降低到一定程度就不再有威胁，或者短时间没威胁，没威胁就不是风险了。
针对测试的各种风险，还是建立一种“防患于未然”或“以预防为主”的管理意识比较靠谱。
此文为个人经验，不对之处请指教。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
