Bug (Agile)

在本主题中，您可以学习如何填写 Bug 工作项的详细信息。 有关如何创建 Bug 工作项的更多信息，请参见工作项和工作流 (Agile)。

主题内容	相关主题
Bug 创建和跟踪概述 定义 Bug 将测试用例链接到 Bug 将详细信息、附件或超链接添加到 Bug 解决和关闭 Bug	过程指南 敏捷规划和迭代 工作簿 “会审”工作簿 面板和报表 “Bug”面板 “Bug 状态”报表 “Bug 趋势”报表 “重新激活”报表 “情景概述”报表（敏捷） 字段参考 工作分配和工作流字段引用 区域和迭代字段引用 计划、分级和优先级别字段引用 标题、ID、说明和历史记录字段引用 链接工作项以及链接控件和限制 附件控件和字段引用

必需的权限

若要查看 Bug，您必须是**“Readers (访问者)”组的成员，或者您的“查看此节点中的工作项”必须设置为“允许”。 若要创建或修改 Bug，您必须是“Contributors (参与者)”组的成员，或者您的“编辑此节点中的工作项”权限必须设置为“允许”**。 有关更多信息，请参见管理权限。

定义 Bug

Bug 可传达团队正在开发的代码中存在潜在问题。 在定义 Bug 时，您需要以可帮助访问者了解问题的全面影响的方式来准确报告问题。 您还应描述用于查找 Bug 的操作，以便团队的其他成员可以更轻松地重现该行为。 测试结果应清晰地显示出问题。 清晰和可理解的描述将影响修复 Bug 的可能性。

Bug 的工作项窗体将数据存储在下图所示的字段和选项卡中：

在定义 bug 时，必须定义在工作项窗体的上方区域的 标题。 可以将所有其他字段保留为空白，也可以接受其默认值。

定义 Bug

1. 在 Bug 的工作项窗体的上方区域，指定以下一个或多个字段：

   • 在**“标题”**（必需）中键入一个短语，用于描述所找到的代码缺陷。

   • 在 分配给 列表中，选择负责修复 bug 的团队成员的名称，或保留在会审过程后将要赋值的此字段留空。

     备注

     只能为“Contributors (参与者)”组的成员分配工作项。

   • 在 区域 和 迭代 列表中，选择适当的区域和迭代或保留后将要赋值的这些字段留空在计划或会审会议期间。

     备注

     每个团队项目的项目管理员为该项目定义区域和迭代路径，以便团队可以根据这些指定跟踪进度。有关更多信息，请参见创建和修改区域和迭代。

   • 在 堆栈级别，键入指示 bug 的相对重要性。在同一迭代的其他 bug 比较的数字。

   • 在 优先级 列表中，选择指示 bug 的重要性，1 代表最重要的值，而 4 代表最不重要。

     默认情况下，此字段的值为 2。

   • 在 严重级别 列表中，选择指示 bug 对项目的影响。值。

     默认情况下，此字段的值为**“3 - 中”**。

2. 在 重现步骤 选项卡上，提供尽可能详细的信息根据需要，以便其他团队成员可以了解必须修复的问题。

   可以对在此字段中提供的内容进行格式设置。

3. 在 系统信息 选项，请指定一个或多个以下类型的信息：

   • 在 发现版本 列表中，选择或键入在其中找到缺陷的版本的名称。

     备注

     每个版本都与一个唯一的版本名称相关联。有关如何定义版本名称的信息，请参见Customize Build Numbers。

   • 在创建 Bug 时，不要在**“集成版本”**中指定版本。 在解决 Bug 时，键入包含代码或修复 Bug 的版本的名称。

   • 在**“系统信息”**中描述在其中发现 Bug 的软件环境。

4. 在 历史记录 选项卡上，提供尽可能详细的信息，以便您希望。

   可以对在此处提供的内容进行格式设置。

   每次团队成员更新 Bug 时，其历史记录都会显示更改日期、进行更改的团队成员和所更改的字段。

5. （可选）将 Bug 链接到其他工作项，如测试用例或其他 Bug。

   有关这些活动的更多信息，请参见本主题后面部分中的将测试用例链接到 Bug。

