私はそのTest Automationようなことに非常に慣れていません。最近、多くの s を欠いている CAD のような WPF アプリケーションの UI テストを自動化するアプリケーション (または、スクリプトかもしれません) を作成する必要があるプロジェクトに割り当てられましたAutomationId。
MSDN やその他の情報源で少し検索した後、VS2010 に含まれるMicrosoft UI Automation Library新機能を使用する必要があるかどうかについて少し混乱しています。Coded UI Testこれら 2 つのうちのどちらがどのシナリオに適用されるか、一方が他方に対してどのような利点を持ち、どちらが私の目的に適しているかについて、明確なイメージが得られません。
この問題に関する経験/知識がある場合は、光を当ててください。前もって感謝します。
基本的に、Microsoft UIA は .Net 4.0 の新しいアクセシビリティ ライブラリです。WPF アプリケーションとコントロールには、AutomationPeer クラスによる UIA のサポートが組み込まれています。
コード化された UI テストは、Microsoft UIA ライブラリを基盤として使用する記録と再生の自動化ツールです。C# でコードを書くのに比べてツールであるため、より多くのテスト ケースを記録するための QA の生産性が向上します。
自動化のサポートが計画されているアプリケーションの場合、Coded-Ui で十分です。AutomationID がない場合は、コントロールに名前などの一意のプロパティがあることを確認してください。これを確認するには、UIVerify または Inspect を使用します。
固有のプロパティが利用できない場合は、コード化された UI と組み合わせて使用できる以下の他の手法があります。
イベントから アプリケーションが UI オートメーション イベントを受け取ると、イベント ハンドラーに渡されるソース オブジェクトは AutomationElement です。たとえば、フォーカス変更イベントをサブスクライブしている場合、AutomationFocusChangedEventHandler に渡されるソースは、フォーカスを受け取った要素です。詳細については、「UI オートメーション イベントをサブスクライブする」を参照してください。
ポイントから: 画面座標 (カーソル位置など) がある場合は、静的 FromPoint メソッドを使用して AutomationElement を取得できます。
ウィンドウ ハンドルから: HWND から AutomationElement を取得するには、静的 FromHandle メソッドを使用します。
フォーカスされたコントロールから: 静的な FocusedElement プロパティから、フォーカスされたコントロールを表す AutomationElement を取得できます。
コード化された UI テストを活用して使用できる場合は、そのルートに進みます。指定した構成がサポートされていることを確認してください。
UI オートメーション ライブラリは、コード ビハインドのすべてを解決します。これにより、UISpy などのツールを使用してコントロールの内部にアクセスし、テストを構築できるようになります。
一方、コード化された UI テストには依然としてコード ビハインドがありますが、テストしている特定のアプリケーションの手順を記録できるため、作成できるテストの数が大幅に増加します。
上記の回答を補完するために、CUITEを見てください。これはかなり役に立ち、適切なアプローチである可能性があります。
私は、CodedUITest ライブラリを使用して「独自のローリング」「セミフレームワーク」を開始し、自動化の詳細を (C#) コードから分離するためのパラダイムを考案しました。基本的に、各行がテスト ステップ (または別のワークシートのシナリオへのポインター) であるスプレッドシートから実行する必要があることを読み取るドライバーを作成しています。現時点では、不完全ですが有望です。WPF アプリケーションに対して動作し、部分的に成功しています。主な問題の 1 つは、開発者がコントロールを一意かつ一貫して識別することを怠ったことです。
ベイ