工作项和工作流 (CMMI)

团队使用工作项来跟踪、监视和报告产品及其功能的开发情况。 工作项是团队成员在 Visual Studio Team Foundation Server 中创建的数据库记录，用于记录工作的定义、分配、优先级别和状态。 MSF过程模板CMMI process improvement v6.0定义了九种类型的工作项:要求，任务，更改请求，bug，问题，函数，检查，测试用例和共享步骤的风险。 测试用例和共享步骤专门用于测试运行程序和 Microsoft 测试管理器。

主题内容 定义要求、任务和其他工作项 创建要求、任务或其他类型的工作项 一次创建多个要求、任务或其他工作项 创建自动链接到其他工作项的工作项 使用 Test and Lab Manager 创建测试用例和测试计划 使用 Test Runner 和 Test and Lab Manager 打开和跟踪 Bug 查看分配给您的工作项 自定义工作项类型和相关任务

通过定义各个工作项并将这些工作项存储在公共数据库和指标仓库中，可以随时回答有关项目运行状况的各种问题。 工作项、工作项间的链接和文件附件都存储在用于跟踪工作项的 Team Foundation 数据库中，如下图所示。

定义要求、任务和其他工作项

可以在工作项窗体中指定和更新工作项信息。 本节中的主题提供了有关如何在各个工作项窗体中工作的详细信息。

任务	相关内容
定义和跟踪功能要求和操作要求。 团队创建要求来捕获和跟踪产品必须解决客户问题的方式。 团队可以使用要求来描述方案和服务质量、安全措施、安全性、功能、操作和用户界面标准。 要求将经历“已建议”、“活动”、“已解决”和“已关闭”工作流状态。	要求 (CMMI)
跟踪和审批更改请求。团队可以使用更改请求跟踪对产品或基线的某一部分建议的更改。 如果建议对配置管理系统中的任何工作产品进行更改，则团队成员应该创建更改请求。 变更控制委员会应该先分析然后接受或拒绝建议的更改。 如果委员会接受更改请求，则团队将生成任务来实现更改。 更改请求将经历“已建议”、“活动”、“已解决”和“已关闭”工作流状态。	更改请求 (CMMI)
跟踪和估计工作。 团队将创建任务来跟踪实现要求或其他工作环节所必须花费的小时数。 任务应表示可以在一、两天内完成的工作单元。 可以将较大的任务拆分成较小的子任务。 可以创建任务来跟踪以下工作：开发代码、设计和运行测试、解决 Bug 以及执行回归测试。 此外，还可以创建任务来支持团队必须执行的一般性工作。 通过跟踪每个任务的工时，团队可以深入了解在项目上取得的进度。 任务将经历“已建议”、“活动”、“已解决”和“已关闭”工作流状态。 可以使用“剩余工作”、“燃尽”和“燃速”报表来监视团队进度、识别工作流中的问题并确定团队燃速。	任务 (CMMI) “剩余工时”报表 “燃尽和燃速”报表（敏捷）
打开和跟踪 Bug。 可以通过创建 Bug 工作项来跟踪代码缺陷。 通过创建 Bug，可以采用有助于其他团队成员了解问题的全面影响的方式来准确报告缺陷。 在 Bug 中，您应描述导致意外行为的步骤，以便其他人可以重现 Bug，测试结果应清楚地表明问题所在。 此描述的清晰度和完整性通常会影响修复 Bug 的可能性。 Bug 将经历“已建议”、“活动”、“已解决”和“已关闭”工作流状态。 可以使用“Bug 状态”报表来跟踪团队在解决和关闭 Bug 方面的进度。	Bug (CMMI) “Bug 状态”报表
定义和管理进度障碍。 可以通过创建问题工作项来定义项目的已知问题、潜在问题或障碍。 在需要采取具体措施时，一个问题可以转换成一个或多个团队必须完成的任务，以便缓解问题。 例如，技术问题可能导致需要构造体系结构原型。 团队应始终鼓励其成员识别问题，并确保他们对阻碍团队成功的问题提供尽可能多的相关信息。 团队应准许个人识别问题，而不要让个人害怕因诚实地表达了假设性或有争议的观点而遭到报复。 与维持消极的风险环境的团队相比，创建和维持积极的问题管理环境的团队将更早、更迅速地识别并解决问题，并且所遇到的混乱和冲突也更少。 问题将经历“已建议”、“活动”、“已解决”和“已关闭”工作流状态。 您可以使用“问题”工作簿对问题进行检查、分级和管理。	问题 (CMMI) “问题”工作簿
确定并减轻项目成功的风险。团队使用风险工作项对能够对项目产生负面效果的可能的事件或情况进行归档。 项目管理的关键环节是确定并管理项目风险。 风险工作项提供了特定字段，以记录缓解和应变计划以及跟踪风险对开发工作可能造成的影响。 风险将经历“已建议”、“活动”、“已解决”和“已关闭”工作流状态。	风险 (CMMI)
捕获详细信息以及团队在代码评审期间制定的决策。团队使用评审工作项对设计或代码评审的结果进行归档。 评审工作项具有特定字段，这些字段用于记录有关设计或代码在名称正确性、代码相关性、扩展性、代码复杂性、算法复杂性以及代码安全性方面的达标情况详细信息。 评审工作项支持对决策以及团队为保证产品质量而执行的工作进行记录维护。 检查将经历“活动”、“已解决”和“已关闭”工作流状态。	评审 (CMMI)
测试应用程序。 团队可以使用测试用例来定义将支持用户情景测试的测试。 可以定义指定要运行的操作和验证步骤序列的手动测试用例，也可以指定引用自动化文件的自动测试用例。 说明 用于创建和定义测试用例的建议客户端为 测试管理器。您还可以使用此工具创建测试套件和测试配置，从而为项目确定完整的测试条件范围。在测试配置中，指定要运行测试用例和测试套件的软件环境。有关更多信息，请参见测试应用程序。 测试用例将经历“设计”、“就绪”和“已关闭”工作流状态。 可以使用“测试用例准备情况”报表来确定团队在定义测试用例方面的进度。	测试用例 (CMMI) “测试用例准备情况”报表
定义共享步骤。 团队可以使用共享步骤来简化手动测试用例的定义和维护。 在共享步骤中，定义要作为测试用例一部分运行的操作和验证步骤序列。 许多测试需要对多个测试用例执行相同的步骤序列。 通过创建共享步骤，可以一次性地定义步骤序列并将其插入到许多测试用例中。 重要事项 用于创建和定义共享步骤的建议客户端为 测试管理器。可以使用团队资源管理器和 Team Web Access 查看这些类型的工作项；然而，不能使用 Team Web Access 修改或更新某些字段。 共享步骤将经历“活动”和“已关闭”工作流状态。	Shared Steps (CMMI)

