さらに詳細に後述するように、本開示のいくつかの実施形態は、グラフィカルユーザーインターフェイス(GUI)に基づいたアプリケーション(以下、「GUIアプリケーション」と呼ぶ)のミーリー型順序回路モデル(Mealy Machine model)などの決定性有限状態マシンモデル(deterministic finite−state machine model)(以下、「DFSMモデル」と呼ぶ)を生成する分析モジュールを含んでもよい。DFSMモデルは、GUIアプリケーションの振る舞いを示すことができる。いくつかの実施形態においては、DFSMモデルは、GUIアプリケーションの開発及びテストにおいて使用されてもよい。このような例においては、DFSMモデルを使用し、GUIアプリケーションの開発者によって予想又は所望されている機能及び特徴をGUIアプリケーションが含んでいるか否かを判定してもよい。これにより、DFSMモデルを使用して、所望通りに機能しておらず、且つ、GUIアプリケーションが所望通りに機能するように相応して変更されうるGUIアプリケーションの1つ又は複数の特徴を識別してもよい。したがって、DFSMモデルに基づいてGUIアプリケーションの設計を変更し、GUIアプリケーションのモデル駆動型の開発(Model−Driven Development:MDD)及びモデルに基づいたテスト(Model−Based Testing:MBT)を支援してもよい。
添付図面を参照し、本開示の実施形態について説明する。
図1は、本開示の少なくとも1つの実施形態に従って構成されたGUIアプリケーション102のDFSMモデルを生成する例示用のシステム100を示している。
GUIアプリケーション102は、電子装置上に含まれうる任意の適切なGUIアプリケーションであってもよい。電子装置は、限定を伴うことなしに、タブレットコンピュータ、スマートフォン、ナビゲーションシステム、エンターテインメントシステム、デスクトップコンピュータ、ラップトップコンピュータ、デジタル音楽プレーヤーなどを含んでもよい。
GUIアプリケーション102は、GUIアプリケーション102の個別のビュー(以下、「ビュー」と呼ぶ)とそれぞれが関連付けられた1つ又は複数の別個のGUIコンポーネントを含んでもよい。このビューは、互いに排他的な方式で実行されてもよく、且つ、GUIアプリケーション102によって実行される動作のうちの少なくともいくつかとそれぞれが関連付けられてもよい。GUIアプリケーションのビューの例が添付の図2Aに示されている。
GUIアプリケーション102のそれぞれのビューは、1つ又は複数の別個の画面と関連付けられてもよい。この場合に、それぞれの画面は、画面上の1つ又は複数のユーザーアクションに対するGUIアプリケーション102の応答を表すのみならず、GUIアプリケーション102の動作の少なくとも一部分をサポートしてもよい。GUIアプリケーション102の動作の少なくとも一部分をサポートするために、それぞれの画面は、1つ又は複数のウィジェットを含んでもよい。それぞれのウィジェットは、ウィジェットに対してユーザーによって実行される1つ又は複数のアクションに基づいてGUIアプリケーション102の動作のうちの1つ又は複数の動作を実行するように構成されてもよい。例えば、ウィジェットは、GUIアプリケーション102のGUI上のボタンとして表示されてもよく、且つ、モバイル装置のタッチスクリーンを介したウィジェットのタップに基づいて第1動作を実行するように構成されてもよい。同一のウィジェットが、タッチスクリーンを介してウィジェット上において実行されたタッチ長押し(long tap)又はその他のアクションに基づいて第2動作を実行するように構成されてもよい。さらには、いくつかの例においては、画面全体が、ウィジェットとして構成されてもよい。例えば、画面のスワイプにより、GUIアプリケーション102を別の画面に遷移させてもよい。GUIアプリケーションのビューの例示用の画面も、添付の図2Aに示されている。
それぞれの画面は、GUIアプリケーション102の1つ又は複数の状態とさらに関連付けられてもよい。いくつかの実施形態においては、画面と関連するGUIアプリケーション102の状態は、画面と関連する1つ又は複数のウィジェットの状態に基づいたものであってもよい。ウィジェットの状態は、ウィジェットを表す1つ又は複数の属性の値によって表現されてもよい。例えば、ウィジェットの異なる状態は、ウィジェットが有効化されているか又は無効化されているか、可視状態にあるか又は非可視状態にあるか、不透明であるか又はそうでないかなどに基づいたものであってもよい。したがって、GUIアプリケーション102は、画面と関連付けられうるウィジェットの状態の数に基づいて特定の画面と関連する複数の状態を含んでもよい。
また、画面と関連するGUIアプリケーション102の状態は、画面に到達する前に到達した以前の状態又は画面に基づいたものであってもよい。例えば、特定の画面に、第1の以前の画面及び第2の以前の画面から到達する場合がある。したがって、GUIアプリケーション102は、第1の以前の画面から特定の画面への到達に関係付けられた特定の画面と関連する状態を含んでもよく、且つ、第2の以前の画面から特定の画面への到達に関係付けられた特定の画面と関連する別の状態を含んでもよい。さらに詳細に後述するように、GUIアプリケーション102の画面上において実行されるアクションの出力をGUIアプリケーション102の異なる状態と関連付けてもよい。
上述のように、図2Aは、本明細書に記述されている少なくともいくつかの実施形態に従って構成された請求書のチップを判定するように構成されたチップGUIアプリケーション202(以下、「チップアプリケーション202」と呼ぶ)の例示用のビュー及び画面を示している。チップアプリケーション202は、請求書入力ビュー204を含んでもよい。請求書入力ビュー204は、請求書の金額の入力と関連付けられてもよい。チップアプリケーション202の設定ビュー206は、チップアプリケーション202の設定の変更と関連付けられてもよい。また、チップアプリケーション202は、チップ合計ビュー208を含んでもよい。チップ合計ビュー208は、チップの金額の表示と関連付けられてもよい。
また、チップアプリケーション202は、ビュー204、206、及び208と関連付けられうる画面を含んでもよい。例えば、チップアプリケーション202は、請求書入力ビュー204と関連付けられうる請求書入力画面210、設定ビュー206と関連付けられうる設定画面212、及び、チップ合計ビュー208と関連付けられうるチップ合計画面214を含んでもよい。
図示の実施形態においては、請求書入力画面210は、請求書入力画面210上において実行されうる動作及び/又はコマンドと関連する1つ又は複数のウィジェットを含んでもよい。例えば、請求書入力画面210は、ユーザーが請求書金額を入力できるように構成された入力ウィジェット216を含んでもよい。また、請求書入力画面210は、ユーザーが、関連する「計算」ボタンをタップしたときに、GUIアプリケーション202がチップ合計画面214及びチップ合計ビュー208に遷移するように構成された計算ウィジェット218を含んでもよい。請求書入力画面210は、ユーザーが、関連する「設定」ボタンをタップしたときに、チップアプリケーション202が設定画面212及び設定ビュー206に遷移するように構成された設定ウィジェット220をさらに含んでもよい。
また、チップ合計画面214も、チップ合計画面214上において実行されうる動作及び/又はコマンドと関連付けられうるウィジェットを含んでもよい。図示の実施形態においては、チップ合計画面214は、ユーザーが、関連する「設定」ボタンをタップしたときに、チップアプリケーション202がチップ合計画面214及びチップ合計ビュー208から設定画面212及び設定ビュー206に遷移するように構成された請求書入力画面210の設定ウィジェット220と同様に設定ウィジェット222を含んでもよい。また、チップ合計画面214は、関連する「戻る」ボタンがタップされたときに、現在の画面に到達するために「戻る」以外のアクションが実行された以前の画面にチップアプリケーション202が遷移してもよいように構成された戻るウィジェット224を含んでもよい。例えば、図示の実施形態においては、チップ合計画面214には、請求書入力画面210内の計算ウィジェット218と関連する「計算」ボタンをタップすることにより、到達してもよい。したがって、戻るウィジェット224と関連する「戻る」ボタンをタップすることにより、チップアプリケーション202が請求書入力画面210に戻るようにしてもよい。
また、設定画面212は、設定画面212上において実行されうる動作及び/又はコマンドと関連付けられうるウィジェットを含んでもよい。例えば、図示の実施形態においては、設定画面212は、ユーザーがボックスをタップすることに応答して、関連するボックスの「チェック」状態を切り替えるように構成されうる税率ウィジェット226を含んでもよい。ボックスがチェックされたときには、算出されたチップから税率を除外することが可能であり、且つ、ボックスのチェックが外されたときには、算出されたチップに税率を含めることができる。
また、設定画面212は、戻るウィジェット224と同様に戻るウィジェット228を含んでもよい。この戻るウィジェット228は、関連する「戻る」ボタンがタップされたときに、現在の画面に到達するために「戻る」以外のアクションが実行された以前の画面にチップアプリケーション202が遷移できるように構成されている。例えば、図示の実施形態においては、設定画面212には、請求書入力画面210内の設定ウィジェット220と関連する「設定」ボタンをタップすることにより、到達してもよい。したがって、請求書入力画面210内の設定ウィジェット220と関連する「設定」ボタンがタップされたときには、戻るウィジェット228と関連する「戻る」ボタンをタップすることにより、チップアプリケーション202を請求書入力画面210に戻してもよい。さらには、設定画面212には、チップ合計画面214内の設定ウィジェット222と関連する「設定」ボタンをタップすることにより、到達してもよい。したがって、チップ合計画面214内の設定ウィジェット222と関連する「設定」ボタンがタップされたときには、戻るウィジェット228と関連する「戻る」ボタンをタップすることにより、チップアプリケーション202をチップ合計画面214に戻してもよい。
本開示の範囲を逸脱することなしに、図2Aに対して変更を加えてもよい。例えば、いくつかの実施形態においては、「戻る」及び/又は「設定」ボタンは、チップアプリケーション202をインストールしうる電子装置の一部のボタンであってもよく、且つ、関連する画面上に明示的に表示されなくてもよい。さらには、チップアプリケーション202は、任意の数のその他の機能、ビュー、画面、及び/又はウィジェットを含んでもよい。特定の例は、説明を支援するためのものに過ぎず、且つ、本開示を限定するためのものではない。
図1を再度参照すれば、いくつかの例においては、ウィジェットに対して実行される動作は、GUIアプリケーション102の出力を結果的にもたらしてもよい。この場合に、GUIアプリケーション102は、GUIアプリケーション102の1つの状態からGUIアプリケーション102の別の状態に遷移してもよい。遷移は、同一の画面及びビューと関連する状態、同一のビューと共に含まれている異なる画面と関連する状態、及び/又は異なるビューに含まれうる異なる画面と関連する状態の間におけるものであってもよい。
図2Bは、本開示の少なくとも1つの実施形態による図2Aのチップアプリケーション202と関連する状態の間における例示用の遷移を示している。図示の実施形態においては、チップアプリケーション202の請求書入力状態230は、請求書入力画面210と関連付けられてもよい。チップアプリケーション202は、請求書入力画面210の計算ウィジェット218と関連する「計算」ボタンのタップに応答して、請求書入力状態230から、チップ合計画面214と関連するチップ合計状態232に遷移するように構成されてもよい。また、チップアプリケーション202は、請求書入力画面210の設定ウィジェット220と関連する「設定」ボタンのタップに応答して、請求書入力状態230から、設定画面212と関連する第1設定状態234に遷移するように構成されてもよい。
チップ合計画面214と関連するチップ合計状態232に関して、チップアプリケーション202は、チップ合計画面214の戻るウィジェット224と関連する「戻る」ボタンのタップに応答して、チップ合計状態232から請求書入力状態230に遷移するように構成されてもよい。さらには、チップアプリケーション202は、チップ合計画面214の設定ウィジェット222と関連する「設定」ボタンのタップに応答して、チップ合計状態232から、設定画面212と関連付けられうる第2設定状態236に遷移するように構成されてもよい。したがって、チップアプリケーション202の第1設定状態234及び第2設定状態236は、いずれも、設定画面212と関連付けられてもよい。その理由は、設定画面212には、請求書入力画面210及び関連する請求書入力状態230とチップ合計画面214及び関連するチップ合計状態232との両方から到達してもよいからである。
第2設定状態236に関して、チップアプリケーション202は、設定画面212の戻るウィジェット228と関連する「戻る」ボタンのタップに応答して、第2設定状態236から、チップ合計状態232に遷移して戻るように構成されてもよい。その理由は、第2設定状態236には、チップ合計画面214及び関連するチップ合計状態232から到達したからである。第1設定状態234に関して、チップアプリケーション202は、設定画面212の戻るウィジェット228と関連する「戻る」ボタンのタップに応答して、第1設定状態234から、請求書入力状態230に遷移して戻るように構成されてもよい。その理由は、第1設定状態234には、請求書入力画面210及び関連する請求書入力状態230から到達したためでる。
さらには、第1設定状態234及び第2設定状態236の両方において、税率ウィジェット226と関連するボックスのチェック状態とアンチェック状態を切り替えることにより、チップアプリケーション202が設定画面212において留まるという結果になってもよい。いくつかの実施形態においては、チップアプリケーション202は、税率ウィジェット226と関連するボックスがチェックされているのか又はアンチェックされているのかとは無関係に、同一の設定状態にあるとみなされてもよい。
図1を再度参照すれば、GUIアプリケーション102は、分析モジュール104によって受信されるように構成されてもよく、分析モジュール104は、GUIアプリケーション102のDFSMモデル106を生成するように構成されてもよい。いくつかの実施形態においては、分析モジュール104は、処理装置(processor)108と、メモリ110とを含んでもよい。処理装置108は、様々なコンピュータハードウェア又はソフトウェアモジュールを含む任意の適切な特殊目的又は汎用のコンピュータであってもよい。
メモリ110は、保存されたコンピュータ実行可能命令又はデータ構造を担持又は保持するためのコンピュータ可読媒体を含んでもよい。このようなコンピュータ可読媒体は、汎用又は特殊目的コンピュータによってアクセスされうる任意の使用可能な媒体であってもよい。一例として、且つ、限定を伴うことなしに、このようなコンピュータ可読媒体は、ランダムアクセスメモリ(RAM)、読出し専用メモリ(ROM)、EEPROM(Electrically Erasable Programmable Read−Only Memory)、CD−ROM(Compact Disc Read−Only Memory)、又はその他の光ディスクストレージ、磁気ディスクストレージ、又はその他の磁気ストレージ装置、フラッシュメモリ装置(例えば、ソリッドステートメモリ装置)、或いは、コンピュータ実行可能命令又はデータ構造の形態で望ましいプログラムコードを担持又は保存するように使用されうると共に汎用又は特殊目的コンピュータによってアクセスされうる任意のその他のストレージ媒体を含む有体の又は持続的なコンピュータ可読保存媒体を含んでもよい。また、上述のものの組合せも、コンピュータ可読媒体の範囲に含まれてもよい。コンピュータ実行可能命令は、例えば、処理装置108に特定の機能又は機能のグループを実行させる命令及びデータを含んでもよい。
いくつかの実施形態においては、分析モジュール104は、DFSMモデル106をGUIアプリケーション102の振る舞いを表すミーリー型順序回路モデルとして生成するように構成されてもよい。例えば、いくつかの実施形態においては、分析モジュール104は、DFSMモデル106として、図2Bに関して記述されているチップアプリケーション202の振る舞いをモデル化しうる図2A及び図2Bのチップアプリケーション202のミーリー型順序回路モデルを生成するように構成されてもよい。
いくつかの実施形態においては、分析モジュール104は、動的なクローリング(crawling)と、L*アルゴリズムと呼ばれる既知の能動的学習アルゴリズム又はその異なる変形とを使用して、DFSMモデル106を生成するように構成されてもよい。一般に、L*アルゴリズムは、テスト対象であると共に観察された入出力(I/O)シーケンスと一貫性を有するシステムの有限状態モデルがL*アルゴリズムによって生成されうる方式により、テスト対象のシステム(例えば、GUIアプリケーション102)と関連する入出力シーケンスを調査するアルゴリズムである。いくつかの実施形態においては、L*アルゴリズムの特定の変形を利用し、システムのミーリー型順序回路モデルを学習してもよく、このモデルの出力値は、現在の状態及び入力値に基づいて判定されてもよい。
通常、L*アルゴリズム及び関連するDFSMモデルは、有限の入力ドメイン及び出力ドメインを有する有限状態システムの振る舞いを判定及びモデル化するのに有用である。しかしながら、GUIアプリケーション(例えば、GUIアプリケーション102)は、通常、当然のこととして、有限状態型のシステムではない。したがって、分析モジュール104は、L*アルゴリズムの使用を許容するためにGUIアプリケーション102が有限状態システムとして表現されうる方式により、GUIアプリケーション102をモデル化するように構成されてもよい。
いくつかの実施形態においては、分析モジュール104は、実際のデータの代わりに入力タイプ及び出力タイプとして入力データ及び出力データをモデル化するための抽象化を実行するように構成されてもよい。このような抽象化は、入力データ及び/又は出力データの無限の可能性が存在しうる例において、有限数の状態を許容することになろう。したがって、抽象化は、GUIアプリケーション102が有限状態システムとして表現されえないときに、GUIアプリケーション102が有限状態システムとして表現されうる方式により、GUIアプリケーション102をモデル化してもよい。
例えば、GUIアプリケーションの技術的な立場において且つ従来の観点において、GUIアプリケーション102として使用されうる―図2A及び図2Bのチップアプリケーション202は、請求書入力画面210内に無限数の潜在的な入力値を有してもよい。その理由は、任意の数が請求書金額として使用されうるためである。さらには、それぞれの請求書金額は、異なる入力として、且つ、観点によっては、チップアプリケーション202の異なる状態に対応するものとして、みなされてもよい。同様に、請求書金額に対する出力であってもよいチップ合計画面214上に表示されうるチップ合計は、請求書入力画面210上において入力された請求書金額に応じた任意の数であってもよい。したがって、演算されたチップ合計の異なる値を有するそれぞれの画面は、従来は、請求書入力画面210上における「計算」アクションの別個の出力として解釈されてもよい。
しかしながら、図2Bに関して上述したように、請求書入力画面210内において入力された請求書金額とは無関係に、チップアプリケーション202は、「計算」ボタンをタップすることに応答して、チップ合計画面214を生成してもよい。したがって、請求書入力画面210上の請求書合計入力を、数が何であるのかとは無関係に、数である単一の入力タイプとして抽象化してもよい。同様に、チップ合計画面214上において出力されるチップ合計金額も、数が何であるのかとは無関係に、数である単一の出力タイプとして抽象化してもよい。
このような抽象化により、請求書金額とは無関係に、同一の状態を請求書入力画面210に使用することが可能になり―例えば、請求書入力状態230は、請求書入力画面210と関連する潜在的に無限数の状態が有限数に低減されうるように、請求書金額とは無関係に、請求書入力画面210について使用されてもよい。同様に、このような抽象化により、請求書入力金額及びチップ合計金額とは無関係に、チップ合計画面214を、チップの計算の出力として使用することが可能になり―例えば、チップ合計状態232は、チップ合計画面214と関連する潜在的に無限数の状態が有限数に低減されうるように、チップ合計とは無関係に、チップ合計画面214について使用されてもよい。
実行されうる別のタイプの抽象化は、GUIアプリケーション102のコレクションフィールドと関係するものであってもよい。コレクションフィールドは、任意の数の一連の項目を含みうるGUIアプリケーション102のフィールドであってもよい。例えば、コレクションフィールドは、項目やトランザクションなどのリストとして構成されてもよい。したがって、GUIアプリケーションの技術的な立場及び従来の観点において、コレクションフィールドを含むGUIアプリケーション102の画面は、潜在的に、コレクションフィールド内に含まれる項目の数に応じて、無限数の状態と関連付けられてもよい。対照的に、本開示のいくつかの実施形態においては、GUIアプリケーション102の特定の画面のコレクションフィールドは、コレクションフィールドが空である際の1つの状態と、コレクションフィールドが空ではない際(入力された(populated)状態とも呼ぶ)の別の状態という2つの異なる状態と関連付けられたものにコレクションフィールドを低減する抽象化を使用して、モデル化されてもよい。コレクションフィールドの空の状態は、特定の画面上の第1入力と関連付けられているものとして抽象化されてもよく、且つ、コレクションフィールドの入力された状態は、特定の画面上の第2入力と関連付けられているものとして抽象化されてもよい。この抽象化を使用して、コレクションフィールドを含む特定の画面と関連する潜在的に無限数の状態及び入力を有限数に低減してもよい。
また、L*アルゴリズムは、テスト対象のシステム―例えば、GUIアプリケーション102―と関連する全ての動作及びコマンドがテスト対象のシステムの全ての状態において使用可能であろうという仮定に基づいて動作してもよい。しかしながら、これは、GUIアプリケーションには当てはまらない場合もある。この問題に対処するために、分析モジュール104は、特定の状態において使用不可能でありうるアクションがエラー出力を生成しうるエラー状態及びエラー出力として機能しうると共にエラー状態への遷移を結果的にもたらしうるGUIアプリケーション102のダミー状態及びダミー出力を生成することにより、L*による分析に適したものとなるようにGUIアプリケーションの真の振る舞いを拡張するべく構成されてもよい。したがって、GUIアプリケーション102は、アクションが実際に特定の画面及び状態について使用不可能でありうるときにも、GUIアプリケーション102と関連付けられたアクションの全てが、GUIアプリケーション102の全ての状態において使用可能であるものとして、モデル化されてもよい。
例えば、チップアプリケーション202に関して、チップアプリケーション202を起動するためにチップアプリケーション202と関連付けられたアイコンをタップすること(以下、「Init」と呼ぶ)、「計算」ボタンをタップすること(以下、「Cal」と呼ぶ)、「設定」ボタンをタップすること(以下、「Set」と呼ぶ)、「税率の除外」ボックスをタップすること(以下、「Tax」と呼ぶ)、及び「戻る」ボタンをタップすること(以下、「Back」と呼ぶ)というアクションが、チップアプリケーション202に対して、実行されてもよい。しかしながら、これらのアクションの全てが、全ての画面上において又は全ての状態において使用可能でなくてもよい。例えば、「Init」、「Cal」、及び「Tax」アクションは、チップ合計画面214上において且つチップ合計状態232において使用可能でなくてもよい。
チップアプリケーション202に対してL*アルゴリズムの使用及びDFSMモデルの生成を許容するために、特定の状態におけるアクションの使用不可能性に起因して可能でない場合のあるチップアプリケーション202内における遷移及びその関連する出力が、ダミーエラー状態及びダミーエラー出力によってキャプチャされうるように、ダミーエラー状態及びダミーエラー出力をチップアプリケーション202について生成してもよい。例えば、チップ合計画面214上における且つチップ合計状態232における使用不可能なアクション「Init」、「Cal」、及び「Tax」の稼働は、ダミーエラー出力を生成すると共にチップ合計状態232からダミーエラー状態への遷移を結果的にもたらす応答を有するものとしてモデル化されてもよい。したがって、使用不可能なアクション「Init」、「Cal」、及び「Tax」は、実際には、チップ合計画面214上において且つチップ合計状態232において使用不可能でありうるにも拘らず、チップ合計画面214上において且つチップ合計状態232において使用可能であるものとしてモデル化されてもよい。
また、L*アルゴリズムは、従来、L*アルゴリズムが、テスト対象のシステム―例えば、GUIアプリケーション102―と関連する初期状態において始まるように、構成されてもよく―この場合に、初期状態は、毎回、同一の状態であってもよい。しかしながら、いくつかの例においては、GUIアプリケーション102は、複数の初期状態を含んでもよい。したがって、GUIアプリケーション102に対してL*アルゴリズムの使用を許容するために、分析モジュール104は、GUIアプリケーション102のダミー初期状態を生成してもよい。分析モジュール104は、ダミー初期状態におけるダミー入力アクションに対する応答としてダミー初期状態から実際の初期状態への遷移をモデル化することにより、GUIアプリケーション102を実際の初期状態において始まるものとしてモデル化するように構成されてもよい。
例えば、分析モジュール104は、GUIアプリケーション102が第1初期状態及び第2初期状態を含みうるときに、GUIアプリケーション102のダミー初期状態を生成してもよい。分析モジュール104は、ダミー初期状態において実行された第1ダミーアクションに基づいてダミー初期状態から第1初期状態への遷移を生成することにより、第1初期状態において始まるGUIアプリケーション102をモデル化してもよい。同様に、分析モジュール104は、ダミー初期状態において実行された第2ダミーアクションに基づいてダミー初期状態から第2初期状態への遷移を生成することにより、第2初期状態において始まるGUIアプリケーション102をモデル化してもよい。
さらには、いくつかの実施形態においては、分析モジュール104は、GUIアプリケーション102と関連するスタックを、境界が定められている(bounded)と共にGUIアプリケーション102の異なる状態及び入出力シーケンスとそれぞれが関連付けられうる有限数の構成を有するものとして、取り扱うように構成されてもよい。例えば、図2A及び図2Bのチップアプリケーション202は、3つの異なる画面と、チップアプリケーション202の画面のうちのいずれか1つの画面に到達するための最大で2つのアクションの層と、を有してもよい。したがって、「戻る」アクションと関連するチップアプリケーション202のバックスタック(back stack)は、2つのフィールドと、それぞれのフィールドごとに4つの異なる可能性―空、請求書入力画面210、設定画面212、及びチップ合計画面214―と、を有してもよい。したがって、バックスタックは、バックスタックの入力に関する限り、16個の異なる構成(configuration)を有してもよい。これらの構成は、それぞれ、チップアプリケーション202の異なる出力と関連付けられてもよく、且つ、有限の金額であってもよい。対照的に、スタックをモデル化する従来の方法は、プッシュダウンオートマトンを使用しており、これらのプッシュダウンオートマトンは、実際のアプリケーションのスタックに基づいた振る舞いをモデル化するために境界が定められていない(unbounded)スタックの使用を前提としている。
GUIアプリケーション102がGFSMモデル106としてモデル化されうるように上述したGUIアプリケーション102のモデル化に基づいて、分析モジュール104は、GUIアプリケーション102を動的にクローリングすると共にL*アルゴリズムを実行することにより、DFSMモデル106を生成するように、構成されてもよい。いくつかの実施形態においては、分析モジュール104は、図3〜図5に関して後述する方法300、400、及び500に従ってDFSMモデル106を生成するように、構成されてもよい。上述のように、DFSMモデル106を使用してGUIアプリケーション102をテストすることにより、予想及び所望通りに稼働するGUIアプリケーション102と関連しうるバグ又はその他の問題を見出してもよい。
図2Cは、本開示の少なくとも1つの実施形態によるチップアプリケーション202について生成されうる例示用のDFSMモデル250(以下、「モデル250」と呼ぶ)である。モデル250は、上述のダミー初期状態として機能しうる「e」というラベルが付与されたダミー初期状態252を含んでもよい。ダミー初期状態は、NULL又はダミーアクションに対する出力(「e」として表記され、且つ、ダミー初期状態252のラベルを形成する)であると表現されてもよい。その理由は、チップアプリケーション202内の実際のアクションが、ダミー初期状態への到達を結果的にもたらしえないからである。
モデル250は、請求書入力状態230及び請求書入力画面210と対応しうる初期状態254を含んでもよい。図2Bに関して上述したように、チップアプリケーション202の起動は、請求書入力画面210が出力として表示されることを結果的にもたらしてもよい。したがって、モデル250は、ダミー初期状態252から初期状態254への遷移を示しうる遷移エッジ264を含んでもよい。図示の実施形態においては、ダミー初期状態252から初期状態254への遷移は、チップアプリケーション202との関係における起動アクション(「Init」として表記される)の実行がチップアプリケーション202による請求書入力画面210(「B」として表記される)の表示又は出力を生成しうることを示す「Init/B」の入出力シーケンスによって表記される。
モデル250は、ダミーエラー状態262と、ダミー初期状態252からダミーエラー状態262への遷移を示しうる遷移エッジ292とを含んでもよい。図示の実施形態においては、遷移エッジ292によって示されているダミー初期状態252からダミーエラー状態262への遷移は、入出力シーケンス「{Cal,Tax,Set,Back}/X」によって表記されてもよい。その理由は、「Cal」、「Tax」、「Set」、及び「Back」は、チップアプリケーション202を起動するために使用不可能なアクションでありうるからである。したがって、ダミー初期状態252における使用不可能なアクション「Cal」、「Tax」、「Set」、及び「Back」の実行は、ダミーエラー状態262(「Sigma」というラベルによっても示されている)への遷移と、ダミー出力「X」の生成とを結果的にもたらすことになろう。
モデル250は、初期状態254に対して実行される1つ又は複数のアクションを介して到達されうる後続の状態256、258、及び260をさらに含んでもよい。図示の実施形態においては、後続の状態256は、図2Bの設定画面212及び第1設定状態234と関連付けられてもよい。図2Bに示されているように、チップアプリケーション202は、請求書入力画面210の設定ウィジェット220と関連する「設定」ボタンをタップしたときに、第1設定状態234に遷移してもよい。したがって、モデル250は、表記された入出力シーケンス「Set/S」を伴う初期状態254から後続の状態256への遷移を示しうる遷移エッジ280を含んでもよい。ここで、「S」は、「設定」ボタンのタップに対する出力としての設定画面212の生成を示している。また、後続の状態256には、入力シーケンス「Init.Set」というラベルが付与されてもよい。
「Tax/S」の入出力シーケンスと関連する後続の状態256における自己遷移エッジ284は、「Tax」アクションに応答して後続の状態256に留まることを示しており、図2Bの設定画面212の税率ウィジェット226と関連するボックスのクリックが、チップアプリケーション202が設定画面212上において及び第1設定状態234において留まることを結果的にもたらしうることを表記している。さらには、遷移エッジ286は、「{Init,Cal,Set}/X」と表記された入出力シーケンスに基づいた後続の状態256からダミーエラー状態262への遷移を示してもよい。その理由は、「Init」、「Cal」、及び「Set」が、後続の状態256と関連付けられうるチップアプリケーション202の設定画面212において使用不可能なアクションでありうるからである。
さらには、図2Bに関して上述したように、第1設定状態234の設定画面212内の「戻る」ボタンのクリックは、チップアプリケーション202のバックスタック内に含まれている情報に基づいて、「戻る」ボタンのクリックに対する応答として、チップアプリケーション202を請求書入力画面210及び関連する請求書入力状態230に遷移して戻らせてもよい。したがって、モデル250は、入出力シーケンス「Back/B」によって示されているように、後続の状態256から初期状態254及び請求書入力画面210に遷移して戻ることを示しうる遷移エッジ282を含んでもよい。
モデル250は、初期状態254からダミーエラー状態262への遷移を示しうる遷移エッジ288を含んでもよい。図示の実施形態においては、遷移エッジ288によって示されている初期状態254からダミーエラー状態262への遷移は、入出力シーケンス「{Init,Tax,Back}/X」によって表記されてもよい。その理由は、「Init」、「Tax」、及び「Back」が、初期状態254と関連付けられうるチップアプリケーション202の請求書入力画面210において使用不可能なアクションでありうるからである。
図2Bにおいて示されているように、チップアプリケーション202は、請求書入力画面210の計算ウィジェット218と関連する「計算」ボタンのタップに基づいて、チップ合計画面214及びチップ合計状態232に遷移してもよい。したがって、モデル250は、「Cal/T」と表記された入出力シーケンスを伴う初期状態254から後続の状態258への遷移を示しうる遷移エッジ266を含んでもよい。この場合に、「T」は、出力としてのチップ合計画面214を示している。また、後続の状態258には、入力シーケンス「Init.Cal」というラベルが付与されてもよい。
遷移エッジ276は、「{Init,Cal,Tax}/X」と表記された入出力シーケンスに基づいた後続の状態258からダミーエラー状態262への遷移を示してもよい。その理由は、図2Bに示されているように、「Init」、「Cal」、及び「Tax」が、図2Cの後続の状態258と関連付けられうるチップ合計画面214上における且つ関連するチップ合計状態232における使用不可能なアクションでありうるからである。
さらには、図2Bに関して上述したように、関連するチップ合計状態232のチップ合計画面214内の「戻る」ボタンのクリックは、チップアプリケーション202のバックスタック内に含まれている情報に基づいて、チップアプリケーション202をチップ合計画面214及びチップ合計状態232から請求書入力画面210及び関連する請求書入力状態230に遷移して戻らせてもよい。したがって、モデル250は、入出力シーケンス「Back/B」によって表記されているように、後続の状態258から初期状態254への遷移を示しうる遷移エッジ278を含んでもよい。
さらには、モデル250は、後続の状態258から後続の状態260への遷移と関連付けられうる遷移エッジ268を含んでもよい。遷移エッジ268は、チップ合計画面214及び関連するチップ合計状態232から図2Bに関して説明した設定画面212及び関連する第2設定状態236への遷移を示してもよい。したがって、遷移エッジ268は、「Set/S」の入出力シーケンスによって表記されてもよい。また、後続の状態260は、入力シーケンス「Init.Cal.Set」をラベルとして含んでもよい。
「Tax/S」の入出力シーケンスと関連する後続の状態260における自己遷移エッジ272は、「Tax」アクションに応答して後続の状態260に留まることを示しており、図2Bの設定画面212の税率ウィジェット226と関連するボックスのクリックが、チップアプリケーション202が設定画面212上において且つ第2設定状態236において留まることを結果的にもたらしうることを表記している。さらには、遷移エッジ270は、「{Init,Cal,Set}/X」と表記された入出力シーケンスに基づいた後続の状態260からダミーエラー状態262への遷移を示してもよい。その理由は、「Init」、「Cal」、及び「Set」が、後続の状態260と関連付けられうる設定画面212上において且つ第2設定状態236において使用不可能なアクションでありうるからである。
さらには、図2Bに関して上述したように、関連する第2設定状態236の設定画面212内の「戻る」ボタンのクリックは、チップアプリケーション202をチップ合計画面214及び関連するチップ合計状態232へ遷移して戻らせてもよい。したがって、モデル250は、入出力シーケンス「Back/T」によって表記されているように、後続の状態260から後続の状態258に戻る遷移を示しうる遷移エッジ274を含んでもよい。
したがって、図2Cは、本開示に従って生成されうる図2A及び図2Bに関して記述されたチップアプリケーション202の例示用のDFSMモデルを示している。いくつかの実施形態においては、チップアプリケーション202及びGUIアプリケーション102などのその他のGUIアプリケーションのDFSMモデルの生成は、図3〜図5に関して後述される方法300、400、及び500に基づいたものであってもよい。
図3は、本開示の少なくとも1つの実施形態に従ってGUIアプリケーションのDFSMモデルを生成する例示用の方法300のフローチャートである。方法300は、いくつかの実施形態において、図1の分析モジュール104などの分析モジュールによって実装されてもよい。例えば、分析モジュール104の処理装置108は、方法300のブロックのうちの1つ又は複数のブロックによって表されているGUIアプリケーション102のDFSMモデルを生成するための動作を実行するようにメモリ110内に保存されたコンピュータ命令を実行するように構成されてもよい。別個のブロックとして示されているが、様々なブロックは、所望の実装形態に応じて、更なるブロックに分割されてもよく、さらに少ない数のブロックに組み合わせられてもよく、或いは、除去されてもよい。
方法300は、開始してもよく、且つ、ブロック302において、GUIアプリケーションを動的にクローリングすることにより、テスト対象のGUIアプリケーションのシード観察(seed observation)を生成してもよい。動的なクローリングを実行する方法の一例については、図4に関して、さらに詳細に後述する。動的なクローリングを実行し、GUIアプリケーションの入出力シーケンスを観察してもよい。この入出力シーケンスは、GUIアプリケーションのその他の振る舞いを学習するための適切な起動点(launch point)をL*アルゴリズムが有するように、L*アルゴリズムによって使用されてもよい。
さらには、GUIアプリケーション102のクローリングの間に観察されうるアクションと、クローリングの間に観察されうるGUIアプリケーション102の画面とに基づいて、GUIアプリケーション102の1つ又は複数の画面において使用不可能でありうるアクションの入出力シーケンスを推測してもよい。この場合に、使用不可能なアクションの出力は、ダミーエラー出力であってもよい。観察及び推測される入出力シーケンスは、GUIアプリケーションのシード観察であってもよい。
例えば、「Init」が、チップアプリケーション202を起動するアクションを表記し、「Cal」が、「計算」ボタンをタップすることを表記し、「Set」が、「設定」ボタンをタップすることを表記し、「Back」が、「戻る」ボタンをタップすることを表記し、「Sigma」が、アクションの完全な組{Init,Cal,Set,Back}を表記し、「B」が、請求書入力画面210を表記し、「T」が、チップ合計画面214を表記し、「S」が、設定画面212を表記し、且つ、「X」が、ダミーエラー出力を表記するチップアプリケーション202に関して上述した命名法を使用して、チップアプリケーション202のクローリングは、表1によって列挙されている観察を結果的にもたらすことになろう。
方法300を再度参照すれば、ブロック304において、観察及び推測された入出力シーケンスを使用し、L*アルゴリズムの開始点として使用されうるL*アルゴリズム観察テーブル(observation table)(以下、「L*テーブル」と呼ぶ)を初期化すると共に入力してもよい。この結果、L*アルゴリズムの効率が向上するのみならず、L*アルゴリズムを使用してGUIアプリケーションの振る舞いを学習することが可能になる。対照的に、多くの例において、初期観察テーブルをL*アルゴリズムに提供することに失敗することにより、L*アルゴリズムがGUIアプリケーションの振る舞いを学習するために過大な時間が所要されるという結果となろう。
例えば、表1の入出力シーケンスに基づいて、図2に示されているように、チップアプリケーション202について、初期L*テーブルを生成してもよい。この場合に、行ラベル(最も左側の列内に記録されているもの)は、既に実行された様々なアクションシーケンスを示しており、列ラベル(最上部行内のセルによって示されている)は、アプリケーション内の使用可能な入力アクションの組に基づいたアクション又はアクションシーケンスの別の組を示しており、且つ、その他のセルは、行ラベル内のシーケンスとそのセルの列ラベルを連結させることによって形成されるアクションシーケンスに対するテスト対象のアプリケーションの結果的に得られる出力の適切な添え字を記録している。
ブロック306において、ブロック304において初期化されたL*テーブルが、閉じられており(close)、且つ、一貫性(consistent)を有しているか否かが判定されてもよい。いくつかの実施形態においては、L*アルゴリズムをL*テーブルに対して実行し、L*テーブルが、閉じられており、且つ、一貫性を有しているか否かを判定してもよい。これは、L*アルゴリズムの収束によって実行されるプロセスによって示されてもよい。L*テーブルが、閉じられておらず、且つ、一貫性を有していないときには、方法300は、ブロック308に進んでもよい。ここで、L*アルゴリズムは、GUIアプリケーションの振る舞いに関する1つ又は複数の問合せ(queries)を生成してもよい。この場合に、このような問合せに対する回答は、恐らくは、L*テーブルを、閉じた状態又は一貫性を有する状態とすることになろう。
例えば、上述の表2に基づいて、L*アルゴリズムは、その最後の2つの行内に記録されている応答に起因し、表2が、閉じられておらず、且つ、一貫性を有していないと判定してもよく、且つ、表1及び表2に基づいて、L*アルゴリズムは、表3を生成してもよい。この場合に、最後の行は、L*アルゴリズムによって生成されうるチップアプリケーション202に関する問合せを示している。
ブロック310において、問合せを動的なクローラ(crawler)に入力し、問合せに基づいて制御されたGUIアプリケーションの別のクローリング(「制御されたクローリング」と呼ぶ)を通じて、問合せに対する回答を得てもよい。動的クローラによる問合せの処理については、方法400に関しても説明する。また、特定の問合せに対する回答に加えて、制御されたクローリング(directed crawl)は、問合せの具体的に一部分でなくてもよいGUIアプリケーションの更なる入出力シーケンスを判定するように、構成されてもよい。
ブロック312において、L*テーブルは、制御されたクローリングの間に観察された入出力シーケンスに従って変更及び更新されてもよい。したがって、L*テーブルは、制御されたクローリングの間に観察されうるその他の入出力シーケンスのみならず、クローリングの間に生成されうる問合せに対する回答に従って、更新されてもよい。方法300は、ブロック312の後に、ブロック306に戻ってもよい。この場合に、L*アルゴリズムは、変更されたL*テーブルが、いまや、閉じられており、且つ、一貫性を有しているか否かを判定するべく、変更されたL*テーブルに対して再度実行されてもよい。ブロック306、308、310、及び312は、L*テーブルが、閉じられており、且つ、一貫性を有しているとみなされる時点まで、任意の回数にわたって反復されてもよい。
例えば、表3に対して生成された問合せに基づいて、動的クローラが実行されてもよく、且つ、表4に示されている入出力シーケンスが生成されてもよい。
表4の入出力シーケンスを使用して表3と関連付けられたL*テーブルを更新することにより、以下の表5を生成してもよい。
次いで、L*アルゴリズムは、表5の最後の2つの行が、この表が閉じられておらず、且つ、一貫性を有していないことの責任を担っていると判定してもよく、且つ、別の問合せの組を有する改訂された表を生成してもよい。これらの問合せを動的クローラによって実行し、L*テーブルを更新すると共に、更新されたL*テーブルが、閉じられており、且つ、一貫性を有しているか否かのブロック306、308、310、及び312による判定を可能にしてもよい。このプロセスは、チップアプリケーション202と関連するL*テーブルが、閉じられており、且つ、一貫性を有しているとL*アルゴリズムがみなす時点まで、一連のL*テーブル及び問合せによって反復されてもよい。
方法300を再度参照すれば、L*テーブルが、閉じられており、且つ、一貫性を有しているとみなされたときに、方法300は、ブロック306からブロック314に進んでもよい。ここで、L*テーブルに基づいてL*アルゴリズムによって推測モデルを生成してもよい。推測モデルは、GUIアプリケーションが動作する方法の推測であるDFSMモデルであってもよい。例えば、チップアプリケーション202と関連するL*テーブルが、閉じられており、且つ、一貫性を有しているとみなされるときには、図2Cのモデル250は、チップアプリケーション202のL*テーブルに基づいた推測モデルとして生成されてもよい。
ブロック316において、推測モデルがGUIアプリケーションを十分にモデル化しているか否かが判定されてもよい。推測モデルが十分にGUIアプリケーションをモデル化しているか否かを判定する一例については、図5の方法500に関して後述する。推測モデルがGUIアプリケーションを十分にモデル化していないときには、方法300は、ブロック318に進んでもよい。ブロック318において、同一の結果が得られない推測モデル及びGUIアプリケーションとの関係における一連の動作を示しうる反例(counter example)を生成してもよい。反例の生成の一例についても、図5に関して説明する。ブロック320において、ブロック318において生成された反例に基づいて、L*テーブルを変更してもよく、且つ、方法300は、ブロック306に戻ってもよい。
ブロック316において、推測モデルがGUIアプリケーションを十分にモデル化していると判定されたときには、方法300は、ブロック322に進んでもよい。ブロック322において、推測モデルは、無害化(sanitize)されてもよい。これにより、推測モデルに含まれている無関係の要素を除去してもよい。例えば、推測モデルは、GUIアプリケーションの1つ又は複数の状態において使用不可能なアクションと関連しうるダミーエラー状態を含む場合がある。したがって、ブロック322において、ダミーエラー状態と、推測モデルのダミーエラー状態に結び付く関連する遷移エッジとを推測モデルから除去してもよい。ブロック324において、無害化された推測モデルが、GUIアプリケーションのGUIモデルとして出力されてもよい。
図4は、本開示の少なくとも1つの実施形態に従って構成されたGUIアプリケーションをクローリングする例示用の方法400のフローチャートである。上述のように、方法400を使用し、上述の方法300のブロック302及び310との関係における動作を実行してもよい。方法400は、いくつかの実施形態においては、図1の分析モジュール104などの分析モジュールによって実装されてもよい。例えば、分析モジュール104の処理装置108は、方法400のブロックのうちの1つ又は複数のブロックによって表されているGUIアプリケーション102をクローリングするための動作を実行するためにメモリ110内に保存されているコンピュータ命令を実行するように構成されてもよい。別個のブロックとして示されているが、様々なブロックは、所望の実装形態に応じて、更なるブロックに分割されてもよく、さらに少ない数のブロックに組み合わせられてもよく、或いは、除去されてもよい。
方法400は、開始されてもよく、且つ、ブロック402において、GUIアプリケーションが読み込まれてもよい。ブロック404において、GUIアプリケーションの初期画面が読み込まれてもよい。ブロック406において、有効なクローリング問合せが受信されているか否かが判定されてもよい。例えば、ブロック406において、有効なクローリング問合せが受信されているか否かは、方法300のブロック308において実行された動作に基づいて判定されてもよい。
有効なクローリング問合せが存在していない場合には、方法400は、ブロック408に進んでもよい。ここで、GUIアプリケーションの現在の画面―初期画面であってもよい―が、実行又はクローリングされていないアクションを有しているか否かが判定されてもよい。実行又はクローリングされていないアクションは、以下においては、「オープンアクション」と呼ばれる場合がある。ブロック408において、現在の画面がオープンアクションを有しているときには、ブロック410において、そのオープンアクションが選択されてもよい。ブロック412において、選択されたアクションが、もはや、オープンであるとみなされ得ないように、選択されたアクションは、実行済みとしてマーキングされてもよい。
ブロック414において、選択されたアクションが実行されてもよく、且つ、ブロック416において、アクションの実行の結果として得られた画面(resulting screen)(「結果として得られた画面」と呼ぶ)が読み込まれてもよい。ブロック418において、結果として得られた画面は、観察済みであるとして記録されてもよく、且つ、現在の画面として設定されてもよい。ブロック418を終了した後に、方法400は、ブロック406に戻ってもよい。
再度、ブロック406において、有効なクローリング問合せが存在しているか否かが判定されてもよい。有効なクローリング問合せが存在していない場合には、方法400は、再度、ブロック408に進んでもよい。ブロック408において、現在の画面がオープンアクションを有していない場合には、方法400は、ブロック420に進んでもよい。ここで、現在の画面が初期画面であるか否かが判定されてもよい。ブロック420において、現在の画面が初期画面でない場合には、方法400は、ブロック422に進んでもよい。ブロック422において、現在の画面に到達するために使用されうるGUIアプリケーションを通じた現在の経路及びトレースが、GUIアプリケーションの新しいトレースとして保存されてもよい。ブロック424において、GUIアプリケーションは、以前の画面に戻ってもよく、且つ、方法400は、ブロック408に戻ってもよい。
ブロック420を再度参照すれば、ブロック420において、現在の画面が初期画面である場合には、方法400は、ブロック423に進んでもよい。ここで、いずれかの以前に観察又はクローリングされた画面が、オープンアクションを有しているか否かが判定されてもよい。ブロック423において、以前に観察された画面がオープンアクションを有していると判定された場合には、ブロック425において、1つ又は複数のオープンアクションを有する以前に観察された画面が読み込まれてもよく、且つ、方法400は、ブロック410に戻ってもよい。対照的に、ブロック423において、オープンアクションを有する以前に観察された画面が存在していないと判定された場合には、方法400は、ブロック426に進んでもよい。ここで、現在の動的クローリングの間に判定されたGUIアプリケーションの経路及びトレースが出力されてもよい。上述のように、方法400を使用してクローリングされうるGUIアプリケーションについてGUIモデルが生成されうるように、出力されたトレース及び経路を使用し、L*テーブルの1つ又は複数のフィールドに入力してもよい。
ブロック406を再度参照すれば、ブロック406において有効なクローリング問合せが存在している場合には、方法400は、ブロック428に進んでもよい。ここで、クローリング問合せの末尾に到達しているか否かが判定されてもよい。クローリング問合せの末尾に到達していない場合には、方法400は、ブロック430に進んでもよい。ここで、クローリング問合せの次のアクションが選択されてもよい。ブロック430を終了することにより、方法400は、問い合わせられたアクションに関して、ブロック412、414、416、及び418と関連するステップが実行されうるように、ブロック412に進んでもよく、且つ、方法400は、ブロック406に戻ってもよい。方法400は、クローリング問合せの末尾に到達しており、且つ、ブロック428において、そのように判定される時点まで、ブロック406、428、430、412、414、416、及び418を反復してもよい。クローリング問合せの末尾に到達しており、且つ、ブロック428において、そのように判定されたら、方法は、ブロック420に進んでもよい。
方法300に関して上述したように、クローリング問合せは、L*テーブルが不完全である―例えば、閉じられておらず、且つ、一貫性を有していない―ことに応答して生成されてもよい。したがって、方法400のブロック406、428、430、412、414、416、及び418を使用して、L*テーブルが、閉じられており、且つ、一貫性を有する状態となるように、L*テーブルの完成を支援しうるGUIアプリケーションに関する振る舞い情報を判定及び取得してもよい。さらには、上述のように、閉じられており、且つ、一貫性を有しているL*テーブルを使用して推測モデルを生成してもよい。この推測モデルは、図5の方法500に従ってGUIアプリケーションと比較されてもよい。
図5は、本開示の少なくとも1つの実施形態に従って構成された、推測モデルが、関連するGUIアプリケーションを十分にモデル化しているか否かを判定する例示用の方法500のフローチャートである。上述のように、方法500を使用し、上述の方法300のブロック316及び318との関係における動作を実行してもよい。方法500は、いくつかの実施形態においては、図1の分析モジュール104などの分析モジュールによって実装されてもよい。例えば、分析モジュール104の処理装置108は、方法500のブロックのうちの1つ又は複数のブロックによって表されている動作を実行するべくメモリ110内に保存されているコンピュータ命令を実行するように構成されてもよい。別個のブロックとして示されているが、様々なブロックは、所望の実装形態に応じて、更なるブロックに分割されてもよく、さらに少ない数のブロックに組み合わせられてもよく、或いは、除去されてもよい。
方法500は、ブロック502において開始されてもよい。ここで、GUIアプリケーションと関連する疑似ランダム入力シーケンス(以下、「入力シーケンス」と呼ぶ)が生成されてもよい。入力シーケンスは、入力シーケンスに応答してGUIアプリケーションの振る舞いを判定するべくGUIアプリケーションによって実行されうる任意の適切なアクションの組を含んでもよい。
ブロック504において、抽象的入力シーケンスが、入力シーケンスから生成されてもよい。抽象的入力シーケンスは、入力シーケンスのアクションに関連しうると共に推測モデルによってモデル化されるGUIアプリケーションの動作のシーケンスを判定するべく推測モデルにおいてアクションとして使用されうるアクションの組を含んでもよい。
ブロック506において、入力シーケンスをGUIアプリケーションに対して実行し、関連する出力シーケンスを取得してもよい。ブロック508において、抽象的入力シーケンスを推測モデルに対して実行し、関連する抽象的出力シーケンスを取得してもよい。ブロック510において、出力シーケンスが抽象的出力シーケンスと実質的に等価であるか否かが判定されてもよい。
出力シーケンスが抽象的出力シーケンスと実質的に等価でない場合には、方法500は、ブロック512に進んでもよい。ここで、抽象的入力シーケンスは、上述の方法300のブロック318において生成される反例として使用されうる反例として出力されてもよい。ブロック510において、出力シーケンスが抽象的出力シーケンスと実質的に等価である場合には、方法500は、ブロック513に進んでもよい。
ブロック512において、入力生成閾値に到達しているか否かが判定されてもよい。入力生成閾値は、GUIアプリケーションが推測モデルによって十分にモデル化されうることを評価するために、GUIアプリケーション及び推測モデルの異なる経路を十分にテストするものとみなされるシーケンス又はこれらの基準の組合せを生成するために、既定数の入力シーケンス又は既定の時間と関連付けられてもよい。入力生成閾値に到達していない場合には、方法500は、ブロック502に戻ってもよい。対照的に、入力生成閾値に到達している場合には、方法500は、ブロック514に進んでもよい。ここで、推測モデルは、GUIアプリケーションを十分にモデル化するものとみなされてもよい。この結果、いくつかの実施形態においては、上述の方法300がブロック316からブロック322に進むことになる。
したがって、方法300、400、及び500を使用し、GUIアプリケーションのDFSMモデルを抽出及び生成してもよい。その結果、GUIモデルを使用し、GUIアプリケーションの振る舞いを検証及びテストしてもよい。且つ、いくつかの例においては、GUIモデルを使用し、GUIアプリケーションと関連するバグをトラブルシュート及び/又は検出してもよい。
当業者は、本明細書に開示されているこのプロセス及びその他のプロセス及び方法においては、プロセス及び方法において実行される機能は、異なる順序において実装されてもよいことを理解するであろう。さらには、概説されたステップ及び動作は、一例として提示されているものに過ぎず、且つ、ステップ及び動作のいくつかは、開示されている実施形態の本質を逸脱することなしに、任意選択であってもよく、さらに少ない数のステップ及び動作として組み合わせられてもよく、或いは、更なるステップ及び動作に拡張されてもよい。
図6は、本開示のいくつかの実施形態に従って構成されたGUIアプリケーションをモデル化する例示用の方法600のフローチャートである。方法600は、いくつかの実施形態においては、図1の分析モジュール104などの分析モジュールにより、実装されてもよい。例えば、分析モジュール104の処理装置108は、方法600のブロックのうちの1つ又は複数のブロックによって表されているGUIアプリケーション102をモデル化するための動作を実行するべくメモリ110内に保存されたコンピュータ命令を実行するように構成されてもよい。別個のブロックとして示されているが、様々なブロックは、所望の実装形態に応じて、更なるブロックに分割されてもよく、さらに少ない数のブロックに組み合わせられてもよく、或いは、除去されてもよい。
方法600は、ブロック602において開始してもよい。ここで、ダミーエラー状態及びダミーエラー出力が、有限状態マシン内において生成されてもよい。ブロック604において、有限状態マシン内においてダミーエラー出力を生成しつつ、GUIアプリケーションの画面上において使用不可能なアクションに対する応答が、ダミーエラー状態への遷移としてモデル化されてもよい。
当業者は、本明細書に記述されているこのプロセス及びその他のプロセス及び方法においては、プロセス及び方法において実行される機能は、異なる順序において実装されてもよいことを理解するであろう。さらには、概説されたステップ及び動作は、例として提供されているものに過ぎず、且つ、ステップ及び動作のいくつかは、開示されている実施形態の本質を逸脱することなしに、任意選択であってもよく、さらに少ない数のステップ及び動作として組み合わせられてもよく、或いは、更なるステップ及び動作に拡張されてもよい。
例えば、いくつかの実施形態においては、画面は、有限状態マシン内の出力としてモデル化されてもよい。これらの実施形態及びその他の実施形態においては、方法600は、有限状態マシン内の入力として画面上のアクションをモデル化することと、画面上において実行されたアクションに応答して、有限状態マシン内の別の出力として、GUIに基づいたアプリケーションによって生成された後続の画面をモデル化することとを含んでもよい。したがって、有限状態マシンは、無限数の入力が存在しうる例においても、有限であってもよい。
同様に、いくつかの実施形態においては、画面は、コレクションフィールドを含んでもよく、且つ、方法600は、コレクションフィールドが空であるときに、コレクションフィールドが有限状態マシン内の第1出力と関連付けられ、且つ、コレクションフィールドが入力されているときには、コレクションフィールドが、有限状態マシン内の第2出力と関連付けられるように、有限状態マシン内における画面のモデル化と関連するステップを含んでもよい。この場合にも、この方式によるGUIアプリケーションのモデル化により、有限状態マシンは、無限数の項目がコレクションフィールド内に存在しうる例においても、有限になり得る。
さらには、いくつかの実施形態においては、方法600は、有限数の構成を含む有限スタック(bounded stack)としてGUIアプリケーションのスタックをモデル化することと、異なる構成を識別(distinguish)するために有限状態マシン内の入出力シーケンスを使用して有限状態マシン内の状態の一部として構成のそれぞれをモデル化することとを含んでもよい。この方式による有限スタックのモデル化により、従来は、スタックが異なる構成を状態へ組み込むのではなく、無限サイズのスタックを有する形式を使用してモデル化されているときに、有限状態マシンの形態におけるスタックのモデル化が可能となろう。
さらには、これらの実施形態又はその他の実施形態において、GUIアプリケーションは、複数の初期画面及び/又は状態(例えば、関連する第1初期状態及び第2初期状態をそれぞれが有する第1初期画面及び第2初期画面)を含んでもよい。これらの実施形態又はその他の実施形態において、方法600は、有限状態マシン内において、ダミー初期状態に対して実行された第1ダミーアクションに対する第1応答として、有限状態マシンのダミー初期状態から第1初期状態への遷移をモデル化することに関連するステップを含んでもよい。第1初期状態は、第1初期画面と関連付けられてもよい。また、方法600は、有限状態マシン内において、ダミー初期状態に対して実行された第2ダミーアクションに対する応答として、有限状態マシンのダミー初期状態から第2初期状態への遷移をモデル化することを含んでもよい。第2初期状態は、第2初期画面と関連付けられてもよい。
上述のように、本明細書に記述されている実施形態は、以下にさらに詳述するように、様々なコンピュータハードウェア又はソフトウェアモジュールを含む特殊目的又は汎用コンピュータ(例えば、図1の処理装置108)の使用を含んでもよい。
さらには、上述のように、本明細書に記述されている実施形態は、保存されているコンピュータ実行可能命令又はデータ構造を担持又は保持するためのコンピュータ可読媒体(例えば、図1のメモリ110)を使用して、実装されてもよい。このようなコンピュータ可読媒体は、汎用又は特殊目的コンピュータによってアクセスされうる任意の使用可能な媒体であってもよい。一例として、且つ、限定を伴うことなしに、このようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD−ROM、又はその他の光ディスクストレージ、磁気ディスクストレージ、或いは、その他の磁気ストレージ装置、フラッシュメモリ装置(例えば、ソリッドステートメモリ装置(solid state memory device))、或いは、コンピュータ実行可能命令又はデータ構造の形態の所望のプログラムコードを担持又は保存するように使用されうると共に汎用目的コンピュータ及び特殊目的コンピュータによってアクセスされうる任意のその他のストレージ媒体を含む有体又は持続的なコンピュータ可読媒体を含んでもよい。また、上述のものの組合せも、コンピュータ可読媒体の範囲に含まれてもよい。
コンピュータ実行可能命令は、例えば、汎用コンピュータ、特殊目的コンピュータ、又は特殊目的処理装置(例えば、1つ又は複数の処理装置)に特定の機能又は機能のグループを実行させる命令及びデータを含んでもよい。主題は、構造の特徴及び/又は方法の動作に固有の言語において記述されているが、添付の請求項に規定されている主題は、必ずしも、上述の特定の特徴又は動作に限定されるものではないことを理解されたい。むしろ、上述の特定の特徴及び動作は、請求項を実施する例示用の形態として開示されたものである。
本明細書において使用されている「モジュール」又は「コンポーネント」という用語は、モジュール又はコンポーネントの動作を実行するように構成された特定のハードウェア実装形態及び/又は演算システムの汎用ハードウェア(例えば、コンピュータ可読媒体や処理装置)によって保存及び/又は実行されうるソフトウェアオブジェクト又はソフトウェアルーチンを意味してもよい。いくつかの実施形態においては、本明細書において記述されている異なるコンポーネント、モジュール、エンジン、及びサービスは、演算システム上において(例えば、別個のスレッドとして)稼働するオブジェクト又はプロセスとして実装されてもよい。本明細書において記述されているシステム及び方法のいくつかは、(汎用ハードウェアによって保存及び/又は実行される)ソフトウェアとして実装されるものとして一般的に記述されているが、特定のハードウェア実装形態、又はソフトウェアと特定のハードウェア実装形態の組合せも、可能であり、且つ、想定される。この説明においては、「演算エンティティ」は、本明細書において以前に規定されている任意の演算システムであってもよく、或いは、演算システム上において稼働する任意のモジュール又はモジュールの組合せであってもよい。
本明細書に記述されている全ての例及び条件に関する言語は、本発明と、当技術分野の発展に寄与する本発明者による概念と、を理解する際に読者の一助となるように教育的な目的を意図したものであり、且つ、具体的に記述されている例及び条件に対する限定を伴うものではないものと解釈されたい。本開示の実施形態が詳細に記述されているが、本開示の精神及び範囲を逸脱することなしに、これらに対して様々な変更、置換、及び変形を実施することができることを理解されたい。