Loading article…
ソフトウェア エンジニアリング において、グラフィカル ユーザー インターフェイス テストとは、製品のグラフィカル ユーザー インターフェイス(GUI) が仕様を満たしているかどうかをテストするプロセスです。これは通常、さまざまなテスト ケースを使用して行われます。
テストケース生成
テスト ケースのセットを生成するために、テスト設計者はシステムのすべての機能をカバーし、GUI自体を完全に実行しようとします。このタスクを達成するには、ドメイン サイズとシーケンスの処理という 2 つの難しさがあります。さらに、テスターは回帰テストを行う必要がある場合にさらに困難に直面します。
CLI (コマンドライン インターフェイス) システムとは異なり、GUI にはテストが必要な追加の操作がある場合があります。Microsoft WordPad などの比較的小さなプログラムで は、 325 の GUI 操作が可能です。[1]大規模なプログラムでは、操作の数は簡単に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 を介した特定のパス）に重点を置きます。計画システムを使用すると、パスが考慮され、テスターはテストする機能に集中できます。これのもう 1 つの利点は、計画システムがパスを生成するときに制限されないため、テスターが予期していなかったパスが見つかることが多いことです。この問題は、対処すべき非常に重要な問題です。[7]
遺伝的アルゴリズム
GUI テスト ケースを生成する別の方法は、初心者ユーザーをシミュレートします。システムの熟練ユーザーは、GUI を通じて直接的で予測可能なパスをたどる傾向がありますが、初心者ユーザーはよりランダムなパスをたどります。そのため、初心者ユーザーは、熟練ユーザーよりも多くの GUI の状態を探索する可能性が高くなります。
難しいのは、「初心者」のシステム使用法をシミュレートするテスト スイートを生成することです。この問題を解決するために、遺伝的アルゴリズムの使用が提案されています。[7]システムにおける初心者のパスはランダムなパスではありません。まず、初心者ユーザーは時間の経過とともに学習し、通常は同じ間違いを繰り返しません。次に、初心者ユーザーは計画に従っており、おそらくドメインまたはシステムに関する知識を持っています。
遺伝的アルゴリズムは次のように機能します。一連の「遺伝子」がランダムに作成され、何らかのタスクにかけられます。タスクを最もうまく完了する遺伝子が保持され、そうでない遺伝子は破棄されます。このプロセスが再度繰り返され、生き残った遺伝子が複製され、残りのセットがさらにランダムな遺伝子で埋められます。最終的に、1 つの遺伝子 (またはしきい値が設定されている場合は少数の遺伝子セット) がセット内の唯一の遺伝子となり、当然、特定の問題に最も適したものになります。
GUI テストの場合、この方法は次のように機能します。各遺伝子は、基本的に、固定長のランダムな整数値のリストです。これらの遺伝子はそれぞれ、GUI のパスを表します。たとえば、特定のウィジェット ツリーの場合、遺伝子の最初の値 (各値は対立遺伝子と呼ばれます) によって操作するウィジェットが選択され、その後の対立遺伝子によって、ウィジェットへの可能な入力の数に応じてウィジェットへの入力が設定されます (たとえば、プルダウン リスト ボックスには 1 つの入力 (選択されたリスト値) があります)。遺伝子の成功は、最も優れた「初心者」の動作に報酬を与える基準によってスコア付けされます。
Xウィンドウ
Xウィンドウシステム用にこのテストを行うシステム（ただし、任意のウィンドウシステムに拡張可能）については、 [7]で説明されています。Xウィンドウシステムは、GUIを直接使用せずに、プログラムにGUI入力を動的に送信し、プログラムからGUI出力を取得する機能（XServerおよびエディターのプロトコル経由）を提供します。たとえば、XSendEvent()を呼び出してプルダウンメニューのクリックをシミュレートすることができます。このシステムにより、研究者は遺伝子の作成とテストを自動化できるため、テスト対象の任意のアプリケーションに対して、初心者ユーザーテストケースのセットを作成できます。
テストケースの実行
当初、戦略は CLI テスト戦略から移行され、適応されました。
マウス位置キャプチャ
CLI 環境でよく使用される方法は、キャプチャ/再生です。キャプチャ再生は、システム テスト中にさまざまな時点でシステム画面がビットマップ グラフィックとして「キャプチャ」されるシステムです。このキャプチャにより、テスターはテスト プロセスを「再生」し、テストの出力フェーズの画面を予想される画面と比較できます。ケースが合格した場合は画面が同一になり、ケースが不合格の場合は画面が異なるため、この検証は自動化できます。
キャプチャ/再生の使用はCLIの世界ではうまく機能しましたが、GUIベースのシステムに実装しようとすると重大な問題が発生します。[8]最も明らかな問題は、GUIシステムの画面は、基盤となるシステムの状態が同じでも見た目が異なり、自動検証が非常に困難になることです。これは、GUIではグラフィカルオブジェクトの外観や画面上の配置が変わる可能性があるためです。フォントが異なり、ウィンドウの色やサイズが変わることがありますが、システム出力は基本的に同じです。これはユーザーには明らかですが、自動検証システムには明らかではありません。
イベントキャプチャ
この問題やその他の問題に対処するため、テスターは「内部」にまで踏み込み、基礎となるウィンドウシステムからGUIインタラクションデータを収集してきました。[9]ウィンドウの「イベント」をログにキャプチャすることで、システムとのインタラクションはGUIの外観から切り離された形式になりました。今では、イベントストリームのみがキャプチャされています。イベントストリームは通常非常に詳細で、ほとんどのイベントは問題に直接関係がないため、イベントストリームをフィルタリングする必要があります。このアプローチは、たとえばMVCアーキテクチャを使用し、モデルとコントローラーがすべてのロジックを保持しながら、ビュー（ここではGUI）をできるだけ単純にすることで簡単にできます。別のアプローチは、ソフトウェアに組み込まれた 支援技術を使用することです。HTMLインターフェイスまたは3層アーキテクチャを使用すると、ユーザーインターフェイスをアプリケーションの残りの部分から適切に分離することもできます。
GUIでテストを実行する別の方法は、GUIにドライバーを組み込み、別のプログラムからソフトウェアにコマンドやイベントを送信できるようにすることです。[7]システムに直接イベントを送受信するこの方法は、入力テストと出力テストを完全に自動化でき、ユーザーエラーを排除できるため、テスト時に非常に便利です。
参照
参考文献
- ^ ab 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 の議事録。IEEE Press、1998 年 5 月。
- ^ S. Esmelioglu および L. Apfelbaum。自動テスト生成、実行、レポート。Pacific Northwest Software Quality Conference の議事録。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. Softw. 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 年。
- ^ abcd DJ Kasik と HG George。初心者ユーザーテストスクリプトの自動生成に向けて。MJ Tauber、V. Bellotti、R. Jeffries、JD Mackinlay、J. Nielsen 編、Proceedings of the Conference on Human Factors in Computing Systems: Common Ground、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 ページ、ニューヨーク、NY、米国、1992 年 5 月。ACM Press。