在 Azure Boards 中定义、捕获、会审和管理软件 bug

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

如何跟踪和管理代码中的缺陷？ 如何确保快速解决软件问题和客户反馈，以支持高质量软件部署？ 如何在新功能上取得良好进展并解决技术债务问题？

至少需要一种方法来捕获软件问题、确定问题的优先级、将其分配给团队成员以及跟踪进度。 你希望以与敏捷做法一致的方式管理代码缺陷。

为了支持这些方案，Azure Boards 提供了特定的工作项类型来跟踪名为 bug 的代码缺陷。 Bug 工作项与其他几个工作项类型共享所有标准功能，还有一些其他功能。 有关标准功能的概述，请参阅关于工作项和工作项类型。

“bug”还提供以下功能：

• 供每个团队选择跟踪 bug 的方式的选项
• 用于捕获 bug 的测试工具
• 跨 Azure DevOps 的内置集成，用于跟踪与生成、发布和测试关联的 bug

注意

Bug 工作项类型不适用于基本流程。 基本流程会将 bug 作为问题跟踪，并在从 Azure DevOps Services 或 Azure DevOps Server 2019.1 或更高版本创建新项目时可用。

先决条件

• 项目访问权限： 是 项目成员。

• 权限：

  • 若要查看、关注和编辑工作项，请在此节点中查看工作项，并在此节点权限中编辑工作项设置为“允许”。 默认情况下，参与者组具有这些权限。 有关详细信息，请参阅设置工作跟踪权限。

• 若要将标记添加到工作项，请将项目级 “创建新标记定义 ”权限设置为“ 允许”。 默认情况下，参与者组拥有此权限。

• 访问级别：

  • 若要向工作项添加新标记或查看或关注拉取请求，请至少具有基本访问权限。
  • 若要查看或关注工作项，至少 具有利益干系人 访问权限。 有关详细信息，请参阅关于访问级别。
  • 所有项目成员（包括 读者 组中的项目成员）都可以发送电子邮件，其中包含工作项。

  注意

  • 为希望参与讨论和评审进度的成员提供 利益干系人访问权限 。 这些成员通常不参与代码，但想要查看工作项、积压工作、面板和仪表板。
  • 利益干系人 无法添加新标记，即使权限是显式设置的，但由于其访问级别。 有关详细信息，请参阅利益干系人访问快速参考。

提示

若要报告 bug，用户必须至少具有利益干系人访问权限。 对于添加 bug 的区域路径，用户必须将编辑此节点中的工作项权限设置为允许。 有关详细信息，请参阅设置工作跟踪权限

bug 工作项类型

下图显示了 Scrum 流程的 Bug 工作项类型。 敏捷流程和能力成熟度模型集成 (CMMI) 流程的 bug 工作项类型跟踪类似信息。 它与要求一起显示在产品积压工作上，或与任务一起显示在任务板上。

注意

从 Web 门户看到的映像可能与本文中看到的映像不同。 这些差异源于对 Web 应用所做的更新、你或管理员已启用的选项，以及创建项目时选择的流程：（敏捷、基本、Scrum 或 CMMI）。 基本流程适用于 Azure DevOps Server 2019 更新 1 及更高版本。

特定于 bug 的字段

Bug 工作项类型使用一些特定于 bug 的字段。 要捕获初始问题和正在进行的发现，请使用下表中所述的字段。 有关特定于为能力成熟度模型集成 (CMMI) 流程定义的 Bug 的字段的信息，请参阅 Bug、问题和风险字段参考。 有关所有其他字段的信息，请参阅工作项字段索引。

---

字段、组或选项卡

使用情况

---

重现步骤（友好名称=重现步骤）

用于捕获足够的信息，以便其他团队成员可以完全了解代码缺陷。 包括查找或重现 Bug 和预期行为所执行的操作。

---

系统信息发现版本

与 bug 和要应用的测试相关的软件和系统配置的信息。 通过测试工具创建 bug 时，系统信息和发现版本字段会自动填充。 这些字段指定有关发生 bug 的软件环境和生成的信息。 有关详细信息，请参阅测试不同的配置。

