Bug (CMMI)

在本主题中，您可以学习如何填写 Bug 工作项的详细信息。 Bug 可传达团队正在开发的代码中存在潜在问题。 有关更多信息，请参见处理 Bug。

有关如何创建此类工作项的信息，请参见工作项和工作流 (Agile)。

主题内容	相关主题
定义 Bug 将 Bug 链接到其他工作项 将详细信息、附件或超链接添加到 Bug 更改 Bug 的状态	过程指南 处理 Bug 工作簿 “会审”工作簿 (CMMI) 面板和报表 “Bug”面板 (CMMI) “Bug 状态”报表 “Bug 趋势”报表 “重新激活”报表 字段参考 标题、ID、说明和历史记录 (CMMI) 指派、工作流和计划 (CMMI) 区域和迭代 用于跟踪 Bug、问题和风险的字段 (CMMI) 链接工作项 (CMMI) 附件

所需权限

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

定义 Bug

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

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

   

在定义 Bug 时，必须在工作项窗体的上方区域定义**“标题”，以及在“详细信息”选项卡上的“症状”**框中键入文本。 可以将所有其他字段保留为空白，也可以接受其默认值。

定义 Bug

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

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

   • 在**“根源”**列表中，单击错误的原因。

     可以指定下列值之一：“编码错误”、“设计错误”、“规范错误”、“沟通错误”或“未知”。

   • 在**“指派给”**列表中，单击负责修复此 Bug 的团队成员的名字。

     提示

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

   • 在**“状态”列表中，保留默认值“已建议”**。

     默认情况下，“原因”字段的值为“新建”。 **“解决原因”字段是只读字段，用于捕获“原因”字段从“活动”更改为“已解决”**时该字段的值。 有关这些字段以及如何使用这些字段跟踪工作流的更多信息，请参见本主题后面的更改 Bug 的状态。

   • 在**“区域”列表和“迭代”**列表中，单击相应的区域和迭代。

     提示

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

   • 在**“优先级别”**列表中，单击一个值以指示 Bug 的重要性，1 代表最重要，4 代表最不重要。

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

   • 在**“严重级别”**列表中，单击一个值以指示 Bug 对项目的影响。

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

   • 在**“会审”**列表中，单击会审子状态。

     有效值包括**“挂起”（默认值）、“详细信息”、“收到信息”和“已会审”。 此字段标识处于“已建议”**状态的 Bug 的会审级别。

   • 在**“受阻”列表中，如果问题使解决 Bug 的进度受阻，请单击“是”**。

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

3. 在**“详细信息”**选项卡上，提供尽可能详细的信息，以便其他团队成员可以了解必须修复的问题。

   • 在**“症状”**（必填）中，描述发现的代码缺陷或意外行为。

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

4. 在**“系统信息”**选项卡上，指定以下一类或几类信息：

   • 在**“发现环境”**中，描述在其中发现 Bug 的软件设置和配置。

   • 在**“发现途径”**中，描述 Bug 的发现途径。

     例如，Bug 可能是在客户评审过程中发现的，或是通过临时测试发现的。

5. 在**“系统信息”**选项卡上，描述在其中发现 Bug 的软件环境。

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

6. 在**“修复”**选项卡上，描述用于修复 Bug 的建议更改。

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

7. 在**“其他”**选项卡上，指定以下一类或多类信息：

   • 在**“发现版本”**列表中，单击或键入在其中发现潜在缺陷的版本的名称。

     提示

     每个版本都与一个唯一的版本名称相关联。 有关如何定义版本名称的信息，请参见自定义生成号。

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

   • 在**“初始估计”**中，键入修复 Bug 所需的小时数。

8. 在**“测试用例”和“所有链接”**选项卡上，可以创建从 Bug 到其他工作项（例如任务、更改请求、测试用例和其他 Bug）的链接。

   在**“附件”**选项卡上，可以附加为要修复的 Bug 提供更多详细信息的规范、图像或其他文件。

   有关更多信息，请参见本主题后面的以下各节：

   • 将 Bug 链接到其他工作项

   • 向要求添加详细信息、附件或超链接

9. 在工作项工具栏上，单击 “保存工作项”。

   提示

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

将 Bug 链接到其他工作项

通过在 Bug 与其他工作项之间建立关系，可以跟踪依赖项并更快速地查找相关信息。 在 Bug 的工作项窗体中，可以创建自动链接到 Bug 的工作项，或者可以创建指向现有工作项的链接。

使用**“测试用例”和“所有链接”**选项卡可创建指向特定类型工作项和特定类型链接的链接。 有关每个选项卡的限制的更多信息，请参见链接工作项 (CMMI)。

创建任务、Bug、更改请求、测试用例或其他工作项并将其链接到 Bug

1. 打开 Bug 的工作项窗体，然后执行以下操作之一：

   • 若要创建并链接到测试用例，请单击**“测试用例”选项卡，然后单击 “新建”**。

   • 若要创建其他任何类型的工作项并链接到它，请单击**“所有链接”选项卡，然后单击 “新建”**。

   将打开**“添加新的链接工作项”**对话框。

   

2. 在**“链接类型”**列表中，保留默认值，或单击下列选项之一：

   • 若要创建指向测试用例的链接，请单击**“测试方”**。

   • 若要创建指向其他任何类型工作项的链接，请单击**“相关”**或表示要跟踪的关系的其他链接类型。

3. 在**“工作项类型”**列表中，单击要创建的工作项的类型。

4. 在**“标题”**中，键入简短的针对性说明。

5. （可选）在**“注释”**中键入附加信息。

