テスト計画から自動テストを実行する

Azure DevOps Services |Azure DevOps Server 2022 |Azure DevOps Server 2020

テスト計画でテスト ケースを自動化し、Azure Test Plans から直接実行します。 自動テストには、次の利点があります。

• ビルドまたはリリース ワークフローでのテストの実行を熟知していない可能性があるテスト担当者向けのわかりやすいプロセス。
• フィルター条件を満たすすべてのテストが実行されるビルドまたはリリース ワークフローのスケジュールされたテストではなく、選んだテストをオンデマンドで実行する柔軟性。
• テスト インフラストラクチャの問題が原因で失敗したいくつかのテスト、または失敗したテストの修正を含む新しいビルドを再実行する機能。

前提条件

環境を設定する

1. [Test Plans] ページでテスト計画を選び、ショートカット メニューを開いて、[テスト計画の設定] を選びます。

   

2. [テスト 計画の設定] ダイアログで、テスト バイナリを含むビルドを生成するビルド パイプラインを選択します (クラシック ビルド パイプラインと YAML ビルド パイプラインの両方がサポートされています)。 その後、テストする特定のビルド番号を選ぶか、テストの実行時にシステムに最新のビルドを自動的に使用させることができます。

   

3. Azure Test Plans でテスト計画からテストを実行するには、Test Manager から自動テストを実行するテンプレートから作成されたリリース パイプラインが必要です。 このテンプレートを使用して作成された既存のリリース パイプラインがある場合は、それを選択し、テスト実行用にリリース パイプライン内の既存のステージを選択します (クラシック リリース パイプラインと YAML リリース パイプラインの両方がサポートされています)。 そうでない場合は、ダイアログで [新規作成] を選び、Visual Studio Test タスクが既に追加されている単一のステージを含む新しいリリース パイプラインを作成します。

   

   ビルドまたはリリース パイプラインからテスト コードにパラメーターを渡すにはどうすればよいですか?

4. 必要に応じて、リリース パイプラインとステージにわかりやすい名前を割り当てます。

5. Visual Studio がエージェント コンピューターに既にインストールされている場合は、このステップをスキップします。 そうでない場合は、パイプライン定義に Visual Studio テスト プラットフォーム インストーラー タスクを追加します。

6. Visual Studio テスト タスクをリリース パイプラインに追加し、次のように構成します。

   • Visual Studio テスト タスクのバージョン 3 を使用していることを確認します。

   • [次を使用してテストを選択] が [テストの実行] に設定されていることを確認します。 この設定は何を意味していますか?

   • vsTestVersion の場合は、toolsInstaller を選択します。

   • 物理ブラウザーまたはシック クライアントで実行される UI テストがある場合は、自動ログオンが有効になっている対話型プロセスとして実行するようにエージェントが設定されていることを確認します。 ビルドまたはリリースをキューに入れる前に、対話形式で実行するようにエージェントを設定する必要があります。 [テスト ミックスに UI テストが含まれています] チェック ボックスでは、エージェントは対話モードで自動的に構成されません。これは、エラーを回避するためにエージェントを適切に構成するためのリマインダーとしてのみ使われます。

   • ヘッドレス ブラウザーで UI テストを実行している場合、対話型プロセスの構成は必要ありません。

   • テスト プラットフォームのプロビジョニング方法と、Visual Studio のバージョンまたはテスト マシンにインストールされているテスト プラットフォームの場所を選びます。

   • テストでアプリの URL やデータベースの接続文字列などの入力パラメーターが必要な場合は、ビルド成果物から関連する設定ファイルを選びます。 このファイルが成果物に含まれていない場合は、ビルド パイプラインでビルド成果物の発行タスクを使って、設定ファイルを格納場所に発行できます。 次の例では、アプリケーションの URL が実行設定ファイルで公開されており、[テストの実行パラメーターのオーバーライド] の設定を使ってステージング URL に設定するようにオーバーライドされています。

   

   Visual Studio のテスト タスクのオプション設定について詳しくは、Visual Studio のテスト タスクに関する記事をご覧ください。

