ビルド、配置、およびテストのワークフローに関するガイダンス

  • [アーティクル]

このトピックでは、ビルド、配置、テスト ワークフローに推奨されるアプローチについて説明します。 ニーズに応じて、最適なアプローチを決定できます。 ただし、プロジェクト サイクルの段階で、ニーズは変わる場合があります。 プロジェクトの開始にあたり、アプリケーションを夜間にビルドするとします。 プロジェクトの進行に伴い、このワークフローに単体テストを追加してビルドの品質をテストすることができます。 これらのテストは、多くの場合、ビルド確認テストまたはスモーク テストと呼ばれます。 チームがテストを実行するための準備を整えるときに、アプリケーションの配置を含むようにワークフローを自動化できます。 これにより、配置したアプリケーションの最新バージョンで手動テストまたは自動テストを実行できるようになります。 または、配置時のビルドの品質を検証する完全なワークフローとして自動テストをビルド、配置、および実行する場合もあります。

このようなワークフローの中で、mstest.exe を使用して自動テストをテスト プロジェクトのアセンブリから実行できます。 または、tcm.exe を使用してテスト計画のテスト スイートから自動テストを実行できます。 テスト計画から自動テストを実行するには、次のタスクを実行する必要があります。

  1. テスト計画とテスト スイートの作成 (「テスト計画の使用によるテスト作業の定義」を参照)

  2. テスト スイート内のテスト ケースの自動テストへの関連付け (「方法: テスト ケースに自動テストを関連付ける」を参照)

  3. 仮想環境または物理環境の作成 (「環境」を参照)

以下のセクションの情報を参照し、ワークフローで必要なタスクのソフトウェア コンポーネントをセットアップしてください。

  • 要件

    「要件」では、ワークフローの中でビルド、配置、テストを使用するための要件について説明します。

  • ビルド

    単純にアプリケーションをビルドする場合は、既定のビルド テンプレートを使用できます。 ビルドの設定方法の詳細については、「アプリケーションのビルド」を参照してください。

  • ビルドおよびテスト

    自動テストをビルド処理の一部として実行する場合は、既定のビルド テンプレートを使用してテスト プロジェクトからテストを実行するように選択できます。 テストが成功した場合は、ビルドが正常に行われたと考えることができます。 「自動テストのビルドと実行」を参照してください。

    重要

    この場合、mstest.exe を使用してビルド プロセスの一部としてテストが実行されます。 mstest.exe の詳細については、「MSTest.exe コマンド ライン オプション」を参照してください。

  • ビルドと配置

    アプリケーションの最新のビルドを使用してテスト計画から手動テストを実行する場合、アプリケーションをビルドして物理環境または仮想環境に配置することができます。 「Build, Deploy and Run Manual Tests from a Test Plan (テスト計画からの手動テストのビルド、配置、および実行)」を参照してください。

  • ビルド、配置、およびテスト

    配置後にアプリケーションの品質を確認する場合は、物理環境または仮想環境を使用して、アプリケーションをビルドおよび配置し、テスト計画から自動テストを実行できます。 「環境を使用したテスト計画からの自動テストのビルド、配置、および実行」を参照してください。

    重要

    この場合、tcm.exe を使用してビルド プロセスの一部としてテストが実行されます。 tcm.exe の詳細については、「tcm: コマンド ラインからのテスト計画の自動テストのインポートと実行」を参照してください。

要件

ワークフローで必要なタスクに基づき、物理マシンまたは仮想マシンの各タスクで必要なコンポーネントをインストールできます。 次の図に、このセクションの情報に基づいて仮想マシンにインストールできるソフトウェアの例を示します。

ビルド、配置、およびテストの要件

すべてのタスクのソフトウェア要件

  • Team Foundation Server

ビルドのソフトウェア要件

  • ビルド コントローラー

    各チーム プロジェクト コレクションに少なくとも 1 つのビルド コントローラーが必要

  • ビルド エージェント

    各ビルド コントローラーに少なくとも 1 つのビルド エージェントが必要