---

验收条件

提供在关闭 bug 之前要满足的条件。 在开始工作之前，应尽可能明确地说明客户验收条件。 团队应将此条件作为验收测试的基础，并评估项目是否已完成并达到满意的效果。

---

集成版本

指定包含修复 bug 的代码的生成的名称。 解决 bug 时，应指定此字段。

对于本地 Azure DevOps，要访问所有已运行的生成的下拉菜单，可以更新发现版本和集成版本的 FIELD 定义来引用全局列表。 将使用每个运行的生成自动更新全局列表。 有关详细信息，请参阅基于生成和测试集成字段的查询。

有关如何定义内部版本号的信息，请参阅经典管道配置。

---

优先级¹

• 1：产品需要在交付和处理之前成功解决工作项。
• 2：产品要求在交付之前成功解决工作项，但不需要立即处理。
• 3：根据资源、时间和风险来选择性地解决工作项。

---

严重性¹

对 bug 或工作项对项目或软件系统的影响的主观评级。 例如：如果用户界面中的远程链接（一个罕见事件）导致应用程序或网页崩溃（这是严重的客户体验），则可以指定严重性 = 2 - 高和优先级 = 3。 允许的值和建议准则包括：

• 1 - 严重：必须修复。 导致一个或多个系统组件或整个系统终止，或导致大量数据损坏的缺陷。 没有可接受的替代方法可以实现所需的结果。
• 2 - 高：考虑修复。 导致一个或多个系统组件或整个系统终止，或导致大量数据损坏的缺陷。 存在一种可接受的替代方法来实现所需的结果。
• 3 - 中：（默认）导致系统产生错误、不完整或不一致结果的缺陷。
• 4 - 低：具有可接受的解决方法来实现所需结果的次要缺陷或外观缺陷。

---

部署

部署控件支持包含工作项的发布的链接和显示。 要使用该控件，必须启用发布设置。 有关详细信息，请参阅本文后面的将工作项链接到发布。

---

开发

开发控件支持指向开发对象的链接并显示这些链接。 这些对象包括 Git 提交和拉取请求，或 TFVC 更改集和版本控制项。 可以定义来自工作项或提交、拉取请求或其他开发对象的链接。 有关详细信息，请参阅本文后面的将工作项链接到开发。

---

备注

¹ 要更改菜单选择或选择列表，请参阅自定义工作跟踪体验。 自定义方法取决于项目使用的流程模型。

选择团队跟踪 bug 的方式

你的团队可以将 bug 作为要求或任务进行跟踪。 要支持团队选择，请考虑以下因素。

• 团队规模。 小型团队可以通过将 bug 作为要求进行跟踪来维护轻型占用空间。
• 跟踪工作的组织要求。 如果你的团队需要跟踪小时数，请选择将 bug 作为任务进行跟踪。
• 组织团队的工作。 如果你的团队依赖于产品积压工作来确定工作的优先级并添加 bug，请根据需要跟踪 bug。
• 团队要使用的工具，例如“规划”窗格、速度图表、预测、汇总和交付计划。 将 bug 作为任务跟踪会阻止使用其中一些工具。

下表总结了团队跟踪 bug 所需的三个选项。 要了解详细信息并设置团队选项，请参阅显示积压工作 (backlog) 和版块上的 bug。

---

选项

选择何时要...

---

将 bug 作为要求跟踪

• 根据需求对 bug 进行优先级排序或堆栈分级
• 估算预测的 bug 工作量
• 更新面板上的 bug 状态
• 在速度图表和累积流图中包含 Bug
• 可以使用预测工具来支持冲刺规划
• 将 bug 拖放到规划窗格，以将 bug 分配给冲刺
• 查看交付计划上的 bug

注意

• Bug 分配到“要求类别”

---

将 Bug 作为任务跟踪

