AI ベースのエンドツーエンドテスト自動化

この記事では、**コンピュータユーザーエージェント（CUA）**をテスト自動化に活用する方法を紹介します。この新しい技術によりプログラミングの知識がほとんどなくても、テスト対象アプリケーションに変革を起こさずにテストが実行できます。

通常従来のエンドツーエンドテストでは、アプリケーション自体のコードを変更し、テストIDを追加する必要がありました。テストIDを使用することによって、テスト対象ページの構成要素を特定し、操作することが可能になります。

しかしAI技術を使うと、人間が画面を見て操作を判断するように、アプリケーションと直接やり取りできます。これにより、テスト自動化の発展性が広がります。

弊社は非英語のテストケースを作成し、日本語及びハンガリー語でテストを実行しました。記事の最後には、この手法で発見した制約も共有します。

簡単なデモ

詳細に入る前に、実際的な動作方法の簡単なデモを見てみましょう。

モデルについて

今年OpenAIはcomputer-use-previewモデルを公開しました。このモデルはOpenAIのOperatorやChatGPTの新しいAgentモードにも利用されています。このモデルはGUI（グラフィカルユーザーインターフェイス）とやり取りするよう設計されています。

本モデルに基づいて製造された製品は、買い物などのタスクを自動化する目的で開発されましたが、弊社は「このモデルをテスト自動化に使えないか？」という別のアイデアがありました。

コンピュータユーザーエージェントはスクリーンショットを見て、どの入力操作が行うかを判断します。例えば、画面上のボタンをクリックしたり、ページをスクロールしたり、キーボード入力を行ったりすることができます。

弊社の目標は、このモデルをAIテスターとして、実際の人間のテスターのようにアプリケーションのテストを実行できるようにすることでした。

まず、テストケースの形をスケッチし、AIテスターが実行するテストケースは手動テストケースをできるだけ似るべきと決定しました。これは従来のエンドツーエンド自動化と異なり、テストプランの実行自動化です。

テストケースの記述

この手法で自動テストを実行するため、まずテストケースの書き方を検討しました。例としてテストケースのスケッチを作り、モデル上に構築したいAPIを把握できました。結果は以下の通りです：

このコードは最も高レベルですが、アプリケーションのノウハウは必要ありません。手動テストケースのように読みやすく、ユーザーインターフェイスを理解できる人なら誰でも書けます。

• clickOn(description): 画面上に指定された要素をクリック
• fillIn(fields): フォームなどに指定されたフィールドに入力
• expectOnScreen(description): 現在画面上に表示されている内容が真実であることを確認

以上の機能があれば、UIアプリケーションのほぼ全てのテストケースを記述ようになります。

TypeScriptやJavaScriptはUnicodeでエンコードされた機能名と変数名を対応しているので、あらゆる言語でテストコードを書くことができます。例えば日本語で同じテストケースは以下となります：

そしてハンガリー語では：

もちろん、上記の機能の実装で進めました。次にclickOnはどのように動作していることについてご案内します。

AI によるクリック操作

OpenAIは、コンピュータユーザーエージェントループを実装することをおすすめしています。

ループの各ステップでは以下のことが実行されます：

• 現在のアプリケーション状態のスクリーンショットを取得
• スクリーンショットとメッセージをモデルに送信
• モデルは次のどちらかを選択
  • コンピュータを操作させ、座標にクリックするやテキスト入力などの入力行動を実行
  • メッセージで応答　ー　タスク完了または自律操作不可能と伝える
• モデルの入力操作を実行し、入力の処理が完了されるまで待機
• モデルがメッセージで応答するまでループを繰り返す

これはOperatorやChatGPT Agentモードと同じ動作方法です。

このループを実装し、モデルに単一の簡単なステップだけ実行させる厳密なシステムプロンプトを作成しました。ステップが完了できない場合の例外処理に関する指示も明確にする必要があります。

考え出した最終的なシステムプロンプトは以下の通りです：

ある動作のプロンプトに例外処理指示を組み込みことを決定しました。clickOnの例では、プロンプトは以下の通りです：

{{targetDescription}}はクリックされた要素の記述に交代されます。（例：送信ボタン）

動作の仕組み

実用化

