软件测试风险分析.pdf

  1. 1、本文档共6页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
作为 软件测试 计划的一部分,软件测试风险的分析与控制是其中重要的环节。如果前期风险分析与控制比 较充分,那么会使软件的测试成功性大大增加,且可将由风险异常引发的额外成本(如人力,时间等)降 到最低。 查阅了网上很多关于软件测试风险控制的 文章 ,其中不乏精品之作。 本文将此类知识进行了归纳, 查漏补缺,并在思维导向性上给出了简单的实施步骤,以使得在实际应用中能得到更好的运用。 第一部分:软件测试项目级的风险分析 1. 从人、料、法、环、时等方面分析测试项目级的风险分布 探寻测试隐藏的风险时, 应招集测试全组成员举行会议, 建议采用头脑风暴和询问 5Why 的方式进行, 以集思广益和深度挖掘。下面就在鱼骨图中以 TQM (全面质量管理 ) 的人、机、料、法、环等五个方面 来全方位的分析和罗列项目级可能隐藏的风险 (注:考虑到在软件测试中 “机 ”这一项更多的属于环境这一 分类,故删除此类。另外时间对于软件测试是一个非常重要的属性,故添加之)。 下面对鱼骨图中的各个分支及子分支进行相应注解: 人, 即测试人员: 业务不熟:测试人员对被测系统的业务流程不熟悉,体现在对需求的理解上把握不准、理解不透 侧、理解错误等。 测试人员变动:离职,岗位调动,请假等。 定位效应:测试过的可靠的功能,特别是在多次回归且没有发现问题,在此后往往会认为此功能 是可靠的。 疲态:某一些功能点一直由某一位测试人员测试,经过多次回归后,测试人员对该功能点的测试 显示出倦意和缺乏兴趣。 同化效应:经过和开发的长时间接触,往往会被开发的思维逻辑所同化,渐渐丧失从用户角度出 发的测试观察点。 料, 即测试相关文档(在 TQM 中指的是生产原材料): Spec (详细规格说明书)缺失:只有 PRD (项目需求概要说明书),没有 spec 。笔者所在的公 司,早些时候的产品更多的时候只有 PRD ,没有 Spec 。 需求变更:这是最不想,但又最经常发生的事情 测试用例 /数据设计不充分:某些时候由于编写测试人员的个人因素或时间的限制等方面因素导 致。 质量标准不统一:如某些 Bug 的优先级方面,测试和开发的认同不一致。 法, 即测试方法和实施: 错误或缺失测试方法:对功能点没有采用正确的测试方法,或某些测试方法没有被忽视,如边界 测试等,导致测试不充分。 场景的缺失或部分缺失: Spec 非常详细,所有的精力放在功能点的测试上,忽视了业务场景( S pec 中无定义)的全( 100% )测试。 测试用例实施不充分:测试用例由于各种原因没有完全测试,如在回归测试中。 环, 即测试环境: 被测软件版本不统一:没有有效的 配置管理 ,这种情况及易出现 测试软件环境不一致:测试员之间或和开发之间的 操作系统 类型不一致、操作系统的干净程度不 一致。 测试硬件环境不一致:测试员之间或和开发的设备不一致,如 CPU 频率,内存大小等。 测试硬件未及时到位 时, 即测试时间: 测试时间不足:里程碑之间留给测试的时间无法满足全测试要求。 测试时间延长:由于需求方突然宣布原进度表中的里程碑时间点延后,导致项目的进度表一下松 弛了许多。笔者参加过的两个项目就遇见过这种情况,我们为世界某著名品牌电脑供应商开发并 提供随机软件。在项目进展到中后期时,客户忽然通知我们暂时不安排我们的软件在他们这一版 本系统中进行安装,要等到下一版本,时间延迟可能长达三个月,甚至更多。 注:以上五个方面不可能将所有软件测试中潜在的风险全部罗列,旨在给出思维方式。 2. 采用 FMEA 评估及分析风险项 在采用 FMEA 对风险进行评估和分析前,有

文档评论(0)

kxg2020 + 关注
实名认证
内容提供者

至若春和景明,波澜不惊,上下天光,一碧万顷,沙鸥翔集,锦鳞游泳,岸芷汀兰,郁郁青青。

1亿VIP精品文档

相关文档