• 估算与任务类似的 bug 的工作量
• 更新冲刺 (sprint) 任务面板上的 bug 状态
• 将 bug 作为子项链接到要求
• 将 bug 拖放到规划窗格，以将 bug 分配给冲刺

注意

• Bug 分配到“任务类别”
• 用户情景（敏捷）、产品积压工作项 (Scrum) 或要求 (CMMI) 是 Bug 的自然父工作项类型
• Bug 在交付计划中不可见

---

Bug 不显示在积压工作 (backlog) 或版块上

• 使用查询管理 bug

注意

• Bug 与 Bug 类别关联，不会显示在积压工作或板上
• Bug 在积压工作、板、冲刺积压工作、任务板或交付计划中不可见
• 不能将 bug 拖放到“规划”窗格，以将 bug 分配给冲刺

---

自定义工作项类型

可以自定义 Bug 和其他工作项类型。 或者，创建自定义类型来跟踪软件问题或客户反馈。 对于所有工作项类型，可以自定义以下元素：

• 添加或删除自定义字段
• 在工作项窗体中添加自定义控件或自定义选项卡
• 自定义工作状态
• 添加条件规则
• 选择显示工作项的积压工作 (backlog) 级别

在自定义流程之前，建议查看关于配置和自定义 Azure Boards。

要自定义特定流程，请参阅自定义继承流程。

添加或捕获 bug

可以从多个不同的 Azure DevOps 工具定义 bug。 这些工具包括积压工作和板以及测试工具。

提示

默认情况下，创建 bug 时，标题字段是唯一的必填字段。 可以采用与使用 Azure Boards 添加用户情景或产品积压工作项相同的方式添加 bug。 可以根据状态更改添加条件规则，使某些字段成为必填字段。 有关详细信息，请参阅向工作项类型添加规则。

从积压工作 (backlog) 或版块中添加 bug

如果团队选择以要求的形式管理 bug，则可以从产品积压工作或面板定义 bug。 有关详细信息，请参阅创建产品积压工作或使用面板。

• 从产品积压工作中添加 bug

  

• 从板添加 bug

  

提示

从产品积压工作或面板添加 bug 时，该 bug 会被自动分配给团队定义的默认区域路径和迭代路径。 有关详细信息，请参阅积压工作 (backlog) 和面板引用的团队默认路径。

从冲刺 (sprint) 积压工作 (backlog) 或任务面板添加 bug

如果你的团队选择以任务的形式管理 bug，则可以从面板、产品积压工作、冲刺 (sprint) 积压工作 (backlog) 或冲刺 (sprint) 任务面板定义 bug。 将 bug 作为子级添加到产品积压工作项。

• 从冲刺 (sprint) 积压工作 (backlog) 中添加链接的子 bug

  添加 bug 的方式与将任务添加到冲刺 (sprint) 积压工作 (backlog) 的方式相同。 有关详细信息，请参阅将任务添加到积压工作项。

  

• 从面板添加链接的子 bug

  添加 bug 的方式与将任务添加到积压工作项的方式相同。 有关详细信息，请参阅将任务或子项添加为清单。

  

从测试工具创建 bug

可用于在测试期间添加 bug 的两个测试工具，包括 Web 门户 Test Runner 以及测试和反馈扩展。

• Test Runner：运行手动测试时，可以选择创建 bug。 有关详细信息，请参阅运行手动测试。

  

• 测试和反馈扩展：运行探索测试时，可以选择“创建 bug”或“创建任务”。 有关详细信息，请参阅使用测试和反馈扩展的探索测试。

  

Bug 生命周期和工作流状态

与所有其他工作项类型一样，Bug 工作项类型具有定义完善的工作流。 每个工作流由三个或更多的状态和一个原因组成。 原因指定项从一个状态转换到另一个状态的原因。 下图演示了为敏捷、Scrum 和 CMMI 流程定义的默认 bug 工作流。

敏捷	Scrum	CMMI

