缺陷处理流程.ppt

三 基于测试流程上的缺陷管理系统 缺陷的定义软件没有达到产品说明书表明的功能软件出现了产品说明书中不一致的表现软件功能超出产品说明书的范围软件没有达到用户期望的目标 虽然产品说明书中没有要求 测试员或用户认为软件的易用性差不是所有缺陷都会修改市场的压力使得产品最终发行有时间限制测试员错误理解或者不正确操作引出的缺陷 FAQ 错误的修改影响的模块较多 带来的风险较大 遗留 修改性价比太低 FAQ 遗留 缺陷报告中提出的问题很难重现 FounderR D 3 1缺陷报告管理系统 是测试流程在工具上的固化通过权限控制来实现流程监控记录了缺陷识别到关闭过程中的所有数记录了版本变更的信息是开发和测试之间沟通的信息平台实时的数据和信息的更新度量和统计分析 为改进产品提供依据 FounderR D FounderR D 采用LotusNotes作为bug管理平台完全电子化的信息传递统一管理和备份 具备数据统计和查询功能能够进行个性化二次开发 方正测试缺陷跟踪与管理系统 3 1 1系统测试缺陷处理流程 FounderR D Bug报告准则如何重现错误 使用最少步骤重现现象描述没有歧义尽量简单 一个bug一个报告可以提出对错误的解决建议开发人员拒绝修改的bug程序员无法重现或者现象难以捕捉没有明确的报告以说明重现bug的步骤程序员无法读懂的bug报告用户很少使用或者不符合用户使用习惯的操作出错由不受信任的测试人员提出 缺陷报告 FounderR D 3 1 2集成测试缺陷处理流程 FounderR D 4 1缺陷分析的关注点 1 对软件问题的功能域分布进行分析 找出系统的薄弱环节要详细采集每个功能模块或系统构件的bug数据 并按功能 错误类型 严重程度等分类比较实际发现的软件bug是否与预期的问题分布相吻合二八定理 80 的软件问题总是发生在大约20 的功能模块 系统构件 中 FounderR D 缺陷分析的关注点 2 对bug的注入阶段的分布进行分析 并与历史数据相比较 应按不同的开发阶段详细采集bug的数据要求软件各开发阶段的缺陷密度小于本单位过去的平均值而且要求需求分析 设计和代码复查阶段的缺陷排除率之和大于或等于规定值 例如75 同行评审 FounderR D FounderR D 缺陷分析的关注点 3 应对软件缺陷类型进行分析 以便针对各自的特点 先修复严重缺陷 可参考PSP中缺陷类型标准 如下表 其中缺陷类型是按照问题的复杂度来排列的 类型10到40是比较简单的编码缺陷 类型50到100是比较复杂的设计缺陷 缺陷分析的关注点 4 应动态采集每个测试周期中发现的bug数 并有效地控制缺陷的修复率 5 应密切观察bug的状态 并及时跟踪其状态的变化 以检查测试和开发人员的工作情况 FounderR D 缺陷分析的关注点 6 应该采集bug不同方式的修复数据 以便检验软件产品是否满足交付规则分析修改代码 改变设计 封掉功能遗留以及下一版本解决的bug数约占缺陷总数的比例 在有严密和有效的质量保证体系条件的监控下 常常会引起有较高比例的延期解决的缺陷数 这是因为许多细微的或枝节性的问题被测试出来 经过评价证明不会造成大的质量影响 但可为产品进一步升级提供有价值的参考 FounderR D 4 2测试人员的绩效评价 评价标准 1 bug数量 同一个项目组内 提交bug数量的多少是衡量测试人员工作效率的一方面 另一个衡量指标是每人日提交的bug数 2 bug严重程度 Bug的严重程度是衡量bug的质量的一个重要因素 好的bug应该是极端严重的 对系统造成极大危害的 3 bug价值 Bug的双方面评判 对于bug的价值开发人员在另外一个角度上进行评判以上三个因素的加权平均才能更有效的评价测试人员的绩效 FounderR D 4 3缺陷统计分析工具介绍 FounderR D 测试结果分析和评价 缺陷密度 基本的缺陷测量是以每千行代码的缺陷数 Defects KLOC 来测量的 称为缺陷密度 Dd 其测量单位是defects KLOC 可按照以下步骤来计算一个程序的缺陷密度 累计开发过程中每个阶段发现的缺陷总数 D 统计程序中新开发的和修改的代码行数 N 计算每千行的缺陷数Dd 1000 D N 例如 一个29 6万行的源程序总共有145个缺陷 则缺陷密度是 Dd 1000 145 296000 0 49defects KLOC 在计算缺陷密度时 最重要的是要使用正确的规模测量 FounderR D 测试结果的分析和评价 输出 测试综合报告 测试过程的总结测试数据分析 按照严重程度等方式分类统计的分析 包括测试密度等 产品主要问题和总体评价遗留的问题总结最终的测试结论 FounderR D 测试结果分析和评价 为了了解和控制缺陷带来的费用 很有必要测量缺陷排除的效果测量 一种测量方法是计算每小时排除缺陷的个数 一种是计算缺陷排除效益 即测量通过某一排除方法所发现的缺陷的百分比 缺陷排除效益是45 100个缺陷 开始测试 测试 发现45个缺陷 missing55defects FounderR D 测试结果分析和评价 测试覆盖率测量语句覆盖率测试经历语句数 总语句数分支覆盖率测试经历支路数 总支路数简单路径覆盖率测试经历简单路径数 总简单路径数功能覆盖率界面数菜单数输入 输出的数据元数构件 模块 FounderR D 4 5软件测试经验分享 所有的测试都应追溯到需求 因最严重的错误是导致程序无发满足需求的错误 软件开发人员和管理人员首先应该尽早地和不断地进行各种软件质量保证活动 如需求和设计阶段同行评审和走查等 软件开发人员应避免检查自已的程序 利用同行评审的方式对代码进行审查 自己检查容易依照原有的程序设计思路进行 往往查不出问题 在设计测试用例时 必须明确预期的输出结果 否则对实际的输出结果很难有检验的标准 测试失去意义 测试用例应由输入数据和与之对应的期望输出结果这两部分组成 在输入数据中 应当包括合理的输入条件和不合理的输入条件 在进行各种分析和修复工作中 要充分注意修复工作所产生的影响效果和波及效果 FounderR D 软件测试经验分享 统计表明大约有60 的错误是在设计阶段之前注入的 并且修正一个软件错误所需的费用将随着软件生存期的进展而上升 错误发现得越晚 修复它的费用就越高 而且呈指数增长的趋势 测试后程序中残存的错误数目与该程序中已发现的错误数目 即检错率 很可能成正比 编码规范 需求理解 技术能力 内部耦合性是引起这些现象的原因 程序中的大部分错误往往是在一小部分模块中发现的 遵循普遍适用的 二八定理 即80 的错误往往是由20 的模块所造成的 例如 IBM公司的OS 370操作系统中 47 的错误仅与该系统中的4 的程序模块有关 要严格执行测试计划 排除测试的随意性 这样才能消除各种无序操作所造成的副作用 测试设计决定了测试的有效性和效率 测试工具只能提高测试效率应当对每一个测试结果做全面的检查 这样才有可能找到真正的出错原因 为今后的调试工作奠定基础 FounderR D 结束语 产品越复杂 测试花费的时间就越长 费用就越大 测试发现缺陷的效率也就越低 缺陷会掩盖或加重其它缺陷 也就是说 当一个程序有许多缺陷时 由于缺陷相互作用 使得发现和修复缺陷的过程更加复杂 这使得一些缺陷很难查找和修复 一个缺陷可能掩盖其它缺陷 使得这些被掩盖的