グラフィカルユーザーインターフェースのテスト

プランニングシステムは、演算子を用いて初期状態から目標状態への経路を決定します。プランニング問題の簡単な例として、2つの単語と、単語内の1文字を別の文字に置き換える1つの操作が与えられた場合、目標は一方の単語をもう一方の単語に変更することかもしれません。

^{[ 1 ]}では、著者らはプランナーIPP ^{[ 6 ]}を使用してこの手法を実証しました。まず、システムのUIを分析して可能な操作を決定します。これらがプランニング問題で使用される演算子になります。次に、初期システム状態が決定され、テスターがシステムのテストを可能にすると考える目標状態が指定されます。プランニングシステムは、初期状態から目標状態へのパスを決定し、これがテストプランになります。

プランナーを使用してテストケースを生成することには、手動で生成する場合に比べていくつかの具体的な利点があります。プランニングシステムは、その性質上、テスターに​​とって非常に有益な方法でプランニングの問題に対する解決策を生成します。

1. プランは常に有効です。システムの出力は、目標状態を達成するために演算子を使用する有効かつ正しいプラン、またはプランなしのいずれかです。これは、テスターが動作すると考えていたものの実際には動作しなかった無効なテストケースのために、手動でテストスイートを作成する際に多くの時間を無駄にする可能性があるため、有益です。
2. プランニングシステムは順序を重視します。特定の機能をテストする場合、テストケースは複雑で、GUI上で特定の順序で操作を実行するパスをたどる必要があります。これを手動で行うと、エラーが発生する可能性があり、また非常に困難で時間のかかる作業となる場合があります。
3. 最後に、そして最も重要な点として、計画システムは目標指向型です。テスターは、最も重要なこと、つまりシステムの機能性をテストすることにテストスイートの生成を集中させます。

テストスイートを手動で作成する場合、テスターは機能のテスト方法（つまり 、GUI を通る具体的なパス）に重点を置きます。プランニングシステムを使用すると、パスは自動的に処理されるため、テスターはテストする機能に集中できます。この利点の 1 つは、プランニングシステムはパスを生成する際に何ら制約を受けず、テスターが想定していなかったパスを見つけることができる場合が多いことです。この問題は、対処すべき非常に重要な問題です。^{[ 7 ]}

GUIテストケースを生成するもう一つの方法は、初心者ユーザーをシミュレートすることです。システムの熟練ユーザーはGUI上で直接的かつ予測可能な経路をたどる傾向がありますが、初心者ユーザーはよりランダムな経路をたどります。そのため、初心者ユーザーは熟練ユーザーよりも多くのGUIの状態を探索する可能性が高いと言えます。

問題は、「初心者」のシステム使用をシミュレートするテストスイートを生成することにある。この問題を解決するために遺伝的アルゴリズムの使用が提案されている。 ^{[ 7 ]}初心者のシステム内の経路はランダムな経路ではない。第一に、初心者のユーザーは時間をかけて学習し、一般的に同じ間違いを繰り返すことはない。第二に、初心者のユーザーは計画に従っており、おそらくドメイン知識またはシステム知識を持っている。

遺伝的アルゴリズムは次のように機能します。まず、ランダムに生成された「遺伝子」のセットに対して何らかのタスクを実行します。タスクを最も効率的に完了した遺伝子は保持され、そうでない遺伝子は破棄されます。このプロセスは、残った遺伝子を複製し、残りのセットにさらにランダムな遺伝子を追加することで繰り返されます。最終的には、1つの遺伝子（または、何らかの閾値が設定されている場合は少数の遺伝子）がセット内に唯一の遺伝子として残り、それが与えられた問題に最も適した遺伝子となります。

GUIテストの場合、この方法は次のように機能します。各遺伝子は基本的に、一定の長さのランダムな整数値のリストです。これらの遺伝子はそれぞれ、GUI内のパスを表します。たとえば、特定のウィジェットツリーの場合、遺伝子の最初の値（各値はアレルと呼ばれます）が操作対象のウィジェットを選択し、続くアレルがウィジェットへの入力可能な値の数に応じてウィジェットへの入力値を設定します（たとえば、プルダウンリストボックスには、選択されたリスト値が1つの入力として存在します）。遺伝子の成功は、最も優れた「初心者」の動作を評価する基準によって採点されます。

KasikとGeorgeは、X Window SystemのGUIテストを実行するためのシステムを発表しました。このシステムは、あらゆるウィンドウシステムに拡張可能です。^{[ 7 ]} X Window Systemは、（XServerとそのプロトコルを介して）GUIを直接使用することなく、プログラムにGUI入力を動的に送信し、プログラムからGUI出力を取得する機能を提供します。たとえば、XSendEvent()を呼び出してプルダウンメニューのクリックをシミュレートするなどできます。このシステムにより、研究者は、テスト対象の任意のアプリケーションのテストケースの生成とテストを自動化し、初心者ユーザー向けのテストケースセットを作成できます。

CLI環境でよく用いられる手法の一つに、キャプチャ/再生があります。キャプチャ再生とは、システムテスト中にシステム画面をビットマップ画像として様々なタイミングで「キャプチャ」するシステムです。このキャプチャによって、テスターはテストプロセスを「再生」し、テストの出力段階における画面を期待される画面と比較することができます。テストが成功した場合は画面が同一になり、失敗した場合は異なるため、この検証は自動化することが可能です。

キャプチャ/再生は CLI の世界ではうまく機能しましたが、GUI ベースのシステムで実装しようとすると重大な問題が発生します。^{[ 8 ]}最も明白な問題は、GUI システムの画面は異なるように見えるのに、基となるシステムの状態は同じであるため、自動検証が非常に困難になることです。これは、GUI ではグラフィカル オブジェクトの外観や画面上の配置が変化するためです。フォントが異なったり、ウィンドウの色やサイズが異なったりしても、システム出力は基本的に同じです。これはユーザーには明らかですが、自動検証システムには明らかではありません。

この問題やその他の問題に対処するため、テスターは「内部」に入り込み、基盤となるウィンドウ システムから GUI 操作データを収集しました。^{[ 9 ]}ウィンドウの「イベント」をログにキャプチャすることで、システムとのインタラクションは GUI の外観から切り離された形式になりました。これで、イベント ストリームのみがキャプチャされます。イベント ストリームは通常非常に詳細で、ほとんどのイベントは問題に直接関係がないため、イベント ストリームのフィルタリングが必要です。このアプローチは、たとえばMVCアーキテクチャを使用し、ビュー (つまり 、ここでは GUI) をできるだけシンプルにして、モデルとコントローラにすべてのロジックを持たせることで簡単にできます。別のアプローチとしては、ソフトウェアに組み込まれている支援技術を使用したり、HTML インターフェイスを使用したり、ユーザー インターフェイスをアプリケーションの残りの部分からより適切に分離できる3 層アーキテクチャを使用したりする方法があります。

GUI 上でテストを実行するもう 1 つの方法は、GUI にドライバを組み込んで、別のプログラムからソフトウェアにコマンドやイベントを送信できるようにすることです。^{[ 7 ]}この、システムに直接イベントを送信したり、システムからイベントを受信したりする方法は、入力と出力のテストを完全に自動化でき、ユーザーエラーを排除できるため、テスト時に非常に望ましいです。