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という関数を導入しました。この関数は：

• ページの言語をlang属性から判定
• 記述に基づくフィールドデータを提供するため AI に指示を出し、記述の言語に関わらず、ページの言語でデータを生成しなければなりません

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

フレームワークにある格関数にアリエスをエクスポートします。これで、あらゆる言語でテストケースを書けます。

制約

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

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

今後の展望

自社製品や顧客プロジェクトのテストケースを迅速に作成する予定です。また他のユースケースはアプリケーションデータを生成するため API や DB スナップショットを使わず、手順を記述してシステムを希望通りの状態に届けます。 また他のユースケースはモデルが行ったステップを記録し、従来の E2E テストとして再利用。これで CUA モデルを使わず、アプリケーション向けの E2E テストを迅速に記述のが可能となります。 その反面に記録されたテストに通常 E2E テストのような管理が必要です。コスト削減と信頼性向上のため色々検討中です。

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

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

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