6. 在工作项工具栏上，选择 保存工作项。

   备注

   在保存 Bug 之后，标识符出现在工作项工具栏下面的标题中。

将测试用例链接到 Bug

通过将 Bug 链接到测试用例，您可使为 MSF for Agile Software Development 定义的众多报表变得准确而完整。

将现有测试用例链接到 Bug

1. 在 测试用例 选项卡中，选择 链接。

   将打开**“将链接添加到 Bug”**对话框。

2. 在**“链接类型”列表中，保留默认值“测试方”，该值是从“测试用例”**选项卡添加的链接所支持的唯一链接类型。

3. 在 工作项 ID，键入要将 bug 链接到的一个或多个测试用例的 ID，或选择 浏览 查找要链接到的测试用例。 可以选择 我的测试用例 团队查询来查找测试用例选中要链接到的测试用例旁边的复选框。

   有关更多信息，请参见查找要链接或导入的工作项。

4. （可选）为要链接到的测试用例键入说明。

5. 选择**“确定”**。

6. 选择 保存工作项。

   备注

   Bug 和将其链接到的测试用例都会更新。

将详细信息、附件或超链接添加到 Bug

您可将信息添加到某个 Bug，以帮助他人重现或修复该 Bug。 可以通过以下方式向 Bug 添加详细信息：

• 在**“重现步骤”或“历史记录”**字段中键入信息。

• 附加文件。

  例如，可以附加电子邮件线索、文档、图像、日志文件或其他类型的文件。

• 添加指向网站或指向存储在服务器或网站上的文件的超链接。

向 Bug 添加详细信息

1. 选择 详细信息 选项。

2. 在**“重现步骤”**中键入信息。

3. （可选）在**“历史记录”**中键入信息。

   您可以设置文本格式以强调重点或捕获点符列表。 有关更多信息，请参见标题、ID、说明和历史记录字段引用。

4. 选择 保存工作项。

向 Bug 添加附件

1. 在**“附件”**选项卡中，执行以下操作之一：

   • 将文件拖动到附件区。

   • 选择 或按 CTRL+V 粘贴已复制的文件。

   • Choose  添加，然后选择 浏览。 在**“附件”**对话框中，键入或浏览到要附加的文件的名称。

     （可选）在**“注释”**框中，键入有关附件的附加信息。 若要返回到 附件 选项卡中，选择 确定。

2. 选择 保存工作项。

向 Bug 添加超链接

1. 在 所有链接 选项卡中，选择 链接。

   

2. 在 链接类型 列表中，选择 超链接。

3. 在**“地址”**中键入链接目标的地址。

   如果目标是网站，请键入 URL，或者从 Internet 浏览器中复制该 URL，然后将其粘贴到**“地址”**框中。 如果目标是服务器位置，请键入 UNC 名称格式的地址。

4. （可选）在**“注释”**框中键入有关超链接的附加信息。

5. 选择 确定，然后选择 保存工作项。

解决和关闭 Bug

在修复 Bug 之后，将其**“状态”**从“活动”更改为“已解决”。 在对修复进行验证之后，将其状态从“已解决”更改为“已关闭”。 任何团队成员都可更改 Bug 的状态。 此外，也可出于其他原因来解决无法修复的 Bug，如本主题后面部分所述。 有关更多信息，请参见工作分配和工作流字段引用。

解决或关闭 Bug

1. 打开 Bug 的工作项窗体。

2. 在 状态 列表中，选择 已解决 或 已关闭。

   • 如果将状态从**“活动”更改为“已解决”，“原因”字段会更改为“已修复”**。

     验证 原因 的值是否正确，或者选择不同的选项。

     有关更多信息，请参见本主题后面部分中的从“活动”到“已解决”。

   • 如果将状态从**“已解决”更改为“已关闭”，“原因”字段会更改为“已验证”**。

3. 选择 保存工作项。

典型工作流进度： 团队成员使用默认原因“新建”创建一个处于“活动”状态的 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 描述的问题所处的功能区域不再存在于产品之中，则该 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 的日期和时间。

请参见

概念

“会审”工作簿

用户情景 (Agile)

测试用例 (Agile)

其他资源

适用于 Visual Studio ALM 的敏捷过程模板

工作项和工作流 (Agile)