私のテスト自動化の実践では、保守作業を軽減する GUI マッピング戦略を常に使用しています。
たとえば、「Google 検索」ボタン (www.google.com) を識別する必要がある場合、その XPath は次のようになります。
//input[@name='q']/html/body/center/form/table/tbody/tr/td[2]/input[3]しかし、多分私は何かを逃していますか？ドキュメント構造が変更された場合、これについて知っておく必要があり、一部のテストは失敗するはずですか?
どう思いますか？どのようなベスト プラクティスをお勧めしますか?
要素にスクリプティング/CSS で使用される ID がある場合、その ID をテストで使用します。それ以外の場合は、テスト用に HTML を積極的に計測します。つまり、あいまいさを避けるために、テスト用にid を追加できるということです。通常、これを示すために接頭辞を付けます。id="ftGoogleButton". これは、HTML のみを扱う人々が、要素に関連付けられた自動テストがあることを理解できるようにするためです。通常、特定の ID への参照については css/js のみを検索するため、この規則は実用的です。
私は同じことをし、2番目ではなく最初の定式化を選択します...ほとんどのテストで。
それらのテストでカバーされる機能に関連する変更でテストを中断し、同じテストでアプリに対する他のほとんどの変更を無視する必要があります。
そのため、「foo」の検索で 0 個以上のドキュメントが返されることを確認している場合、それはページの構造とは関係なく、そのような変更を無視する必要があります。
ただし、検索フォームに送信ボタンが装備されていることを確認するために作成されたテストでは、フォームからボタンへの移動に使用される XPath でこれらの仮定を具体化する必要があります。
krosenvold が言ったように、開発者に htmlnameやid属性を標準化してもらい、それらを使用することは最良の戦略の 1 つです。私の論文Test Automation as a Development Requirementでは、このトピックと、開発者がアプリケーションをより自動化に適したものにするためにできるその他のことについて説明しています。
また、その後のメンテナンスを容易にするために、すべてのオブジェクト識別プロパティを 1 つの中央リポジトリに格納する必要があります。ほとんどの商用ツールにはこの機能が組み込まれていますが、オープン ソース ツールでは、独自のメカニズムを展開する必要がある場合があります。