测试风险控制规程

测试风险控制规程

2011年08月13日

修改历史

日期版本作者修改内容更改请求号2011-8-13 V0.1 张梅娜创建

“更改请求号”为文档正式发布后需要变更时的编号，编号方法待定。

正式批准

角色签名日期备注

目录

测试风险控制规程 (1)

1. 目的 (4)

2. 范围 (4)

3. 参考资料 (4)

4. 测试风险概述 (4)

5. 测试风险划分及构成 (4)

5.1 测试风险分类 (4)

5.1.1 按照软件开发阶段分类 (4)

5.1.2 按照测试生命周期分类 (5)

5.2 测试风险优先级划分 (6)

5.3 测试风险构成 (6)

5.3.1 测试风险基本构成图 (6)

5.3.2 测试风险构成分析 (6)

6. 测试风险控制 (9)

6.1 测试风险分析控制流程 (9)

6.2 测试风险控制原则 (9)

6.2.1 可控测试风险的控制原则 (9)

6.2.2 不可控测试风险的控制原则 (10)

1.目的

本文是针对于本公司测试事业部的软件测试过程中对于测试风险进行控制的指导性文件，对软件测试整个生命周期中所涉及到的测试风险进行划分及实施相应风险避规，以有效保证软件质量。

2.范围

本文适用于本公司测试事业部内的所有测试负责人在进行项目测试或产品测试中的相关测试管理工作。

3.参考资料

《测试计划》

《性能测试计划》

《变更请求规程》

《缺陷监控及管理过程指导规范》

《测试评估指导规范》

《测试实施规程》

4.测试风险概述

作为测试计划的一部分，测试风险的分析与避规是其中重要的环节。如果前期测试风险分析与控制比较充分，那么会使测试成功率大大增加，而且可以将因风险而引发的额外成本（如人力，时间等）降到最低。

5.测试风险划分及构成

5.1 测试风险分类

5.1.1按照软件开发阶段分类

按照软件开发阶段划分，测试风险分类如下：

按照软件生命周期划分

软件生命周期 测试风险分类 优先级 需求阶段 需求风险 非常高

设计阶段 架构风险 非常高

编码阶段 开发风险 非常高 代码编写质量 非常高 配置风险 较高

测试阶段 业务流程风险 非常高 环境风险 非常高 需求变更风险 非常高 人员风险 较高 配置风险 非常高 测试方法风险 非常高 缺陷维护风险 非常高 其他风险 高

验收阶段 验收文档风险 较高 环境风险 较高

5.1.2按照测试生命周期分类

按照测试生命周期段划分，测试风险分类如下：

按照测试生命周期划分

软件生命周期 测试风险分类 优先级

测试分析阶段 需求风险 非常高

测试计划阶段 时间进度风险 非常高 测试团队风险 非常高 测试策略风险 高

测试设计阶段 测试点覆盖风险 非常高 测试设计方法风险 较高

测试执行阶段 代码编写质量 非常高 需求变更风险 非常高 配置风险 较高 业务流程操作风险 非常高 接口操作风险 较高 环境风险 非常高 人员稳定性风险 较高 测试专业技术风险 非常高 缺陷维护风险 非常高 故障异常风险 非常高 其他风险 高

测试收尾阶段 需求变更风险 非常高 其他风险 高

5.2 测试风险优先级划分

确定风险的优先级一般常使用定性风险评估法和定量风险评估法,以确定风险影响程度的高低.

¾定量风险评估法

在定量风险评估中，所评估的内容是在风险评估与成本效益分析期间收集的各个组成部分计算的客观数字值。例如通过因测试人员减少带来的任务压力、测试质量不高所造成的生产损失、测试延期所造成的成本输出以及其他直接和间接商业价值等来估计各个测试资产的真实价值。相对造成的损失越大风险越高。

¾定性风险评估法

定性风险评估与定量风险评估的区别在于在定性风险评估法中不用向资产分配难以确定的预期损失和控制成本，取而代之的是计算相对值。例如在测试项目中需求的不明确将造成后期测试不准确或是覆盖不完整，以至于造成进度拖延等情况，这时需求分析的准确度就是影响测试进度以及项目进度的最大风险。

其影响越深造成损失越大风险也就越高。

5.3 测试风险构成

5.3.1测试风险基本构成图

5.3.2测试风险构成分析

测试风险的构成内容不可能将所有软件测试中潜在的风险全部列举出来，在本规程汇总旨在给出风险分析的思

维方式。

5.2.2.1 开发

开发即是开发风险。主要影响测试的开发风险如下：

¾程序架构：程序架构不合理以及程序架构频繁变更。

¾编码质量：编码质量不高，每个开发人员都有自己的一套编码模式。

¾开发进度：开发进度较缓慢，导致后期测试时间压缩。

5.2.2.2 资料

资料即是测试相关输入的文档资料。主要存在影响测试的资料方面风险如下：

¾文档缺失：部分应该输入测试的文档不具备。例如原始需求、详细设计说明书、概要设计说明书等。

¾需求变更：需求变更在所有软件生命周期中都是频繁出现，往往影响了测试进度。

¾需求分析不准确：因需求分析前期需求获取不准确或其他因素导致需求分析的不准确。

¾设计不充分：有时候由于编写文档人员的个人因素或是时间限制等方面原因导致输入测试文档设计的不充分和不完整，遗漏了一些重要内容。

¾质量标准不统一：文档和测试过程中的质量标准没有统一的标准，导致测试人员和开发人员认识不同。

¾文档质量问题：输入测试的文档内容含糊、表述不清，以及内容不完整。该问题将影响测试质量和初期测试设计质量。

5.2.2.3 人员

人员即是指测试人员。主要存在影响测试的人员方面风险如下：

¾疲劳测试：一般出现在两个方面，a、测试人员长时间不休息或只短暂的进行反复测试，特别是通宵测试导致测试人员过度疲劳；b、某个功能点一直由同一个测试人员测试，经过多次回归测试之后，测试人员对该功能点的测试显示出倦意和缺乏兴趣。

¾思想同化效应：测试人员在经过同开发人员长期接触，往往会被开发人员的思维逻辑同化，渐渐丧失从用户角度出发的测试观点，且无法很好的运用测试思想进行工作。

¾专业技术能力：测试人员专业技术能力不高。

¾业务流程熟悉度：测试人员对被测系统的业务流程不熟悉，体现在对需求的理解上把握不准、理解不透彻、理解错误等方面。

¾稳定性：这里的稳定性是指测试人员的稳定性，测试团队人员的离职、岗位调动等情况都会在一定程度上影响测试进度。

¾功能定位效应：功能定位效应是指测试人员对测试过的可靠的功能，特别是在多次回归且没有发现问题，在此后往往会认为此功能是可靠的，而忽略需求变更或是其他问题引起的功能稳定。

¾测试团队人员到位：测试团队人员无法按照预期时间到位。

5.2.2.4 时间

时间主要指的是测试时间，主要存在影响测试的测试时间风险如下：

¾项目进度停滞：项目初期进度因某种原因停滞，后期导致测试进度压缩和测试工作量的增大。

¾测试时间不足：项目中里程碑之间留给测试的时间无法满足全程测试要求

¾时间点延长：由于客户(需求方)突然宣布原进度表中的里程碑时间点延后，导致项目的进度表松弛。