《测试风险控制规程》由会员分享,可在线阅读,更多相关《测试风险控制规程(10页珍藏版)》请在金锄头文库上搜索。
1、 测试风险控制规程测试风险控制规程 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
2、按照软件开发阶段分类 . 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. 目的目的 本文是针对于本公司 测试事业部的软件测试过程中对于测试风险进行控制的指导性文件,对软 件测试整个生
3、命周期中所涉及到的测试风险进行划分及实施相应风险避规,以有效保证软件质量。 2. 范围范围 本文适用于本公司 测试事业部内的所有测试负责人在进行项目测试或产品测试中的相关测试管 理工作。 3. 参考资料参考资料 测试计划 性能测试计划 变更请求规程 缺陷监控及管理过程指导规范 测试评估指导规范 测试实施规程 4. 测试风险概述测试风险概述 作为测试计划的一部分,测试风险的分析与避规是其中重要的环节。如果前期测试风险分析与 控制比较充分,那么会使测试成功率大大增加,而且可以将因风险而引发的额外成本(如人力,时 间等)降到最低。 5. 测试风险划分及构成测试风险划分及构成 5.1 测试风险分类测试
4、风险分类 5.1.1 按照软件开发阶段分类按照软件开发阶段分类 按照软件开发阶段划分,测试风险分类如下: 按照软件生命周期划分 按照软件生命周期划分 软件生命周期 软件生命周期 测试风险分类 测试风险分类 优先级 优先级 需求阶段 需求风险 非常高 设计阶段 架构风险 非常高 编码阶段 开发风险 非常高 代码编写质量 非常高 配置风险 较高 测试阶段 业务流程风险 非常高 环境风险 非常高 需求变更风险 非常高 人员风险 较高 配置风险 非常高 测试方法风险 非常高 缺陷维护风险 非常高 其他风险 高 验收阶段 验收文档风险 较高 环境风险 较高 5.1.2 按照测试生命周期分类按照测试生命周
5、期分类 按照测试生命周期段划分,测试风险分类如下: 按照测试生命周期划分 按照测试生命周期划分 软件生命周期 软件生命周期 测试风险分类 测试风险分类 优先级 优先级 测试分析阶段 需求风险 非常高 测试计划阶段 时间进度风险 非常高 测试团队风险 非常高 测试策略风险 高 测试设计阶段 测试点覆盖风险 非常高 测试设计方法风险 较高 测试执行阶段 代码编写质量 非常高 需求变更风险 非常高 配置风险 较高 业务流程操作风险 非常高 接口操作风险 较高 环境风险 非常高 人员稳定性风险 较高 测试专业技术风险 非常高 缺陷维护风险 非常高 故障异常风险 非常高 其他风险 高 测试收尾阶段 需求
6、变更风险 非常高 其他风险 高 5.2 测试风险优先级划分测试风险优先级划分 确定风险的优先级一般常使用定性风险评估法和定量风险评估法,以确定风险影响程度的高低. ? 定量风险评估法 在定量风险评估中,所评估的内容是在风险评估与成本效益分析期间收集的各个组成部分计算的客 观数字值。例如通过因测试人员减少带来的任务压力、测试质量不高所造成的生产损失、测试延期所造成 的成本输出以及其他直接和间接商业价值等来估计各个测试资产的真实价值。 相对造成的损失越大风险越 高。 ? 定性风险评估法 定性风险评估与定量风险评估的区别在于在定性风险评估法中不用向资产分配难以确定的预期损失 和控制成本,取而代之的是
7、计算相对值。例如在测试项目中需求的不明确将造成后期测试不准确或是覆盖 不完整, 以至于造成进度拖延等情况, 这时需求分析的准确度就是影响测试进度以及项目进度的最大风险。 其影响越深造成损失越大风险也就越高。 5.3 测试风险构成测试风险构成 5.3.1 测试风险基本构成图测试风险基本构成图 5.3.2 测试风险构成分析测试风险构成分析 测试风险的构成内容不可能将所有软件测试中潜在的风险全部列举出来, 在本规程汇总旨在给出风险分析的思 维方式。 5.2.2.1 开发开发 开发即是开发风险。主要影响测试的开发风险如下: ? 程序架构:程序架构不合理以及程序架构频繁变更。 ? 编码质量:编码质量不高
8、,每个开发人员都有自己的一套编码模式。 ? 开发进度:开发进度较缓慢,导致后期测试时间压缩。 5.2.2.2 资料资料 资料即是测试相关输入的文档资料。主要存在影响测试的资料方面风险如下: ? 文档缺失: 部分应该输入测试的文档不具备。例如原始需求、详细设计说明书、概要设计说明书等。 ? 需求变更: 需求变更在所有软件生命周期中都是频繁出现,往往影响了测试进度。 ? 需求分析不准确:因需求分析前期需求获取不准确或其他因素导致需求分析的不准确。 ? 设计不充分:有时候由于编写文档人员的个人因素或是时间限制等方面原因导致输入测试文档设计的不 充分和不完整,遗漏了一些重要内容。 ? 质量标准不统一:
9、 文档和测试过程中的质量标准没有统一的标准,导致测试人员和开发人员认识不同。 ? 文档质量问题:输入测试的文档内容含糊、表述不清,以及内容不完整。该问题将影响测试质量和初期 测试设计质量。 5.2.2.3 人员人员 人员即是指测试人员。主要存在影响测试的人员方面风险如下: ? 疲劳测试:一般出现在两个方面,a、测试人员长时间不休息或只短暂的进行反复测试,特别是通宵测试 导致测试人员过度疲劳;b、某个功能点一直由同一个测试人员测试,经过多次回归测试之后,测试人员 对该功能点的测试显示出倦意和缺乏兴趣。 ? 思想同化效应:测试人员在经过同开发人员长期接触,往往会被开发人员的思维逻辑同化,渐渐丧失从
10、用 户角度出发的测试观点, 且无法很好的运用测试思想进行工作。 ? 专业技术能力:测试人员专业技术能力不高。 ? 业务流程熟悉度: 测试人员对被测系统的业务流程不熟悉, 体现在对需求的理解上把握不准、 理解不透彻、 理解错误等方面。 ? 稳定性:这里的稳定性是指测试人员的稳定性,测试团队人员的离职、岗位调动等情况都会在一定程度上 影响测试进度。 ? 功能定位效应:功能定位效应是指测试人员对测试过的可靠的功能,特别是在多次回归且没有发现问题, 在此后往往会认为此功能是可靠的,而忽略需求变更或是其他问题引起的功能稳定。 ? 测试团队人员到位:测试团队人员无法按照预期时间到位。 5.2.2.4 时间
11、时间 时间主要指的是测试时间,主要存在影响测试的测试时间风险如下: ? 项目进度停滞:项目初期进度因某种原因停滞,后期导致测试进度压缩和测试工作量的增大。 ? 测试时间不足:项目中里程碑之间留给测试的时间无法满足全程测试要求 ? 时间点延长:由于客户(需求方)突然宣布原进度表中的里程碑时间点延后,导致项目的进度表松弛。 5.2.2.5 环境环境 环境主要指的是测试环境,主要存在影响测试的测试环境风险如下: ? 测试环境硬件未及时到位:测试环境所需要的硬件设施未及时到位。 ? 测试环境硬件问题:测试环境和开发环境、生产环境的设备配置不一致,如 CPU 频率,内存大小等。导 致测试准确性降低。 ?
12、 测试环境软件问题:测试环境和开发环境、生产环境的软件版本不一致,如操作系统类型、操作系统干 净程度等。导致测试准确性降低。 ? 环境接口问题:测试环境配置接口错误。 ? 兼容性问题:测试环境中软硬件不兼容。 ? 程序版本不一致:程序版本导致测试不准确,有多种原因造成包括开发没有提交最新程序版本、测试环 境没有及时更新配置最新的程序版本等问题。 5.2.2.6 方法方法 方法主要指的是测试过程中所使用的测试方法,主要存在影响测试的测试方法风险如下: ? 测试用例设计问题:因对需求没有进行完整的测试分析导致测试用例设计不能完整覆盖需求。且因测试 方法使用不得当或方法缺失导致测试用例不完整。 ?
13、测试用例执行不充分:因测试进度原因或是回归测试原因导致测试用例执行不充分。 ? 场景缺失或部分缺失:因关注点主要放在功能测试上而导致忽略了业务场景测试,或是导致部分业务场 景的缺失。 ? 测试方法错误、不得当或缺失:对功能点没有采用正确的测试方法进行分析,或者某些测试方法被忽视 掉,如边界测试、错误推测法等,从而导致测试不充分。 ? 测试数据准备问题:测试过程中测试数据准备不完整,或是测试数据没有依照业务流程进行准备而导致 测试数据不准确。 6. 测试风险控制测试风险控制 6.1 测试风险分析控制流程测试风险分析控制流程 6.2 测试风险控制原则测试风险控制原则 测试风险是不可避免的、总是存在
14、的,因此对测试风险的管理和控制非常重要,必须尽力降低测试中所存在 的风险,最大程度地保证质量和满足客户的需求。测试风险可分为可控和不可控两种。对于可控的测试风险可以 直接避免,对于不可控的风险需要尽量将风险降到最低。 测试风险要尽早预测和估计,不要等风险出现的事后才采取相关措施。 6.2.1 可控测试风险的控制原则可控测试风险的控制原则 针对可控的测试风险可以适时采取相关的有效测试风险控制方法,具体如下: ? 测试环境:在测试环境配置前将所有相关的环境检查进行列表核对,在测试环境配置完毕后,由指定人 员按已列出环境检查内容逐一检查; ? 测试方法:测试负责人需要有良好的测试技术基础和一定的实践
15、经验,在能很好的把控测试计划和测试 策略的同时能够对测试人员进行测试技能培训,能够从根本上解决测试方法问题; ? 需求变更:适时对需求变更进行跟踪,并及时同项目经理、需求分析师进行沟通。以确认最新的需求进 行适当测试调整。 ? 测试质量保证:依照测试生命周期过程,在每个里程碑组织相关评审,对整个过程进行监控。 6.2.2 不可控测试风险的控制原则不可控测试风险的控制原则 有些风险不可避免,就需要设法降低风险,例如“程序中未发现的缺陷”这种风险总是存在,我们就要通过提 高测试用例的覆盖率(如达到 90%)以降低这种风险; 为了避免、转移或降低风险,事先要做好风险管理计划和控制风险的策略,并对风险
16、的处理还要制定一些应 急的、有效的处理方案。针对于一些不可控的测试风险主要的控制方法如下: ? 资源、时间、成本的控制措施:做资源、时间、成本等估算时,要留有一定余地,不要过度饱和; ? 人员流动的控制措施:对每个关键的测试工程师培养后备人员,做好测试人员流动的准备,采取适当措 施确保人员一旦离开公司,其所在项目的测试工作不会受到严重影响,仍然能可以正常有序的开展; ? 文档质量的控制措施:制定文档标准,并建立相应可行的管理机制和变更措施,以保证文档及时产生和 适时变更; ? 风险跟踪:对软件生命周期的所有过程进行日常跟踪,及时发现影响测试风险所显现的各种征兆,采取 适当措施避免风险。 ? 风险预测:项目开始前,把一些环节或边界上的可能会有变化、难以控制的因素列入测试计划中的风险 管理;并针对测试的各种风险,建立一种“防患于未然”或“以预防为主”的管理意识。 ? 其他措施:对测试生命周期中的所有工作多进行互审,以便能够及时发现问题并解决问题,包括对不同 的测试人员在不同的测试模块上相互调换;