AI駆動のテスト自動化:LLMを活用した壊れにくいPlaywrightスクリプトの構築

AI tutorial - IT technology blog
AI tutorial - IT technology blog

壊れやすいテストスイートという悩み

それは大抵、金曜日の午後4時30分に起こります。重要なアップデートをプッシュしようとした矢先、CI/CDパイプラインが突然失敗するのです。原因は何でしょうか?開発者がCSSクラス名を変更したか、ボタンを新しい<div>でラップしたことかもしれません。アプリケーション自体はユーザーにとって完璧に動作していても、End-to-End(E2E)テストはid="submit-btn-v2"という要素を見つけられず、エラーになります。

Playwright、Selenium、Cypressなどの標準的な自動化ツールは非常に高速ですが、本質的に硬直的です。これらはハードコードされた指示に従います。特定のXPathをクリックするようにスクリプトに指示し、そのパスがノード1つ分でも変われば、テストはクラッシュします。私の経験では、QAエンジニアは毎週のスプリントの30%から40%を「ロケーターのメンテナンス」、つまり新しいテストを作る代わりに古いテストを直すことに費やしています。

手動テスターからハイレベルなQAエンジニアへとステップアップするには、このボトルネックを解消する必要があります。大規模言語モデル(LLM)をテストワークフローに統合することで、壊れやすいセレクターから脱却し、「意図ベース(intent-based)」のテストへと移行できます。これは、どの座標をクリックするかではなく、何を達成したいかをコンピュータに伝えることを意味します。

なぜ従来のセレクターは失敗するのか

自動化が失敗するのは、根本的な断絶があるからです。人間がページを見ると「『ログイン』と書かれた青いボタン」が見えます。しかし、スクリプトにはdiv > form > div:nth-child(3) > buttonとしか見えません。UIが変わっても、人間には依然としてボタンが見えますが、スクリプトは迷子になってしまいます。

ReactやTailwind CSSのようなモダンなフロントエンドフレームワークが、この問題をさらに悪化させています。これらは、コードがビルドされるたびに変わるclass="css-1v2x3y4"のような動的でハッシュ化されたクラスを生成することがよくあります。これが技術的負債の山を築きます。これを解決するには、手動テスターのようにページのコンテキストを理解し、リアルタイムで変更に適応できるシステムが必要です。

PlaywrightとLLMの橋渡し

私たちの戦略では、ブラウザの制御、ネットワークのインターセプト、スクリーンショットの取得といった低レベルのオーケストレーションにはPlaywrightを使用し、意思決定はGPT-4oやClaude 3.5 SonnetのようなLLMに委ねます。セレクターをハードコードする代わりに、フィルタリングしたDOMをAIに渡し、「チェックアウトボタンはどこ?」と尋ねるのです。

このハイブリッドアプローチにより、2つの主要な機能が解放されます:

  • 自己修復(Self-Healing): プライマリセレクターが失敗したとき、スクリプトは自動的にAIに対して、ラベルや視覚的な目的から要素を見つけるよう依頼します。
  • 自然言語テスト: 「カートの中で最も高価なノートパソコンを追加して」といったプレーンな英語(または日本語)でテストを記述し、AIにその意図をブラウザのアクションに変換させることができます。

実践:自己修復型テストランナーの構築

PythonとPlaywrightを使用して、機能的な概念実証(PoC)を構築してみましょう。標準的なセレクターが失敗したときにLLMを起動するフォールバックメカニズムを作成します。

前提条件

OpenAIのAPIキーとPlaywrightライブラリが必要です。以下のコマンドを使用してインストールしてください:

pip install playwright openai
playwright install chromium

ステップ1:DOMコンテキストの抽出

HTMLファイル全体をLLMに送信するのは非効率でコストがかかります。一般的なランディングページには5,000行のコードが含まれていることがあり、1リクエストあたり0.10ドルのトークン費用がかかる可能性があります。代わりに、インタラクティブな要素のみを抽出します。

