软件测试风险分析.pdf

作为 软件测试 计划的一部分，软件测试风险的分析与控制是其中重要的环节。如果前期风险分析与控制比 较充分，那么会使软件的测试成功性大大增加，且可将由风险异常引发的额外成本（如人力，时间等）降 到最低。 查阅了网上很多关于软件测试风险控制的 文章 ，其中不乏精品之作。 本文将此类知识进行了归纳， 查漏补缺，并在思维导向性上给出了简单的实施步骤，以使得在实际应用中能得到更好的运用。 第一部分：软件测试项目级的风险分析 1. 从人、料、法、环、时等方面分析测试项目级的风险分布 探寻测试隐藏的风险时， 应招集测试全组成员举行会议， 建议采用头脑风暴和询问 5Why 的方式进行， 以集思广益和深度挖掘。下面就在鱼骨图中以 TQM （全面质量管理 ） 的人、机、料、法、环等五个方面 来全方位的分析和罗列项目级可能隐藏的风险 （注：考虑到在软件测试中 “机 ”这一项更多的属于环境这一 分类，故删除此类。另外时间对于软件测试是一个非常重要的属性，故添加之）。 下面对鱼骨图中的各个分支及子分支进行相应注解： 人， 即测试人员： 业务不熟：测试人员对被测系统的业务流程不熟悉，体现在对需求的理解上把握不准、理解不透 侧、理解错误等。 测试人员变动：离职，岗位调动，请假等。 定位效应：测试过的可靠的功能，特别是在多次回归且没有发现问题，在此后往往会认为此功能 是可靠的。 疲态：某一些功能点一直由某一位测试人员测试，经过多次回归后，测试人员对该功能点的测试 显示出倦意和缺乏兴趣。 同化效应：经过和开发的长时间接触，往往会被开发的思维逻辑所同化，渐渐丧失从用户角度出 发的测试观察点。 料， 即测试相关文档（在 TQM 中指的是生产原材料）： Spec （详细规格说明书）缺失：只有 PRD （项目需求概要说明书），没有 spec 。笔者所在的公 司，早些时候的产品更多的时候只有 PRD ，没有 Spec 。 需求变更：这是最不想，但又最经常发生的事情 测试用例 /数据设计不充分：某些时候由于编写测试人员的个人因素或时间的限制等方面因素导 致。 质量标准不统一：如某些 Bug 的优先级方面，测试和开发的认同不一致。 法， 即测试方法和实施： 错误或缺失测试方法：对功能点没有采用正确的测试方法，或某些测试方法没有被忽视，如边界 测试等，导致测试不充分。 场景的缺失或部分缺失： Spec 非常详细，所有的精力放在功能点的测试上，忽视了业务场景（ S pec 中无定义）的全（ 100% ）测试。 测试用例实施不充分：测试用例由于各种原因没有完全测试，如在回归测试中。 环， 即测试环境： 被测软件版本不统一：没有有效的 配置管理 ，这种情况及易出现 测试软件环境不一致：测试员之间或和开发之间的 操作系统 类型不一致、操作系统的干净程度不 一致。 测试硬件环境不一致：测试员之间或和开发的设备不一致，如 CPU 频率，内存大小等。 测试硬件未及时到位 时， 即测试时间： 测试时间不足：里程碑之间留给测试的时间无法满足全测试要求。 测试时间延长：由于需求方突然宣布原进度表中的里程碑时间点延后，导致项目的进度表一下松 弛了许多。笔者参加过的两个项目就遇见过这种情况，我们为世界某著名品牌电脑供应商开发并 提供随机软件。在项目进展到中后期时，客户忽然通知我们暂时不安排我们的软件在他们这一版 本系统中进行安装，要等到下一版本，时间延迟可能长达三个月，甚至更多。 注：以上五个方面不可能将所有软件测试中潜在的风险全部罗列，旨在给出思维方式。 2. 采用 FMEA 评估及分析风险项 在采用 FMEA 对风险进行评估和分析前，有