回答が遅くなり申し訳ありません...私の質問への回答に関する通知を見逃してしまいました:-(申し訳ありません!
まだ解決策を探している場合は、ここに私の提案があります。
2 台のマシン (サーバー用とクライアント用) で構成されるテスト環境があるとします。その場合、両方でテストを実行することはできません。または、実行中のテストを十分に制御できないと言ったほうがよいでしょう。同時に複数のコンピューターで自動テストを実行する方法を 確認してください。
実際に関連する質問を「Visual Studio Development Forum」に投稿しました。ここで得た回答を確認できます。 build-deploy-test ワークフローを使用して、同じ環境
つまり、それぞれが 1 台のマシン (サーバー用とクライアント用) で構成される 2 つの環境を作成することになります。ただし、ビルド定義で両方の環境を参照することはできず、 DefaultLabTemplate
で 1 つの環境しか選択できません。
それは私が提案できる解決策につながります:
- 2 つのラボ環境を作成する
- 3 つのビルド定義を作成する
- 最初のものはテストコードのみをビルドします
- 2 つ目は、最初のビルドから最後に成功したビルドをデプロイし、サーバー環境でテストを開始します。
- 3 つ目は、最初のビルドから最後に成功したビルドをデプロイし、クライアント環境でテストを開始します。
- 夜間に最初のビルド定義を自動的に実行する
- 後で後者の 2 つを同時にトリガーします。
それは本当にいいことではありません...
テストコードを構築するビルド定義を、テストを実行する2つのビルド定義と同期させる必要があります。
数か月前に同様のテストを設定することを考えていましたが、それが私が思いついた最良の解決策でした...
まだ試していない別のオプションは次のとおりです。
- 2 台のマシンで構成される単一のテスト環境を使用し、それぞれに異なるロール (サーバーとクライアント) を使用します。
- MTMで、2 つのテスト設定 (サーバー ロール用とクライアント ロール用) を作成します。
- tcm.exeツールを使用してテストを開始するバッチ ファイルを作成します(詳細については、「方法: Tcm を使用してコマンド ラインから自動テストを実行する」を参照してください)。作成したテスト設定ごとに 1 つずつ、合計 2 つのtcm.exe
呼び出し
が必要です。tcm.exe呼び出しはテスト実行をキューに入れるだけ
なので、(多かれ少なかれ) すぐにこのバス ファイルはテストを (多かれ少なかれ) 同時に開始します。
- DefaultLabTemplateを使用してビルド定義を作成します。この定義は次のようになります。
- テストコードをビルドする
- それらを環境内の両方のマシンに展開します
- バス スクリプトを最後の展開ステップとして実行します
(このスクリプトがビルド マシン上にあることを確認するか、そこに展開するか、ビルド マシンからアクセスできるようにする必要があります)。
私が言ったように、私はまだそれを試していません。
このアプローチの欠点は、DefaultLabTemplateによって提供される手段によってテストが開始されないため、ビルド ログにテスト パーツが表示されないことです。したがって、テストが失敗してもビルドは失敗しません。ただし、 MTM
で
テスト結果を確認することはでき、各マシンのテスト結果を確認できます。
しかし、あなたにとってより重要なこと (残りの結果があるか、テストが失敗した場合に失敗するビルド定義があるか、または両方があるか) に応じて、それが解決策になる可能性があります。