好像所有带有‘管理’字样的东西都变得不那么具体了。

　　一般这个东西要对症下药了，所以首先得知道有什么样的风险。在实际的工作中主要遇到过以下的风险类型：

　　1、需求变更，这个是大的风险，因为后期限是不变的，需求变了，意味着更多的工作要在已计划好的日程表中做完。风险可排老大

　　2、人员变动，在一个可以持续2，3个月的项目中，中途可能有人离职

　　3、需求理解问题，由于缺少行业知识，业务背景，有可能对需求的认识不够透彻

　　4、复查工作没做好

　　5、需求覆盖率不高

　　6、测试用例执行没有达到

　　7、测试环境和实际环境有偏差

　　8、测试缺陷很难重现，导致无法定位根源从而没有修复

　　针对第一条：估计每个公司都在这上面吃过亏吧。所以才有那么多的软件开发模型。我所经历过的一些比较大的项目，采用的都是增量迭代的开发模式，所以在每一个小的阶段，需求是相对稳定的。但是也有变更的时候，这种时候，我们一般是要求走需求变更流程，根据变更的大小来确定策略：如果变更造成的工作量小于3天/人，作为一个ADHOC项目，如果大于3天/人，作为另一个新的项目。这个当然要和客户达成一致。

　　针对第2条：好是每个岗位培养备份的人员

　　3，4，5条其实可以归结为一条，我们尽量在需求分析阶段把自己所有不明白，不清晰的问题提出来，整理成一个文档，先内部回答，这个内部可以包含开发，然后发给需求方请求答案。测试用例评审会要组织好，在开始之前，要求每个人所设计的用例至少被2个不同级别的人员评审过，然后再评审会上确定终的问题和解决方案，会后跟踪这些评审会上出现问题的状态。

　　第6条是完全可以避免的。如果时间确实很紧，按优先级别选择重要的CASE去跑。

　　第7条嘛，一般是在搭建测试环境之前，列出一些需要检查的项，搭好后，让人按这个检查项一项一项的去检验。

　　第8条，还真没什么好办法，如果你有，麻烦告诉我下。我们一般遵循的是只要是出现过的，哪怕一次也是缺陷，都要记录在案的。也可以在交付客户时说明并一同交付。

　　说在后的，做测试肯定要得到老大的支持和重视，否则风险控制都是空谈啦。尽量每个阶段都要文档化，规范化。

　　做任何事情都有风险，风险管理无非是消除，消除不了减少，减少不了降低。降低到一定程度不再有威胁，或者短时间没威胁，没威胁不是风险了。

　　针对测试的各种风险，还是建立一种“防患于未然”或“以预防为主”的管理意识比较靠谱。

　　此文为个人经验，不对之处请指教。