(57)【要約】【課題】ＧＵＩの状態に対して網羅的に自動操作する技術において、複数のテスト対象アプリケーションが動作する端末を多数用意して並行的に自動操作する場合の、ＧＵＩの状態遷移グラフの生成の処理時間を短縮化する。【解決手段】網羅操作制御部５は、表示されたＧＵＩの状態から未操作のＧＵＩ要素が存在するＧＵＩの状態（目標状態）へ到達するパスを抽出し、該目標状態に状態を遷移させたときに未操作のＧＵＩ要素が確実に存在するかを判定し、存在しないと判定しない場合には他の目標状態へパスを抽出して前記判定処理を再度行い、抽出されたパスに沿ってＧＵＩ要素を自動操作することでＧＵＩを未操作のＧＵＩ要素が存在する状態に変化させる。【選択図】図１６
2014232514.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末上で動作するテスト対象アプリケーションのグラフィカルユーザインタフェース（ＧＵＩ）の状態を網羅的に自動操作する方法であって、
記憶手段に予め記憶した起動ファイルを複数の端末でそれぞれ実行することにより各端末においてテスト対象アプリケーションを起動させる第１のステップを備え、
更に、各端末に対してそれぞれ、
端末の表示手段に表示されたテスト対象アプリケーションのＧＵＩ状態を取得する第２のステップと、
表示されたＧＵＩの状態がこれまで取得したことのない場合に該ＧＵＩ状態において操作可能なすべてのＧＵＩ要素を取得する第３のステップと、
テスト対象アプリケーションが終了した状態であった場合に、起動ファイルを実行することでテスト対象アプリケーションを再起動し、表示されたＧＵＩの状態に対して再帰的に処理を継続する第４のステップと、
表示されたＧＵＩの状態において未操作のＧＵＩ要素が存在する場合に、該ＧＵＩ要素を自動操作してテスト対象アプリケーションのＧＵＩを状態遷移させ、遷移後の状態に対して処理を再帰的に継続する第５のステップと、
表示されたＧＵＩの状態において未操作のＧＵＩ要素が存在せず且つこれまで取得した他のＧＵＩの状態に未操作のＧＵＩ要素が存在する場合に、表示されたＧＵＩの状態から未操作のＧＵＩ要素が存在するＧＵＩの状態（目標状態）へ到達するパスを抽出し、該目標状態に状態を遷移させたときに未操作のＧＵＩ要素が確実に存在するかを判定し、存在しないと判定しない場合には他の目標状態へパスを抽出して前記判定処理を再度行う第６のステップと、
抽出されたパスに沿ってＧＵＩ要素を自動操作することでＧＵＩを未操作のＧＵＩ要素が存在する状態に変化させ、変化した状態に対して処理を再帰的に継続する第７のステップと、
取得したすべてのＧＵＩの状態において未操作のＧＵＩ要素が存在しない場合に処理を終了させる第８のステップとを、
各端末間で並行して処理する
ことを特徴とするグラフィカルユーザインタフェースの自動操作方法。
【請求項２】
前記第６のステップにおいては、目標状態までのパスを抽出した際に、自処理に係る端末において該目標状態まで状態を遷移させることを示す目標状態管理情報を各並行処理で共有の記憶手段に記憶するとともに、該記憶処理から判定処理までの間は目標状態管理情報の記憶手段への書き込み処理を並行処理間で排他制御する
ことを特徴とする請求項１記載のグラフィカルユーザインタフェースの自動操作方法。
【請求項３】
目標状態管理情報は端末の識別子と目標状態の組からなり、
前記第１のステップの後に各端末について端末の識別子と空値の組を目標状態管理情報として記憶手段に記憶し、
前記第６のステップにおいては、目標状態までのパスを抽出した際に目標管理情報を自処理に係る端末の識別子と目標状態の組に書き換え、目標管理情報として自処理に係る目標状態と同じ目標状態を持つ端末の識別子の数と、該目標状態における未操作のＧＵＩ要素の数とに基づき前記判定処理を行う
ことを特徴とする請求項２記載のグラフィカルユーザインタフェースの自動操作方法。
【請求項４】
前記第６のステップにおいては、これまでの処理で実行した状態遷移の列である実行パスの集合に基づき目標状態へのパスを抽出する
ことを特徴とする請求項１乃至３何れか１項記載のグラフィカルユーザインタフェースの自動操作方法。
【請求項５】
前記第６のステップにおいては、これまでの処理で取得したＧＵＩの状態の遷移を表す状態遷移グラフに基づき目標状態へのパスを抽出する
ことを特徴とする請求項１乃至３何れか１項記載のグラフィカルユーザインタフェースの自動操作方法。
【請求項６】
複数の端末上で動作するテスト対象アプリケーションのグラフィカルユーザインタフェース（ＧＵＩ）の状態を網羅的に自動操作する装置であって、
端末の表示手段に表示されているＧＵＩからＧＵＩの状態を取得するＧＵＩ状態取得手段と、
ＧＵＩ要素を操作してＧＵＩの状態を遷移させるＧＵＩ自動操作手段と、
ＧＵＩの第１の状態から第２の状態へのパスを抽出するパス集合探索手段と、
記憶手段に予め記憶した起動ファイルを複数の端末でそれぞれ実行することにより各端末においてテスト対象アプリケーションを起動させ、更に、各端末に対してそれぞれ、端末の表示手段に表示されたテスト対象アプリケーションのＧＵＩ状態をＧＵＩ取得手段により取得し、表示されたＧＵＩの状態がこれまで取得したことのない場合に該ＧＵＩ状態において操作可能なすべてのＧＵＩ要素を取得し、テスト対象アプリケーションが終了した状態であった場合に、起動ファイルを実行することでテスト対象アプリケーションを再起動し、表示されたＧＵＩの状態に対して再帰的に処理を継続し、表示されたＧＵＩの状態において未操作のＧＵＩ要素が存在する場合に、該ＧＵＩ要素をＧＵＩ自動操作手段により自動操作してテスト対象アプリケーションのＧＵＩを状態遷移させ、遷移後の状態に対して処理を再帰的に継続し、表示されたＧＵＩの状態において未操作のＧＵＩ要素が存在せず且つこれまで取得した他のＧＵＩの状態に未操作のＧＵＩ要素が存在する場合に、表示されたＧＵＩの状態から未操作のＧＵＩ要素が存在するＧＵＩの状態（目標状態）へ到達するパスをパス集合探索手段により抽出し、該目標状態に状態を遷移させたときに未操作のＧＵＩ要素が確実に存在するかを判定し、存在しないと判定しない場合には他の目標状態へのパスをパス集合探索手段により抽出して前記判定処理を再度行い、抽出されたパスに沿ってＧＵＩ要素をＧＵＩ自動操作手段により自動操作することでＧＵＩを未操作のＧＵＩ要素が存在する状態に変化させ、変化した状態に対して処理を再帰的に継続し、取得したすべてのＧＵＩの状態において未操作のＧＵＩ要素が存在しない場合に処理を終了させる処理を各端末間で並行して実行する網羅操作制御手段とを備えた
ことを特徴とするグラフィカルユーザインタフェースの自動操作装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、グラフィカルユーザインタフェースの動作を表す状態遷移グラフを生成する技術に関する。
【背景技術】
【０００２】
最近のソフトウェアの大部分はグラフィカルユーザインタフェース（以下ＧＵＩ）を備えており、ＧＵＩへの操作によってＧＵＩが期待通りに変化することのテストは、ソフトウェア開発において必須の作業である。ＧＵＩの多くはウインドウシステムを採用しており、ウインドウ内のボタンやテキストボックスなどＧＵＩ要素を操作することでＧＵＩが変化する。これをＧＵＩの状態遷移と呼ぶ。ここでの操作とは具体的には、マウスクリックやキーボード入力などのことである。もし、このような操作による変化後のＧＵＩが期待どおりの状態ではなかった場合、これをＧＵＩのエラーと言う。
【０００３】
ＧＵＩのエラーを発見するためには、ＧＵＩに対するあらゆる操作手順を実行し、操作後のＧＵＩを確認する必要がある。しかし、ＧＵＩは多くのＧＵＩ要素で構成されているため、その操作順番の組み合わせは膨大な数に及ぶ。よってこの確認を人手で行うと、その作業は膨大な工数を必要とする。
【０００４】
従来技術として、ＧＵＩの要素を自動操作し実際にＧＵＩを遷移させ、さらに遷移したＧＵＩに対して自動操作を再帰的に繰り返す技術が提案されている。このような自動操作の結果、ＧＵＩ要素の操作に対するＧＵＩの遷移を表現する状態遷移グラフを生成することができる。このような状態遷移グラフを使ってＧＵＩのエラーの検出や、ＧＵＩをテストするためのテストケース生成が可能となる。ここでは、それら自動操作の従来技術とその問題点を説明する。
【０００５】
非特許文献１では、初期のＧＵＩとして表示されている複数のウインドウ内のＧＵＩ要素を順次自動的に操作する。ＧＵＩ要素を操作すると新規にウインドウが表示される（あるいはブラウザ等をベースとしたＧＵＩの場合は、別のＧＵＩ要素で構成されるＧＵＩに表示が切り替わる）場合があり、その場合は、新規ウインドウ内のＧＵＩ要素に対して同様の処理を再帰的に繰り返す。例えば図１のように初期のＧＵＩが１つのウインドウで構成され、そのウインドウ内のＧＵＩ要素として２つのラジオボタンと１つのボタンが存在する場合を考える。ボタンを押すとラジオボタンの選択状態に応じて、ＧＵＩが（ａ）、（ｂ）あるいは（ｃ）へと切り替わる。このようなＧＵＩに対して非特許文献１の技術を適用すると、以下のような手順で自動操作する。
【０００６】
１．ラジオボタン１を操作（ラジオボタン１が選択状態になる）
２．ラジオボタン２を操作（ラジオボタン２が選択状態になる。ラジオボタン１の選択状態は解除される）
３．ボタン１を操作（ＧＵＩが（ｃ）に切り替わる）
４．ＧＵＩ（ｃ）のＧＵＩ要素（キャプションがＹｅｓ，Ｎｏのボタン）を操作。
【０００７】
非特許文献１の問題は、自動操作の過程で出現する各ＧＵＩ要素を１度しか操作しない点である。結果として先ほどの自動操作の手順のように、（ａ）や（ｂ）のＧＵＩへ遷移することができず、生成される状態遷移グラフも（ａ）や（ｂ）への遷移が欠けた不完全なものとなる。
【０００８】
このような非特許文献１の問題に対して、非特許文献２のようにＧＵＩの状態に対して網羅的に自動操作することでより精密なＧＵＩの状態遷移グラフを生成する技術が提案されている。ＧＵＩの状態とは、ＧＵＩとして表示されているＧＵＩ要素の構造を表現した情報である。ＧＵＩ要素はキャプションや活性状態、選択状態等のプロパティとその値の情報を保持している。ＧＵＩを構成する要素の状態は、ＧＵＩ要素名、プロパティ、プロパティの値という組の集合で表現できる。図２に図１の初期のＧＵＩの各要素の状態の例を示す。ＧＵＩは複数のウインドウで構成される。よって各ウインドウの状態とはそれらウインドウを構成するＧＵＩ要素の状態の集合である。そしてＧＵＩの状態は各ウインドウの状態の集合で表現することができる。
【０００９】
例えば、図１の初期のＧＵＩはラジオボタンの選択に応じて異なる状態として表現することができる。ラジオボタン１とラジオボタン２ともに未選択の場合、ラジオボタン１を選択した場合、ラジオボタン２を選択した場合のＧＵＩの状態を図３に示す。このＧＵＩではウインドウは１つしか存在しないため、それぞれのウインドウの状態をｗ0，ｗ1，ｗ2とすると、各ＧＵＩの状態は｛ｗ0｝，｛ｗ1｝，｛ｗ2｝となる。
【００１０】
非特許文献２では、まずテスト対象のアプリケーションを起動し、初期のＧＵＩを表示させる。初期のＧＵＩからＧＵＩの状態を取得し、操作可能なＧＵＩ要素を自動操作する。この処理によって表示されているＧＵＩの状態が変化するため、変化したＧＵＩの状態に対して同様の処理を再帰的に繰り返す。このようにすることで、例えば、図３の各状態においてボタン１を自動操作すれば、図１のＧＵＩ（ａ）（ｂ）（ｃ）へ遷移することが可能になるため、非特許文献１より精密な状態遷移グラフが構築できる。
【００１１】
このように出現したすべてのＧＵＩの状態に対して網羅的にＧＵＩ要素を自動操作するためには、自動操作の過程で出現したＧＵＩの状態と、そのＧＵＩの状態において操作したＧＵＩ要素を記憶しておく必要がある。記憶しなかった場合、同じＧＵＩの状態が出現したときに、過去に操作したことのあるＧＵＩ要素を繰り返し操作してしまい、無限ループに陥る可能性がある。そこで、非特許文献２では、ＧＵＩの状態の集合Ｓと状態遷移の集合Ｔに対して、出現したＧＵＩの状態や発生した状態遷移をそれぞれの集合に追加し記憶する。
【００１２】
具体的には、現在表示されているＧＵＩの状態を取得し、そのＧＵＩの状態が過去に出現したことがあるか、すなわちＧＵＩ状態の集合Ｓに現在のＧＵＩ状態が含まれるか調べる。もし含まれなければ、そのＧＵＩの状態をＧＵＩ状態の集合Ｓに追加する。さらに現在のＧＵＩ状態において可能な状態遷移を状態遷移の集合Ｔに追加する。状態遷移とは形式的には、操作前の状態、操作するＧＵＩ要素、操作後の状態の組で表現できる。
【００１３】
例えば、図１の初期のＧＵＩに対して、非特許文献２による自動操作を実施した場合を考える。まずディスプレイには初期のＧＵＩが表示されるため、初期ＧＵＩの状態ｓ0＝｛ｗ0｝を取得する。ＧＵＩ状態ｓ0は状態の集合Ｓにまだ登録されていないため、集合ＳにＧＵＩ状態ｓ0を追加する。さらにこのＧＵＩ状態ではラジオボタン１、ラジオボタン２、ボタン１が操作可能であるため、状態遷移として（ｓ0，ラジオボタン１，ＴＢＤ）、（ｓ0，ラジオボタン２，ＴＢＤ）、（ｓ0，ボタン１，ＴＢＤ）を集合Ｔに追加する（図４）。図４の状態遷移の集合Ｔを示す表の各行が追加した状態遷移に対応する。状態遷移における操作後の状態がＴＢＤであるのは、まだ未操作であるため、操作後の状態が未決定（Ｔｏ  Ｂｅ  Ｄｅｔｅｒｍｉｎｅｄ）であることを意味する。これ以降ではＧＵＩの状態のことを単に状態と呼ぶ。
【００１４】
次に現在の状態ｓ0において未操作である遷移を１つ選択し、そのＧＵＩ要素を自動操作する。例えばここでは、図４の集合Ｔからラジオボタン１を自動操作したとする。その結果、ＧＵＩは図５のように変化する。このＧＵＩの状態をｓ1とすると先ほど選択した状態遷移（ｓ0，ラジオボタン１，ＴＢＤ）を（ｓ0，ラジオボタン１，ｓ1）に置き換える。以降はこれまでの処理を再帰的に現在の状態ｓ1に対して繰り返す。すなわち状態ｓ1が集合Ｓに含まれるか調べ、含まれていないため集合Ｓにｓ1を追加する。さらに状態ｓ1に対して可能な遷移を集合Ｔに追加する。そして、状態ｓ1で可能な遷移を１つ選択し、例えばラジオボタン１を自動操作する。このときの状態の集合Ｓと状態遷移の集合Ｔを図６に示す。
【００１５】
このように初期のＧＵＩから自動操作処理を繰り返したときのＧＵＩの状態遷移を図７に示す。ＧＵＩの状態はｓ0，ｓ1，ｓ1，ｓ2，ｓ1，ｓ3，のように遷移し、状態ｓ3において終了ボタン（ボタン２）を押してアプリケーションが終了するまで継続される。この時点でのＧＵＩ状態の集合Ｓと状態遷移の集合Ｔを図８に示す。アプリケーションが終了してしまった場合、非特許文献２はアプリケーションを再起動し初期のＧＵＩを表示し処理を繰り返す。
【００１６】
非特許文献２はこのような自動操作の結果、状態遷移グラフを生成することができる。状態遷移グラフとは形式的には、ＧＵＩ状態の集合と状態遷移の集合の対＜Ｓ，Ｔ＞で表現する。状態遷移グラフを図形式で表現するとき、集合Ｓに含まれる状態をノードで表現し、状態遷移はノード間の有向エッジとして表現する。すなわち、Ｔに含まれる遷移において操作前の状態と対応するノードから操作後の状態と対応するノードへエッジを引く。さらにエッジには遷移のＧＵＩ要素をラベルとして記述する。図８のＧＵＩの状態集合Ｓと状態遷移Ｔの状態遷移グラフの図形式を図９に示す。図中のエッジで先がノードを示していないもの、例えばノードｓ0のラジオボタン２やボタン１というラベルのエッジは、操作後の状態がＴＢＤである状態遷移を意味している。
【００１７】
このように自動操作処理を継続していくと、表示されているＧＵＩ状態ｓにおいて未操作のＧＵＩ要素が存在しない場合がある。もしこのとき、他のＧＵＩの状態ｓ’に未操作のＧＵＩ要素が存在するならば、自動操作によって状態ｓから状態ｓ’にＧＵＩを遷移させ、未操作のＧＵＩ要素を操作する必要がある。例えば、表示されているＧＵＩの状態がｓ1だった場合、図９の状態遷移グラフが示すようにｓ1には未操作の状態遷移が存在しない。よって、例えば未操作の状態遷移が存在する状態ｓ2にＧＵＩを遷移させる必要がある。
【００１８】
非特許文献２では状態ｓから状態ｓ’にＧＵＩを遷移させるために、実行パスを利用する。実行パスとは、上記処理による一連の自動操作によって発生した状態遷移の有限列のことである。例えば発生した状態遷移がｔ1，ｔ2，ｔ3，…，ｔnであるならば、実行パスはｔ1ｔ2ｔ3…ｔnと表現できる。非特許文献２では、初期のＧＵＩ状態から自動操作によってアプリケーションが終了するまでの状態遷移列を１つの実行パスとして保存する（再びアプリケーションが再起動されて自動操作された場合には別の実行パスとして保存する）。このように蓄積された実行パスの集合からパス（部分的な状態遷移列）ｔi…ｔjを抽出する。ただし、ｔiの操作前の状態はｓで、ｔjの操作後の状態はｓ’でなければならない。さらに、任意の１≦ｉ≦ｎ−１に対して、状態遷移ｔiの操作後の状態とｔi+1の操作前の状態が等しい必要がある。例えば、状態ｓ1からｓ2へのパスは（ｓ1，ラジオボタン２，ｓ2）となる。パスの状態遷移ｔiからｔjまでのＧＵＩ要素を順次自動操作することでＧＵＩの状態をｓ’に遷移させることができる。非特許文献２は前述までの処理により非特許文献１よりも精密な状態遷移グラフを取得することができる。
【００１９】
非特許文献２では、自動操作の過程で出現するＧＵＩの状態に対して、網羅的にＧＵＩ要素を操作することで精密な状態遷移グラフを取得する。よって状態遷移グラフを得るまでの処理時間は出現するＧＵＩの状態の数に対して比例増加する。出現しうるＧＵＩの状態数は、ＧＵＩを構成するＧＵＩ要素の数に対して指数的に増加するため、結果として処理時間はＧＵＩ要素の数に対して指数増加し、ＧＵＩ要素の数が多いアプリケーションに適用するためには対策が必要となる。非特許文献２ではこの処理時間増加への対応として、自動操作処理の並行化が述べられている。図１０で自動操作の並行化を説明する。並行化するためには、まずテスト対象アプリケーションが動作する端末を複数用意する。非特許文献２の自動操作装置は、用意された複数の端末からアプリケーションのＧＵＩ状態を取得し、それぞれの端末のＧＵＩ状態に合わせて未操作のＧＵＩ要素を自動操作する。近年のＣＰＵやＯＳはマルチスレッディングに対応しており複数の端末のＧＵＩ状態取得や自動操作を並行処理することが可能である。このようにテスト対象アプリケーションが動作する端末を増加させることで、網羅的な自動操作を並行化し処理時間を短縮化することができる。
【先行技術文献】
【非特許文献】
【００２０】
【非特許文献１】A. Memon, I. Banerjee, A. Nagarajan, "GUI Ripping: Reverse Engineering of Graphical User Interfaces for Testing", In proc. of the 10th Working Conference on Reverse Engineering (WCRE 2003), IEEE, pp.260-269, 2003
【非特許文献２】中島、増田、高橋、“網羅的な操作と操作ログ検索によるＧＵＩテストの自動化手法の提案”、信学技法、Vol.112、No.378、電子情報通信学会、pp.13-18、2013
【発明の概要】
【発明が解決しようとする課題】
【００２１】
非特許文献２の並行化の問題点は、このような単純な方式の並行化では、端末数の増加に対して、処理時間の短縮が実現できない点である。その原因は前述の表示されているＧＵＩ状態ｓで未操作のＧＵＩ要素が存在しない場合の処理にある。非特許文献２では、このとき、状態ｓから未操作のＧＵＩ要素が存在する状態ｓ’へのパスをそれまで蓄積した実行パスから抽出する。例えば、表示されているＧＵＩ状態がｓである端末が複数ある場合に、マルチスレッディングで単純に自動操作処理を並行化すると、それらの端末に対して同一のパスが抽出されることになる。同一のパスは最終的な目的状態である未操作のＧＵＩ要素が存在する状態ｓ’も同じであるため、それぞれの端末のＧＵＩをパスに沿って自動操作すると、それぞれＧＵＩの状態がｓ’になる。状態ｓ’に未操作のＧＵＩ要素が十分存在すれば、それぞれの端末で未操作のＧＵＩ要素を操作することが可能である。しかし、もし未操作のＧＵＩ要素が十分に存在しなければ、いくつかの端末では未操作のＧＵＩ要素を操作することができるが、残りの端末では未操作のＧＵＩ要素が存在しなくなってしまい、パスの抽出やパスに沿っての自動操作処理が無駄となってしまう。
【００２２】
例えば、図９で具体的に説明する。今、並行化のためにテスト対象アプリケーションが動作する端末が３端末存在し、それぞれの端末のテスト対象アプリケーションが状態ｓ1であると仮定する。このとき、単純に処理をマルチスレッディングで処理すると未操作のＧＵＩ要素が存在する状態へのパスとして、それぞれの端末に対してパス（ｓ1，ラジオボタン２，ｓ2）が抽出される。しかし状態ｓ2には図９が示すように２つしか未操作のＧＵＩ要素は存在しない。したがって、それぞれの端末でパスに沿って自動操作してＧＵＩを状態ｓ2にしても、２つの端末では未操作のＧＵＩ要素を自動操作できるが、残り１つの端末では未操作のＧＵＩ要素が存在しないことになってしまい無駄な処理となる。このように端末数を増加させても、未操作のＧＵＩ要素を自動操作できない端末が増加してしまい、処理時間が短縮化できない。
【００２３】
本発明は上記事情に鑑みてなされたものであり、その目的とするところは、ＧＵＩの状態に対して網羅的に自動操作する技術において、複数のテスト対象アプリケーションが動作する端末を多数用意して並行的に自動操作する場合の、ＧＵＩの状態遷移グラフの生成の処理時間を短縮化することにある。
【課題を解決するための手段】
【００２４】
上記目的を達成するために、本願発明は、複数の端末上で動作するテスト対象アプリケーションのグラフィカルユーザインタフェース（ＧＵＩ）の状態を網羅的に自動操作する方法であって、記憶手段に予め記憶した起動ファイルを複数の端末でそれぞれ実行することにより各端末においてテスト対象アプリケーションを起動させる第１のステップを備え、更に、各端末に対してそれぞれ、端末の表示手段に表示されたテスト対象アプリケーションのＧＵＩ状態を取得する第２のステップと、表示されたＧＵＩの状態がこれまで取得したことのない場合に該ＧＵＩ状態において操作可能なすべてのＧＵＩ要素を取得する第３のステップと、テスト対象アプリケーションが終了した状態であった場合に、起動ファイルを実行することでテスト対象アプリケーションを再起動し、表示されたＧＵＩの状態に対して再帰的に処理を継続する第４のステップと、表示されたＧＵＩの状態において未操作のＧＵＩ要素が存在する場合に、該ＧＵＩ要素を自動操作してテスト対象アプリケーションのＧＵＩを状態遷移させ、遷移後の状態に対して処理を再帰的に継続する第５のステップと、表示されたＧＵＩの状態において未操作のＧＵＩ要素が存在せず且つこれまで取得した他のＧＵＩの状態に未操作のＧＵＩ要素が存在する場合に、表示されたＧＵＩの状態から未操作のＧＵＩ要素が存在するＧＵＩの状態（目標状態）へ到達するパスを抽出し、該目標状態に状態を遷移させたときに未操作のＧＵＩ要素が確実に存在するかを判定し、存在しないと判定しない場合には他の目標状態へパスを抽出して前記判定処理を再度行う第６のステップと、抽出されたパスに沿ってＧＵＩ要素を自動操作することでＧＵＩを未操作のＧＵＩ要素が存在する状態に変化させ、変化した状態に対して処理を再帰的に継続する第７のステップと、取得したすべてのＧＵＩの状態において未操作のＧＵＩ要素が存在しない場合に処理を終了させる第８のステップとを、各端末間で並行して処理することを特徴とする。
【００２５】
本発明の好適な態様の一例としては、前記第６のステップにおいては、目標状態までのパスを抽出した際に、自処理に係る端末において該目標状態まで状態を遷移させることを示す目標状態管理情報を各並行処理で共有の記憶手段に記憶するとともに、該記憶処理から判定処理までの間は目標状態管理情報の記憶手段への書き込み処理を並行処理間で排他制御することを特徴とするものが挙げられる。
【００２６】
さらに、本発明の好適な態様の一例としては、目標状態管理情報は端末の識別子と目標状態の組からなり、前記第１のステップの後に各端末について端末の識別子と空値の組を目標状態管理情報として記憶手段に記憶し、前記第６のステップにおいては、目標状態までのパスを抽出した際に目標管理情報を自処理に係る端末の識別子と目標状態の組に書き換え、目標管理情報として自処理に係る目標状態と同じ目標状態を持つ端末の識別子の数と、該目標状態における未操作のＧＵＩ要素の数とに基づき前記判定処理を行うことを特徴とするものが挙げられる。
【発明の効果】
【００２７】
本発明によれば、ＧＵＩの状態に対して網羅的に自動操作する技術において、複数のテスト対象アプリケーションが動作する端末を多数用意して並行的に自動操作する場合の、ＧＵＩの状態遷移グラフの生成の処理時間を短縮化することができる。
【図面の簡単な説明】
【００２８】
【図１】ＧＵＩの一例
【図２】図１の初期のＧＵＩの各要素の状態の例
【図３】ＧＵＩの状態遷移の一例
【図４】ＧＵＩの状態遷移の一例
【図５】ＧＵＩの状態遷移の一例
【図６】ＧＵＩの状態遷移の一例
【図７】ＧＵＩの状態遷移の一例
【図８】ＧＵＩの状態遷移の一例
【図９】状態遷移グラフの一例
【図１０】自動操作の並行化を説明するシステム構成図
【図１１】本実施の形態に係るグラフィカルユーザインタフェースの状態装置の構成図
【図１２】目標状態管理部のデータの一例
【図１３】網羅操作制御部の動作を説明するフローチャート
【図１４】網羅操作制御部の動作を説明するフローチャート
【図１５】網羅操作制御部の動作を説明するフローチャート
【図１６】網羅操作制御部の動作を説明するフローチャート
【図１７】網羅操作制御部の動作を説明するフローチャート
【図１８】目標状態管理部のデータの一例
【図１９】実施例に係る自動操作装置のシステム構成例
【図２０】実施例に係る目標状態管理部のデータの一例
【図２１】実施例に係る目標状態管理部のデータの一例
【図２２】実施例に係る目標状態管理部のデータの一例
【発明を実施するための形態】
【００２９】
本発明の一実施の形態に係るグラフィカルユーザインタフェースの網羅的な並行化自動操作方法を実施する自動操作装置について図１１を参照して説明する。ここでは周知のコンピュータ上に実現した例を示すもので、図中、１は入力装置、２はコンピュータ本体、３は記憶装置、４は表示装置である。
【００３０】
入力装置１は、キーボード、マウス等からなり、ユーザがコンピュータ本体２に所定の情報、ここでは起動ファイルを入力できる。また入力装置１は、テスト対象アプリケーションが動作する端末の識別子を登録、削除できる。端末の識別子はホスト名やあるいはＩＰネットワークで接続された端末であればＩＰアドレス等でよい。この端末の識別子が入力装置から登録された場合は記憶装置３に追加され、入力装置から削除される場合は記憶装置３から削除される。
【００３１】
記憶装置３は、入力装置１から入力された端末の識別子のリストと、網羅操作制御部５が実施する図１３〜図１７の手続きの出力結果であるＧＵＩ状態の集合Ｓと状態遷移の集合Ｔ、実行パスの集合Ｐを記憶保存するとともに、各種処理において必要な情報の一時記憶を行う装置である。なお後述するように、網羅操作制御部５による処理は、テスト対象アプリケーションを実行する端末毎にマルチスレッドで実行される。そして記憶装置３に記憶保存されるＧＵＩ状態の集合Ｓと状態遷移の集合Ｔ、実行パスの集合Ｐは、各スレッドで共有される共有リソースである点に留意されたい。また、各スレッドが該共有リソースのデータを追加・削除・参照する場合には、排他ロックをかけて同時に複数のスレッドが共有リソースに操作できないように制御する点にも留意されたい。
【００３２】
表示装置４は、液晶ディスプレイ、ＣＲＴ等画像表示装置等からなり、記憶装置３に保存されている端末の識別子のリストやＧＵＩ状態の集合Ｓと状態遷移の集合Ｔ、実行パスの集合Ｐの内容を表示することができる。また状態遷移グラフ＜Ｓ，Ｔ＞を図形式で表示することができる。
【００３３】
コンピュータ本体２は、各装置を制御するとともに、網羅操作制御部５、ＧＵＩ状態取得部６、ＧＵＩ自動操作部７、パス集合探索部８、目標状態管理部９を構成する。なお、コンピュータ本体２の各部は、ハードウェアにより構成してもよいし、コンピュータ本体２にプログラムをインストールすることによって構成してもよい。なお該プログラムは、記録媒体に記録することも、ネットワークを通して提供することも可能である。
【００３４】
網羅操作制御部５は、テスト対象アプリケーションの全てのＧＵＩの状態を網羅的に取得する処理を制御するものである。網羅操作制御部５は、入力装置１より与えられた起動ファイルを、ネットワーク等によりコンピュータ本体２と接続された各端末で実行することで該端末においてテスト対象アプリケーションを起動し、ＧＵＩ状態取得部６によりＧＵＩの状態を取得し、ＧＵＩ自動操作部７により未操作のＧＵＩ要素を自動操作する。この自動操作によってＧＵＩ状態が遷移するため、遷移したＧＵＩの状態に対してこれらの処理を再帰的に繰り返す。該網羅操作制御部５による処理は、テスト対象アプリケーションを実行する端末毎にマルチスレッドで実行される。網羅操作制御部５の動作については後述する。
【００３５】
ＧＵＩ状態取得部６は、ネットワーク等によりコンピュータ本体２と接続された各端末で動作するテスト対象アプリケーションのＧＵＩの状態を取得することができる。ＧＵＩ状態取得部６は、網羅操作制御部５が図１３〜図１７の手続きを実施するにあたって、ステップＳ５、Ｓ６９６、Ｓ６９９５４において呼び出される。
【００３６】
ＧＵＩ自動操作部７は、網羅操作制御部５が指定するＧＵＩ要素をネットワーク等によりコンピュータ本体２と接続された各端末で動作するテスト対象アプリケーションのＧＵＩに対して自動操作することができる。ＧＵＩ自動操作部７は、網羅操作制御部５が図１３〜図１７の手続きを実施するにあたって、ステップＳ６９５、Ｓ６９９５３において呼び出される。
【００３７】
パス集合探索部８は、網羅操作制御部５が指定するＧＵＩの状態から未操作のＧＵＩ要素が存在する状態へのパスを探索する。パス集合探索部８は、網羅操作制御部５が図１３〜図１７の手続きを実施するにあたって、ステップＳ６９９１で呼び出される。このステップでは実行パスの集合からパスを探索すると記載しているが、例えば、それまで蓄積した状態遷移グラフ＜Ｓ，Ｔ＞上からも同様のパスを探索してもよい。実行パスや状態遷移グラフからのパスの探索方法は公知の技術である。
【００３８】
目標状態管理部９は、記憶装置３に登録された端末の識別子と目標状態のペアをリスト形式で保持する。目標状態管理部９で保持するリストのデータ構造の一例を図１２に示す。図１２は、端末の識別子がＩＰアドレスであり端末数が３のときであり、各端末の目標状態が空値である場合の一例である。網羅操作制御部５が図１３〜図１７の手続きをコンピュータ本体２と接続された端末ごとにマルチスレッドで実行する際に、各スレッドがステップＳ６９９１で発見したパスｐの最後の状態遷移の操作後の状態を、ステップＳ６９９３にて該当端末の識別子の目標状態として登録する。ここで、目標状態管理部９で保持するリストは、記憶装置３に記憶保存されるＧＵＩ状態の集合Ｓと状態遷移の集合Ｔ、実行パスの集合Ｐと同様に、各スレッドで共有される共有リソースである点に留意されたい。また、各スレッドが該共有リソースのデータを追加・削除・参照する場合には、排他ロックをかけて同時に複数のスレッドが共有リソースに操作できないように制御する点にも留意されたい。
【００３９】
網羅操作制御部５は、図１３の手続きを実施する。図１３の手続きでは、記憶装置３に登録された各端末に対して、入力装置１より与えられた起動ファイルを実行することで、それぞれの端末でテスト対象アプリケーションを起動し（ステップＳ１）、初期のＧＵＩ画面をそれぞれの端末に表示する。さらにＧＵＩの状態の集合Ｓ、状態遷移の集合Ｔ、実行パスの集合Ｐを空集合に設定する（ステップＳ２）。その後、記憶装置３に登録された端末の識別子と目標状態のペアを目標状態管理部９に登録する。このとき目標状態は空値で登録する。なお前述のように、集合Ｓ，Ｔ，Ｐおよび目標状態管理部９に登録される情報（端末の識別子と目標状態のペア）はマルチスレッディングで並行的に自動操作処理を実施する際の共有リソースとなり、それぞれのスレッドから同じ情報にアクセスする。また、これ以降の処理は端末ごとにマルチスレッドで処理されるため、集合Ｓ，Ｔ，Ｐ、目標状態管理部９に登録される情報以外の変数等はスレッドごとに用意され、各スレッドで独自の値が代入されることに注意されたい。また、スレッドが前述の共有リソースにデータを追加・削除・参照する場合には、排他ロックをかけて同時に複数のスレッドが共有リソースに操作できないように制御する。次いで実行パスπに、長さ０の列を意味する定数εを設定する（ステップＳ４）。ＧＵＩ状態取得部６を利用して現在表示されているＧＵＩの状態を取得し、これをｓ0とおく。また現在の状態を表す変数ｓにｓ0を代入する（ステップＳ５）。最後に図１４の手続きを実施する（ステップＳ６）。
【００４０】
図１４の手続きにおいては、まず、現在の状態ｓが状態の集合Ｓに含まれるか調べる（ステップＳ６１）。もし含まれない場合には、現在の状態ｓを集合Ｓに追加する（ステップＳ６２）。さらに現在の状態ｓから操作可能なＧＵＩ要素の集合Ｅを抽出する（ステップＳ６３）。そして集合Ｅに含まれるＧＵＩ要素をｅとするとき、すべてのＧＵＩ要素に対して、状態遷移（ｓ，ｅ，ＴＢＤ）を状態遷移の集合Ｔに追加する（ステップＳ６４，Ｓ６５，Ｓ６６）。このような状態遷移の追加処理が完了した場合、あるいは、ステップＳ６１にて現在の状態ｓが状態の集合Ｓに含まれている場合は、状態遷移の集合Ｔに操作後の状態がＴＢＤである状態遷移が存在しないか調べる（ステップＳ６７）。存在しない場合は、網羅的な自動操作が完了したことになるため、それまで蓄積したＧＵＩ状態の集合Ｓ、状態遷移の集合Ｔ、実行パスの集合Ｐを記憶装置に出力し（ステップＳ６８）、手続きを終了する。ステップＳ６７にてＴＢＤである状態遷移が存在する場合は、図１５の手続きを実行する（ステップＳ６９）。
【００４１】
図１５の手続きにおいては、まずアプリケーションが終了していて、ＧＵＩが何も表示されていないか調べる（ステップＳ６９１）。もし終了している場合には、起動ファイルを使ってアプリケーションを再起動する（ステップＳ６９２）。さらに、実行パスπを実行パスの集合Ｐへ追加し、πに長さが０の列を意味する定数εを代入し、現在の状態を示す変数ｓに初期状態ｓ0を代入する（ステップＳ６９３）。そして図１４の手続きのステップＳ６１に戻る。もしステップＳ６９１でアプリケーションが終了していない場合には、変数ｓの示す現在の状態において未操作のＧＵＩ要素が存在するか調べる。すなわち状態遷移の集合Ｔの中に操作前の状態がｓで、操作後の状態がＴＢＤであるような状態遷移ｔを探し出す（ステップＳ６９４）。状態遷移ｔのＧＵＩ要素をｅとすれば、ｔ＝（ｓ，ｅ，ＴＢＤ）と表現することができる。このような状態遷移ｔが存在する場合、ＧＵＩ自動操作部７によってｔのＧＵＩ要素ｅを自動操作し（ステップＳ６９５）、ＧＵＩを遷移させる。さらに遷移したＧＵＩの状態をＧＵＩ状態取得部６によって取得し、変数ｓ’に代入する（ステップＳ６９６）。この処理によって状態遷移ｔの操作後の状態が決定するため、ｔを（ｓ，ｅ，ｓ’）で置き換える（ステップＳ６９７）。実行パスπの末尾に状態遷移ｔを追加し、現在の状態を示す変数ｓをｓ’に置き換える（ステップＳ６９８）。そして図１４の手続きのステップＳ６１へ戻る。もし、ステップＳ６９４にて、状態遷移ｔが発見できない場合には、図１６の手続きを実施する（ステップＳ６９９）。
【００４２】
図１６の手続きにおいては、パス集合探索部８によって実行パスの集合Ｐ∪｛π｝から同様のパスｐを探索する（ステップＳ６９９１）。次いでパスｐが発見できたか調べる（ステップＳ６９９２）。もし発見できなければ、変数ｓの示す状態（ただし、アプリケーション再起動後の初期状態ではない）から状態ｓ’へＧＵＩを遷移することができない。よってアプリケーションを再起動して手続きを継続するために、図１５のステップＳ６９２に戻る。もしパスｐが発見できた場合には、パスｐの最後の状態遷移（ｓl，ｅl，ｓl‘）とし、目標状態管理部９で管理されている端末の識別子と目標状態のペアを、当該端末の識別子と状態ｓl’で書き換える（ステップＳ６９９３）。例えば、目標状態管理部９の端末の識別子と目標状態のペアが図１２の状態であったときに、今、端末の識別子１９２．１６８．１．１の端末に対するスレッドでこの処理が実行された場合、１９２．１６８．１．１と空値のペアを、１９２．１６８．１．１と状態ｓl’のペアで書き換え、図１８の状態になる。その後、目標状態管理部９の目標状態が状態ｓl’であるペアの数をＮ、集合Ｔの操作前の状態がｓl’かつ操作後の状態が定数ＴＢＤである状態遷移の数をＮTBDとし（ステップＳ６９９４）、Ｎ≦ＮTBDを判定する（ステップＳ６９９５）。もしＮ≦ＮTBDである場合は、パス集合探索部８によって発見したパスを利用して、状態ｓl’への遷移しようとする端末数（Ｎ）が、状態ｓl’の未操作のＧＵＩ要素の数（ＮTBD）以下であることになる。これは、パスに沿って自動操作して状態ｓl’へ到達したときに、確実に未操作のＧＵＩ要素が存在し、未操作のＧＵＩ要素を自動操作することができる。よって図１７の手続きに進む。このような処理を実施することで、非特許文献２の問題点を解決することができる。もしＮ＞ＮTBDである場合は、このまま状態をｓl’に変化させても未操作のＧＵＩ要素が存在しない場合があるため、ステップＳ６９９３で目標状態管理部９に対して書き換えた端末の識別子と状態ｓl’のペアを、当該端末の識別子と空値とのペアに書き換える（ステップＳ６９９６）。そして再度ステップＳ６９９１へと戻り、別のパスを探索する。なお前述のステップＳ６９９３、Ｓ６９９４、Ｓ６９９５の一連の処理を実施するときは、目標状態管理部９の共有リソースである端末の識別子と目標状態のペアへの排他ロックを個々の処理で解除せず、これらのすべての処理が完了したときに排他ロックを解除する。
【００４３】
図１７の手続きでは、まずはパスｐの長さが０でないか調べる（ステップＳ６９９５１）。０でなければ、パスｐの先頭の状態遷移をｔ＝（ｓt，ｅt，ｓt’）として取り出し（ステップＳ６９９５２）、ＧＵＩ自動操作部７がＧＵＩ要素ｅtを操作する（ステップＳ６９９５３）。それによってＧＵＩが遷移するためＧＵＩ状態取得部６を利用してＧＵＩの状態を取得し、現在の状態を示す変数ｓに代入する（ステップＳ６９９５４）。さらにパスπの末尾に状態遷移（ｓt，ｅt，ｓ）を追加し、状態遷移の集合Ｔへ状態遷移（ｓt，ｅt，ｓ）を追加する（ステップＳ６９９５５）。このとき変数ｓの示す現在の状態がＧＵＩ状態の集合Ｓに含まれている、あるいは、その状態において未操作のＧＵＩ要素が存在するか調べる（ステップＳ６９９５６）。もしこの条件に合致しない場合には、ステップＳ６９９５１に戻って、パスｐの次の先頭を取り出しステップＳ６９９５１からＳ６９９５６を実行する。パスｐに含まれていたすべての状態遷移に対してステップＳ６９９５１からＳ６９９５６を実行し、ステップＳ６９９５１のステップでパスの長さが０になっていたら、パスｐに沿ってＧＵＩ要素を自動操作しても、未操作のＧＵＩ要素を持つ状態へ到達できないことになる。よって図１６のステップＳ６９９３で目標状態管理部９に対して書き換えた端末の識別子と状態ｓl’のペアを、当該端末の識別子と空値とのペアに書き換える（ステップＳ６９９５７）。そしてテスト対象アプリケーションを再起動し処理を継続するために図１６のステップＳ６９２へ戻る。
【００４４】
もしパスｐの先頭の状態遷移ｔ＝（ｓt，ｅt，ｓt’）に対してステップＳ６９９５１からＳ６９９５６を実行し、ＧＵＩ要素ｅtを操作してＧＵＩの状態が集合Ｓに含まれていない、あるいは、そのＧＵＩの状態において未操作のＧＵＩ要素が存在する場合には、図１６のステップＳ６９９３で目標状態管理部９に対して書き換えた端末の識別子と状態ｓl’のペアを、当該端末の識別子と空値とのペアに書き換える（ステップＳ６９９５８）。そして図１４のステップＳ６１に戻り、再帰的に未操作のＧＵＩ要素を自動操作する。
【００４５】
このように本発明により、ＧＵＩの状態に対して網羅的に自動操作する技術において、複数のテスト対象アプリケーションが動作する端末を用意して並行的に自動操作するときに、それぞれの端末で未操作のＧＵＩ要素を確実に自動操作させることができ、端末数の増加に応じてＧＵＩの状態遷移グラフ生成の処理時間を短縮させることが可能になる。
【００４６】
なお、上述した実施形態では、網羅操作制御部５、ＧＵＩ状態取得部６、ＧＵＩ自動操作部７、パス集合探索部８、目標状態管理部９をコンピュータ本体２上で実現した例を示したが、ハードウェアで実現してもよい。またこれら各装置が、適切な通信路で相互に接続された複数のハードウェア上に分散して存在し、相互に通信し合いながら実行することもできる。さらに、テスト対象アプリケーションを動作させる複数の端末はそれぞれ別個のハードウェアとして用意してもよいし、仮想端末や仮想ＯＳ等を利用して複数の端末を１つ又は複数のハードウェア上に仮想的に用意するようにしてもよいし、さらには本発明の自動操作装置と同一のハードウェア上に実装するようにしてもよい。すなわち、本発明の要旨の範囲内においては実装形態は不問である。
【実施例】
【００４７】
本発明による網羅的なＧＵＩの自動操作の実施例を示す。ここでのテスト対象アプリケーションは図１のように画面遷移するものとする。また本実施例では、図１９に示すように、並行的に操作する端末数を３とし、各端末は自動操作装置としてのコンピュータ本体２とＩＰネットワークで接続されている。各端末のＩＰアドレスは、それぞれ１９２．１６８．１．１、１９２．１６８．１．２、１９２．１６８．１．３とする。
【００４８】
本発明では、まず入力装置１から図１のテスト対象アプリケーションを起動するファイル（スクリプト、バッチファイル）と各端末の識別子として１９２．１６８．１．１、１９２．１６８．１．２、１９２．１６８．１．３が入力され、記憶装置３に端末の識別子が追加される。
【００４９】
本発明では、網羅操作制御部５が図１３〜図１７の手続きを実施する。まず図１３のステップＳ１にて起動ファイルを実行し各端末上でテストアプリケーションを起動する。次いでステップＳ２でＧＵＩ状態の集合Ｓ、状態遷移の集合Ｔ、実行パスの集合を空集合で初期化する。ステップＳ３では、目標状態管理部９に記憶装置３に記憶された各端末の識別子と空値のペアを登録する。その登録内容を図１２に示す。これ以降の手続きは、端末ごとにマルチスレッディングによって並行的に実行される。
【００５０】
本実施例では、網羅操作制御部５が図１３〜図１７の手続きを各端末で並行的に実施した結果、集合Ｓ、Ｔそれぞれが図８の状態であると仮定する。また、各端末のテストアプリケーションの表示されているＧＵＩの状態が各々ｓ1であると仮定する。このとき、図８が示すように集合Ｔの操作前の状態がｓ1である状態遷移で遷移後の状態がＴＢＤであるもの、すなわち未操作のＧＵＩ要素が存在しない。したがって、それぞれの端末に対するスレッドは、図１６のステップＳ６９９１に進み、状態ｓ1から未操作のＧＵＩ要素を持つ状態へのパスを探索する。各スレッドは同じアルゴリズムでパスを探索するため、ここでは各スレッド同じパスが取得でき、ここではそのパスを（ｓ1，ラジオボタン２，ｓ2）とする。
【００５１】
もし、このまま各スレッドが図１８のステップＳ６９９５１へと進み、このパスに沿って自動操作を実施すると、表示されるＧＵＩの状態が３端末ともｓ2になる。図８の状態遷移の集合Ｔが示すように操作前の状態がｓ2であり、操作後の状態がＴＢＤであるような遷移は２つしか存在しない。よって、例えば１９２．１６８．１．１と１９２．１６８．１．２の端末のＧＵＩ状態が１９２．１６８．１．３の端末より先にｓ2へと変化した場合、１９２．１６８．１．１と１９２．１６８．１．２の端末は未操作のＧＵＩ要素であるラジオボタン２とボタン１を操作できるが、１９２．１６８．１．３の端末がｓ2において未操作のＧＵＩ要素を自動操作しようとしても、該当のＧＵＩ要素が存在ないため、パスに沿って自動操作した処理が無駄になる。
【００５２】
そこで本発明では、パスに沿って自動操作する前に、図１６のステップＳ６９９３を実行する。すなわちパス（ｓ1，ラジオボタン２，ｓ2）の最後の状態遷移の操作後の状態ｓ2を、端末の識別子とのペアとして目標状態管理部に登録する。マルチスレッディング処理は各スレッドの処理を同時に実施するわけでなく、厳密には逐次的に処理する。よって１９２．１６８．１．１に対するスレッドが最初にステップＳ６９９３を実行すると、目標状態管理部９の端末の識別子と目標状態のペアのリストは図２０になる。目標状態管理部９の端末の識別子と目標状態のペアへの排他ロックは解除しないため、他のスレッドはステップＳ６９９３を実行できずに待機することになる。よって１９２．１６８．１．１に対するスレッドは、さらにステップＳ６９９４を実行する。目標状態管理部９の目標状態が状態ｓ2であるペアの数Ｎ＝１，状態ｓ2の未操作のＧＵＩ要素の数ＮTBD＝２なので、この場合ステップＳ６９９５においてＮ≦ＮTBDの判定を満たし、図１７のステップＳ６９９５１のステップへと進む。結果としてパスに沿って自動操作することで、未操作のＧＵＩ要素を自動操作することができる。１９２．１６８．１．１のスレッドが図１７のステップＳ６９９５１へと進んだ時点で、目標状態管理部９の端末の識別子と目標状態のペアへの排他ロックが解除される。
【００５３】
次に１９２．１６８．１．２のスレッドがステップＳ６９９３を実行すると目標状態管理部９の端末の識別子と目標状態のペアのリストは図２１（ａ）もしくは（ｂ）になる。（ａ）は１９２．１６８．１．１のスレッドが状態ｓ2において未操作のＧＵＩ要素をまだ操作していない状態の場合である。もし１９２．１６８．１．１のスレッドが状態ｓ2において未操作のＧＵＩ要素を操作していれば、（ｂ）となる。（ａ）の場合は、１９２．１６８．１．２のスレッドはステップＳ６９９４にて目標状態管理部９の目標状態が状態ｓ2であるペアの数Ｎ＝２，状態ｓ2の未操作のＧＵＩ要素の数ＮTBD＝２となるため、ステップＳ６９９５においてＮ≦ＮTBDの判定を満たし、図１７のステップＳ６９９５１へと進む。結果としてパスに沿って自動操作することで、未操作のＧＵＩ要素を自動操作することができる。また（ｂ）の場合でも、ステップＳ６９９４にて目標状態管理部９の目標状態が状態ｓ2であるペアの数Ｎ＝１，１９２．１６８．１．１のスレッドが状態ｓ2において未操作のＧＵＩ要素を操作しているので状態ｓ2の未操作のＧＵＩ要素の数ＮTBD＝１となり、ステップＳ６９９５においてＮ≦ＮTBDの判定を満たし、図１７のステップＳ６９９５１へと進む。結果として、結果としてパスに沿って自動操作することで、１９２．１６８．１．２のスレッドも未操作のＧＵＩ要素を自動操作することができる。１９２．１６８．１．２のスレッドが図１７のステップＳ６９９５１へと進んだ時点で、目標状態管理部９の端末の識別子と目標状態のペアへの排他ロックが解除される。
【００５４】
最後に１９２．１６８．１．３のスレッドがステップＳ６９９３を実行すると目標状態管理部９の端末の識別子と目標状態のペアのリストは図２２になる。ただし、１９２．１６８．１．１、１９２．１６８．１．２のスレッドはまだ状態ｓ2で未操作のＧＵＩ要素を操作していないものとする。１９２．１６８．１．３のスレッドはステップＳ６９９４にて目標状態管理部９の目標状態が状態ｓ2であるペアの数Ｎ＝３，状態ｓ2の未操作のＧＵＩ要素の数ＮTBD＝２となるため、ステップＳ６９９５においてＮ≦ＮTBDの判定を満たさない。よって、ステップＳ６９９６へと進んで、目標状態管理部９の自身の端末の識別子１９２．１６８．１．３と目標状態ｓ2のペアを１９２．１６８．１．３と空値のペアに書き換える。このときの目標状態管理部９が管理する端末の識別子と目標状態のペアは図２１の（ａ）となる。そしてステップＳ６９９１へと戻り、別の未操作のＧＵＩ要素を持つ状態へのパスを再度探索する。
【００５５】
このように１９２．１６８．１．３の端末に対するスレッドは、未操作のＧＵＩ要素が存在しない可能性がある状態ｓ2へテスト対象アプリケーションのＧＵＩを遷移させることなく、確実に未操作のＧＵＩ要素が存在する状態へ遷移することが可能となる。結果として、網羅的な自動操作による状態遷移グラフの生成時間を短縮化できる。
【符号の説明】
【００５６】
１…入力装置、２…コンピュータ本体、３…記憶装置、４…表示装置、５…網羅操作制御部、６…ＧＵＩ状態取得部、７…ＧＵＩ自動操作部、８…パス集合探索部、９…目標状態管理部。
【図１】
2014232514.tif 000003
【図２】
2014232514.tif 000004
【図３】
2014232514.tif 000005
【図４】
2014232514.tif 000006
【図５】
2014232514.tif 000007
【図６】
2014232514.tif 000008
【図７】
2014232514.tif 000009
【図８】
2014232514.tif 000010
【図９】
2014232514.tif 000011
【図１０】
2014232514.tif 000012
【図１１】
2014232514.tif 000013
【図１２】
2014232514.tif 000014
【図１３】
2014232514.tif 000015
【図１４】
2014232514.tif 000016
【図１５】
2014232514.tif 000017
【図１６】
2014232514.tif 000018
【図１７】
2014232514.tif 000019
【図１８】
2014232514.tif 000020
【図１９】
2014232514.tif 000021
【図２０】
2014232514.tif 000022
【図２１】
2014232514.tif 000023
【図２２】
2014232514.tif 000024