7. [エージェント ジョブ] 項目を選び、デプロイ キューが、テストを実行するマシンを含むキューに設定されていることを確認します。 テストでエージェント プールの特別なマシンが必要な場合は、実行時に選択する要求を追加できます。

   [並行処理] を [複数の実行] に設定し、エージェントの数を指定して、複数のエージェントにテストを分散させると、テスト時間を最小限に抑えられる可能性があります。

   注

   CodeUI や Selenium などの UI テストを IE、Firefox、Chrome などの物理ブラウザーで実行する場合は、マシン上のエージェントをサービスとしてではなく対話モードで実行する必要があります。 詳細情報。

8. リリース パイプラインの [パイプライン] ページで、テスト バイナリを含むビルド パイプラインがこのリリース パイプラインに成果物ソースとしてリンクされていることを確認します。

   

9. リリース パイプラインを保存します。

10. この例のステップ 2 の [テスト計画の設定] ダイアログで [新規作成] を選んだ場合は、テスト計画の設定が含まれているブラウザー ページに戻ります。 [テスト計画の設定] ダイアログで、保存したリリース パイプラインとステージを選びます。

    

自動テストを実行する

1. Test Plans Web ポータルで、テスト計画を開き、自動テストを含むテスト スイートを選びます。

2. 実行するテスト ケースを選択し、[ Web アプリケーションの実行] をクリックします。

   

   これらのテストのテスト バイナリは、ビルド パイプラインによって生成されたビルド成果物で使用できるようになっている必要があります。

3. システムは、自動テストのみが選択されていることを確認します (手動テストはすべて無視されます)。また、ステージを検証して Visual Studio のテスト タスクが存在することと有効な設定があることを確認し、選ばれたリリース パイプラインのリリースを作成するためのユーザーのアクセス許可を調べて、テスト実行を作成してから、選ばれたステージへのリリースの作成をトリガーします。

   

4. [テストの実行を表示] を選んでテストの進行状況を表示し、失敗したテストを分析します。 テスト結果には、エラー メッセージ、スタック トレース、コンソール ログ、添付ファイルなど、失敗したテストをデバッグするための関連情報が含まれています。

5. テストの実行が完了すると、Azure Test Plans の [実行] ページにテスト結果が表示されます。 [実行の概要] ページでは、実行の概要が示されます。

   

   テストの実行に使われたリリースへのリンクがあるため、後で戻って結果を分析する必要がある場合、テストを実行したリリースを簡単に見つけることができます。 リリースを開いてリリース ログを見る場合も、このリンクを使います。

テストが実行されない場合に調べるべき一般的なエラー シナリオや問題は何ですか?

6. [テスト結果] ページには、テスト実行での各テストの結果の一覧が表示されます。 テストを選ぶと、エラー メッセージ、スタック トレース、コンソール ログ、添付ファイルなど、失敗したテストのデバッグ情報が表示されます。

   

7. [テスト プラン] で [実行] ページに移動し、すべてのテスト実行の概要を確認できます。 ここから、各テスト実行の詳細ビューを開くことができます。

   

FAQ

Azure Test Plans についてよくあるご質問 (FAQ) を次に示します。

Q: Azure Test Plans から自動テストを実行するには、どのようなアクセス許可が必要ですか?

A: プロジェクトの共同作成者になるか、次のアクセス許可を持っていること。

• リリースを作成する
• リリースを管理する
• リリース ステージを編集する
• デプロイを管理する

詳しくは、リリースのアクセス許可に関する記事をご覧ください。

Q: テスト実行の特定のインスタンスについて、テスト計画レベルで設定されているビルドまたはステージをオーバーライドできますか?

A: はい。これを行うには、[オプションを指定して実行] コマンドを使います。 左側の列でテスト スイートのショートカット メニューを開き、[オプションを指定して実行] を選びます。

[オプションを指定して実行] ダイアログに次の値を入力して、[OK] を選びます。

• [テストの種類とランナー]: [リリース ステージを使用した自動テスト] を選びます。
• [ビルド]: テスト バイナリを含むビルドを選びます。 テスト結果は、このビルドに関連付けられます。
• [リリース パイプライン]: 選んだビルド成果物を使用できるパイプラインをリリース パイプラインの一覧から選びます。
• [リリース ステージ]: リリース パイプラインで構成されているステージの名前を選びます。