6. 单击**“确定”**。

   随即将打开与所指定工作项的类型相对应的窗体，其中含有您提供的信息。

7. 按下列主题所述，指定其余字段：

   • 任务 (CMMI)

   • 更改请求 (CMMI)

   • 测试用例 (CMMI)

   • 问题 (CMMI)

   • 风险 (CMMI)

   • 评审 (CMMI)

8. 单击 “保存工作项”。

将多个现有工作项链接到 Bug

1. 打开 Bug 的工作项窗体，然后执行以下操作之一：

   • 若要链接到一个或多个测试用例，请单击**“测试用例”选项卡，然后单击 “链接到”**。

   • 若要链接到一个或多个其他类型的工作项，请单击**“所有链接”选项卡，然后单击 “链接到”**。

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

   

2. 在**“链接类型”**列表中，保留默认值，或单击下列选项之一：

   • 若要创建指向测试用例的链接，请单击**“测试方”**。

   • 若要创建指向其他任何类型工作项的链接，请单击**“相关”**或表示要跟踪的关系的其他链接类型。

3. 单击**“浏览”**。

   将显示**“选择链接工作项”**对话框。

   

4. 在**“工作项 ID”**中键入工作项，或者浏览到要链接的工作项。

   也可以运行团队查询来查找要链接的工作项。 这些查询包括“活动 Bug”、“更改请求”、“打开的任务”、“打开的测试用例”和“打开的任务”。

5. 选中要链接到要求的每个工作项旁边的复选框。

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

6. （可选）键入对链接目标工作项的说明。

7. 单击**“确定”，然后单击 “保存工作项”**。

   提示

   Bug 和它链接到的工作项都将更新。

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

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

• 在以下选项卡中键入信息：“说明”、“重现步骤”、“系统信息”、“修复”或“历史记录”。

• 附加文件。

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

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

向 Bug 添加详细信息

1. 单击以下选项卡之一：“重现步骤”、“详细信息”、“系统信息”或“修复”。

2. 键入要添加的信息。

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

3. 单击 “保存工作项”。

向 Bug 添加附件

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

   • 将文件拖动到附件区。

   • 单击 或按 Ctrl+V 粘贴已复制的文件。

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

     （可选）在**“注释”框中，键入有关附件的更多信息。 若要关闭“附件”对话框，请单击“确定”**。

2. 单击 “保存工作项”。

向 Bug 添加超链接

1. 在**“所有链接”选项卡上，单击 “链接到”**。

   

2. 在**“链接类型”列表中，单击“超链接”**。

3. 在**“地址”**中，执行下列任务之一：

   • 如果目标是网站，请键入 URL，或者从 Internet 浏览器中复制该 URL，然后将其粘贴到**“地址”**框中。

   • 如果目标是服务器位置，请键入 UNC 名称格式的地址。

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

5. 单击**“确定”，然后单击 “保存工作项”**。

解决和关闭 Bug

团队可通过将 Bug 的**“状态”**设置为下列值之一来跟踪该 Bug 的进度：

• 已建议

• 活动

• 已解决

• 已关闭

团队成员创建 Bug 时，默认情况下它处于**“已建议”状态。 当团队接受当前迭代的 Bug 时，团队会将该 Bug 的状态更改为“活动”，并可能会创建任务来实现该 Bug。 当团队成员修复 Bug 后，会将该 Bug 的状态从“活动”更改为“已解决”。 在对修复进行验证之后，团队成员会将其状态从“已解决”更改为“已关闭”**。

任何团队成员都可更改 Bug 的状态。 此外，也可出于其他原因来解决或关闭无法修复的 Bug，如本主题后面部分所述。

有关可用于跟踪工作项状态的数据字段的更多信息，请参见指派、工作流和计划 (CMMI)。

更改 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 的日期和时间。

• 状态更改日期：更改 Bug 状态的日期和时间。

已解决

指派为修复 Bug 的团队成员在 Bug 得到修复时对其进行解决。 或者，团队成员可能确定应出于其他原因来解决或关闭 Bug，如下表所述。

由“已解决”改为“活动”

由于下表所述的原因之一，团队成员可以将 Bug 从“已解决”状态重新激活：

原因	何时使用	要采取的其他操作
未修复	当解决方法不可接受或修复不正确时。	提供有关您拒绝解决方法或修复未正确工作的原因的详细信息。 此信息应能够帮助拥有该 Bug 的下一个人员正确解决该 Bug。
测试未通过	当测试证明仍存在 Bug 时。	提供有关哪个测试未通过以及在哪个生成中的详细信息。

当团队成员将 Bug 从“已解决”状态重新激活时会自动捕获以下数据：

• 激活者：重新激活 Bug 的团队成员的名字。

• 激活日期：根据服务器时钟记录的重新激活 Bug 的日期和时间。

已关闭

如果某个已关闭的 Bug 所描述的问题或代码缺陷重新出现或以前未修复，则团队成员可以将该 Bug 更改为活动状态。

从关闭到活动

在将 Bug 从已关闭状态重新激活时，可以指定下表中的原因之一：

原因	何时使用	要采取的其他操作
回归测试	当 Bug 在以后的代码生成中重新出现时。	无。
错误地关闭	当 Bug 被错误地关闭或因其他原因关闭时。	无。

当团队成员将 Bug 从“已关闭”状态重新激活时会自动捕获以下数据：

• 激活者：重新激活 Bug 的团队成员的名字。

• 激活日期：根据服务器时钟记录的重新激活 Bug 的日期和时间。

请参见

其他资源

工作项和工作流 (CMMI)

项目 (CMMI)