配置のソフトウェア要件

  • 1 つのビルド コントローラー (アプリケーションのビルドに使用されるものと同じビルド コントローラーを使用可能)

  • 仮想環境の場合: 仮想環境内の各マシンにつき、1 つのビルド エージェントと 1 つのラボ エージェント

環境でのテストのソフトウェア要件

  • テスト コントローラー

    各チーム プロジェクト コレクションに少なくとも 1 つのテスト コントローラーが必要

  • テスト エージェント

    環境内の各仮想マシンに 1 つのテスト エージェントが必要

  • 仮想環境の場合: 仮想環境内の各マシンにつき、1 つのラボ エージェント (テスト エージェントに加えて)

これらのコンポーネントによるテストの実行方法の詳細については、「テスト コンピューターでのテストの実行またはデータの収集の設定」を参照してください。

これらのコンポーネントのインストール方法の詳細については、「Visual Studio Agents、テスト コントローラー、およびビルド コントローラーのインストールと構成」を参照してください。

以降のセクションでは、ソフトウェア コンポーネントをインストールするコンピューターを決定する方法について説明します。 これによって、セットアップに必要なコンピューターの数を決定できます。

ビルド コントローラーおよびビルド エージェントのコンピューター要件

必要なコンピューターを決定するには、次の情報に基づいてトポロジを決定する必要があります。

  • 各チーム プロジェクト コレクションに少なくとも 1 つのビルド コントローラーが必要です。

  • 各コンピューターで使用できるビルド コントローラーは 1 つだけです。

  • 一般的なインストールでは、ビルド エージェントが実行するタスクによってプロセッサに高い負荷がかかる場合があります。 このため、Team Foundation Server のパフォーマンスが大幅に低下する可能性があります。 この場合、ビルド エージェントを Team Foundation Server とは別のコンピューターに配置する必要があります。

  • Team Foundation Server と同じコンピューターにビルド コントローラーをインストールできます。 ビルド コントローラーが多数のアクティブなビルド エージェントを管理している場合、システム メモリが大量に消費される可能性があるため、別のコンピューターにビルド コントローラーをインストールすることも検討してください。

たとえば、3 つのチーム プロジェクト コレクションがあり、それぞれにビルドする必要があるアプリケーションがある場合、3 つのビルド コントローラー用に 3 台のコンピューターが必要です。また、Team Foundation Server に 1 つのビルド コントローラーをインストールする場合、さらに 2 台のコンピューターが必要です。

重要

ビルド コンピューターおよびビルド エージェントのセットアップに使用できるトポロジの詳細については、「ビルド システム トポロジの例」を参照してください。

テスト コントローラーおよびテスト エージェントのコンピューター要件

ソフトウェア コンピューター間の通信問題を緩和するために、テスト コントローラー コンピューターと Team Foundation Server コンピューターを同じドメインに配置することをお勧めします。 異なるドメインまたはワークグループ内にコンポーネントをインストールする方法の詳細については、「ワークグループおよび複数ドメインの要件」を参照してください。

テスト コントローラーに必要なコンピューターを決定するには、次の情報に基づいて必要なトポロジを決定する必要があります。

  • 物理環境または仮想環境でテストする場合、テスト コントローラーが必要です。

  • 複数の物理環境または仮想環境に対して 1 つのテスト コントローラーを使用できます。

  • 環境を含むチーム プロジェクト コレクションにテスト コントローラーを登録する必要があります。

  • 1 つのテスト コントローラーは、1 つのチーム プロジェクト コレクションにのみ登録できます。

  • 必要なテスト コントローラーは、それぞれ別々のコンピューターにインストールする必要があります。

たとえば、3 つのチーム プロジェクト コレクションがあり、それぞれに環境を作成する場合、少なくとも 3 つのテスト コントローラーが必要です。 この場合、少なくとも 3 台のコンピューターが必要です。

注意