Q: テストを実行するためにリリース ステージを使うのはなぜですか?

A: Azure Pipelines には、成果物としてテスト バイナリを取得してテストを実行するための優れたオーケストレーション ワークフローがあります。 このワークフローは、既存のスケジュールされたテスト リリース パイプラインのクローンなど、スケジュールされたテスト ワークフローで使われているのと同じ概念を共有するので、スケジュールされたワークフローでテストを実行しているユーザーは簡単に適応できます。

もう 1 つの大きな利点は、タスク カタログ内の豊富なタスク セットを利用できることであり、テストを実行する前と後にさまざまなアクティビティを実行できます。 例としては、テスト データの準備とクリーニングや、構成ファイルの作成とクリーニングなどがあります。

Q: Visual Studio テスト タスク バージョン 2 で [テストの実行] を選ぶと、どのように機能しますか?

A: テスト管理サブシステムは、テスト実行オブジェクトを使って、実行するように選ばれたテストの一覧を渡します。 テスト タスクは、テスト実行識別子の検索、コンテナーやテスト メソッドの名前などのテスト実行情報の抽出、テストの実行を行い、テストの実行結果を更新して、テスト実行でテスト結果に関連付けられているテスト ポイントを設定します。 監査の観点から、Visual Studio タスクは、履歴リリースとテスト実行識別子から、オンデマンド テスト実行のために送信されたテストへのトレースを提供します。

Q: エージェントは対話モードで、またはサービスとして実行する必要がありますか?

A:コード化された UI や Selenium のテストなど、UI のテストを実行する場合、テスト マシン上のエージェントは、エージェントが Web ブラウザーを起動できるよう、サービスとしてではなく、自動ログオンが有効にされた対話モードで実行する必要があります。 PhantomJS などのヘッドレス ブラウザーをお使いの場合は、エージェントをサービスとして、または対話モードで実行できます。 詳しくは、ビルド エージェントとリリース エージェント、Windows へのエージェントのデプロイ、エージェント プールに関する記事をご覧ください。

Q: Selenium テストの実行方法に関する詳細なドキュメントはどこにありますか?

A:Selenium テストの概要に関する記事をご覧ください。

Q: 同じテストに対して複数の構成を選んだ場合はどうなりますか?

A: 現在、オンデマンド ワークフローは構成に対応していません。

Q: 製品バイナリとテスト バイナリを異なるビルドからダウンロードする必要がある場合はどうなりますか? または、Jenkins などのソースから成果物を取得する必要がある場合はどうですか?

A: 現在の機能は、Azure Pipelines ワークフローを用いた、1 つのチーム ビルドのオンデマンド テスト用に最適化されています。 ユーザーのフィードバックに基づき、Jenkins などの Azure Pipelines 以外の成果物を含む、複数成果物のリリースのサポートが評価されています。

Q: スケジュールされたテストのリリース パイプラインが既にあります。 同じパイプラインを再利用してオンデマンドでテストを実行できますか? それとも新しいパイプラインを作成する必要がありますか?

A: 次の理由で、Azure Test Plans からのオンデマンド自動テストには、個別のリリース パイプラインとステージを使うことをお勧めします。

• 小数のオンデマンド テストを実行するたびにアプリをデプロイしたくない場合があります。 スケジュールされたテストのステージは、通常、製品をデプロイしてからテストを実行するように設定されます。

• 新しいリリースは、オンデマンド実行ごとにトリガーされます。 毎日少数のオンデマンド テスト実行を実行するテスト担当者が多くいる場合、これらの実行のリリースによって、スケジュールされたテストのリリース パイプラインに負荷がかかりすぎ、スケジュールされたテストと運用環境へのデプロイを含むパイプラインのトリガーとなるリリースを見つけるのが困難になる可能性があります。

• リリースをトリガーしたものをトレースできるよう、テスト実行識別子を入力として Visual Studio テスト タスクを構成することが必要な場合があります。 詳しくは、Visual Studio テスト タスクで "テスト実行 (オンデマンド実行用)" を選んだ場合の動作に関するセクションをご覧ください。