对于 Scrum bug，可将状态从已提交（类似于活动）更改为完成。 对于敏捷和 CMMI，首先解决 bug 并选择一个指示 bug 已修复的原因。 通常，创建 bug 的人员随后会验证修复，并将状态从已解决更新为已关闭。 如果在解决或关闭 bug 后发现更多工作，请通过将状态设置为已提交或活动来重新激活它。

注意

敏捷流程 bug 工作项类型以前有一个规则，该规则将 bug 重新分配给创建 bug 的人员。 此规则已从默认系统流程中删除。 可以通过添加规则来恢复此自动化。 有关继承进程，请参阅根据状态更改自动重新分配。

验证修补程序

为了验证修补程序，开发人员或测试人员会尝试重现 Bug 并查找更多意外行为。 如有必要，他们会重新激活 bug。

验证 bug 修复时，你可能会发现该 bug 未修复，或者你可能不同意解决方法。 在这种情况下，请与解决 Bug 的人员讨论 Bug，达成一致，并且可以重新激活 bug。 如果重新激活 bug，请在 bug 说明中包含重新激活 bug 的原因。

关闭 bug

当团队成员确认 bug 已修复时，即可关闭 bug。 但是，你也可能出于以下原因之一而关闭 bug。 可以选择的原因取决于项目流程和 bug 转换状态。

敏捷流程：

• 延迟：将 bug 修复推迟到下一个产品发布。
• 已修复：bug 验证为已修复。
• 重复：bug 跟踪当前定义的另一个 bug。 可以将每个 bug 与重复/项重复链接类型链接，并关闭其中一个 bug。
• 保留原样：功能按原样工作。
• 无法重现：测试证明无法重现 bug。
• 已过时：bug 的功能不再显示在产品中。
• 已复制到积压工作 (backlog)：已打开用户情景来跟踪 bug。

Scrum 流程：

• 不是 Bug：验证为不是 bug。
• 重复：bug 跟踪当前定义的另一个 bug。 可以将每个 bug 与重复/项重复链接类型链接，并关闭其中一个 bug。
• 已从积压工作 (backlog) 中删除：验证为不是 bug。 从积压工作 (backlog) 中删除 bug。
• 工作完成：bug 验证为已修复。

CMMI 流程：

• 延迟：将 bug 修复推迟到下一个产品发布。
• 重复：bug 跟踪当前定义的另一个 bug。 可以将每个 bug 与重复/项重复链接类型链接，并关闭其中一个 bug。
• 已拒绝：验证为不是 bug。
• 已验证：bug 验证为已修复。

提示

修复 bug 并在部署中主动发布修补程序后，建议的做法是永远不要因为回归而重新打开它。 相反，应考虑打开新的 bug 并链接到旧的、已关闭的 bug。

最好在讨论字段中描述有关关闭 bug 的更多详细信息，以避免将来对关闭 bug 的原因感到困惑。

合并拉取请求时自动关闭 bug

如果团队使用 Git 存储库，则可以将链接 bug 和其他工作项中的状态设置为在拉取请求成功合并后关闭。 有关详细信息，请参阅本文后面的在拉取请求中设置工作项状态。

列出和会审 bug

大多数团队（无论选择哪种选项来跟踪 bug）都会定义一个或多个 bug 查询。 通过查询，可以列出活动 bug、未分配的 bug、过时的 bug、bug 趋势等。 可以将查询和查询图表添加到团队仪表板，以监控 bug 状态和进度。

Bug 查询

打开共享查询或使用查询编辑器创建有用的 bug 查询，例如以下选项：

• 按优先级排列的活动 bug（State <> Done 或 State <> Closed）
• 正在进行的 bug（State = Committed 或 State = Active）
• 目标发布要修复的 bug（Tags Contains RTM）
• 最近的 bug，例如在过去三周内打开的 bug (Created Date > @Today-21)

一旦有了团队感兴趣的查询，就可以创建状态或趋势图。 还可以将创建的图表添加到仪表板。

查询结果中的会审模式

