UIオートメーションとWPFの経験[終了]

Question

かなり大きなWPFベースのアプリケーションを開発しており、テストスイート（すでに多数のユニットテストが含まれています）に自動UIテストを含めたいと考えています。

UI Automation Framework Microsoftは、テストセットアップでアプリケーションをプログラムで起動し、対話するのに最適なように思えます。ただし、サンプルの確かな参照と技術の経験を見つけるのに苦労しました。MSDNで利用可能な記事と小さなサンプルは、それが確実な選択であることを確信させるのに十分ではありません。

では、テストスイートでUIオートメーションフレームワークを使用した実際の経験はありますか？警告と落とし穴は何ですか？テストスクリプトを作成する際のベストプラクティスは、「記録して再生」できますか。スクリプト可能な形式にするには、アプリケーションからのテストをどの程度促進する必要がありますか、それを自動ビルドにどのように組み込みましたか？ UIオートメーションフレームワーク以外の方向に目を向けるべきですか？

ここに経験を投稿したり、見逃したかもしれない良い参考文献へのリンクをお気軽にどうぞ

Answer 1

私が働いている場所では、システムのテストツールの評価を開始しました。 UI Automation Frameworkを使用する white というツールに出会いました。白には記録機能もありますが、問題のように見えて、まだ開発中だと思います。

私たちがやろうとしたのは、ユニットテストのように設定することでした。つまり、 [TestFixture] [Test] などです。 その後、ユニットテストと同時にそれらをnunitで実行することができました。

ウィンドウ内の一部のコンポーネントにアクセスするのは難しいことがわかっていますが、その理由を調査する機会はあまりありません。

ソフトウェアの支払いを気にしない場合は、 TestCompleteをお勧めします。

Answer 2

仕事中のWPFアプリのUIオートメーションを実行中です。 WhiteとIronRubyを使用していますが、うまく機能します。ここでそれをどのように行ったかを書きました： http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby-and-white/

Answer 3

私たちは最初は白を使い、それから遠ざかりました。 Win32 API、Winforms、Javaアプリ、およびMS UIオートメーションAPIを汎用的かつ抽象的にしようとします。 MS UIオートメーションAPIは、win32 API、winforms、およびWPFを汎用かつ抽象化しようとしているため、「最低公分母の最低公分母」になります。シナリオ。

この結果、White要素検索APIは、見つける必要があるさまざまなUI要素を見つけるのに十分な柔軟性を持たず、基盤となるUIオートメーションフレームワーク要素を十分に公開できなかったため、便利です。

私たちは最終的に、独自のフレームワークを採用しました。 MS UIAutomationフレームワークを直接使用しますが、対処しないシナリオに対処するための拡張メソッドとヘルパークラスがあります。 （主にキーボードおよびマウス入力）。

注：テストスクリプトと自家製のフレームワークはすべてIronRubyを使用しています。既存のクラスにメソッドを追加するRubyの機能と、柔軟な構文（method_missingとの組み合わせ）は、この種の機能には最適です。