创建要求、任务或其他类型的工作项

通过打开 Team Web Access 或团队资源管理器并执行本节中的过程，可以创建工作项。 创建工作项后，可以随时修改和添加详细信息（如冲刺 (sprint) 进度）。

创建要求、任务或其他类型的工作项

1. 打开 Team Web Access 或团队资源管理器，并连接到包含要创建工作项的团队项目的团队项目集合。

   有关更多信息，请参见在 Team Foundation Server 中连接团队项目。

2. 执行以下步骤之一：

   • 在 Team Web Access，找到导航窗格的快速启动区域，然后选择 新建工作项 箭头。 在 工作项类型 菜单中，选择要创建的工作项的类型。

   • 在 团队资源管理器，打开 团队 菜单，指向 添加工作项，然后选择工作项的类型。

   会打开一个具有指定类型的工作项窗体。

   

3. 定义窗体顶部中的字段，并且在工作项类型需要时为窗体底部中的每个选项卡定义字段。

   有关更多信息，请参见本主题前面的定义用户情景、任务或其他工作项。

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

   备注

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

一次创建多个要求、任务或其他工作项

可以使用 Office Excel 快速定义自动链接到要求的多个任务。 此外，还可以使用 Office Excel 快速定义要求、任务和问题。 有关详细信息，请参阅下列主题：

• 使用绑定到 Team Foundation Server 的 Microsoft Excel 管理工作项

• 使用工作项的树列表执行自顶向下的规划（在 Excel 中）

创建自动链接到其他工作项的工作项

可以创建自动链接到现有要求或其他工作项的工作项。 可以从打开的工作项窗体或工作项查询的结果列表中执行此操作。

创建链接到现有工作项的工作项

1. 打开 Team Web Access 或团队资源管理器，并连接到包含要定义链接工作项的团队项目的项目集合。

2. 选择 打开的工作项 团队查询，然后选择 打开。

3. 执行以下操作之一：

   • 在 Team Web Access，请在新工作项要链接到的现有工作项旁边的下箭头，然后选择 添加新的链接工作项。

   • 在 团队资源管理器，选择新工作项要链接到的现有工作项，然后选择 添加新的链接工作项。

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

   

4. 定义以下字段：

   • 在 链接类型 列表中，选择对应于工作项之间的关系要创建的链接类型。

     若要将某个任务链接到要求，选择 子级。

     对于更改请求的链接，请选择 影响者。

     对于一个链接到测试用例，请选择 测试方。

     对于所有其他类型工作项的链接，请选择 相关 或表示要跟踪的关系的其他链接类型。

   • 在 工作项类型 列表中，选择要创建的工作项的类型。

   • 在**“标题”**中，键入一个描述要跟踪的要求、任务或其他类型工作项的名称。

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

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

   将打开一个工作项窗体，其中包含您已提供的信息。

