跟踪 Bug

  • 项目

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

运行测试来验证要求时，肯定会发现 bug。 使用 bug 工作项描述和跟踪找到的每个 bug 的进度。

Bug for CMMI project (work item form)

有关如何创建 bug 工作项的详细信息，请参阅 “运行手动测试”。 发现 bug 时，请按照本文中的过程确定其优先级，确保它们得到修复，并确保你有工作记录和所涉及的决策。

会审 Bug

在项目开始开发工作和测试后，应按设置间隔举行会审会议。 你召开会议的频率以及他们应该多久取决于你的情况。

通常，bug 会审会议由项目经理运行，由团队主管以及业务分析师和利益干系人参与，他们可以谈论特定的项目风险。 项目经理可以使用活动 Bug 查询来查询新的和重新打开的 bug，以生成要会审的 bug 列表。

在会审开始之前，请设计一组条件来确定应修复哪些 bug 以及优先级。 条件通常会确定 bug 的严重性、与重要价值特征相关的 bug (或延迟) 或其他项目风险的重大机会成本。

会审条件应存储在项目的 Documents 文件夹中。 随着时间的推移，文档将更新。 假定项目启用了版本控制，并且项目上任何给定时间使用的特定条件都可以检索到审核和评估证据目的。

在项目早期，你可能会决定修复你会审的大部分 bug。 但是，随着项目继续进行，可能会引发 (或条形) 的会审条件，以减少修复的 bug 数。

提高会审条件栏并允许报告 bug 保持未固定状态是一种权衡。 这是一个权衡，说修复 bug 比满足项目范围、预算和计划更重要。

使用条件确定要修复的 bug 以及如何设置其状态、优先级、严重性和其他字段。 默认情况下，模板提供四个优先级：1 用于“必须修复”到 4，用于“不重要”。如果更改流程模板中的定义，则应相应地更新指南、帮助文本和任何条件文档。

修复 Bug

Bug 通过会审并已确定优先级后，应将其分配给开发人员进行其他调查。

bug 工作项有一个用于重现步骤的选项卡，该选项卡应提供重现 bug 所需的内容。 但是，还可以使用 IntelliTrace 帮助重现困难 bug。 有关 IntelliTrace 的详细信息，请参阅 跟踪测试结果。

开发人员决定一个操作过程后，他们应该在 bug 工作项中记下他们的决定。

确定修补程序

与其他团队成员合作，开发人员可能会建议一个修补程序，该修补程序对代码的其他部分具有影响，并且可能需要进行显著的回归测试。 与评估此类修复风险相关的任何对话都应记录在 bug 工作项历史记录中，因为它记录了用于审核或标准 CMMI 评估方法的审核或标准 CMMI 评估方法的有用决策分析和风险管理证据， (SCAMPI) 评估。 有关 CMMI 的详细信息，请参阅 CMMI 的背景。

更新并运行单元测试以修复 Bug

单元测试将验证代码单元的正确实现。 编写和执行单元测试能在测试开始前标识 Bug，因此可以帮助降低质量控制的成本。 对于作为实施开发任务或 Bug 修复的一部分而编写的所有代码，开发人员必须为其编写单元测试。 有关详细信息，请参阅单元测试代码。

在测试优先开发策略中进行任何代码修复之前，你可能更喜欢编写单元测试。 敏捷软件开发人员首选此类策略。 CMMI 不要求以特定顺序编写单元测试，仅实现对功能的有效验证。

CMMI 评估需要编写和运行单元测试的证据。 请务必将测试链接到代码修复的任务工作项，并将这些任务链接到 bug 工作项。 这提供了一个证据的可追溯性，证明一个 SCAMPI 潜在顾客评估者将查找。

评审并重构代码以修复 Bug

代码评审用于确保在代码集成到日常生成之前，新代码或更改的代码符合既定的质量条。 质量考虑因素有编码标准、与体系结构和设计的一致性、性能、可读性和安全性。 代码评审还提供来自其他开发人员的有关应如何编写代码的其他见解。 有关如何查看和重构代码的详细信息，请参阅 “实现开发任务”。

关闭 Bug

修复 bug 后，应将其分配给测试人员，以验证问题是否已解决，然后再关闭 bug 工作项。

验证修补程序

若要验证修复，测试人员应尝试重现 bug、查找其他意外行为，并在必要时重新激活 bug。

验证 bug 解析时，你可能会发现 bug 未完全修复，或者你可能不同意解决方法。 在这种情况下，你将与解决 Bug 的人员讨论 bug，达成协议，并可能重新激活 bug。 如果确实重新激活 bug，请确保在 bug 说明中包含重新激活 bug 的原因，以便保留信息。

关闭 bug 工作项

由于许多原因，bug 已关闭。 在简单情况下，bug 已验证为已修复，也可以关闭。 但是，bug 可以推迟到下一个版本的产品，经证实无法重现，或确认为重复版本。 必须记录上述每个原因，并且必须正确关闭 bug，以确保对关闭原因没有任何混淆。