テスト影響分析の台頭

スイートとタグの作成

ユニット、サービス、機能UIの主要なグループ分け。単体テスト内では、他のサブセットをサンプリングする「エクスプレス」を含む、意味のあるサブグループのタグ。

「ショッピングカート」テストの実行後、1つを除いてすべて合格しました。

このアプローチは、Ant、Maven、MSBuild、Rakeなどの再帰的なビルドテクノロジーで機能します。

歴史的に、チームはテストを無限に高速化することを諦め、スイートまたはタグを使用して、いつでもテストのサブセットをターゲットにしてきました。スイートとタグを作成することで、テストのサブセットを言葉で説明できます。たとえば、「ショッピングカートのUIテスト」です。タグまたはスイートは、アプリケーションのビジネス分野、または技術的または階層的なグループ分けを暗示している可能性があります。タグとスイートを定義するには、専門家の設計上の創造性が必要です。少なくとも、最適なグループ分けを目指して努力するためには。これは、人間が判断するのが難しい場合でも、不十分、不正確、不正確にグループ化される可能性があることも意味します。同時に実行されるテストの数が少なすぎたり多すぎたりすると、1つのスイートのみを実行する可能性が高くなります。これは、コンピューティングリソースと時間の無駄遣いになり、バグが見落とされるリスクもあります。チームは、コミットごとに小さいスイートを使用するCIジョブと、すべてのテストを実行する夜間ビルドジョブを選択する場合があります。明らかに、それは悪いニュースを遅らせ、継続的インテグレーションの目的を無効にします。

しかし、スイートとタグは、ソフトウェア開発の世界の大部分がテストコードベースを整理してきた方法です。

ソースとテストの事前計算されたグラフ

概念的な「サイズ」指定を持つ276のテスト。

特定のコミットに対して実行されたもの。2つの障害が発生しました。たまたま、それらのいくつかは小さく、いくつかは中程度、いくつかは大きいことがわかりました。ツリー/フラクタルを描いたのは、概念を説明するのに役立つからです（実際にはそうではありません）。

Googleの伝説的な社内ビルドシステムBlazeは、長年にわたっていくつかのオープンソーステクノロジーにコピーされてきました。最も注目すべきは、FacebookのBuckとGoogleのBazelです。Twitter、Foursquare、SquareによるPants。Google内のBlazeは、モノレポ全体で単一の**有向グラフ**をナビゲートします。Blazeには、テストを本番コードに直接関連付けるメカニズムがあります。そのメカニズムは、本番ソースと関連するテストソースのきめ細かいディレクトリツリーです。チェックインされたBUILDファイルによる明示的な依存関係宣言があります。これらのBUILDファイルは、開発者によって維持および進化させることができますが、自動化ツールによって正しいか正しくないかを確認することもできます。このプロセスを時間をかけて繰り返すと、有向グラフが正確かつ効率的になります。

重要なことに、そのツールは依存関係に関する冗長な主張を指摘する可能性があります。したがって、特定のディレクトリ/パッケージ/名前空間の場合、開発者はテストのサブセットを非常に簡単に開始できますが、BUILDファイルから有向グラフを介して可能なものだけです。開発者にとって統合前と統合インフラストラクチャの両方にとって究極の時間の節約は、スケーリングされたCIインフラストラクチャ「Forge」（後のTAP）であり、この組み込みインテリジェンスに基づいて実行するテストの自動サブセット化でした。

Google規模の継続的テストの抑制には、驚くべき統計がたくさんあります。私の意見では、これはGoogleに数千万ドルの費用がかかりましたが、長年にわたって数十億ドルの利益をもたらしました。おそらく、収益：賃金の比率よりもはるかに大きいでしょう。

Microsoftによる広範なTIAの取り組み

Microsoftは、テスト影響分析のアイデアを製品化するために最も長く協調的な努力を続け、その概念にその名前とその頭字語を与えました。

これまでに、2017年3月から8月までのブログ記事シリーズがあります。**テスト影響分析による継続的テストの高速化-**パート1、パート2、パート3、およびパート4。

これに関する古い記事は8年前にさかのぼります

1. Visual Studio 2010でのテスト影響分析 (2009)
2. テスト影響分析によるテストプロセスの合理化) (2010)
3. 前回のビルド以降、どのテストを実行する必要がありますか？ (2010)
4. 方法：コード変更後にどのテストを実行する必要があるかを確認するためのデータを収集する (2010)
5. テスト影響分析 (2011)

MicrosoftのPratap Lakshmanは、彼らの実装の進化について詳しく説明しました。TIA技術の現在の進化に関して、Pratapは次のように述べています：[1]

        Testcasemethod1 <--> a.cs, b.cs. d.cs
        Testcasemethod2 <--> a.cs, k.cs, z.cs 

TFSとVisual StudioにおけるTIAの最初の数年間について、彼は次のように述べています。

従来のコードカバレッジツールとスクリプトを使用したテスト影響分析

