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

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

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

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

为了支持这些方案,Azure Boards提供了特定的工作项类型来跟踪名为 Bug 的代码缺陷。 Bug 工作项与其他几个工作项类型共享所有标准功能。 有关标准功能的概述,请参阅 跟踪用户情景、问题、bug、功能和长篇故事的工作

Bug 还提供以下附加功能:

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

注意

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

先决条件

  • 必须连接到项目。 如果还没有项目, 请创建一个项目
  • 必须添加到项目中。 若要添加, 请将用户添加到项目或团队
  • 若要查看或修改工作项,必须将 “查看此节点中的工作项 ”和 “编辑此节点中的工作项 ”权限设置为 “允许”。 默认情况下, “参与者” 组具有此权限集。 若要了解详细信息,请参阅 设置工作跟踪的权限和访问权限
  • 若要添加新标记以添加到工作项,必须具有 基本 访问权限或更高权限,并将项目级别的 “创建新标记定义 ”权限设置为 “允许”。 默认情况下, “参与者” 组具有此权限集。 即使为 利益干系人显式设置了权限,他们也不会有权添加新标记,因为它们的访问级别是禁止的。 若要了解详细信息,请参阅 利益干系人访问快速参考
  • 所有项目成员(即使是属于 “读者 ”组的成员)都可以通过电子邮件发送工作项。
  • 必须连接到项目。 如果还没有项目, 请创建一个项目
  • 必须添加到项目中。 若要添加, 请将用户添加到项目或团队
  • 若要查看或修改工作项,必须将 “查看此节点中的工作项 ”和 “编辑此节点中的工作项 ”权限设置为 “允许”。 默认情况下, “参与者” 组具有此权限集。 若要了解详细信息,请参阅 设置工作跟踪的权限和访问权限
  • 若要添加新标记以添加到工作项,必须具有 基本 访问权限或更高权限,并将项目级别的 “创建新标记定义 ”权限设置为 “允许”。 默认情况下, “参与者” 组具有此权限集。 即使为 利益干系人显式设置了权限,他们也不会有权添加新标记,因为它们的访问级别是禁止的。 若要了解详细信息,请参阅 利益干系人访问快速参考
  • 所有项目成员(即使是属于 “读者 ”组的成员)都可以通过电子邮件发送工作项。

提示

若要报告 bug,用户必须至少具有 利益干系人 访问权限,并将 “编辑此节点中的工作项 ”权限设置为 “允许 ”,才能在其中添加 bug 的区域路径 。 若要了解详细信息,请参阅 设置工作跟踪的权限和访问权限

Bug 工作项类型

下图显示了 Scrum 进程的 Bug 工作项类型。 敏捷和 CMMI 进程的 Bug 工作项类型跟踪类似信息。 它设计为与要求一起显示在产品积压工作上,或与任务一起显示在任务板上。

注意

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

Bug 工作项类型、Scrum 流程表单、Azure DevOps Server 2020 和云服务。

Bug 工作项类型的屏幕截图,Scrum 进程的窗体,Azure DevOps Server 2019 和 TFS 2018。

特定于 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 更改集和版本控制项。 可以定义来自工作项或提交、拉取请求或其他开发对象的链接。 若要了解详细信息,请参阅本文后面的 将工作项链接到开发


注意:

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

选择团队跟踪 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 分配给任务类别
  • 用户情景 (敏捷) 、产品积压工作项 (Scrum) 或要求 (CMMI) 是 Bug 的自然父工作项类型
  • Bug 在交付计划中不可见

Bug 不出现在积压工作或板上

  • 使用查询管理 bug

注意

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

自定义工作项类型

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

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

在自定义过程之前,建议查看配置和自定义Azure Boards

若要自定义特定进程,请参阅 自定义继承过程

若要自定义特定进程,请参阅 自定义继承进程自定义本地 XML 进程模型

若要自定义特定进程,请参阅 自定义本地 XML 进程模型

添加或捕获 bug

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

提示

