需求可跟踪性

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

“需求可跟踪性”是指能够关联和记录开发过程的两个或更多阶段,然后可以从其源向前或向后跟踪这些阶段。 需求可跟踪性可帮助团队深入了解指标,例如“需求的质量”或“交付需求的准备情况”。 需求可跟踪性的一个基本方面是将需求关联到测试用例、错误和代码更改。

阅读术语表以了解测试报表术语。

运行自动测试的敏捷团队

敏捷团队的特征包括但不限于以下几种

  • 更快的发布周期
  • 管道中持续测试
  • 可忽略不计的手动测试占用情况;仅限于探索性测试
  • 高度自动化

以下几节从质量错误来源的角度探讨敏捷团队的可跟踪性。

质量可跟踪性

通过简单的测试结果监控方法,将项目要求与测试结果联系起来,实现端到端的可追溯性。 要将自动测试与需求联系起来,请参阅测试报告

  1. 在生成或发布摘要的“测试”选项卡下的结果部分中,选择要链接到需求的测试,然后选择“链接”。

    选择要链接到需求的测试

  2. 选择要以下列方式之一链接到所选测试的工作项:

    • 从建议的工作项列表中选择适用的工作项。 该列表基于最近查看和更新的工作项。
    • 指定工作项 ID。
    • 根据标题文本搜索工作项。

    选择需求工作项

    该列表仅显示属于“需求”类别的工作项。

  3. 一旦需求与测试结果建立了链接,就可以按需求分组查看测试结果。 需求是系统提供的众多“分组依据”选项之一,用于轻松浏览测试结果。

    按需求对结果进行分组

  4. 团队通常希望将需求可跟踪性的汇总视图固定到仪表板。 为此,请使用“需求质量”小组件。

    创建团队仪表板

  5. 使用所需的选项配置“需求质量”小组件并保存。

    • 需求查询:选择捕获需求的工作项查询,例如当前迭代中的用户情景。
    • 质量数据:指定应跟踪其需求质量的管道阶段。

    配置小组件

  6. 查看团队仪表板中的小组件。 其中列出了范围中的所有需求,还有测试的通过率和失败测试的数量。 选择“失败”测试计数将打开所选生成或版本的“测试”选项卡。 小组件还有助于跟踪需求,而无需任何关联的测试。

    不含测试的跟踪需求

通过简单的测试结果监控方法,将项目要求与测试结果联系起来,实现端到端的可追溯性。 要将自动测试与需求联系起来,请参阅测试报告

  1. 在生成或发布摘要的“测试”选项卡下的结果部分中,选择要链接到需求的测试,然后选择“链接”。

    选择要链接到需求的测试

  2. 选择要以下列方式之一链接到所选测试的工作项:

    • 从建议的工作项列表中选择适用的工作项。 该列表基于最近查看和更新的工作项。
    • 指定工作项 ID。
    • 根据标题文本搜索工作项。

    选择需求工作项

    该列表仅显示属于“需求”类别的工作项。

  3. 团队通常希望将需求可跟踪性的汇总视图固定到仪表板。 为此,请使用“需求质量”小组件。

    创建团队仪表板

  4. 使用所需的选项配置“需求质量”小组件并保存。

    • 需求查询:选择捕获需求的工作项查询,例如当前迭代中的用户情景。
    • 质量数据:指定应跟踪其需求质量的管道阶段。

    配置小组件

  5. 查看团队仪表板中的小组件。 其中列出了范围中的所有需求,还有测试的通过率和失败测试的数量。 选择“失败”测试计数将打开所选生成或版本的“测试”选项卡。 小组件还有助于跟踪需求,而无需任何关联的测试。

    不含测试的跟踪需求

Bug 可跟踪性

测试可衡量向用户交付更改的置信度。 测试失败表示更改出现问题。 失败的原因可能包括受测源出错、测试代码错误、环境问题、不可靠测试等。 Bug 提供了一种可靠的方法来跟踪测试失败,并促使团队负责采取所需的补救措施。 要将错误与测试结果联系起来,请参阅测试报告

  1. 在“测试”选项卡的结果部分中,选择应为其创建错误的测试,然后选择“错误”。 多个测试结果可被映射到一个错误上,这通常是在故障原因归结为一个原因(如不可用的依赖服务、数据库连接故障或类似问题)时进行的。

    将 bug 链接到测试

  2. 打开工作项。 错误捕获测试结果的完整上下文,包括错误信息、堆栈跟踪、注释等关键信息。

    捕获 bug 详细信息

  3. 直接在“测试”选项卡中的上下文中查看包含测试结果的 bug。“工作项”选项卡还列出了测试结果的任何链接要求。

    在“测试”选项卡中查看 bug

  4. 在工作项中,直接导航到关联的测试结果。 测试用例和特定测试结果都链接到 bug。

    Bug 中的测试链接

  5. 在工作项中,选择“测试用例”或“测试结果”以直接转到所选生成或发布的“测试”页。 可以排查故障,更新 bug 中的分析,并根据需要进行更改以修复问题。 虽然这两个链接都指向“测试”选项卡,但默认部分包括“历史记录”和“调试”。

    “测试”选项卡全页视图

源可跟踪性

排查在一段时间内持续发生的测试失败时,务必要反向跟踪到初始更改集,也就是失败的源。 这一步骤可以大大有助于缩小识别有问题的测试或受测源的范围。 要发现测试失败的第一个实例并将其跟踪回关联的代码更改,请访问生成或发布中的“测试”选项卡。

  1. 在“测试”选项卡中,选择要分析的测试失败。 根据是生成还是发布,选择测试的“生成失败”或“发布失败”列。

    查看失败的版本

    “测试”选项卡的另一个实例将在新窗口中打开,其中显示了测试的第一个连续失败实例。

    发起测试失败

  2. 根据生成或发布管道,可以选择时间线或管道视图以查看提交的代码更改。 可以分析代码更改,以确定测试失败的潜在根本原因。

    查看代码提交

使用计划内测试的传统团队

从手动测试转向持续、自动化测试的团队,如果已经拥有自动化测试子集,可以将其作为管道的一部分或按需执行计划内测试又称作“自动测试”,可以关联到测试计划中的测试用例,并且可从 Azure Test Plans 中执行。 关联后,这些测试有助于实现相应需求的质量指标。

帮助和支持