自動GUIテスト：途中で会う

https://stackoverflow.com/questions/822275

03-07-2019
|

質問

GUIの自動テスト用のシステムの開発を担当しましたが、いくつかのアドバイスを利用できます。幸運なことに、私たちはGUIの大幅な再設計の最中にあり、作業を行っている開発者は、コードを自動化により使いやすくすることにオープンです。私の問題は、何を追加するように頼むべきかわからないということです。どのフックを追加しても、インターフェイスの機能、外観、またはセキュリティに影響を与えることはできず、パフォーマンスに顕著な影響を与えることはありません。それ以外は、空が限界です！

問題のアプリケーションは、AJAXを介してアクセスされるWebベースのJavaアプリです。既存の機能のほとんどは、jsp、Javascript、および少しのFlash 8を使用してコーディングされています。次の機能は、 YUI Javascriptライブラリ。柔軟性と価格タグ（無料）のおかげで、テストツールとして Selenium にかなり満足しています。主なポイント：テストの再利用性と保守の容易さを目指しています。私の好みは、テスト開発に記録再生システムを使用するのではなく、ページ要素を検出、検証、実行するコードを書くことです。

コードにどのフックを配置できるか、またはテスト開発をより簡単にし、テスト自体をより堅牢にするためのベストプラクティスに関するガイダンスを提供できますか？

解決

基本的な指針：テストを行う場合、テスターはアプリケーションをその状態にする方法と、その状態になったら状態が正しいことを検証する方法が必要です。

最初に行うことは、自動化がプログラミングであり、UIがAPIであることを確実に理解させることです。

UIをarbitrarily意的に変更しないという合意-テスターのボブがコンポーネントがボタンからリンクに変更され、それが仕様に一致し、クリックして続行することを確認した場合。自動化では比較的簡単にコードを変更できますが、複数の場所で行う必要がある変更です。（テスターとしての仕事は、変更が発生することを理解し、メンテナンスのコストを最小限に抑えることです。彼らの仕事は、重要な変更のみを行い、影響を理解することです）
あなたがどのページにいるかを判断する方法...ボブはログインと注文入力の違いを知ることができますが、自動化はどのように知るのでしょうか？「ユーザー名」ラベルのある入力フィールドの場合、ログインページ。入力フィールドに注文番号がある場合、注文フィールド。

よくありません-ページタイトル、非表示コンポーネントなど、ページを識別するための一貫したUI要素を使用することをお勧めします

対話する必要があるすべての要素（クリック、入力、検証など）を一意に識別する方法。INPUT_42....ではなく
デベロッパーに、テスターがデバッグを高速化するために提供できる情報を尋ね、ログファイルに保存するよう依頼します
プログラムの状態をダンプする機能
一貫したエラー処理＆amp;レポート（また、ちょうどよいUIデザイン）

他のヒント

ほとんどの質問と同様に、状況によって異なります。主にあなたのサイトがどのようなもので、どのような種類のコントロールがページにあるのか-繰り返し要素などがたくさんありますか？

Selenium RCとSelenium IDEを使用して多くの成功を収めました。主なことは、Seleniumとそのコマンドの使用に慣れることです。また、ページ上のオブジェクト（XPathとCSSセレクター、および「含む」関数）の検索に慣れることも役立ちます。不要なのは、同じ選択パスを持つ要素がたくさんあることです。以下のテーブルとdivに固有の部分がない場合、テストがさらに複雑になる可能性があります。

<html>
  <body>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
  </body>
</html>

画像をテストするには、画像ファイル名以外の何かに基づいて画像の存在を確認できるので、画像の更新時にテストを変更する必要はありません。 Flashオブジェクトをテストする必要がある場合は、このサイトをご覧ください。

それ以外にも、開発側に組み込むことができることに気づいたことはあまりありません。テストのセットアップとページ上の要素の検索を開始すると、おそらく開発者があなたを助けるために何をする必要があるかがすぐにわかります。

1つのアドバイス：テストコードを抽象化の少なくとも2つの層に保管してください：

上位層：これは、特定のアプリケーション用語/アクションなどに向けられたある種のファサードである必要があります。この層は、Selenium RCライブラリを直接使用しません。バックグラウンドで...を使用します...
... 下位層：いくつかの一般的なテストパターンを備えたライブラリ（例：＆quot; ラジオボタンコントロールの値Xが選択されていることをアサート＆quot;）、Selenium RCライブラリを使用します。

こうすることで、テストが保守しやすくなり、テスト対象についてより理解しやすくなります。 3層のアプローチも試みました。 3番目（最上位）の層はXMLを使用して指定されたテストです。これは、非プログラミングテスターがC＃コードを詳しく調べることなく受け入れテストを指定できるようにするためでした。

McWafflestixとs_hewittによるコメントへの追加-gui要素は、適切にタグ付けされ、一意であり、gui自動化で成功するために予測可能である必要があります。要素IDが予測できない場合、問題が発生します。予測可能とは、必ずしも静的であるとは限りません。ユーザー名フィールドやログインボタンなどの静的ページ要素の場合、これらの名前/ IDはビルドからビルド、実行から実行まで静的であると予想されます。チェックボックス、ラジオボタン、動的コンテンツの場合、これらは動的でありながら予測可能であると期待しています。たとえば、class =＆quot; contentdetail＆quot;のdivがあるとします。およびid =＆quot; 12345＆quot;。確実に対話する必要があるオブジェクトを見つけるためにxpathを作成できる限り、あなたは良いはずです。

編集：開発者がテストの自動化をサポートする優れた方法は、テストのセットアップです。アプリケーションによっては、自動化されたテストのセットアップと分解が問題になる場合があります。たとえば、倉庫のワークフローアプリケーションでは、ワークフローの最初のテスト（倉庫へのアイテムの受け入れ）は簡単にセットアップできますが、ワークフローの最後のテスト（倉庫から顧客へのアイテムの出荷）は簡単です。多くの依存関係（アイテムは倉庫にあり、十分な数量、正しい在庫場所などにある必要があります）。自動化コードのほとんどは、アプリを介してナビゲートして入力するだけで、実行できるポイントに到達できるテスト。これらの場合、依存関係を注入したり、データベースを何らかの既知の状態にリセットしたりするために、何らかの外部ユーティリティ（アプリの外部、メインGUIは影響を受けません）があると有益な場合があります。私の倉庫の例では、ユーティリティはAPIレベルでシナリオを設定できるため、自動化されたGUIテストは関連するポイントで取得できます。

開発者がコードに追加して支援できることはほとんどありません。

問題は、コードパスの実行とそれらのコードパスの有効性をテストする場合、ユニットテストで行う必要があり、それらはGUIから完全に離婚する必要があるということです。しかし、GUIを本当にテストしたい場合は、ユーザー入力をシミュレートするだけです。これに役立つ1つのことは、テストフレームワークによって適切に検出されて実行されるように、オブジェクトとコントロールに適切にタグを付けることです。それ以外に、できることは多くありません（それ自体でかなり役立つことがありますが）。

（適切な）単体テストにはかなりグリーンですが、GUIのテストを避けてくださいといういくつかの言及に出くわしました。通常、特定の理由を省略しているため、実際にバックアップすることはできません。

私がとるアプローチ（および「.NETコンポーネントのプログラミング」でJuval Lowyからアドバイスされたアプローチは、インターフェイスを介してGUIから実際のコードを抽象化することです。 GUI自体を実際にテストせずに、GUIによってトリガーされるビジネスロジック。

これは非常にうまく機能し、ビジネスロジックをGUIから大きく分離した、よりクリーンなコードになり、GUIの変更によるストレスも大幅に軽減されました。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow