软件测试常见风险分析

软件测试常见风险分析（一）

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、做好质量卡点，严控冒烟提测质量，能方便后期有条不紊的执行测试。