チーム プロジェクト コレクションでサポートする環境が多く、複数のテスト コントローラーが必要な場合は、同じ Team Foundation Server に複数のテスト コントローラーを登録できます。

ビルド コントローラーとテスト コントローラーに必要なコンピューターの削減

複数のビルド コントローラーとテスト コントローラーが必要な場合は、ビルド コントローラーと同じコンピューターにテスト コントローラーをインストールすることで、コンピューターの数を削減できます。 たとえば、3 つのチーム プロジェクト コレクション A、B、C があり、それぞれにビルド コントローラーとテスト コントローラーが 1 つずつ必要な場合、同じコンピューターにビルド コントローラーとテスト コントローラーをインストールできます。 この方法を使用することで、コントローラー用に必要なコンピューターは 6 台ではなく 3 台になります。

自動テストのビルドと実行

ワークフロー タスクとしてビルドおよびテストを使用するには、作成する既定のビルド定義で次の情報を指定しておく必要があります。

次の図のように、ビルド エージェントは、mstest.exe を使用してドロップ フォルダーにあるテスト アセンブリからテストを実行します。 アプリケーションのソリューションから既定のテスト設定 (local.testsettings) を使用し、ビルド エージェントを使用してローカルにテストを実行できます。

注意

local.testsettings ファイルをビルド処理の中で使用するには、このファイルを Team Foundation Server にチェックインする必要があります。

ビルド エージェントだけでテストを実行する場合、診断データ アダプターを使用して情報を収集することはできません。 このシナリオで診断データ アダプターを使用する場合は、ビルド エージェントと同じコンピューターにテスト エージェントをインストールする必要があります。 または、「テスト計画からの自動テストのビルド、配置、および実行」のセクションで説明されているとおり、物理環境または仮想環境を使用できます。

テスト エージェントを使用しないビルドおよびテスト

ワークフローでテストをビルドおよび実行する方法の詳細な手順については、「方法: アプリケーションのビルド後にスケジュールされているテストを構成および実行する」を参照してください。

ヒント

リモートでテストを実行するテスト設定をビルド定義に使用して、テスト コントローラーを使用することはお勧めできません。 テスト コントローラーおよびテスト エージェントを使用する場合、「テスト計画からの自動テストのビルド、配置、および実行」のセクションで説明されているとおり、物理環境または仮想環境を使用してください。

Visual Studio、Team Foundation Server、および Team Foundation ビルド を使用してワークフローを定義する方法について学習している場合は、すべてのコンポーネントを 1 つのコンピューターにインストールできます。 ただし、このシステムを使用するユーザーが多く、複数のビルドを実行している場合は、この方法はお勧めしません。

注意

コード化された UI テストを実行するには、まずアプリケーションを物理環境または仮想環境に配置することをお勧めします。 この方法により、テストの失敗を調査するために手動の手順を実行する必要がある場合に、同じ環境を使用できます。 アプリケーションを配置せずにコード化された UI テストを実行するには、デスクトップとやり取りするためのビルド エージェントを構成する必要があります。 また、テスト エージェントをビルド マシンにインストールし、テストのためにドロップ フォルダーから最新のビルドを使用する必要があります。 ビルド エージェントの設定方法の詳細については、「コード化された UI テストを実行するようにテスト エージェントを設定」を参照してください。

ビルドと配置

ワークフローのアプリケーションをビルドおよび配置するには、物理環境または仮想環境を使用する必要があります。

仮想環境

Visual Studio Lab Management を使用した仮想環境を利用してビルドと配置を行うには、ラボの既定のテンプレートを使用します。 このラボのテンプレートを使用して、次の操作を実行できます。

  • 使用する仮想環境の選択

  • 配置の開始点として使用する環境のスナップショットの選択

  • アプリケーションの配置に使用するビルド定義またはビルドの選択

  • ドロップ フォルダーからアプリケーションを配置するために実行するスクリプトの追加

  • ビルドと配置のワークフローでの配置後における仮想環境のスナップショットの取得