开始编码和测试后，需要定期召开会审会议来评审 bug 并设置优先级。 通常，项目所有者运行 bug 会审会议。 可以谈论特定项目风险的团队主管、业务分析师和其他利益干系人将参加会审会议。

项目所有者可以为新的和重新打开的 bug 定义共享查询，以列出要会审的 bug。

在查询结果页中，可以使用向上和向下箭头在 bug 工作项列表中快速上下移动。 查看每个 bug 时，可以分配它、添加详细信息或设置优先级。

整理 bug 并将其分配给冲刺 (sprint)

如果团队将 bug 作为要求跟踪，请查看积压工作 (backlog) 中的活动 bug 列表。 使用筛选器函数，可以只关注 bug。 在产品积压工作中，还可以执行以下任务：

• 整理积压工作上的 bug。 堆栈相对于其他项的排名。 启用筛选时禁用堆栈排名。
• 使用规划窗格将 bug 分配给积压工作中的冲刺。
• 使用映射窗格将父 bug 指向功能或其他项目组合积压工作项。
• 查看组合积压工作项的工作汇总。

如果团队将 bug 作为任务跟踪，请使用托管查询列出和会审 bug。 在每个冲刺中，你将看到从冲刺积压工作或任务板分配给冲刺的 bug。

任务面板项与查询列表项

你可能注意到冲刺 (sprint) 任务面板上显示的项不同于在相应的冲刺 (sprint) 积压工作 (backlog) 中创建的查询列表，并想知道原因。

可以将任务或 bug 分配给迭代，但不能将其链接到父积压工作项。 这些项显示在创建的查询中，但可能不会显示在任务面板本身。 系统将运行查询，并在显示任务面板项之前应用几个后台流程。

以下几个原因可能导致属于任务类别的工作项不会显示在冲刺 (sprint) 积压工作 (backlog) 或任务面板上：

• 未将任务或 bug 链接到父积压工作项。 只有其迭代路径设置到冲刺的已链接到父产品积压工作项 (Scrum)、用户情景（敏捷）或要求 (CMMI) 的 bug 和任务会显示在冲刺积压工作页上。
• 任务或 bug 是另一个任务或 bug 的父级，或者用户情景是另一个用户情景的父级。 如果要创建任务、bug 或用户情景的层次结构，则只会显示层次结构底部的子级任务或子级情景。 有关详细信息，请参阅排除重新排序和嵌套问题。
• 任务或 bug 链接的父任务对应于为其他团队定义的积压工作项。 或者，任务或 bug 的父积压工作项的区域路径与该任务或 bug 的区域路径不同。

创建链接到 bug 的内联测试

当团队将 bug 作为要求跟踪时，可以使用面板添加测试来验证 bug 修复。

更新 bug 状态

可以通过将 bug 拖放到板上的新列来更新 bug 状态。

• 如果团队将 bug 作为要求跟踪，请使用面板，如下图所示。 有关详细信息，请参阅更新工作项状态。

  

• 如果团队将 bug 作为任务跟踪，则使用任务面板。 有关详细信息，请参阅更新和监控任务面板。

  

自定义板以跟踪中间状态

可以添加中间列来跟踪板上的 bug 状态。 还可以定义基于板列状态进行筛选的查询。 有关详细信息，请参阅以下文章：

• 将列添加到面板
• 自定义冲刺 (sprint) 任务板
• 查询面板的更改

根据工作流状态自动执行 bug 重新分配

要自动执行选择操作，请将自定义规则添加到 Bug 工作项类型。 例如，添加规则，如下图所示。 此规则指定在团队成员解决 bug 后将 bug 重新分配给打开 bug 的人员。 通常，该人员会验证 bug 是否已修复并关闭该 bug。 有关详细信息，请参阅将规则应用于工作流状态（继承进程）。

在拉取请求中设置工作项状态

创建拉取请求时，可以在说明中设置链接工作项的状态值。 遵循语法：{state value}: #ID。