検討と様々なPOCの上、テストランナーにはmocha、ブラウザ自動化ライブラリにはpuppeteerを選択しました。これらのツールを活用する小規模なフレームワークを構築し、望ましき高レベルAPIを取得しました。

その後、.test.jsファイルを作成することでテストケースを記述できるようになります。

実行させるために以下のコマンドを使います：

各ステップに時間がかかるため、タイムアウトを長めに設定することが重要です。高性能なモデルですが、時に処理が遅くなる場合があります。

他言語への対応

弊社で多言語UIテストも多く実行しています。フレームワーク的には以下の2点が課題となります：

• テストは1回書くだけで、AIが理解するあらゆる言語で動作させたい
• システム挙動の要件を正確に伝えるため、テストを自分の言語またはお客様の言語で記述したい

前者にはgenerateDataFieldという機能を導入しました：

• ページの言語をHTMLのlang属性から判定
• AIに指示を出す：提供されていれば、記述に基づくフィールドデータを生成・ 記述の言語に関わらず 、ページの言語 で生成することが必須

後者は、TypeScriptとJavaScriptのUnicodeサポートにより問題ありませんでした。aliases.ja.tsとaliases.hu.tsファイルを作成し、以下のように動作します：

フレームワーク内の各機能のエイリアスをエクスポートすることで、あらゆる言語でテストケースを記述ことができます。

制約

この手法にはいくつかの制約があります。AI技術に依存しているため、完全な精度には保証がありませんが、AIの成長に従って制約が減少する見込みです。また、研究プレビュー版モデルの上にこのPOCを構築しましたが、モデルはまだ未完成です。

• プレビュー版モデルにとって非英語のインターフェースを解読するのが時々困難です。日本語のUIの上でもテストを実行して多くの場合機能しましたが、信頼性が低いので手動で確認する必要がある偽陽性や偽陰性が発生しました。
• モデルは構造化出力をまだ対応していないので、応答フォーマットの指示を必ずしも遵守しません。ステップの成否を判定するのが難しいです。その理由で対策として第二モデルを活用し、CUA出力はレビューされるようになりましたが、その一方費用と複雑性も増加しています。
• 大きなUI要素ではうまく動作しますが、ピクセル単位の正確さが必要の場合はまだチャレンジです。ビデオゲームでの小さいアイコンの場合失敗率が高いです。
• レイテンシにより、リアルタイム性を着実にテストできません。（例：自動消失するトーストメッセージは検知される以前消失します。）

今後の展望

自社製品やお客様プロジェクトのテストケースを迅速に作成する予定です。また他のユースケースはアプリケーションデータを生成するためAPIやDBスナップショットを使わず、手順を記述してシステムを希望通りの状態に届けます。

また他のユースケースはモデルが行ったステップを 記録 し、従来のE2Eテストとして再利用することです。これにより、アプリケーションのE2Eテストを迅速に作成し、毎回CUAモデルを呼び出さずに実行できるようになります。その反面に記録されたテストが脆弱になり（ハードコードされたIDまたはセレクターを使用）、通常のE2Eテストと同様に継続的なメンテナンスが必要になることです。

このアプローチをよりコスト削減と信頼性向上のため色々開発手法を検討しているところです。

• 現在実験している手法の一つは、CUAを呼び出す前に、テスト対象のDOMを理解した非CUAモデルを使用することです。モデルがステップを実行できない場合（例：テストIDが見つからない場合）、フォールバックとしてCUAを呼び出すことができます。その結果、CUAの呼び出し回数がテスト実行にかかるコストや時間とともに削減されます。
• また、偽陽性と偽陰性をより確実に検出するための複数の技術を実験しています。他のAIモデルを使用して、CUAループ中に取りまとめられた結果（スクリーンショット、ブラウザのログ、アクションなど）を見直したら、CUAの元の結論が正しかったかどうかを判定できます。
• CUAループのコストを削減するもう一つの方法は、より優れた会話状態管理を実装することです。実際的に最後の少数のメッセージを温存し、それ以前のものは削除すべきです。これにより、ステップに要する文脈の大きさを制限する同時にトーケン数も削減します。

このPOCに興味がありますか？

このPOCに興味がある場合は、お気軽にお問い合わせください。解決策のデモや貴社でのテストも対応可能です。