默认情况下,创建 bug 时, “标题” 字段是唯一必需的字段。 可以采用与使用 Azure Boards添加用户情景或产品积压工作项相同的方式快速添加 bug。 如果要使某些字段是必需的,请根据状态更改添加条件规则。 若要了解详细信息,请参阅 将规则添加到工作项类型 (继承过程)

从积压工作或板中添加 bug

如果你的团队选择 根据要求管理 bug,则可以从产品积压工作或看板定义 bug。 若要了解详细信息,请参阅 创建产品积压工作开始使用看板

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

    从产品积压工作添加 bug 的屏幕截图:添加 bug。

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

    从看板“添加 bug”添加 bug 的屏幕截图。

提示

从产品积压工作或看板添加 bug 时,将自动为该 bug 分配为团队定义的默认区域路径和迭代路径。 若要了解详细信息,请参阅 积压工作和板引用的团队默认值

从冲刺积压工作或任务板添加 bug

如果你的团队选择 通过任务管理 bug,则可以定义看板、产品积压工作、冲刺积压工作或冲刺任务板中的 bug。 将 bug 作为子级添加到产品积压工作项。

  • 从看板添加链接的子 bug
    添加 bug 的方式与将任务添加到积压工作项的方式相同。 若要了解详细信息,请参阅 添加任务或子项作为清单

    从看板添加 bug 的屏幕截图,将子 bug 添加到积压工作项。

  • 从冲刺积压工作中添加链接的子 bug
    添加 bug 的方式与将任务添加到 Sprint 积压工作的方式相同。 若要了解详细信息,请参阅 将任务添加到积压工作项

    从 Sprint 积压工作添加 bug 的屏幕截图,将子 bug 添加到积压工作项。

从测试工具创建 bug

可用于在测试时添加 bug 的两个测试工具包括 Web 门户测试运行程序和测试 & 反馈扩展。

  • 测试运行程序:运行手动测试时,可以选择 “创建 bug”。 若要了解详细信息,请参阅 运行手动测试

    从“测试运行程序”“创建 bug”功能添加 bug 的屏幕截图。

  • 测试 & 反馈扩展:运行探索性测试时,可以选择 “创建 bug”“创建任务”。 若要了解详细信息,请参阅使用测试反馈扩展的探索性测试&屏幕截图,以从测试&反馈扩展、创建 bug 或任务功能添加 bug。

Bug 生命周期和工作流状态

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

敏捷 Scrum CMMI
Bug 工作流状态,敏捷过程模板 Bug 工作流状态,Scrum 过程模板 Bug 工作流状态,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。

Scrum 进程:

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

CMMI 过程:

  • 延迟:将 bug 修复延迟到下一个产品发布。
  • 重复: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 查询,例如以下选项:

  • 按优先级 (State <> DoneState <> Closed) 显示的活动 bug
  • 正在进行的 bug (State = CommittedState = Active)
  • 要为目标版本修复的 bug (Tags Contains RTM)
  • 最近的 bug - 在过去三周内打开的 bug (Created Date > @Today-21)

获得团队感兴趣的查询后,可以 创建状态或趋势图。 还可以将创建的图表添加到 仪表板

查询结果中的会审模式

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

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

在查询结果页中,可以使用向上和向下箭头在 bug 工作项列表中快速上下移动。 查看每个 bug 时,可以分配、添加详细信息或设置优先级。 若要了解详细信息,请参阅 会审工作项

查询结果、活动 Bug 和会审模式右窗格的屏幕截图。

整理 bug 并将其分配给冲刺

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

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

任务板项与查询列表项

你可能会注意到并想知道冲刺任务板上显示的项目为何不同于在相应的冲刺积压工作中创建的查询列表。

可以将任务或 bug 分配给迭代,但不能将它们链接到父积压工作项。 这些项将显示在创建的查询中,但可能不会显示在任务板本身上。 系统运行查询,然后在显示任务板项之前应用一些后台进程。