6. 按照工作项类型的需要定义其余字段。

   有关更多信息，请参见本主题前面的定义要求、任务或其他工作项。

7. 选择 保存工作项。

使用 Test and Lab Manager 创建测试用例和测试计划

通过使用 测试管理器，不仅可以创建测试用例，还可以创建支持项目测试的测试套件和测试配置。 可以使用测试配置定义要运行测试用例和测试套件的软件环境。

测试计划、测试套件和测试配置

可以将测试用例组织到测试计划的测试套件层次结构中，从而对测试用例分组。 通过创建测试套件，可将测试用例的集合作为组来运行。 有关如何使用 测试管理器 定义测试用例、测试套件和测试计划的更多信息，请参见测试应用程序。

使用 Test Runner 和 Test and Lab Manager 打开并跟踪 Bug

可以使用测试管理器提交 Bug，Bug 中自动包含有关您已运行的测试用例和测试环境的信息以及发现代码缺陷的特定测试步骤。 使用测试管理器创建的 Bug 会自动将 Bug 链接到发现该 Bug 时已运行的测试用例。

您可以按下列方式创建 Bug：

• 若是使用 测试运行程序 运行测试、查看测试结果或查看 Bug，则使用 测试管理器

• 使用 Team Web Access 或团队资源管理器

• 使用 Office Excel（在同时提交多个 Bug 时很有用）

有关如何使用 测试管理器 提交、跟踪和验证 Bug 和修复的信息，请参见下表中的相关内容。

任务	相关内容
创建 Bug。 若在临时测试中发现了异常的应用程序行为，则可以迅速创建 Bug。	如何：使用 Microsoft 测试管理器提交 Bug
收集诊断数据支持调试。 使用 测试运行程序，可以收集有关用托管代码编写的，开发人员随后可以使用IntelliTrace查找错误的应用程序的诊断跟踪数据。	在难以重现的 Bug 中包含诊断跟踪数据
创建记录操作日志文件并将其添加到 Bug。 运行手动测试时，可以采用文本形式将操作记录在日志文件中。 可以自动将此文件添加到在运行手动测试时创建的任何 Bug 中。	如何：使用 Bug 中的录制操作创建测试用例
根据 Bug 和记录操作日志文件创建测试用例。 可以使用操作日志根据 Bug 或测试结果来创建手动测试用例。 通过采用此方法，您不必键入所有步骤即可创建测试用例。	如何：使用录制的操作创建测试用例
基于测试结果验证和更新 Bug 的状态。 如果提交某个基于测试用例的 Bug，则可以直接从 Microsoft 测试管理器 中的“我的 Bug”列表验证该 Bug。 若要采取此方法，测试结果必须与测试用例相关联。 可以迅速地重新运行测试、基于结果更改 Bug 的状态并向 Bug 添加注释。	如何：使用 Microsoft 测试管理器验证 Bug 是否已修复

查看分配给您的工作项

团队成员通过打开“我的工作项”团队查询或通过访问“我的面板”，可以快速查找分配给其的工作项。 有关详细信息，请参阅下列主题：

• 共享查询 (CMMI)

• 我的面板 (Agile)

• 查找和编辑指派给您的工作项

自定义工作项类型和相关任务

任务	相关内容
了解可以用于在所有类型的工作项间跟踪信息的字段。 用于跟踪工作项的数据库存储未在工作项窗体中出现的字段的数据。 您可以了解有关这些工作项字段、特定字段的限制以及进行报告和索引的字段的更多信息。	工作项字段参考 (Visual Studio ALM)
添加、移除或自定义使用各种类型的工作项跟踪数据的方式。 您可以根据自己的要求自定义现有类型的工作项或新建类型。 每种类型的工作项都有一个对应的 XML 定义文件，该文件将导入到团队项目。	所有 WITD XML 元素参考
自定义用于跟踪工作项的对象，以支持跟踪项目的要求。 您可以自定义团队用来跟踪进度的数据字段、工作流和工作项窗体。 若要自定义用于跟踪工作项的对象，您可修改某个 XML 文件并将其导入承载项目集合的服务器。	自定义项目跟踪数据、窗体、工作流及其他对象
添加、移除或修改用于控制工作流的状态或转换。 通过定义工作流的初始状态、有效状态、这些状态之间的有效转换以及有权执行这些转换的用户或组，可以控制该工作流。 工作项类型的 WORKFLOW 节控制如何跟踪工作项。	定义和自定义工作项工作流
修改和自定义某种类型的工作项的窗体。 通过工作项类型定义中的 FORM 节，可控制该工作项类型显示用户界面元素的方式。 每种工作项类型必须只有一个窗体。 您可以描述整个窗体，包括其所有选项卡、字段和组。	设计和自定义工作项窗体

请参见

概念

选择过程模板

项目 (CMMI)