デスクトップアプリケーションのUIオートメーションパターンとベストプラクティス

バックグラウンド

現在、MS Officeのプラグインのテストを自動化しています。私たちはVS 2010でコード化されたUIテストを作成しています。「コード化されたUIテストビルダー」ツールを使用できると思いますが、それは実際には私の特定のケースには適していません。

このため、さまざまなアクション機能を追加するUIコントロール/マップごとに、独自のUIマップクラスと拡張メソッドを作成しました。たとえば、ボタンを押すか、UI値をアサートします。

テストケースのシナリオはテストクラスにあります。

私はこの分野の新人であり、自動化テスターとして働くのも初めてです。

質問

プログラミング/設計の観点から、デスクトップアプリケーションのテスト自動化に関するいくつかの優れた実践についての経験とアドバイスを共有してくれる人は親切でしょうか？

UIオートメーションテストのベストプラクティスは、できる限り少ないことです。UIは頻繁に変更されるため、自動化を常に更新する必要があります。一般に、UIオートメーションなしで自動テストを実行できるように製品コードを構造化することをお勧めします。

つまり、UIオートメーションを常に削除できるわけではありません。あなたはオフィスについて言及しているので、私はあなたがWindows用にコーディングしていて、.Netを使用していると仮定しています。私は現在の仕事でかなりしています。これが私が学んだことのいくつかです。

1）.Net 3.0で導入されたUIAutomationライブラリを見てください。それらは、自動化のための広範囲で非常にシンプルな使用ライブラリーを提供します。（http://msdn.microsoft.com/en-us/library/ms753107.aspx）

2）UISpyをダウンロード（http://msdn.microsoft.com/en-us/library/ms727247.aspx）

3）製品のUIを自動化します。

3a）WPFの場合は、すべてにAutomationIDを設定します。

3b）独特のコントロールとウィンドウクラス名（ソースコードクラス名ではなく、UIクラス名）を作成してください。意味がわからない場合は、UI Spyをロードして、ウィンドウを確認してください。異なるアプリ間でいくつのウィンドウが＃32770のクラス名を持っているかに注意してください。これは、Windowsダイアログボックスのクラス名です。ダイアログを拡張し、独自の名前を設定しないウィンドウは、デフォルトでこれに設定されます。これは、UIオートメーションの観点から、あらゆる種類の悲しみを引き起こします。

4）Thread.Sleep（）ステートメントを避けます。代わりにウェイター（UIAutomationのドキュメントを参照）を使用してみてください。

5）テストコードとUIオートメーションコードを混在させないでください。UIオートメーションを実行するための個別のライブラリを作成します。テストからこれらのライブラリを呼び出します。UIが変更されると、オートメーションの更新がはるかに簡単になります。

6）イベントを発生させるアクションを実行する前に、常にUIイベントのリスナーを登録します。実際には、これはスレッドを操作することを意味します。

6a）例：ボタンをクリックしてウィンドウを開いた後、Window Openedイベントの待機を開始しないでください。ウィンドウは、ウェイターが登録される前に開いて、イベントを取得しない場合があります。

7）開いたばかりのウィンドウが必要なウィンドウであるとは決して想定しないでください。Windowsであらゆる種類のウィンドウが予期せず開く場合があります。

私はさらに続けることができますが、これは少し長くなっています。

再利用可能なユースケースから機能テストを構築する

アプリケーションをその場でエンドツーエンドでテストするときが来たら、機能テストを実行しています。通常、テスト対象の一連の要件があり、それらを表すさまざまなユースケースを構築できます。

例として、「標準ユーザーとしてログイン」のユースケースを考えます。テストフレームワークがアプリケーションを起動し、ログイン画面を待ち、資格情報を入力し、ログインボタンをクリックして、適切な画面にログインが成功したことを確認します。

「標準ユーザーとしてログイン」のユースケースを実行した後、それを基にして何か他のことを実行する必要があります。「標準ユーザーとしてログイン」のユースケースのすべてのコードを繰り返す必要はないので、そのビットを実行するテストフレームワークコードへの参照を作成するだけです。

これは、ユースケースのリストを含むある種の包括的な機能テストがあることを意味します。これらのユースケースには、アプリケーションの動作を引き起こし（ボタンXをクリック）、動作を検証する（画面が青色に変わる）テストフレームワークメソッドが含まれています。

全体として、特定のシーケンスを対象とし、特定の応答をテストする一連の再利用可能なユースケースを構築し、それらをビジネス要件と密接に関連するさまざまな機能テストに集約できます。それが整ったら、ビルドプロセス全体を完全に自動化する絶好の位置にいます。

あなたがさらに読むことに興味があるなら、私はこのアプローチについて他で書いていますが、この記事は、あなたが要求したデスクトップアプリケーションではなく、JavaのWebアプリケーション（MavenおよびSeleniumRCを使用）を対象としています。