async def get_interactive_elements(page):
    # AIが判断を下すために必要なメタデータのみを抽出する
    elements = await page.evaluate("""
        () => {
            const interactive = Array.from(document.querySelectorAll('button, input, a, [role="button"]'));
            return interactive.map(el => ({
                tag: el.tagName,
                text: el.innerText || el.placeholder || el.ariaLabel,
                id: el.id,
                classes: el.className
            }));
        }
    """)
    return elements

ステップ2:AIにセレクターを尋ねる

ロケーターが失敗したとき、簡略化したJSONリストをLLMに送信します。構造化されたプロンプトを使用することで、モデルが会話形式の説明ではなく、使用可能なセレクターを返すようにします。

from openai import OpenAI
client = OpenAI()

async def ai_find_element(goal, elements):
    prompt = f"""
    ブラウザを自動操作しています。'{goal}'に最適な要素を見つけてください。
    利用可能な要素: {elements}
    返すべきは'id'または一意のCSSセレクターのみです。IDが存在しない場合は、\"text='Login'\"のようなテキストセレクターを使用してください。
    """
    
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}]
    )
    return response.choices[0].message.content.strip()

ステップ3:弾力性のあるクリックの実装

次に、ロジックを耐障害性のある関数にラップします。標準の2秒のタイムアウトに達した場合、AIがテスト実行を救うために引き継ぎます。

async def resilient_click(page, selector, goal):
    try:
        # まずは高速で低コストな方法を試す
        await page.click(selector, timeout=2000)
    except Exception:
        print(f"セレクターが失敗しました。AIが '{goal}' を検索しています...")
        elements = await get_interactive_elements(page)
        new_selector = await ai_find_element(goal, elements)
        await page.click(new_selector)

セレクターを超えて:ビジュアルアサーション

ビジュアル検証こそ、マルチモーダルLLMが真に威力を発揮する分野です。従来のツールはピクセルを比較しますが、1ピクセルのずれで誤検知が発生するため、非常に不安定なことで知られています。Visionモデルを使えば、「チェックアウトボタンは表示されており、赤色ですか?」や「モバイル版でレイアウトが崩れていませんか?」といった、より高度な質問が可能です。

最近、私はチェックアウトフローにおける50個の個別のアサーションを、1枚のスクリーンショット分析に置き換えました。これにより、ヘッダーが「今すぐ支払う」ボタンに重なっているというCSSのデグレードをキャッチできました。これは、要素が技術的にDOM内に存在し続けているため、従来の機能テストでは見逃されていたはずのバグです。

現場からの教訓

AIを活用したテストは革新的ですが、万能の「銀の弾丸」ではありません。まず、コストを考慮してください。すべてのアクションに対してLLMを呼び出すのは高価です。AIは、CI環境での偽陰性を防ぐためのフォールバックメカニズムとしてのみ起動させるべきです。

次に、レイテンシ(遅延)の予測を管理してください。標準的なPlaywrightのセレクターは5ミリ秒で解決しますが、AIの呼び出しには3〜5秒かかることがあります。開発フェーズでセレクターを「発見」するため、あるいは安全網としてAIを使用し、10分以内でのテスト実行が必要な場合に、すべての操作をAIに頼らないようにしましょう。

最後に、常に監査証跡を保持してください。プロンプトが曖昧でAIが間違ったボタンをクリックした場合、その理由を知る必要があります。自己修復ロジックがトリガーされるたびに、スクリーンショットを保存し、AIの推論プロセスをログに記録することをお勧めします。

結論

Playwrightの実行速度とLLMの推論能力の組み合わせは、次世代の品質保証を象徴しています。私たちは、テストがアプリケーションの意図を理解するインテリジェントなエージェントとなる世界へと向かっています。まずは、最も壊れやすいコンポーネントに自己修復を実装することから始めてみてください。それが、インフラを複雑にしすぎることなく、メンテナンスの負担を軽減する最も効果的な方法です。

Share: