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

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

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

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

前提条件

• プロジェクトに接続する必要があります。 プロジェクトがまだない場合は、作成します。
• ユーザーがプロジェクトに追加されている必要があります。 追加するには、「 プロジェクトまたはチームにユーザーを追加する」を参照してください。
• 手動テストまたは自動テストを表示または実行するには、 Basic 以上のアクセス権が必要です。

詳細については、「 手動テストアクセスとアクセス許可」を参照してください。

• また、次の項目も必要です。
  • Visual Studio 2017 または Visual Studio 2015 以前を使用した自動テスト メソッドに関連付けられている自動テストを含むテスト 計画。
  • テスト バイナリを含むビルドを生成するビルド パイプライン 。
  • テストするアプリ。 ビルドおよびリリース ワークフローの一部としてアプリをデプロイし、オンデマンド テストにも使用できます。
  • リリースの作成と管理、リリース環境の編集、デプロイの管理を行うアクセス許可。 詳細については、「 リリース パイプラインのアクセス許可を設定する 」と「 リリースのアクセス許可」を参照してください。

環境を設定する

1. [テスト プラン] ページで、テスト 計画を選択し、ショートカット メニューを開き、[テスト プランの設定] を選択します。

   

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

   

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

   

   ビルド パイプラインまたはリリース パイプラインからテスト コードにパラメーターを渡操作方法。

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

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

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

   • Visual Studio テスト タスクのバージョン 2 が選択されていることを確認します。 バージョン番号は、タスク設定パネルのドロップダウン リストに表示されます。

     

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

     

   • [ Test platform version]\(テスト プラットフォームのバージョン \) 設定で、[ Installed by Tools Installer]\(ツール インストーラーによってインストール\) を選択します。

     

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

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

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

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

     

     Visual Studio テスト タスクのオプション設定の詳細については、「 Visual Studio テスト タスク」を参照してください。

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

   

   Parallelism を複数の実行に設定し、エージェントの数を指定することで、複数のエージェントにテストを分散することで、テスト時間を最小限に抑えることができます。

   Note

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

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

   

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

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

    

自動テストを実行する

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

2. 実行するテストを選択し、[実行] メニューを開き、[テストの実行] を選択します。

   

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

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

   

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

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

   

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

Note

自動テスト結果では、ファイルの手動添付はサポートされていません。

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

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

   

7. [Test Plans] ページを開き、テストプランを選択して、テストの実行が完了した後にテストが更新された場合にテストの状態を確認します。 テストを選択して、最近のテスト結果を表示します。

   

よく寄せられる質問

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 の [列オプション] リンクを使用して、Automation 状態列をテストの一覧に追加します。 詳細については、「前提条件」セクションを参照してください。

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

  • [ 実行の概要 ] ページのリンクを使用して、テストの実行に使用されるリリース インスタンスにアクセスし、リリース ログを表示します。

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

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

関連記事

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