这些原因可能导致属于任务类别的工作项不显示在冲刺积压工作或任务板上:

  • 该任务或 bug 尚未链接到父积压工作项。 只有链接到父产品积压工作项 (Scrum) 、用户情景 (敏捷) 或要求 (CMMI) 且迭代路径设置为冲刺的 bug 和任务才会显示在冲刺积压工作页上。
  • 任务或 bug 是另一个任务或 bug 的父级,或者用户情景是另一个用户情景的父级。 如果已创建任务、bug 或用户情景的层次结构, 则仅显示层次结构底部的子级任务或子级情景
  • 任务或 bug 的链接父项对应于为另一个团队定义的积压工作项。 或者,任务的 或 bug 的父积压工作项的区域路径不同于任务的 或 bug 的区域路径。

创建链接到 bug 的内联测试

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

看板的屏幕截图,其中 3 列显示已添加并链接到 bug 的内联测试。

更新 bug 状态

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

  • 如果团队 按要求跟踪 bug,请使用看板,如下图所示。 若要了解详细信息,请参阅 看板入门

    看板的屏幕截图,拖放以更新状态。

  • 如果团队 将 bug 跟踪为任务,请使用任务板。 若要了解详细信息,请参阅 更新和监视任务板

    任务板的屏幕截图,拖放以更新状态。

自定义开发板以跟踪中间状态

可以添加中间列来跟踪开发板上的 bug 状态。 还可以定义根据板列的状态进行筛选的查询。 要了解更多信息,请参阅下列文章:

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

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

定义基于已解决状态重新分配 bug 的规则的屏幕截图。

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

创建拉取请求时,可以在说明中设置链接的工作项 的状态 值。 遵循语法: {state value}: #ID。 合并拉取请求时,系统会读取说明并更新工作项状态。 在以下示例中,我们将工作项 #300 和 #301 设置为 Resolved,将 #323 和 #324 设置为 Closed。

在 PR 中设置工作项状态的屏幕截图。

注意

此功能需要安装 Azure DevOps Server 2020.1 更新。 若要了解详细信息,请参阅 Azure DevOps Server 2020 Update 1 RC1 发行说明、Boards

跨 Azure DevOps 的集成

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

显示用于链接工作项以生成和释放对象的链接类型的概念图。

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

开发控件支持链接到和显示生成、Git 提交和拉取请求的链接。 或者,使用 TFVC 存储库时,它支持指向变更集和版本控制项的链接。 选择链接将在新的浏览器选项卡中打开相应的项。若要了解详细信息,请参阅 从工作项推动 Git 开发

工作项表单上的开发控制,其中包含生成、拉取请求和提交的示例链接。

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

包含示例版本的工作项窗体上的部署控制。

管道通常定义为在 Git 存储库发生新提交时自动运行。 如果自定义管道设置,与提交管道关联的工作项将显示为管道运行的一部分。 若要了解详细信息,请参阅 自定义管道

管道设置的屏幕截图,从所选分支自动链接此运行中的工作项。

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

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

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

两个活动 bug 查询图表的屏幕截图:按状态和优先级显示的 Bug 趋势。

了解有关查询、图表和仪表板的详细信息;请参阅 关于托管查询图表以及 仪表板

使用分析视图和分析服务创建 bug 报告

分析服务是 Azure DevOps 的报告平台,取代了基于SQL Server Reporting Services的先前平台。

分析视图提供预生成的筛选器来查看工作项。 bug 报告支持四个分析视图。 可以使用定义的这些视图,或进一步编辑它们,以创建自定义的筛选视图。

  • Bug - 按月显示的所有历史记录
  • Bug - 过去 26 周
  • Bug - 过去 30 天
  • Bug - 今日

若要了解有关使用分析视图的详细信息,请参阅 什么是分析视图基于自定义分析视图在 Power BI 中创建活动 bug 报表

可以使用 Power BI 创建比从查询获取的报表更复杂的报表。 若要了解详细信息,请参阅 使用 Power BI 数据连接器进行连接

预定义SQL Server bug 报告

敏捷和 CMMI 过程支持以下报表。

这些报表要求为项目配置SQL Server Analysis Services和SQL Server Reporting Services。 若要了解如何为项目添加SQL Server报表,请参阅向项目添加报表

市场扩展

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

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

接下来尝试此操作

产品积压工作和看板

看板

冲刺积压工作和任务板

Azure DevOps 中的集成

行业资源