 |
ソフトウェアエンジニアリングにおいて、グラフィカルユーザーインターフェーステストとは、製品のグラフィカルユーザーインターフェース（GUI）が仕様を満たしていることを確認するためのテストプロセスです。これは通常、様々なテストケースを用いて行われます。
テストケース生成
テストケースセットを生成するために、テスト設計者はシステムの全機能を網羅し、GUI自体を完全にテストしようとします。このタスクを達成する上での難しさは2つあります。ドメインのサイズとシーケンスの処理です。さらに、テスターは回帰テストを行う際にさらに困難に直面します。
CLI（コマンドラインインターフェース）システムとは異なり、GUIにはテストが必要な追加操作が含まれる場合があります。Microsoft WordPadの ような比較的小規模なプログラムでは、325種類のGUI操作が可能です。[ 1 ]大規模なプログラムでは、操作の数は簡単に桁違いに大きくなります。
2つ目の問題は、シーケンスの問題です。システムの一部の機能は、GUIイベントのシーケンスによってのみ実行される場合があります。例えば、ファイルを開くには、まずファイルメニューをクリックし、次に「開く」操作を選択し、ダイアログボックスでファイル名を指定して、新しく開いたウィンドウにアプリケーションをフォーカスする必要があります。実行可能な操作の数が増えると、シーケンスの問題は指数関数的に増大します。これは、テスターが手動でテストケースを作成する場合に深刻な問題となる可能性があります。
回帰テストはGUIでもしばしば課題となります。基盤となるアプリケーションは変更されていないにもかかわらず、GUIは大幅に変更される可能性があります。GUI上の特定のパスをたどるように設計されたテストは、ボタン、メニュー項目、またはダイアログの位置や外観が変更されている可能性があるため、失敗する可能性があります。
これらの問題により、GUIテストの問題領域は自動化へと向かうようになりました。ユーザーの動作をシミュレートする包括的な テストスイートを自動生成するための様々な手法が提案されています。
多くのテスト手法は、CLIプログラムのテストに以前使用されていた手法を基盤としていますが、GUIに適用するとスケーリングの問題が生じる可能性があります。例えば、有限ステートマシンベースのモデリング[ 2 ] [ 3 ]（システムを有限ステートマシンとしてモデル化し、プログラムを用いてすべての状態をテストするテストケースを生成する手法）は、状態数が限られたシステムではうまく機能しますが、GUIでは過度に複雑になり、扱いにくくなる可能性があります（モデルベーステストも参照）。
計画と人工知能
CLI技術[ 4 ]を応用したテストスイート生成の新しいアプローチでは、計画システムを使用します。[ 5 ]計画は、人工知能（AI）分野でよく研究されている技術で、次の4つのパラメータを含む問題を解決しようとします。
- 初期状態、
- 目標状態、
- 演算子のセット、および
- 操作対象となるオブジェクトのセット。
計画システム
プランニングシステムは、演算子を用いて初期状態から目標状態への経路を決定します。プランニング問題の簡単な例として、2つの単語と、単語内の1つの文字を別の文字に置き換える1つの操作が与えられた場合、目標は1つの単語を別の単語に置き換えることかもしれません。
[ 1 ]では、著者らはプランナーIPP [ 6 ]を用いてこの手法を実証した。システムのUIをまず分析し、可能な操作を決定する。これらの操作は、計画問題で使用される演算子となる。次に、システムの初期状態が決定され、テスターがシステムの動作テストに適していると考える目標状態が指定される。計画システムは、初期状態から目標状態へのパスを決定し、これがテスト計画となる。
プランナーを使用してテストケースを生成すると、手動で生成する場合に比べていくつかの利点があります。プランニングシステムは、その性質上、テスト担当者にとって非常に有益な方法で、計画上の問題に対する解決策を生成します。
- 計画は常に有効です。システムの出力は、オペレータを用いて目標状態に到達するための有効かつ正しい計画、または計画なしのいずれかです。これは、テスターが動作すると考えていたものの実際には動作しなかった無効なテストケースによって、手動でテストスイートを作成する際に多くの時間を無駄にしてしまう可能性があるため、有益です。
- プランニングシステムは順序に注意を払います。特定の機能をテストする場合、多くの場合、テストケースは複雑で、GUI上のパスに沿って操作が特定の順序で実行される必要があります。手動で行うと、エラーが発生するだけでなく、非常に困難で時間がかかります。
- 最後に、そして最も重要なのは、計画システムは目標指向であるということです。テスターは、システムの機能性をテストするという最も重要な点に焦点を当ててテストスイートを生成します。
テストスイートを手動で作成する場合、テスターは機能をどのようにテストするか（つまり、GUIを介した具体的なパス）に重点を置きがちです。プランニングシステムを使用すれば、パスは自動的に考慮されるため、テスターはテストする機能に集中できます。また、プランニングシステムはパス生成時に何ら制約を受けないため、テスターが予期していなかったパスが見つかることも少なくありません。この問題は、対処すべき非常に重要な問題です。[ 7 ]
遺伝的アルゴリズム
GUIテストケースを生成するもう一つの方法は、初心者ユーザーをシミュレートすることです。システムの熟練ユーザーはGUI上で直接的かつ予測可能なパスを辿る傾向がありますが、初心者ユーザーはよりランダムなパスを辿ります。そのため、初心者ユーザーは熟練ユーザーよりもGUIの様々な状態を探索する可能性が高くなります。
難しさは、「初心者」のシステム使用状況をシミュレートするテストスイートを生成することにあります。この問題を解決するために、遺伝的アルゴリズムの使用が提案されています。[ 7 ]初心者がシステムを利用する経路はランダムではありません。第一に、初心者ユーザーは時間の経過とともに学習するため、通常、同じ間違いを繰り返すことはありません。第二に、初心者ユーザーは計画に従っており、ある程度のドメインまたはシステム知識を持っている可能性があります。
遺伝的アルゴリズムは次のように機能します。「遺伝子」の集合がランダムに生成され、何らかのタスクを実行します。タスクを最も効率的に完了した遺伝子が保持され、そうでない遺伝子は破棄されます。このプロセスが繰り返され、生き残った遺伝子は複製され、残りの遺伝子はさらにランダムな遺伝子で埋められます。最終的に、1つの遺伝子（または閾値が設定されている場合は少数の遺伝子集合）が集合内の唯一の遺伝子となり、与えられた問題に自然と最も適合する遺伝子となります。
GUIテストの場合、この方法は次のように機能します。各遺伝子は、本質的には固定長のランダムな整数値のリストです。これらの遺伝子はそれぞれ、GUI上のパスを表します。例えば、ウィジェットのツリー構造において、遺伝子の最初の値（各値は対立遺伝子と呼ばれます）によって操作対象のウィジェットが選択され、その後に続く対立遺伝子によって、ウィジェットへの入力可能な数に応じてウィジェットへの入力が決定されます（例えば、プルダウンリストボックスの場合、入力は1つ、つまり選択されたリスト値です）。遺伝子の成功度は、最も優れた「初心者」の行動を評価する基準によって評価されます。
Xウィンドウ
XウィンドウシステムのGUIテストを実行するシステムは、あらゆるウィンドウシステムに拡張可能であり、KasikとGeorgeによって導入されました。[ 7 ] Xウィンドウシステムは、GUIを直接使用することなく、プログラムにGUI入力を動的に送信し、プログラムからGUI出力を取得する機能（XServerとそのプロトコル経由）を提供します。例えば、XSendEvent()を呼び出してプルダウンメニューのクリックをシミュレートすることができます。このシステムにより、研究者はテスト対象の任意のアプリケーションに対するテストケースの生成とテストを自動化することができ、初心者向けのテストケースセットを作成することができます。
テストケースの実行
当初、戦略は CLI テスト戦略から移行され、適応されました。
マウス位置キャプチャ
CLI環境でよく使用される手法は、キャプチャ/プレイバックです。キャプチャ/プレイバックとは、システムテスト中の様々な時点でシステム画面をビットマップ画像として「キャプチャ」するシステムです。このキャプチャにより、テスターはテストプロセスを「プレイバック」し、テストの出力フェーズにおける画面を期待される画面と比較することができます。テストが成功した場合は画面が同一で、失敗した場合は画面が異なるため、この検証は自動化できます。
キャプチャ/プレイバックはCLIの世界ではうまく機能していましたが、GUIベースのシステムに実装しようとすると重大な問題が発生します。[ 8 ]最も顕著な問題は、GUIシステムでは画面の見た目が異なっていても、基盤となるシステムの状態は同じである場合があり、自動検証が非常に困難になることです。これは、GUIではグラフィカルオブジェクトの外観や画面上の配置が変化する可能性があるためです。フォントが異なったり、ウィンドウの色やサイズが異なったりしても、システム出力は基本的に同じです。これはユーザーには明らかですが、自動検証システムには明らかではありません。
イベントキャプチャ
この問題やその他の問題に対処するため、テスターは「内部で」基盤となるウィンドウシステムからGUIインタラクションデータを収集してきた。[ 9 ]ウィンドウの「イベント」をログに記録することで、システムとのインタラクションはGUIの外観から分離された形式になる。これで、イベント ストリームのみが記録される。イベント ストリームは通常非常に詳細であり、ほとんどのイベントは問題に直接関連しないため、イベント ストリームをフィルタリングする必要がある。このアプローチは、たとえばMVCアーキテクチャを使用して、モデルとコントローラーがすべてのロジックを保持しながら、ビュー(ここではGUI)をできるだけ単純にすることで、より簡単に行うことができる。別のアプローチとして、ソフトウェアに組み込まれた支援技術、HTMLインターフェイス、またはユーザー インターフェイスをアプリケーションの残りの部分からさらに分離できるようにする 3層アーキテクチャを使用する方法がある。
GUIでテストを実行する別の方法は、GUIにドライバーを組み込み、別のプログラムからコマンドやイベントをソフトウェアに送信できるようにすることです。[ 7 ]システムに直接イベントを送受信するこの方法は、入出力テストを完全に自動化でき、ユーザーエラーを排除できるため、テストに非常に効果的です。
参照
参考文献
- ^ a b Atif M. Memon、Martha E. Pollack、Mary Lou Soffa. 目標駆動型アプローチを用いたGUIのテストケース生成. ICSE '99 Proceedings of the 21st international conference on Software engineering.
- ^ JM Clarke.動作モデルからの自動テスト生成. Pacific Northwest Software Quality Conference Proceedings. IEEE Press, 1998年5月.
- ^ S. Esmelioglu、L. Apfelbaum. 自動テスト生成、実行、レポート作成. Pacific Northwest Software Quality Conference Proceedings. IEEE Press、1997年10月.
- ^ A. Howe、A. von Mayrhauser、RT Mraz. AI計画問題としてのテストケース生成. Automated Software Engineering, 4:77-106, 1997.
- ^ Atif M. Memon、 Martha E. Pollack、Mary Lou Soffa.自動計画を用いた階層型GUIテストケース生成. IEEE Trans. Software Eng., vol. 27, no. 2, 2001, pp. 144-155, IEEE Press.
- ^ J. Koehler, B. Nebel, J. Hoffman, Y. Dimopoulos. ADLサブセットへのプランニンググラフの拡張. Lecture Notes in Computer Science, 1348:273, 1997.
- ^ a b c d D. J. Kasik、HG George. 初心者向けユーザーテストスクリプトの自動生成に向けて. MJ Tauber、V. Bellotti、R. Jeffries、JD Mackinlay、J. Nielsen編、『コンピューティングシステムにおけるヒューマンファクターに関する会議：コモングラウンド』論文集、244-251ページ、ニューヨーク、1996年4月13日～18日、ACM Press. [1]
- ^ LR Kepple. GUIテストの黒魔術. Dr. Dobb's Journal of Software Tools, 19(2):40, 1994年2月.
- ^ ML Hammontree、JJ Hendrickson、BW Hensley.グラフィカルユーザーインターフェースの研究とテストのための統合データキャプチャおよび分析ツール. P. Bauersfeld、J. Bennett、G. Lynch編著、Proceedings of the Conference on Human Factors in Computing System、431-432ページ、ニューヨーク、ニューヨーク州、米国、1992年5月。ACM Press。
