跟踪 Bug

在运行测试以验证要求时，您一定会查找 Bug。 使用 Bug 工作项可描述并跟踪发现的每个 Bug 的进度。

有关如何创建 Bug 工作项的更多信息，请参见使用 Team Web Access 运行手动测试。 在发现 Bug 时，请按照本主题中的过程来确定 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 标准评估方法 (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 的关闭原因。