0

そこで、VS2012 RTMをダウンロードし、コード化されたUIテストプロジェクトをVS2012バージョンにアップグレードしました。

私がこれを行った理由は、IE9の部分的なサポートが原因でVS2010コード化UIツールに問題があったためです。

そのため、開発者のマシンからローカルとリモートの両方でテストを実行し(新しいVisual Studioエージェントツールを使用)、テストは正常に機能しました。おそらく、私のテストが現在機能する理由は、VS2012がテストをアップグレードしてIE9で機能するようにしたからです。

だから-これは私の問題です。これらのテストをビルドマシンから起動して自動化したいのですが、ビルドマシンは引き続きVS2010で実行されており、当面は変更されません。

そこで、新しいVS2012コード化UIテストソリューションをTFSにチェックインし、新しいビルドをキューに入れました。そのため、ビルドマシンがソリューションをビルドしました。そして、ビルドは成功しました。そこにすべて良い。

そこで、次に、Microsoft Test Managerで新しいテストケースを作成し、新しいソリューションの順序付きテストリストに関連付けました。次に、リモートテスト環境(既存のVS2010テストエージェントツールがある)でテストを(既存のVS2010テストコントローラーを使用して)起動しました。

しかし、テストは失敗しました-VS2010コード化UIテストでのテストに影響を与えたのと同じ問題(IE9の完全なサポートがないため)

なぜ彼らは失敗したのですか?

テストコントローラーとエージェントに新しいVS2012エージェントツールが必要ですか?VS2012でソリューションを構築する必要がありますか?

理想的には、ビルドマシンにVS2012 RTMをインストールする必要はありません。テストを機能させて自動化するために、可能な限り最小限のことを行いたいと思います。

これを回避する方法はありますか?

4

1 に答える 1

1

コード化されたUIは、VSインストールまたはエージェントのインストールに付属する参照アセンブリをテストします(アセンブリは、WpfControl、マウス、キーボード、再生、およびその他のクラスを定義します)。

したがって、古いバージョンのdllを使用してビルド/テストマシンで実行した場合、同じ問題が残り、VS2012に付属していた新しい固定アセンブリの使用は開始されません。

一時的な回避策として、参照しているdllを確認し、ビルドプロセスでそれらがテストアセンブリと同じディレクトリに配置されていることを確認できます。そうすれば、それらを検索すると、/ pathを使用せずに現在のディレクトリで、VSインストールディレクトリでそれらを見つけることができます。

于 2012-08-28T00:21:46.840 に答える