合并拉取请求时，系统会读取说明并更新工作项状态。 以下示例将工作项 #300 和 #301 设置为“已解决”，将 #323 和 #324 设置为“已关闭”。

跨 Azure DevOps 集成

Azure DevOps 用于支持集成的方法之一是将对象链接到其他对象。 除了将工作项链接到工作项外，还可以将工作项链接到其他对象。 链接到生成、发布、分支、提交和拉取请求等对象，如下图所示。

可以从工作项或生成和发布对象添加链接。

将工作项链接到开发

开发控件支持链接到生成、Git 提交和拉取请求，并显示这些链接。 使用 TFVC 存储库时，它支持指向更改集和版本控制项的链接。 通过选择链接，可在新的浏览器选项卡中打开相应的项。有关详细信息，请参阅从工作项推动 Git 开发。

将工作项链接到发布

部署控件支持包含工作项的发布的链接和显示。 例如，下图显示了包含指向当前工作项的链接的多个发布。 可以展开每个发布以查看每个阶段的详细信息。 可以选择每个发布和阶段的链接以打开相应的发布或阶段。 有关详细信息，请参阅将工作项链接到部署。

将工作项链接到管道运行

管道通常定义为在 Git 存储库发生新提交时自动运行。 如果自定义管道设置，则与提交管道关联的工作项会显示为管道运行的一部分。 有关详细信息，请查看自定义管道。

生成失败时创建或编辑工作项

如果使用经典管道（而不是 YAML），则可以在生成失败时创建工作项。 有关详细信息，请参阅失败时创建工作项。

监控 bug 状态、分配和趋势

可以使用查询跟踪 bug 状态、分配和趋势，然后可以绘制图表并添加到仪表板。 例如，下面是两个示例，显示了一段时间内按状态显示的活动 bug 趋势，以及按优先级排列的活动 bug。

有关查询、图表和仪表板的详细信息，请参阅托管查询、图表和仪表板。

使用 Analytics 视图和 Analytics 服务创建 Bug 报告

Analytics 服务是 Azure DevOps 的报告平台。 它取代了以前基于 SQL Server Reporting Services 的平台。

Analytics 视图提供预生成的筛选器来查看工作项。 Bug 报告支持四个 Analytic 视图。 可以按照定义使用这些视图，也可以进一步编辑它们以创建自定义筛选视图。

• bug - 按月排列的所有历史记录
• bug - 过去 26 周
• bug - 过去 30 天
• bug - 今日

有关如何使用 Analytic 视图的详细信息，请参阅关于 Analytics 视图和基于自定义 Analytics 视图在 Power BI 中创建活动 bug 报告。

可以使用 Power BI 创建比查询还要复杂的报告。 有关详细信息，请参阅使用 Power BI 数据连接器进行连接。

市场扩展

有多个与 bug 相关的市场扩展。 请参阅 Azure DevOps 市场。

有关扩展的详细信息，请参阅 Microsoft 开发的 Azure Boards 扩展。

后续步骤

使用模板添加和更新工作项

相关文章

• 移除、删除或还原工作项
• 复制或克隆工作项

产品积压工作和面板

• 使用积压工作来管理项目
• 创建积压工作
• 定义功能和长篇故事
• 整理积压工作 (backlog) 并将子工作项映射到父项
• 以交互方式筛选积压工作 (backlog)、Boards、查询和计划
• 预测产品积压工作

Board

• 关于 Boards 和看板
• 使用面板
• 重排卡片顺序
• 添加任务或子项作为清单

冲刺 (sprint) 积压工作 (backlog) 和任务面板

• 了解 Scrum 最佳做法
• 将积压工作项分配给冲刺 (sprint)
• 添加任务
• 更新任务板

Azure DevOps 中的集成

• 链接用户情景、问题、bug 和其他工作项
• 关注工作项或拉取请求
• 配置运行或生成号

行业资源

• 良性和不良技术债务（以及 TDD 如何提供帮助），Henrik Kniberg 著
• 管理技术债务，由 Sven Johann 和 Eberhard Wolff 发布