一、风险识别清单
1、需求
- 产品的业务需求、用户需求、功能需求和系统需求是否完整、清晰？
- 开发人员在产品开发设计之前是否充分了解需求？
2、设计
（1） 是否使用了“新技术”？
（2）系统中是否会存在一些设计“瓶颈”？如果存在，是否有应对措施？
（3）产品是否设计得过于复杂，难以理解？
（4）开发人员是否能够讲清楚产品设计？
（5）开发人员对异常、非功能方面的内容是否考虑得足够全面？
（6）开发人员在设计中是否存在一些比较担心的地方？
（7）开发人员是否会考虑和设计一些可测试性或者易于定位的功能？
（8）对一个需要多人（或多组）才能配合完成的功能，是否有人会进行整体的设计、协调和把关？
（9）对有依赖或结束的内容，是否有充分考虑？
3、流程
（1）项目是否使用了新的流程、开发方法等？
（2）开发人员是否会进行自测？是如何进行自测的？测试的深度和发现问题的情况如何？
（3）开发人员如何进行代码修改，是如何保证修改的正确性的？
（4）开发人员是如何进行版本管理的？
4、变更
（1）新版本在旧功能方面做了哪些修改？修改后的主要影响是什么？
（2）在项目过程中，需求是否总是在变更？
5、组织和人
（1）哪些模块是由其他组织开发的？他们在哪里开发？开发流程、能力如何？
（2）产品的研发团队（包括需求、开发和测试）是否在于不同的地方？彼此分工如何？沟通是否顺畅？
（3）团队人员能力如何？经验如何（包括需求、开发和测试团队）？
（4）团队是否稳定（包括需求、开发和测试团队）？
（5）团队人手是否充足（包括需求、开发和测试团队）？
（6）团队环境是否具备（包括必备的工具、硬件设备）？
6、历史
（1）哪些特性在产品测试时就存在有很多bug？
（2）哪些特性存在较多的客户反馈问题？
（3）历史上上哪些情况曾经导致过阻塞测试活动的问题？
二、风险评估
风险评估的目的：确定风险优先级
1、风险优先级正交表
根据风险发生频率和风险影响程度，“高”“中”“低”相互交错来判断
2、需求类的风险
- 需求的质量不高，不足以支撑后续开发和测试
- 开发和测试未能正确理解需求
需求类的风险，对设计、开发、测试的影响较大，因此风险的影响程度和风险发生频率设置为“高”，重点关注
3、设计类风险
设计类的风险主要集中在设计的正确性和全面性上，这些风险一旦成了问题，就是产品缺陷。对于这些由风险引起的缺陷，评估一下：
（1）测试容易发现这些缺陷吗？
（2）开发修复这些缺陷的改动大吗？影响的功能模块多吗？
（3）测试容易验证这个缺陷吗？回归测试的工作量大吗？
（4）如果这个缺陷逃逸到了用户处，对用户的影响大吗？
一般来说，对于测试难于发现的缺陷，风险的影响程度更高；基础的、底层的、共用的设计，风险的影响程度更高；需要特殊测试工具或复杂测试环境才能验证的，风险的影响程度更高；在用户处发生概率高、会对用户的业务造成更严重影响的问题，风险的影响程度更高。
4、流程类的风险
从风险影响程度来说，会影响团队合作，或是涉及规范性方面的风险，风险影响程度更高，建议至少为中级
5、历史类的风险
历史上曾经发生过的问题，再次成为问题的风险依然很大。所以建议风险发生的概率应该总是高的
三、风险应对
1、回避风险：指主动避开损失发生的可能性。
2、转移风险：指通过某种安排，将自己面临的风险全部或部分转义给其他一方。
3、减轻风险：指采取预防措施，已降低损失发生的可能性和影响程度。
4、接受风险：指自己理性或非理性地主动承担风险。
四、常见风险及应对思路
1、需求类的风险
（1）问题：产品需求在业务场景上描述不够完整、清晰，不能有效指导开发人员和测试人员的工作。
解答：A、加强对业务场景的评审
B、加强开发、测试和需求工程师对业务场景的沟通、讨论，保证开发、测试和需求工程师对场景的验收条件的理解是一致的。
（2）问题：开发人员在进行产品设计之前并没有充分理解了产品需求，特别是在易用性和性能需求方面
解答：A、开展开发人员对需求工程师进行需求确认的活动，确保需求理解的一致性；
B、开发人员需要逐一根据需求编写验收测试用例，确保需求能够被正确实现，无遗漏；
C、开发人员针对易用性进行低保真、高保真设计，并和需求工程师进行评审确认；
D、在需求中需要明确产品的性能规格
E、测试人员尽早展开和产品性能相关的摸底测试。
2、设计类的风险
（1）问题：产品使用了新的技术平台
解答：A、将新平台与旧平台进行差异化分析，确定变化点
B、针对变化点进行专项测试
（2）问题：产品设计得过于复杂，难以理解
解答：A、和需求工程师进行沟通，确认设计没有超过需求要求的范围；
B、要求开发人员对设计进行讲解
C、增加这部分的测试投入
（3）产品中存在需要多人（或多组）才能配合完成的功能，且缺少这个功能的总体负责人
解答：A、建议开发增加一位总体责任人，负责确认接口、整体协调等；
B、建议开发人员对该功能设计自测用例，并在评审开发自测用例时进行确认；
C、将该功能作为接收测试用例，避免该功能造成测试阻塞；
3、流程类风险
问题：开发自测不充分
解答：A、和开发人员约定，在本轮版本转测试的时候，需要提供详细的自测报告；
B、评估开发人员自测用例的质量，必要时提供用例设计指导或直接提供测试用例；
C、搭建自动化测试环境，供开发人员自测使用
4、变更类的风险
问题：项目过程中，需求总是在增加
解答：A、和开发人员、需求工程师进行沟通，进行需求控制
B、裁剪部分低优先级的需求
5、组织和人
（1）问题：测试团队大部分人员没有测试设计的经验
解答：A、在进行测试设计之前，找 写的好的测试用例作为例子
B、增加测试设计的评审检查点，如测试分析、测试标题和测试内容分别进行评审；
C、必要时，测试架构师对测试工程师进行一对一的辅导
（2）问题：xxx测试工具不具备，需要购买
解答：A、定期跟踪工具购买进展；
B、寻找是否有替代工具。
6、历史类风险
（1）问题：xx特性在基线版本中就存在很多bug
解答：对基线版本该特性的缺陷进行分析，分析哪些测试手段容易发现该特性的问题，据此增加探索式测试
（2）基线版本中，开发人员修改引入缺陷导致缺陷趋势无法收敛，对测试进度和产品发布造成了影响，在继承性版本中可能存在相同的风险
解答：对基线版本中开发人员修改引入缺陷的问题进行根因分析，针对根因制定措施
1.作者：Syw
2.本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
3.如果文中有什么错误，欢迎指出。以免更多的人被误导。