HedgeServで働いていたとき、最新の既製のコードカバレッジツールを同じ影響分析に活用するというアイデアがありました。そのアイデアから、2つの概念実証ブログエントリ（Githubに関連コードがあります）を作成しました。1つはMavenとJava[2]用、もう1つはPython[3]用です。eejitのように、斬新な発明をしたと思っていましたが、当時はこの分野にかなりの先行技術（上記のMicrosoft）があることを知りませんでした。私が示した手法は、CIインフラストラクチャ内で実行するのにコストがかかる場合でも、ツールチェーン内で開発するのに費用がかかりません。

テスト影響分析のアイデアの単純な実装では、1つの事前アクティビティが必要です。

1. 単体テストを実行し、コードカバレッジを収集します。
2. テストで扱われた本番ソースファイルから、本番ソース（キー）からテストパス/名前（値）への一時的なマップを作成します。
3. マスターマップを含むソースファイルを更新し、そのテストの以前のエントリをすべて置き換えます。
4. 変更されたマップソースファイルをVCSにコミットします（問題のCIジョブのみがこれを実行する権限を持つ必要があります）。
5. カバレッジデータをクリアします（テストごとのカバレッジレポートが混同されないようにするため）。
6. 次のテストについて＃1に戻ります（最近変更されたソース/テストを最初に？）。

すべてのテストを一度に1つずつ実行すると、本番コードをカバーするテストに接続する包括的なマップが作成されます。

その後、本番コードに変更を加えた場合、どのテストがそのコードを実行したかを把握できるため、実行時に有益な情報が得られる可能性があります。生成されたテストの失敗は、加えられた変更から発生する可能性のある唯一のテストの失敗であることが証明できます。上記の2つの概念実証には、次のことを試みる少量のPythonコードが含まれています。

• 必要になる前にTIAマップを計算する
• 統合前の状況でTIAマップを使用する（わずかな変更を加えることで、CIジョブでも使用できます）

HedgeServのテストベースは、通常の迅速な単体テストと、Microsoft Excelスプレッドシートである統合テストで構成されており、これらは間接的にPythonを呼び出します。12,000件あります。これらのテストは、何時間もかかる広範で高度なアルゴリズムテストであり、「実行数を減らす」戦略なしでは、CIインフラストラクチャで統合ごとに行うことは不可能です。彼らのDevOpsチームは、概念実証を「Test Reducer」（私がこの技術に付けた最初の名前）として運用化し、最速の順列は現在10分です。素晴らしい改善です。開発者とテストエンジニアは統合前に実行でき、CIインフラストラクチャでも同じことができます。HedgeServのソフトウェア開発担当マネージングディレクターであるKevin Looは、「開発者はより迅速なテスト実行に依存しており、自信が高まったため開発ペースが向上した」と述べています。

汎用コードカバレッジツールが使用されているため、TIAの側面は一度に1つのテストを実行する必要があり、事前にコストがかかります。そのため、分析から得られたマップはソース管理にチェックインされ、段階的に更新されます。そのため、差分が簡潔で意味を持つように、テキスト形式で順序付けられている必要があります。マップをソース管理にチェックインすると、CIインフラストラクチャと、統合前（およびコードレビュー前）にテストの実行数を減らしたいと考えている個々の開発者にもメリットがあります。

このTIA設計には、コードカバレッジツールの性質による制限があります。正確な影響グラフを計算するには、一度に1つのテストのみを実行できます。マップデータを使用するには、「git status」（またはgit show >ハッシュ>）を実行し、出力を解析して「変更/追加/削除」された本番コードソースを見つける必要があります。そして、それらが影響マップのキーであり、実行するテストのリストになります。 「一度に1つのテスト」という制限があるのは、データ収集CIジョブのみであるため、多かれ少なかれ永続的に実行されていると見なします。

ご覧のとおり、テストテクノロジーは、本番コードの主要言語の選択とはまったく異なる場合があります。HedgeServの場合、アルゴリズムテストはソース管理下のMicrosoft Excelファイルにありました（BAも貢献しました）。それが可能であれば、SmartBearのTestComplete、HPのUnified Functional Testing（UFT-以前はQTP）、そしてもちろんSeleniumも可能です。唯一の要件は、テストを一度に1つずつ実行するようにスクリプト化できることです（TIAマップを作成している間）。また、最初の作成後、ある程度の頻度でマップを更新することをコミットする必要があります。CIインフラストラクチャを使用してください。

その後、そのマップデータをどこに格納するかを決定する必要があります。ファイル共有、ドキュメントストア、またはリレーショナルスキーマを選択できます。私は、本番ソース自体と同じリポジトリ/ブランチにあるディレクトリ内のテキストファイルを選択しました（お勧めします）。少なくとも、分岐が機能し（分岐モデルが何であれ）、コードの分岐性を反映した異なる影響マップを持つことができます。

最近、クライアント向けに、システムにKDBとQを使用しているプロジェクトを検討し、テスト時間を短縮する方法についてアドバイスしようとしていました。これらに対応するコードカバレッジ技術がないため、その会話はそこで終わりました。

VectorCAST/QA - アプリケーション

VisualStudio用NCrunch