Can LLMs Test Terminal User Interfaces?

あなたはビデオゲームの開発者だと想像してください。あなたは山や都市、キャラクターといった、美しく複雑な世界を構築しましたが、ドアが実際に開くかどうか、あるいはプレイヤーが壁に挟まって動けなくなることがないか、テストするのを忘れてしまいました。ソフトウェアの世界において、これは悪夢です。これを防ぐために、プログラマーは「自動テスター」を使用します。これは、ボタンをクリックしたり、コマンドを入力したり、実際のユーザーがバグを見つける前にソフトウェアを壊そうと試みる、ロボットのアシスタントです。

長い間、私たちは主に2種類のテスト可能なソフトウェアを持ってきました。第一に、スマートフォンのアプリやコンピュータのような**グラフィカル・ユーザー・インターフェース（GUI）**です。これらは、ラベルの付いたドアや窓、ボタンがある、豪華でカラフルな部屋のようなものです。テスターはコンピュータに対して、「『スタート』ボタンはどこですか？」と簡単に尋ねてクリックすることができます。第二に、**コマンドライン・インターフェース（CLI）**です。これは、昔ながらの電報のようなものです。秘密のコードを入力すると、コンピュータがテキストで返答します。これらはシンプルなので、テストが容易です。「これを入力すれば、あれが得られる」という仕組みだからです。

しかし、第三の、より巧妙なタイプのソフトウェアとして、**ターミナル・ユーザー・インターフェース（TUI）**が存在します。これらは「レトロ・フューチャリスティック（レトロ未来派）」なアプリだと考えてください。見た目は古い電報（黒い画面にテキストが表示されるだけ）のようですが、動作は豪華な部屋のように振る舞います。動くカーソル、ポップアップメニュー、そして入力によって変化する複雑な状態を持っています。これらはハッカーやシステム管理者、さらにはAIコーディングアシスタントの間でも人気があります。問題は、これらを適切にテストする方法がまだ確立されていないことです。これらは単純な電報用テスターには複雑すぎますが、豪華な部屋用テスターが必要とする「ラベル付きのボタン」も備わっていません。この論文は、大きな問いを投げかけています。現代の人工知能（AI）ロボットは、これらトリッキーなテキストベースのアプリをテストすることを学習できるのか、それとも私たちと同様に困惑してしまうのだろうか？

---

大いなるTUI探偵物語

この論文の著者たちは、探偵として動くことに決めました。彼らは、ファイルマネージャーからシステムモニターまで、197個の実世界のTUIアプリケーションという膨大なコレクションを集め、厳格なストレス・テストにかけました。しかし、その前に解決すべき謎がありました。それは、**「現在、これらのアプリはどのようにテストされているのか？」**という謎です。

彼らはこれら197個のアプリのコードの中を覗き込み、衝撃的な事実を発見しました。テストコードのうち、画面とのインタラクションを実際に試みているものは、わずか**約12%**でした。さらに悪いことに、画面に触れているテストのほぼ半分は、キーを一つも入力していませんでした！ それらは単に、アプリが最初に起動したときに画面が正しく見えるかどうかを確認しているだけでした。それは、車のエンジンをかけることは一度もせず、塗装の状態だけをチェックしているようなものです。結局のところ、ほとんどのTUIは、目をつぶった状態でテストされているのです。

そこで、チームはAIやランダムな偶然をこれらのアプリに解き放ったらどうなるかを確かめるため、独自のツールを構築しました。彼らは「ヘッドレス」なラボ（画面がなく、仮想ターミナルのみを備えたコンピュータ）を作り、各アプリを特別なコンテナにパッケージ化しました。そして、以下の4つの戦略によるレースを設定しました。

1. ランダム・モンキー： できる限り速く、ランダムなキーをタイプしまくるロボット。
2. AIガイド： 画面を見て、次に何をタイプすべきかを判断する賢い大規模言語モデル（LLM）。
3. 地図を持つAIガイド： 同じ賢いロボットですが、今度はアプリを適切に起動するための正しい「起動コード（引数）」も理解しています。
4. AIスクリプトライター： ソースコードを読み取り、開始前にテスト計画を書き上げるロボット。

彼らはこれらの戦略を197個のアプリに対して実行し、それぞれに**600秒（10分間）**の時間を与えてバグを探させました。

