通过

使用测试影响分析 (TIA) 加快测试速度

  • 项目

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

持续集成 (CI) 是业内的关键实践。 集成会很频繁，并且使用运行回归测试的自动生成进行验证，以尽早检测出集成错误。 但随着代码库的增长和成熟，其回归测试套件也会增长，甚至会增长到运行完整回归测试可能需要数小时的地步。 此测试会降低集成频率，最终违背了持续集成的目的。

为了让 CI 管道快速完成，某些团队会将运行时间较长的测试推迟到管道中的单独阶段执行。 但此操作只会进一步使持续集成失去意义。

相反，在生成管道中使用 Visual Studio 测试任务时，请启用测试影响分析 (TIA)。 TIA 通过自动测试选择执行增量验证。 它将自动选择验证所提交代码所需的一小部分测试。 对于进入 CI/CD 管道的给定代码提交，TIA 将仅选择并运行验证该提交所需的相关测试。 因此，测试运行会更快完成，如果出现故障，则会更快收到警报，而且由于所有测试都是按相关性范围进行的，分析也会更快。

使用 TIA 时的测试时间比较

测试影响分析具有：

  • 可靠的测试选择机制。 它包括现有受影响的测试、以前未通过的测试以及新添加的测试。
  • 安全回退。 对于 TIA 无法理解的提交和场景，它会回退到运行所有测试。 TIA 目前仅限于托管代码和单计算机拓扑。 因此，例如，如果代码提交包含对 HTML 或 CSS 文件的更改，则它无法分析这些更改，并且会回退到运行所有测试。
  • 可配置的替代。 可以按配置的周期运行所有测试。

但是，在 Visual Studio 2015 中使用 TIA 时，请注意以下注意事项：

  • 并行运行测试。 在这种情况下，测试将连续运行。
  • 在启用代码覆盖率的情况下运行测试。 在这种情况下，不会收集代码覆盖率数据。

测试影响分析支持的方案

以下情况支持测试影响分析 (TIA)：

  • TFS 2017 Update 1 及更高版本和 Azure Pipelines
  • 生成管道中的 Visual Studio 测试任务版本 2.*
  • 生成具有多个 VSTest 任务的 vNext
  • 生成代理上的 VS2015 Update 3 及更高版本
  • 本地和托管的生成代理
  • CI 和 PR 工作流
  • Git、GitHub、其他 Git、TFVC 存储库（包括带解决方法的部分映射的 TFVC 存储库）
  • 使用 HTTP/HTTPS 协议的 IIS 交互（通过 REST、SOAP API）
  • 自动测试
  • 单计算机拓扑。 测试和应用 (SUT) 必须在同一台计算机上运行。
  • 托管代码（任何.NET Framework 应用、任何 .NET 服务）

以下情况不支持 TIA：

  • 多计算机拓扑（测试对部署到不同计算机的应用运行）
  • 数据驱动的测试
  • 特定于测试适配器的并行测试执行
  • .NET Core
  • UWP

有关 TIA 范围和应用程序的详细信息

启用测试影响分析

Visual Studio 测试任务的版本 2.* 支持 TIA。 如果应用是单层应用程序，则只需在任务 UI 中勾选“仅运行受影响的测试”。 “测试影响”数据收集器会自动配置。 无需执行其他步骤。

在 VS 测试任务 UI 中启用 TIA

如果应用程序在 IIS 上下文中与服务交互，则还必须使用“.runsettings”文件将测试影响数据收集器配置为在 IIS 上下文中运行。 以下是创建此配置的示例：

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <!-- This is the TestImpact data collector.-->
      <DataCollector uri="datacollector://microsoft/TestImpact/1.0" assemblyQualifiedName="Microsoft.VisualStudio.TraceCollector.TestImpactDataCollector, Microsoft.VisualStudio.TraceCollector, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" friendlyName="Test Impact">
        <Configuration>
          <!-- enable IIS data collection-->
          <InstrumentIIS>True</InstrumentIIS>
          <!-- file level data collection -->
          <ImpactLevel>file</ImpactLevel>
          <!-- any job agent related executable or any other service that the test is using needs to be profiled. -->
          <ServicesToInstrument>
            <Name>TeamFoundationSshService</Name>
          </ServicesToInstrument>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

查看测试影响分析结果

TIA 已集成到现有测试报表的摘要和详细信息级别（包括通知电子邮件）。

报表摘要包括 TIA 集成

报表测试页面包括 TIA 集成

有关 TIA 和 Azure Pipelines 集成的详细信息

管理测试影响分析行为

可以影响测试运行期间包含或忽略测试的方式：

  • 通过 VSTest 任务 UI。 可以将 TIA 设置为按配置的周期运行所有测试。 建议设置此选项，这是调节测试选择的方法。
  • 通过设置生成变量。 即使在 VSTest 任务中启用了 TIA，也可以通过将变量 DisableTestImpactAnalysis 设置为 true 来为特定生成将其禁用。 该替代将强制 TIA 针对该生成运行所有测试。 在后续版本中，TIA 将恢复为优化的测试选择。

当 TIA 打开提交并看到未知文件类型时，它会回退到运行所有测试。 虽然从安全角度来看，此操作很好，但在某些情况下，优化此行为可能很有用。 例如：

  • 将 TI_IncludePathFilters 变量设置为特定路径，以便在要应用 TIA 的存储库中仅包含这些路径。 当团队使用共享存储库时，此操作非常有用。 设置此变量会禁用设置中未包括的所有其他路径的 TIA。
  • 设置 TIA_IncludePathFilters 变量以指定不影响测试结果的文件类型以及应忽略其更改的文件类型。 例如，要忽略对 .csproj 文件的更改，请将该变量设置为值：!\*\*\\\*.csproj。

设置变量时使用 minimatch 模式，并使用分号分隔多个项。

要评估 TIA 是否选择适当的测试：

  • 手动验证所选内容。 了解如何构建 SUT 和测试的开发人员可以使用 TIA 报表功能手动验证测试选择。
  • 运行 TIA 选择的测试，然后按顺序运行所有测试。 在生成管道中，使用两个测试任务，一个只运行受影响的测试 (T1)，一个运行所有测试 (T2)。 如果 T1 通过，确认 T2 是否也通过。 如果 T1 中有测试失败，确认 T2 报告的是相同的失败测试。

有关 TIA 高级配置的详细信息。

提供自定义依赖项映射

TIA 使用以下形式的依赖项映射。

TestMethod1
  dependency1
  dependency2
TestMethod2
  dependency1
  dependency3

TIA 可以为托管代码执行生成此类依赖项映射。 如果此类依赖项驻留在 .cs 和 .vb 文件中，TIA 可以自动监视进入此类文件的提交，然后运行在其依赖项列表中包含这些源文件的测试。

可以通过将依赖项映射显式提供为 XML 文件来扩展 TIA 的范围。 例如，你可能希望支持其他语言（如 JavaScript 或 C++）的代码，或者支持在不同计算机上运行测试和产品代码的方案。 映射甚至可以是近似值，并且可以根据测试用例筛选器（如通常在 VSTest 任务参数中提供）来指定要运行的测试集。

XML 文件应签入到存储库中，通常位于根级别。 然后将生成变量 TIA.UserMapFile 设置为指向该文件。 例如，如果文件名为 TIAmap.xml，将该变量设置为 $(System.DefaultWorkingDirectory)/TIAmap.xml。

有关 XML 文件格式的示例，请参阅 TIA 自定义依赖项映射。

另请参阅

帮助和支持