软件测试常见风险分析（一）
1、需求风险。
对软件需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式；另外需求变更导致测试用例变更，同步时存在误差。
2、测试用例风险。
测试用例设计不完整，忽视了边界条件、异常处理等情况，用例没有完全覆盖需求；测试用例没有得到全部执行，有些用例被有意或者无意的遗漏；
3、缺陷风险。
某些缺陷偶发，难以重现，容易被遗漏；
4、代码质量风险。
软件代码质量差，导致缺陷较多，容易出现测试的遗漏；
5、测试环境风险。
有些情况下测试环境与生产环境不能完全一致，导致测试结果存在误差；
6、试技术风险。
某些项目存在技术难度，测试能力和水平导致测试进展缓慢，项目延期；
7、回归测试风险。
回归测试一般不运行全部测试用例，可能存在测试不完全；
8、沟通协调风险。
测试过程中涉及的角色较多，存在不同人员、角色之间的沟通、协作，难免存在误解、沟通不畅的情况，导致项目延期；
9、其它不可预计风险。
一些突发状况、不可抗力等也构成风险因素，且难以预估和避免。
软件测试常见风险分析（二）
1、 人力
风险评估点:
1 人力资源不够
2 测试用例未被完全执行
3 人员流动,测试人员对业务不熟悉
相对应的风险控制:
1 按照项目计划,测试计划准备好测试需要的人力
2 在测试留存中严格控制测试的执行,抽查,责任归个具体的人
3 做好人员流动的准备,加大业务培训
2、 需求
风险评估点:
1 需求人员,测试人员,开发人员对需求的理解不一致
2 后期需要小的变更点,没有引起重视,未知会到测试
3 需求变动大导致测试工作量增加,可能导致的测试不充分
相对应的风险控制:
1 加强需求评审和沟通
2 项目流程控制,所有变更必须知会测试进行测试和分析
3 通过加班延长测试时间,加大测试人员投入,保证测试充分
3、 开发
风险评估点：
1 开发送测的时间晚于原计划，导致测试时间被压缩
2 开发版本控制混乱，送测版本的次数过于密集或无事先约定
3 开发质量差，导致某些模块的问题过多，遗漏未被发现的缺陷数也会增多
4 开发修复bug考虑不周全，带入新的缺陷
相应的风险控制：
1 开发把握好计划送测的时间，做好晚送测的测试准备，加班或加入人力等
2 与开发约定送测的迭代周期，频繁迭代会导致测试不全或重复测试浪费测试资源
3 统计问题多的模块，按模块的优先级适量加大测试投入
4 bug验证要考虑好相应的场景，回归相关的功能
4、 环境及其他
风险评估点：
1 测试环境与线上真实环境差异大，产生上线后的环境问题
2 回归测试不充分
3 测试用例设计考虑不全
4 测试范围和标准不确定
相应的风险控制
1 尽量使用和线上环境差异少的测试环境，条件允许可模拟一套与线上相近的测试环境，来做项目最后的回归测试或安装测试
2 回归测试前分析问题较多的模块和核心模块，加大测试投入，回归测试把握重点，尽量提高回归测试的效率
3 平时加强测试人员的业务能力和测试技术水平；测试测试邀请业务、开发一同参加补充测试点，共同承担质量风险
3 测试计划中要明确测试范围，测试标准，测试功能的优先等级
参考
| 风险名称 |
风险等级 |
风险描述 |
规避措施 |
| 业务中断风险 |
高 |
本次投产计划为前后端一起发版，后端接口设计未兼容前端旧代码，可能存在前后端发版间隔窗口引发业务中断的风险。 |
请项目经理做投产规划时，考虑是否影响业务，是否需要挂牌或其他预案。 |
| 测试覆盖风险 |
高 |
由于本项目测试时间不足，经与开发负责人XXX和产品负责人XXX确认，对于后端XX服务开关打开/关闭的配置，仅挑选了部分核心场景进行验证，存在覆盖不全的风险。 |
请相关开发和产品上线后做好业务监测，对于未全量测试覆盖的配置场景重点关注并做好预案，出现问题及时响应处理。 |
| 其他风险 |
中 |
UAT验收阶段开发针对优化意见做了部分功能优化变更后即投产，要求直接先上线试用，未再安排充分回归测试时长，测试人员仅快速回归主要功能点，存在优化变更影响原有正常功能的风险。 |
上线后先部分团队推广试用，及时沟通处理反馈，待全量功能稳定后逐步扩大推广。 |
测试经验及建议
1、建议开发做好充分自测，提高转测版本的质量；
2、修复问题时，关注代码改动范围，避免引发新的问题；
3、同类问题尽量要一并修复，不要被动等待测试人员指出一处改一处。
4、做好质量卡点，严控冒烟提测质量，能方便后期有条不紊的执行测试。