Q: Microsoft Test Manager でこれらの実行をトリガーして結果を見ることはできますか?

A: いいえ。 Microsoft Test Manager では、Team Foundation のビルドに対する自動テストの実行はサポートされていません。 Azure Pipelines の Web ベースのインターフェイスでのみ機能します。 手動と自動のすべての新しいテスト製品開発の投資は、Web ベースのインターフェイスで行われています。 Microsoft Test Manager の今後の開発は計画されていません。 「Microsoft Test Manager の使用に関するガイダンス」をご覧ください。

Q: チームに複数のテスト担当者がいます。 同じリリース パイプラインを使って、異なるテスト スイートまたはテスト計画のテストを並列に実行できますか?

A: 次の場合、同じリリース パイプラインを使って複数のテスト実行を並列にトリガーできます。

• ステージに関連付けられているエージェント プールに、並列要求に対応するのに十分なエージェントがあります。 十分なエージェントを利用できない場合でも実行をトリガーできますが、エージェントが使用可能になるまで処理のためにキューを解放します。

• 並列ジョブを有効にするのに十分なジョブがあります。 詳しくは、Azure Pipelines での並列ジョブまたは TFS での並列ジョブに関する記事をご覧ください。

• テスト担当者は、同じテストを並列に実行しません。 これを行うと、実行順序によっては結果が上書きされる可能性があります。

複数の異なるテスト実行を並列に実行できるようにするには、次のように、複数のリリースがデプロイされるのを待っているときの動作用に Azure Pipelines のステージ トリガー オプションを設定します。

• 異なるソースからの並列のテスト実行をアプリケーションがサポートしている場合は、このオプションを [複数のリリースを同時に配置できるようにする] に設定します。

• 異なるソースからの並列のテスト実行をアプリケーションがサポートしていない場合は、このオプションを [一度に 1 つのアクティブな配置のみを許可する] に設定します。

Q: ビルドまたはリリース パイプラインからテスト コードにパラメーターを渡すにはどうすればよいですか?

A:runsettings ファイルを使って、値をパラメーターとしてテスト コードに渡します。 たとえば、複数のステージを含むリリースでは、それぞれの各テスト タスクに適切なアプリ URL を渡すことができます。 runsettings ファイルと一致するパラメーターを、Visual Studio テスト タスクで指定する必要があります。

Q: テストが実行されない場合に調べるべき一般的なエラー シナリオや問題は何ですか?

A: 次のように問題を調べて解決します。

• ビルドを選んだ後で、テストを実行したいリリース パイプラインとステージが表示されません。

  • ビルドを生成しているビルド パイプラインが、リリース パイプラインの [成果物] タブでプライマリ成果物としてリンクされていることを確認します。

• リリースをトリガーするための十分なアクセス許可がないというエラーが表示されます。

  • リリース パイプラインの [セキュリティ] メニューで、ユーザーに対して [リリースの作成] と [デプロイの管理] アクセス許可を構成します。 リリースのアクセス許可に関する記事をご覧ください。

• 自動テストが見つからなかったというエラーが表示されます。

  • 選んだテストの自動化の状態を調べます。 テスト ケースの作業項目でそれを行うか、Azure Test Plans の [列のオプション] リンクを使ってテストの一覧に [オートメーションの状態] 列を追加します。 詳しくは、前提条件のセクションをご覧ください。

• テストが実行されませんでした。リリース パイプラインが正しくないと思われます。

  • [実行の概要] ページのリンクを使って、テストの実行に使われたリリース インスタンスにアクセスし、リリース ログを確認します。

• ステージへのリリースがトリガーされた後で、テストがエラー状態になったり、"進行中" のままになったりします。

  • 選んだリリース ステージで、正しいタスクとバージョンが選択されているかどうかを調べます。 Visual Studio テスト タスクのバージョン 2 以降を使う必要があります。 タスクのバージョン 1 と機能テストの実行タスクはサポートされていません。

関連コンテンツ

• 自動テストとテス トケースを関連付ける
• 自動テスト結果を要件に関連付ける
• 継続的なテストのシナリオと機能