缺陷管理
缺陷管理的基本概念
容易混淆的几个概念
- 失误：导致软件包含故障的人的行为。
- 缺陷：软件的异常情况。在软件自身。
- 故障：引起一个功能组件不能完成所要求的功能的一种意外情况。
- 失效：功能组件执行其规定功能的能力丧失。
缺陷的定义
缺陷（Defect），常常又叫做Bug。
计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。
从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题。
冲产品外部看，缺陷是产品所需要实现的某种功能的失效或违背。
缺陷产生的原因
- 产品说明书不全、不完整和不准确，修改频繁，沟通不畅和理解不同。
- 软件设计过程中考虑不周到，片面，多变，理解和沟通不足。
- 文档不足，压时间，赶进度，设计和编码错误都会引入缺陷。
- 测试和实施过程中安装环境配置错误等。
缺陷的评价标准
- 软件未实现需求规格说明书（SRS）要求的功能。
- 软件未实现需求规格说明书（SRS）虽未明确提及但应该实现的目标。
- 软件出现了需求规格说明书（SRS）指明不应该出现的错误。
- 软件实现了需求规格说明书（SRS）未提到的功能。
- 软件难以理解、不易使用、运行缓慢，或者从测试工程师的角度来看——最终用户会认为不好。
缺陷的属性
缺陷报告的相关属性
缺陷ID、标题、产生的步骤、所属模块、发现人、发现的时间、严重程度、优先级、类型、状态、可再现性、发现阶段、负责人、所属版本、修改日期、引入原因、备注信息、相关附件
缺陷类型
- 遗漏（Missing）
- 错误（Error）
- 额外的实现（Extra）
- 改进（Enhancement）
优先级的划分
| 序号 | 缺陷优先级 | 描述 |
|---|---|---|
| 1 | 紧急 | 缺陷导致系统几乎不能使用或测试不能继续，需立即修复。 |
| 2 | 高 | 缺陷严重，影响测试，需要优先考虑。 |
| 3 | 中 | 缺陷按正常排队等待修复。 |
| 4 | 低 | 缺陷可以在开发人员有时间的时候修改。 |
严重程度划分
| 严重级别 | 严重等级 | 描述 |
|---|---|---|
| 1-致命 | 致命缺陷 | 系统任何一个主要功能完全丧失，用户数据收到破坏，系统崩溃、悬挂、死机或者危及人身安全 |
| 2-严重 | 严重缺陷 | 系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务收到明显的影响，不能执行正常工作功能或实现重要功能。包括：1）可能有灾难性的后果，如造成系统奔溃，造成事故等；2）数据库错误，如数据丢失等。 |
| 3-重要 | 较大缺陷 | 产生错误的结果，导致系统不稳定，运行时好时坏，严重影响系统要求或基本功能实现的问题，例如：1）造成数据库不稳定的错误；2）在说明中的需求未在最终系统中实现；3）程序无法运行，系统以外退出；4）业务流程不正确 |
| 4-一般 | 一般缺陷 | 系统的次要功能没有完全实现，但不影响系统的正常使用，不会影响系统的稳定性。1）提示信息不太准确或用户界面差、操作时间长等问题；2）过程调用或其他脚本错误；3）系统刷新错误；4）产生错误结果，如计算结果，数据不一致等；5）功能的实现有问题；6）编码时数据类型、长度定义错误；7）虽然正确性、功能不受影响，但是系统性能和响应时间受影响。 |
| 5-较小 | 轻微缺陷 | 使操作者不方便或遇到麻烦，但它不影响操作和执行，重点指系统的UI问题。 |
| 6-改进 | 其他缺陷 | 系统中值得改良的问题。 |
缺陷跟踪的交付物
缺陷报告单，也叫缺陷跟踪单。用于提供给开发人员或其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。
缺陷的生命周期
Bug的生命周期
指缺陷从提出到最后完全解决，并通过验证和确认的过程。
状态说明
- 新建：测试人员提交新问题标识的状态。
- 打开：已经确认为是Bug的状态。
- 已修复：开发人员修改后的状态，等待测试验证。
- 重新打开：没有通过重新测试后或重新测试后又发现新问题的状态。
- 已关闭：通过重新测试后的状态。
- 拒绝：开发人员认为不是bug、描述不清、重复，从而拒绝的问题。
- 重复：表示该bug已经被其他测试人员找出来了，或开发认为原因是相同的。
- 延期：由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决或留待后续版本解决的问题。
缺陷报告的书写
缺陷报告单书写准则（5C）
- 准确（Correct）：每个组成部分的描述准确，不会引起误解
- 清晰（Clear）：每个组成部分描述清晰，易于理解
- 简洁（Concise）：质保函必不可少的信息，不包括任何多余内容
- 完整（Complete）：包含复现该缺陷的完整步骤和其他本质信息
- 一致（Consistent）：按照一致的格式书写全部缺陷报告
缺陷报告的写作要点
- 再现：一般是尽量三次再现故障，如果问题是间断的，那要报告问题发生频率。
- 初步定为：可能影响再现的变量，例如配置变化、工作流、数据库，这些都可能改变错误的特征。
- 推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据时是否存在这种问题等，特别是那些可能存在更加严重特征的部分。
- 压缩：精简任何不必要的信息，特别是冗余的测试步骤。
- 去除歧义：使用清晰的语言，尤其是避免使用那些有多个不同或相反含义的词汇。
- 中立：公正的表达自己的意思，对错误及其特征的事实进行陈述，避免夸张、幽默或讽刺。
- 评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在递交错误报告之前自己先阅读一遍。
常用的管理工具
缺陷管理的目的
- 保证信息的一致性。
- 保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效。
- 利于缺陷分析、产品度量，使项目情况可视化加强。
版权声明：本文为sd517125原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接和本声明。