2019年2月22日 / 最終更新日時 : 2020年9月3日 user 事例・ソリューション

テスト自動化における 10 のベストプラクティス #4: 信頼できるロケーターの使用

UI (ユーザーインターフェイス)のテストを適切に設計しない場合、テストの実行速度が遅くなったり失敗しやすくなることが (言い換えれば「脆い」テストになることが) あります。しかし、たとえUIに変更があった場合でも安定したテストを設計することは可能です。

安定したUIテストを設計する上で最も重要な要因のひとつである、UI要素 (テキスト、フォームフィールド、ボタン、スクロールバー、その他のコントロール) を特定するための手法について説明します。

UIテストの基本

一般的な UIは (デスクトップ、モバイル、Webのアプリケーションに関わらず) 入れ子になった一連のコンテナにまとめられます。UIテストでは、コンテナ内のUIオブジェクトの位置を特定するために、オブジェクトID、クラス（class）、名前（name）などの属性によるパスを使用します。

※Ranorex（Ranorex SPY）でUIオブジェクトを特定する方法については以下の動画をご覧ください。RanorexはUIオブジェクトへのパスにワイルドカード (*/*) を含めるため、セレクターの信頼性が高まります。アプリケーションの階層に変更があった場合でも、テスト実行時にUI要素を発見することができます。

安定したロケーターの作成

テスト実行時にUI要素を確実に発見するためには、以下のルールが役立ちます。

座標ベースの認識を使用しない

座標ベースの認識は、(X,Y) 座標と長さを利用してUIオブジェクトを特定します。しかし、UIオブジェクトが常に画面上の同じ位置になければ、正しく特定することができません。座標ベースの認識はUIのレイアウト変更があると機能しなくなるため、たとえ画面サイズが固定されたアプリケーションであっても、これは「脆い」認識方法です。

画像ベースの認識を使用しない

画像ベースの認識では、テスト実行時に「保存されている画像」と「実際の画面上の画像」をピクセル単位で比較します。目的の UI 要素の画像が発見されると、その座標が返されます。
画像ベースの認識には座標ベースの認識と同じ本質的な不安定さがあるため、可能ならば、この方法は避けた方が良いでしょう。一方、自動化された回帰テストでは画像ベースの比較は有用です。この場合、画像によってUIオブジェクトを発見するのではなく、画像自体をUIオブジェクトとして使用しているからです。

動的IDを使用しない

動的IDとは、アプリケーションまたはWebページがロードされるたびに変化するIDのことです。多くの場合、動的IDは動的コンテンツ(たとえば現在日時を表示するWebページ)に関係しています。理想的な方法は、アプリケーションのUI要素ごとに永久的な固有IDを作成し、このIDを使ってオブジェクトの位置を特定することです。それができない場合は、(オブジェクト名も動的でない限り)オブジェクト名、リンク、CSS、XPath といった別の固有な属性を使用しましょう。

※Ranorex Studioは、「ウェイトルール」機能を使用することにより、オブジェクトの動的IDではなく、別のプロパティを使用してオブジェクトを特定します。この方法の詳細については Ranorex ブログの「自動テストと動的 ID (Automated Testing and Dynamic IDs)」を参照ください。

最短のパスを使用する

オブジェクト認識に使用するパス（XPath）は、可能な限り短くしましょう。パスを短くすることで、オブジェクト認識の目標である「早さ」と「安定」のバランスが取られます。

※以下の動画では、RanorexのRanoreXpathを使ってオブジェクトを特定する方法をご紹介します。RanoreXPathは、XML文書からノードを選択するために XPathクエリー言語に基づいていますが、XPath WC3 規格にはない機能を有します。

その他のベストプラクティス

以下のプラクティスは、UI テストのレジリエンスを高め、メンテナンスを削減するのに役立ちます。

オブジェクトリポジトリを使用する

リポジトリを使ってUIオブジェクトを管理すると、UI要素の定義をテストスクリプトと分離できます。UI要素のセレクターを変更しなければならない場合に、そのオブジェクトを参照する各テストケースを変更するだけで済みます。また、共有可能なリポジトリによって、テスターと開発者の連携を強化することもできます。

開発者を巻き込む

前述したように、テスト対象アプリケーションの各UI要素に固有のIDを用意すると、テストが単純化されます。さらに、開発者はログファイルを作成することでテスト業務を補助できます。ログファイルには、アプリケーションの動作を記録するだけでなく、意味のあるエラーメッセージ、ステータスバー、ブレッドクラムといったアプリケーションの他のステータス情報も記録しましょう。

オブジェクト認識のトラブルシューティング

安定したロケーターを使用している場合でも、オブジェクト認識が失敗することがあります。オブジェクト認識の問題を解決するのに役立つヒントを以下でご紹介します。

非表示のUI要素

ドロップダウンメニュー、ポップアップウィンドウ、コンボボックスといった要素は、マウスクリックの後にだけ表示され、フォーカスを失うと非表示になることがあります。このような要素を処理するには、「目的のUI要素にフォーカスを当てるためにユーザーが一般的に実施しそうな操作」をテストスクリプトに必ず組み込んでください。また、テストスクリプトに待機時間を設けて、目的の要素が表示されるまで実行を遅延させる必要もあるかもしれません。