你是唯一能做到生产出无缺陷程序的人.pptVIP

* * * * * * * * * * * * 三、基于测试流程上的缺陷管理系统 缺陷的定义 软件没有达到产品说明书表明的功能 软件出现了产品说明书中不一致的表现 软件功能超出产品说明书的范围 软件没有达到用户期望的目标(虽然产品说明书中没有要求) 测试员或用户认为软件的易用性差 不是所有缺陷都会修改 市场的压力使得产品最终发行有时间限制 测试员错误理解或者不正确操作引出的缺陷(FAQ) 错误的修改影响的模块较多，带来的风险较大（遗留） 修改性价比太低(FAQ，遗留） 缺陷报告中提出的问题很难重现 3.1 缺陷报告管理系统 是测试流程在工具上的固化 通过权限控制来实现流程监控 记录了缺陷识别到关闭过程中的所有数 记录了版本变更的信息 是开发和测试之间沟通的信息平台 实时的数据和信息的更新 度量和统计分析，为改进产品提供依据 采用Lotus Notes作为bug管理平台 完全电子化的信息传递 统一管理和备份 具备数据统计和查询功能 能够进行个性化二次开发 方正测试缺陷跟踪与管理系统 3.1.1 系统测试缺陷处理流程 新建表单 待测试提交 待指定处理人 正在处理 返回处理 待开发提交 待返测 待归档 已归档 个人提交 退回 测试提交 指定处理人 重新指定 处理完毕 返测完毕 归档 重新返测 退回 提交版本更新说明 Bug报告准则 如何重现错误-使用最少步骤重现 现象描述没有歧义 尽量简单-一个bug一个报告 可以提出对错误的解决建议 开发人员拒绝修改的bug 程序员无法重现或者现象难以捕捉 没有明确的报告以说明重现bug的步骤 程序员无法读懂的bug报告 用户很少使用或者不符合用户使用习惯的操作出错 由不受信任的测试人员提出 缺陷报告 3.1.2 集成测试缺陷处理流程 新建表单 待指定处理人 正在处理 待返测 待归档 已归档 返回处理 测试提交 指定处理人 重新指定 处理完毕 返测完毕 归档 重新返测 退回 4.1 缺陷分析的关注点： 1、对软件问题的功能域分布进行分析，找出系统的薄弱环节 要详细采集每个功能模块或系统构件的bug数据，并按功能、错误类型、严重程度等分类 比较实际发现的软件bug是否与预期的问题分布相吻合 二八定理：80%的软件问题总是发生在大约20%的功能模块（系统构件）中。 缺陷分析的关注点 2、对bug的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集bug的数据 要求软件各开发阶段的缺陷密度小于本单位过去的平均值 而且要求需求分析、设计和代码复查阶段的缺陷排除率之和大于或等于规定值（例如75%）。（同行评审） 缺陷分析的关注点 3、应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。 可参考PSP中缺陷类型标准（如下表），其中缺陷类型是按照问题的复杂度来排列的，类型10到40是比较简单的编码缺陷，类型50到100是比较复杂的设计缺陷。 类型编号 类型名称 描 述 10 文档 注释，消息 20 句法 拼写，标点，打字，指令格式 30 联编，打包 理改管理，库，版本控制 40 分配 说明，重名，作用域，限制 50 接口 过程调用和引用，输入/输出，用户格式 60 检查 出错信息，不恰当的检查 70 数据 结构，内容 80 函数 逻辑，指针，循环，递归，计算，函数缺陷 90 系统 配置，记时，内存 100 环境 设计，编译，测试，或其它支持系统问题 缺陷分析的关注点 4、应动态采集每个测试周期中发现的bug数，并有效地控制缺陷的修复率。 5、应密切观察bug的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况 缺陷分析的关注点 6、应该采集bug不同方式的修复数据，以便检验软件产品是否满足交付规则 分析修改代码、改变设计、封掉功能遗留以及下一版本解决的bug数约占缺陷总数的比例。 在有严密和有效的质量保证体系条件的监控下，常常会引起有较高比例的延期解决的缺陷数，这是因为许多细微的或枝节性的问题被测试出来，经过评价证明不会造成大的质量影响，但可为产品进一步升级提供有价值的参考。 4.2 测试人员的绩效评价 评价标准： 1、bug数量： 同一个项目组内，提交bug数量的多少是衡量测试人员工作效率的一方面；另一个衡量指标是每人日提交的bug数。 2、bug严重程度： Bug的严重程度是衡量bug的质量的一个重要因素，好的bug应该是极端严重的，对系统造成极大危害的。 3、bug价值： Bug的双方面评判，对于bug的价值开发人员在另外一个角度上进行评判 以上三个因素的加权平均才能更有效的评价测试人员的绩效！ 4.3 缺陷统计分析工具介绍 测试结果分析和评价 缺陷密度: 基本的缺陷