私たちは広範囲にわたる MSDN ライセンスを持つ MSFT ショップです。
何年にもわたって間違ったことをしてきた後、ついに自動テストを開始する必要があります。私のグループはこれでモルモットです。今までなかったものを作る必要があります。私たちはそこにある多数のオプションを見ました。CC.Net、Bamboo、などのオープンソースの代替手段でうまくやっていく人もいます。MSDN のライセンスと MSFT の焦点のために、 、 を試してみMbUnitたいと思います。MsTestCodedUITeam Build
MSFT の方法で物事を行うことのプラスとマイナスは、MSFT がモノリシックなものを作成することです。相互にうまく機能するさまざまなツールをインストールする必要がありますが、部外者とは必ずしもそうではありません。プラスは、物事が正しく行われると、すべてがかなりスムーズに機能するはずだということです. ゲート チェックイン、TFS を使用したレポートの保存などのオプションがあります。
率直に言って、私はすべての選択肢に混乱しています。私たちの従来のビルド システムは、一連の perl、バッチ スクリプト、実行可能ファイルと一緒にハッキングされていましたが、ビルド チームはチーム ビルドに切り替えました。 .
少なくとも部品が何であるかを見ることができるので、テストのために何かをハックする傾向もあります。* テストを実行する専用の高速コンピューター * ビルド ファイル (テスト コードと製品コード) をそのコンピューターにコピーするためのスクリプト。* コマンド ラインから mstest.exe を実行し、いくつかのテスト dll 内のいくつかのカテゴリ別フィルターでいくつかのテスト バッチを実行するバッチ/perl スクリプト (製品は非常に巨大であるため、さまざまなカテゴリごとにテストを整理したいと考えています)。* psexec.exe (http://technet.microsoft.com/en-us/sysinternals/bb897553) を使用してビルド サーバーから後者のスクリプトをリモートで呼び出すスクリプト、および共有ドライブから xml 出力を取得するスクリプトそして、興味のある人に結果をメールで送信します。
これはおそらく機能しますが、エラー処理が非常に多くの潜在的な障害点でどれだけうまく機能するかを心配する必要があります。MSFT が作成したものを利用して、「正しい方法」で構成するとよいでしょう。良いガイドをどこに向ければよいかわかりません。このようなことをしたことがありますか？
最終的には、割り当てられた時間がなくなった場合に備えて、テスト コンピューターのファームが必要になります。他に懸念される点は、コード化された ui テストが成功するためには、ユーザーがログインする必要があると思われるため、psexec がここで役立つかどうかはわかりません。
あなたの肯定的/否定的な経験を共有していただけますか?おそらく良いガイドを教えてください? ありがとう！