软件测试培训之项目级的风险分析

网友投稿 607 2022-11-11

本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。

软件测试培训之项目级的风险分析

从人、料、法、环、时等方面分析测试项目级的风险分布

探寻测试隐藏的风险时,应招集测试全组成员举行会议, 建议采用头脑风暴和询问5Why的方式进行,以集思广益和深度挖掘。下面就在鱼骨图中以TQM (全面质量管理) 的人、机、料、法、环等五个方面来全方位的分析和罗列项目级可能隐藏的风险 (注:考虑到在软件测试中“机”这一项更多的属于环境这一分类,故删除此类。另外时间对于软件测试是一个非常重要的属性,故添加之)。

人,即测试人员:

测试人员变动:离职,岗位调动,请假等。

定位效应:测试过的可靠的功能,特别是在多次回归且没有发现问题,在此后往往会认为此功能是可靠的。

疲态:某一些功能点一直由某一位测试人员测试,经过多次回归后,测试人员对该功能点的测试显示出倦意和缺乏兴趣。

同化效应:经过和开发的长时间接触,往往会被开发的思维逻辑所同化,渐渐丧失从用户角度出发的测试观察点。

料,即测试相关文档(在TQM中指的是生产原材料):

Spec (详细规格说明书)缺失:只有PRD(项目需求概要说明书),没有spec。笔者所在的公司,早些时候的产品更多的时候只有PRD,没有Spec。

需求变更:这是最不想,但又最经常发生的事情

测试用例/数据设计不充分:某些时候由于编写测试人员的个人因素或时间的限制等方面因素导致。

质量标准不统一:如某些Bug的优先级方面,测试和开发的认同不一致。

法,即测试方法和实施:

错误或缺失测试方法:对功能点没有采用正确的测试方法,或某些测试方法没有被忽视,如边界测试等,导致测试不充分。

场景的缺失或部分缺失:Spec非常详细,所有的精力放在功能点的测试上,忽视了业务场景(Spec中无定义)的全(100%)测试。

测试用例实施不充分:测试用例由于各种原因没有完全测试,如在回归测试中。

环,即测试环境:

被测软件版本不统一:没有有效的配置管理,这种情况及易出现

测试软件环境不一致:测试员之间或和开发之间的操作系统类型不一致、操作系统的干净程度不一致。

测试硬件环境不一致:测试员之间或和开发的设备不一致,如CPU频率,内存大小等。

测试硬件未及时到位时,即测试时间:

测试时间不足:里程碑之间留给测试的时间无法满足全测试要求。

测试时间延长:由于需求方突然宣布原进度表中的里程碑时间点延后,导致项目的进度表一下松弛了许多。笔者参加过的两个项目就遇见过这种情况,我们为世界某著名品牌电脑供应商开发并提供随机软件。在项目进展到中后期时,客户忽然通知我们暂时不安排我们的软件在他们这一版本系统中进行安装,要等到下一版本,时间延迟可能长达三个月,甚至更多。

注:以上五个方面不可能将所有软件测试中潜在的风险全部罗列,旨在给出思维方式。

上一篇:软件测试培训之测试的原则
下一篇:软件测试培训之与研发的约定
相关文章

 发表评论

暂时没有评论,来抢沙发吧~