您现在的位置是:首页 >技术交流 >软件测试常见风险分析网站首页技术交流

软件测试常见风险分析

凯凯恺恺恺恺凯凯 2024-06-17 11:19:25
简介软件测试常见风险分析

软件测试常见风险分析(一)

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服务开关打开/关闭的配置,仅挑选了部分核心场景进行验证,存在覆盖不全的风险。 请相关开发和产品上线后做好业务监测,对于未全量测试覆盖的配置场景重点关注并做好预案,出现问题及时响应处理。

风语者!平时喜欢研究各种技术,目前在从事后端开发工作,热爱生活、热爱工作。