テスト影響分析 (TIA) を使用してテストを高速化する

[アーティクル]
06/10/2024

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

継続的インテグレーション (CI) は、業界の重要なプラクティスです。統合は頻繁に行われ、統合エラーをできるだけ早く検出するために回帰テストを実行する自動ビルドで検証されます。しかし、コードベースが成長し成熟するにつれて、そのリグレッションテスト一式も多くなる傾向があり、完全なリグレッションテストの実行には数時間かかる場合があります。このテストは統合の頻度を遅くし、最終的には継続的インテグレーションの目的を損ないます。

CI パイプラインを迅速に完了するために、一部のチームでは、実行時間の長いテストの実行をパイプライン内の別のステージに延期します。しかし、このアクションは継続的インテグレーションをさらに台無しにするだけです。

代わりに、ビルドパイプラインで Visual Studio テストタスクを使用するときに、テスト影響分析 (TIA) を有効にします。 TIA では、自動テスト選択によって増分検証を実行します。コミットされているコードの検証に必要なテストのサブセットのみが自動選択されます。 CI/CD パイプラインに入る特定のコードコミットに対して、TIA は、そのコミットの検証に必要な関連テストのみを選択して実行します。そのため、テストの実行はより迅速に完了し、障害が発生した場合はより早くアラートを受け取り、すべて関連性によってスコープが設定されるため、分析も高速になります。

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 スコープとアプリケーションの詳細

テスト影響分析を有効にする

TIA は、Visual Studio テストタスクのバージョン 2.* でサポートされています。アプリが単一層アプリケーションの場合は、タスク UI で [影響を受けたテストのみを実行する] をチェックするだけです。テストインパクトデータコレクターは自動的に構成されます。これ以上の手順は不要です。

VS Test タスク 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 では、構成された周期ですべてのテストを実行するように条件を設定できます。このオプションを設定することをお勧めします。これは、テストの選択を規制する手段です。
ビルド変数を設定する。 TIA が VSTest タスクで有効化された後でも、変数である DisableTestImpactAnalysis を true に設定することで、特定のビルドを無効化できます。このオーバーライドにより、TIA はそのビルドのすべてのテストを強制的に実行します。その後のビルドでは、TIA は最適化されたテスト選択に戻ります。

TIA でコミットを開いたときに不明なファイルの種類があると、すべてのテストを実行するようフォールバックします。このアクションは安全の観点からは良いことですが、この動作を調整すると便利な場合があります。次に例を示します。

TI_IncludePathFilters 変数を特定のパスに設定して、TIA で適用するリポジトリにこれらのパスのみを含めることができます。このアクションは、チームが共有リポジトリを使用する場合に便利です。この変数を設定すると、設定に含まれていない他のすべてのパスに対して TIA が無効になります。
TIA_IncludePathFilters 変数を設定して、テストの結果に影響を与えず、変更を無視するファイルの種類を指定します。たとえば、.csproj ファイルへの変更を無視するには、変数を値 : !\*\*\\\*.csproj に設定します。

変数を設定するときに minimatch パターンを使用し、複数の項目をセミコロンで区切ります。

TIA が適切なテストを選択しているかどうかを評価するには、次を実行します。

選択内容を手動で検証します。 SUT とテストがどのように設計されているか知っている開発者であれば、TIA レポート機能を使用してテストの選択を手動で検証できます。
TIA で選択したテストを実行し、すべてのテストを順番に実行します。ビルドパイプラインでは 2 つのテストタスクが使用されます。1 つは、影響を受けるテストのみを実行し (T1)、もう 1 つはすべてのテストを実行します (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 カスタム依存関係マッピングに関するページを参照してください。

参照

ヘルプとサポート

トラブルシューティングページを参照してください。
Stack Overflow に関するアドバイスを受け取り、Developer Community を介してサポートを受ける

次の方法で共有