利益:
- 実際のユーザー結果を検証する data-testid、open wait、assert など、人工知能を使用して堅牢な UI テスト コードを作成する機能
- 脆弱なテスト (不適切なセレクター、ブラインド待機) を回避し、ページ オブジェクト モデル構造でテストを維持しやすくする機能
- コードを破壊して生成されたすべての UI テストをテストし、偽で合格したテストを検出して修正する機能
ユーザーがブラウザーで行うすべてのクリック、すべてのフォーム入力、すべてのページ遷移を手動で何度もテストすることはできません。だからこそ、UI テストの自動化 (ユーザー インターフェイス。これらのテストは、実際のブラウザーをプログラムで駆動することでユーザーの動作を模倣します) が存在します。 Selenium、Playwright、および Cypress は、この作業に最も一般的なツールです。人工知能 (AI) は、これらのツールのコードを書くのに非常に熟練しています。テスト ケースを記述すると、AI が実行可能な自動化スクリプトのドラフトを提供します。しかし、ここでこのモジュールの中心となる警告が再び機能します。AI が生成する UI テスト コードは、多くの場合、「緑色に点灯するが間違ったことを検証する」か、風になびく脆弱なテストになる可能性があります。あなたの仕事は、このコードを実行することではなく、コードが実際に正しいことを堅牢に検証することを確認することです。
この単元では、AI を使用して、堅牢で保守可能で真に検証可能な UI テストを作成することを目指しています。脆弱なテストを回避する方法を学びます。
ソリッド UI テストの 3 つの柱
1. 要素ロケーターを修正します。テストではセレクターを使用してページ上の要素を検索します。 AI は、長い XPath パス (ページ構造に過度に依存するアドレス)、CSS クラス名に基づくセレクター (デザインが変更されると壊れる) など、脆弱なセレクターを生成することがよくあります。堅牢な方法は、開発者がテスト用に追加した data-testid のような安定した属性です。これを AI に明示的に課します。
2. 明示的な待機。 UI テストにおける脆弱性の最大の原因はタイミングです。一定の sleep(3) (ブラインド待機) は悪い習慣です。十分ではない場合もあれば、時間を無駄にする場合もあります。正しい方法は、「この要素が表示されるまで待機する」という明示的な待機を使用することです。 Playwright はこれをほぼ自動的に行います。 Selenium では、明示的にリクエストする必要があります。
3. 意味のある主張。テストでは、「ページが読み込まれた」だけではなく、「注文番号が画面に表示された」など、ユーザーが実際に見る結果を検証する必要があります。 AI によって生成されたテストにアサーションがないか、重要ではない場合、そのテストは疑似パス (1 番目のユニット) を生成します。
注意: AI によって生成された UI テストを初めて見るときは、セレクターがコミットされているか (data-testid)、待機中であるか (ブラインド スリープではない)、アサートによって実際のユーザーの結果が検証されているかどうか、という 3 つのことを確認してください。これら 3 つが OK であれば、テストはおそらく適切です。
ページオブジェクトモデル
テストが大きくなるにつれて、各テスト内にセレクターを記述するのはメンテナンスの悪夢になります。ページ オブジェクト モデル (POM - 各ページ/画面のセレクターとアクションを 1 つのクラスに収集するデザイン パターン) は、セレクターを 1 か所に保持します。インターフェイスが変更された場合は、単一のファイルで更新します。 AI に直接ではなく POM 構造でテストを生成させます。これにより、メンテナンスが大幅に容易になります。
弱いプロンプト / 強いプロンプト
弱い: 「ログイン ページの Selenium テストを作成します。」
Strong: 「Playwright (TypeScript) を使用してログイン フロー テストを作成します。セレクターは data-testid のみを使用します。ページ タイトルではなく、ユーザーに表示される内容の制御は使用しません。」
強力なプロンプト。このツールは、言語、セレクター ポリシー、待機戦略、アーキテクチャ (POM)、および表現的なアサートの期待値を提供します。
テストデータと環境への依存性
堅牢な UI テストは、正しく記述されているだけでなく、独自のテスト データを構築してクリーンアップします。 AI によって生成されたテストは、多くの場合、環境内にすでに存在すると想定されるユーザーまたはレコードにリンクされます (「管理ユーザーとしてログイン」)。この仮定は、テストが別の環境で実行される場合、または別のテストの後に実行される場合に崩れます (ユニット 9 の順序依存性の問題)。実際のところ、すべてのテストでは、テストの開始時に必要なデータが作成され (または API 呼び出しで準備され)、最後にデータがクリーンアップされます。 AI に「このテストが依存するデータをテスト内で設定する。外部からの既製のデータを想定しない」ように明示的に指示します。
もう 1 つの重要な点は、実際のユーザー データを使用して UI テストを実行しないことです。運用データベースのコピーがテスト環境で使用される場合、これらのレコードは実在の人物のデータになります。スクリーンショットやテスト記録により、このデータが明らかになる可能性があります。合成 (架空の) テスト アカウントを使用します。これにより、機密性が保護され、テストが再現可能になります。実際の顧客アカウントを使用して「注文キャンセル」テストを実施することは、倫理的にも運用上も間違いです。
ヒント: UI テストはできるだけ少なくしてください。実際の検証は、高速で安定した API と単体テストに任せます。 UI テストは高価で脆弱です。真のエンドツーエンドのユーザー フロー (テスト ピラミッド ロジック) を検証する場合にのみ使用してください。
車両比較
特徴
セレン
劇作家
ヒノキ
言語
Java、C#、Python、JS
JS/TS、Python、.NET、Java
JavaScript/TypeScript
オートスタンバイ
いいえ（手動）
はい（強い）
はい
マルチブラウザ
広い
クロム/Firefox/WebKit
クロム主体
脆くなる傾向
高（マニュアルスタンバイ）
低い
低い
学びやすさ
中程度
簡単な
簡単な
並列運転
グリッドが必要です
内蔵
居住者/有給
AI にコードを要求する場合は、それがどの車両に属するかを明確に述べてください。そうしないと、混乱を招く、機能しないコードが生成される可能性があります。
コピー可能な 4 つのテンプレート
1) ソリッド UI テストの生成:
あなたの役割: シニア テスト自動化エンジニア。次のフロー: [フロー] の [ツール + 言語] を使用してテストを作成します。ルール:- データ テスト ID のみをセレクターします。 XPath/CSSクラスを使用します。 - 盲目的な睡眠は禁止です。明示的/自動待機を使用します。 - ページオブジェクトモデルを適用します。 - 各アサートで実際のユーザー結果を検証します。各テストの開始時に、どの合格基準を検証しているかをコメントしてください。
2) 脆弱性の制御:
次の UI テストで脆弱性を調べてください:- 不安定なセレクター (長い
3) ページオブジェクトへの変換:
次の単純なテスト コードをページ オブジェクト モデル構造に変換します。セレクターとアクションをページ クラスに移動します。テスト ファイルにはシナリオ フローのみを読み取らせます。 [ツール/言語].Code: [コードを貼り付け]
4) 擬似遷移証明:
この UI テストが実際に検証されていることを証明します。アプリケーション コードにどのような変更を加えると、このテストが RED になりますか?テストを中断する変更が見つからない場合、テストは不十分です。不足しているアサートを追加します。テスト: [テストを貼り付け]
ミニケース3個
ケース 1 — 壊れやすいセレクターからの解放。あるチームが AI を使用して作成した 40 のテストのうち、70% はインターフェイスの更新後に機能しませんでした。それらはどれも実際のバグではなく、すべて脆弱な XPath セレクターでした。チームは、「脆弱性チェック」テンプレートを使用してテストをデータ testid ベースに変換しました。次の 3 回のインターフェイス更新で、誤ったブレークの数はゼロに減少しました。メンテナンス時間は 1 週間あたり 6 時間から 30 分に減少しました。
ケース 2 — 偽合格 UI テスト。 AI が「カートに追加」テストを生成しました。テストは青でした。 「偽の通過証明」テンプレートを実行すると、テストはボタンのクリックとページ タイトルのみをチェックし、カート カウンターが増加したかどうかは確認しなかったようです。カートのロジックが完全に壊れていたとしても、テストは合格しました。 true アサート (カート バッジが「1」) を追加しました。
ケース 3 — ブラインド待機の罠。 AI によって生成された Selenium テストでは、各ステップの後に sleep(2) がありました。 60 回のテストには 14 分かかりましたが、それでも時々壊れました。オープン待機 (要素がクリック可能になるまで待機) に切り替えた後、時間は 5 分に短縮され、脆さは解消されました。ブラインド待機は時間がかかり、信頼性も低かった。
よくある間違い
- 壊れやすいセレクターに同意します。 AIが生成した長いXPathをそのまま使用する。最初のインターフェイス変更時にテストがクラッシュします。
- 盲目的な「眠り」を離れる。固定待機でタイミングを「解決」します。遅くて優柔不断です。
- 些細な主張。ページが読み込まれたことを確認するだけです。実際のユーザー結果をチェックしません (偽パス)。
- POM なしで成長します。各テストにセレクターを配布します。インターフェイスが変更されると、数十のファイルを手動で更新します。
- ツールを指定しない。 AI に必要なツール/言語を伝えない。乱雑で機能しないコードが生成されます。
- 生成されたコードを実行してパスするときは信頼します。コードを壊してテストするわけではありません。
要約すれば
UI テストの自動化では、プログラムで実際のブラウザを動作させることでユーザーの動作を検証します。 AI はこのコードを迅速に生成しますが、脆弱なテスト (不適切なセレクター、ブラインド待機) と偽の合格テスト (不完全/自明なアサート) という 2 つの大きな落とし穴があります。ソリッド UI テストの 3 つの柱は、コミット セレクター (data-testid)、明示的な await、および実際のユーザー結果を検証するアサートです。ページ オブジェクト モデルでテストを生成すると、メンテナンスが大幅に簡素化されます。生成された各テストを、「どのような変更を加えるとこれが壊れるのか?」という質問をしてテストします。
アプリケーションタスク
独自のプロジェクトからユーザー フローを選択します (ログインや検索など)。 「堅牢な UI テスト生成」テンプレートを使用して AI にテストを作成させます。次に、(1) セレクターをチェックして修正し、「脆弱性チェック」で待機します。(2) 各テストが実際に検証されることを「擬似合格証明」で証明します。(3) コードを解読して、テストが赤になることを観察します。作成および修正されたテストの数、見つかった脆弱性と疑似パスの数を報告します。
チェックリスト
- [ ] AI にツール、言語、セレクター ポリシー、アーキテクチャ (POM) を明確に与えました。
- [ ] セレクターが data-testid であることを確認しました。
- [ ] ブラインドスリープの代わりに明示的/自動待機を使用するようにしました。
- [ ] 各アサートが実際のユーザー結果を検証することを確認しました。
- [ ] コードを壊して各テストをテストしました。赤くなるのが見えました。
- [ ] ページ オブジェクト モデル構造のテストを集めました。