仮想環境を使用して、この環境に配置されたビルドを使用して手動テストを実行するか、または自動テストを実行できます。 仮想環境にアプリケーションをビルドおよび配置する方法の詳細については、「方法: アプリケーションを仮想環境に配置する」を参照してください。 仮想環境を使用して手動テストを実行する方法の詳細については、「方法: 仮想環境を使用して手動テストを実行し、再現可能なバグを作成する」を参照してください。

物理環境

アプリケーションを物理環境に配置する場合は、ビルド定義のテンプレートをカスタマイズできます。 ビルド プロセス テンプレートをカスタマイズする方法の詳細については、「カスタム ビルド プロセス テンプレートの作成と使用」を参照してください。

この仮想環境を使用して、テスト計画から手動テストまたは自動テストを実行できます。 これらのテストを実行する方法の詳細については、「テスト ランナーを使用した手動テストの実行」および「テスト計画からの自動テストの実行に関する基本ガイド」を参照してください。

環境を使用したテスト計画からの自動テストのビルド、配置、および実行

テスト計画のビルド、配置、およびテスト処理で自動テストを実行するには、物理環境または仮想環境を使用する必要があります。 ビルド定義は tcm.exe を使用してテストを実行します。 これらのテストをワークフローの中で実行する場合、テストに対してテストの実行が作成されます。そのテスト結果は、Microsoft テスト マネージャーを使用して確認および分析することができます。 テストの実行を分析する方法の詳細については、「方法: Microsoft テスト マネージャーを使用してテストの実行を分析する」を参照してください。 また、これにより、ビルドの品質に関する履歴データを表示できます。 ビルドの品質に一貫した問題があるのはいつか、失敗したテストを含むアプリケーションの領域はどこかを確認できます。

テスト用の物理環境を作成するときに物理マシンまたは仮想マシンを使用できますが、Visual Studio Lab Management を使用して仮想環境を作成することもできます。 仮想環境を利用することで、各コンピューターを使用してアプリケーションを既存のスナップショットから環境内に既知の状態で配置することができます。 さらに、アプリケーションが配置された後に環境のスナップショットを取得しておくことで、この既知の状態に戻り、バグのテストまたは手動テストを実行することができます。 仮想環境によって、高い柔軟性が実現します。 これらの環境の作成方法の詳細については、「テストで使用する物理環境の作成」および「仮想環境の作成」を参照してください。

仮想環境

仮想環境にアプリケーションを配置するために、Team Foundation ビルドに用意されているラボの既定のテンプレート定義を使用できます。 仮想環境を使用するには、Visual Studio Lab Management がインストールされている必要があります。 このラボのテンプレートを使用して、次の操作を実行できます。

  • 使用する仮想環境の選択

  • 配置の開始点として使用する環境のスナップショットの選択

  • アプリケーションの配置に使用するビルド定義またはビルドの選択

  • ドロップ フォルダーからアプリケーションを配置するために実行するスクリプトの追加

  • テストの実行のためのテスト スイート、テスト構成、およびテスト設定の選択

  • ビルドと配置のワークフローでの配置後における仮想環境のスナップショットの取得

仮想環境でビルド、配置、およびテストするための既定のラボ テンプレートのビルド定義を設定する方法の詳細については、「方法: アプリケーションをビルドして配置した後にスケジュールされているテストを構成および実行する」を参照してください。

仮想環境を使用したビルド、配置、およびテスト

物理環境

アプリケーションを物理環境に配置して自動テストを実行するために、ビルド定義のテンプレートをカスタマイズできます。 ビルド プロセス テンプレートをカスタマイズする方法の詳細については、「カスタム ビルド プロセス テンプレートの作成と使用」を参照してください。

物理環境を使用したビルド、配置、およびテスト

参照

概念

テスト コンピューターでのテストの実行またはデータの収集の設定

その他の技術情報

Lab Management ワークフローのカスタマイズ