結果：誰が勝つのか？

結果は驚くべきものであり、少し直感に反するものでした。

1. 「賢い」ロボットは最速ではない。
各戦略が「1回の実行あたり」に発見したバグの数を見たとき、ランダム・モンキーが実際に最も多くのクラッシュを発見しました。なぜなら、それは信じられないほど速かったからです。600秒間で、ランダムなロボットは数百のキーを打ち込むことができました。AIロボットたちは、思慮深く「賢い」ため、考えたり答えを待ったりすることにほとんどの時間を費やしてしまい、同じ時間内に打てるキーはわずか十数個程度でした。

2. しかし、「賢い」ロボットははるかに効率的である。
ここからがひねりです。もし「キー入力1回あたり」の性能で測定した場合、AIロボットはランダム・モンキーよりも13倍優れた結果を出しました。ランダム・モンキーは暗闇でダーツを投げ、運良く当たっているだけでした。一方、AIロボットは注意深く狙っていました。彼らは、「入力ゲート型」のバグ（隠れたメニューをアンロックするための特定のキーシーケンスを入力しなければ発生しないクラッシュ）を見つけることができました。ランダム・モンキーは決してコードを解明できませんでしたが、AIはできたのです。

3. 「起動コード」こそが真のヒーローだった。
最大のブレイクスルーは、AIの知能ではなく、アプリを起動する方法を導き出す能力でした。多くのTUIは、インターフェースを開くために特定のファイルや引数を必要とします。これらがないと、アプリはすぐに終了してしまいます。AIを使って起動入力を自動的に導出する戦略が、最も多くのバグを発見し、最も多くのコードをカバーしました。結局のところ、車の鍵の回し方を知らなければ、車をテストすることはできないのです。

4. 「クラッシュ」の罠。
研究者たちは、私たちが通常バグを数える方法における重大な罠も発見しました。彼らは、「クラッシュ」（プログラムの予期せぬ停止）の82%が、実際にはプログラムが「おい、ファイルが必要だ！」とか「停止するように指示された！」と言っているだけであることを突き止めました。これらは本当のバグではなく、単なる通常の挙動です。単にプログラムが止まった回数を数えるだけでは、誤報を招きます。チームは、実際の画面上のテキストを見て、それが本当のエラーなのか、単なる丁寧な終了なのかを判別する、特別な「クラッシュ検出器」を構築する必要がありました。ノイズをフィルタリングした結果、197個のアプリ全体で179個の真の、有効なバグが見つかりました。

5. コードカバレッジの増加 $\neq$ バグの増加。
ソフトウェアテストにおいて、一般的に「より多くのコードをカバーすれば、より多くのバグが見つかる」と信じられています。しかし、この論文は、それがTUIにおいては当てはまらないことを示唆しています。彼らは、最も多くのクラッシュを見つけたテストが、しばしば低いコードカバレッジを持っていたことを発見しました。なぜでしょうか？ クラッシュを見つけると、テストが即座に中断されるからです！ テストが途中で切れてしまうため、残りのコードをカバーすることができません。これは、TUIにおいては、どれだけの行のコードに触れたかを数えることは、テストの良さを測るための悪い指標であることを意味しています。

結論

この論文は、これらのテキストベースのインターフェースの自動テストは可能であるが、解決には程遠いと結論付けています。明確な勝者となる単一のAIモデルは存在しませんでした。実際、単純なランダムテスターが、その速さゆえに競争力を持っていました。成功の鍵はハイブリッド戦略でした。つまり、AIを使ってアプリを起動し、正しい状態へナビゲートし、その後に高速なランダムテストを使用してインターフェースをストレス・テストするという組み合わせです。

著者らはまた、私たちに優れたツールが必要であると警告しています。現在のテスト方法（単にプログラムが止まるかどうかをチェックする手法）は誤報に満ちています。彼らは、他の人々がこれらのアプリを適切にテストできるように、独自のツールである tuicov と tuibot を公開しました。メッセージは明確です。TUIは、私たちのソフトウェアの世界において巨大で成長している部分ですが、現在はテストにおける「ワイルド・ウエスト（無法地帯）」です。私たちはこれらを飼い慣らすための道具を持ち始めていますが、古いルールに頼るのをやめ、これらのインターフェース特有のテキストベースの性質を理解するテストを設計し始める必要があります。