您现在的位置是:首页 >技术交流 >软件测试常见风险分析网站首页技术交流
软件测试常见风险分析
文章目录
软件测试常见风险分析(一)
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服务开关打开/关闭的配置,仅挑选了部分核心场景进行验证,存在覆盖不全的风险。 请相关开发和产品上线后做好业务监测,对于未全量测试覆盖的配置场景重点关注并做好预案,出现问题及时响应处理。