JP5918102B2 - 解析システム、解析装置、解析方法及び解析プログラム - Google Patents

Description

本発明は、解析システム、解析装置、解析方法及び解析プログラムに関する。

近年、悪性な挙動を行うソフトウェア（以下、「マルウェア」と表記する場合がある）が増加している。未知のマルウェアを検知する手法として、ソフトウェアのプログラムコードを解析することも考えられるが、世の中に出回っているソフトウェアの数が膨大であることや、難読化されているプログラムコードが多いことなどの事情を踏まえると、実際にソフトウェアを実行させて挙動を監視する動的解析が有効であると考えられる。

D.Amalfitano, A.Fasolino, and P.Tramontana, "A GUI Crawling-based technique for Android Mobile Application Testing," In IEEE Fourth International Conference on Software Testing， Verification and Validation Workshops (ICSTW)，2011．

しかしながら、従来の動的解析では、ＧＵＩ（Graphical User Interface）操作を伴うソフトウェアにおけるプログラムコードの実行率（以下、「コードカバレッジ」と表記する場合がある）を効率的に高めることが困難であった。

具体的には、ソフトウェアのプログラムコードは、特定の入力を与えないと一部が実行されないものが多い。このため、高いコードカバレッジを得るためには、そのような特定の入力をプログラムコードに与えることを要する。特に、近年普及が進むスマートフォン（smartphone）上で動作するソフトウェアは、ＧＵＩを前提としたものが多いため、タップ操作やテキスト入力などのユーザイベントを模擬した入力を与えることを要する。しかし、ソフトウェア開発におけるテスト工程などとは異なり、不特定多数のソフトウェアを自動解析する状況においては解析対象ソフトウェアの仕様が明らかではないので、プログラムコードが網羅的に実行されるような適切なユーザイベントを事前に用意することは困難であった。このようなことから、従来の動的解析では、コードカバレッジを効率的に高めることが困難であった。

なお、ユーザイベントを無作為に発生させることも考えられるが、このような手法においても、コードカバレッジを高めることは困難であり、さらに効率的な動的解析であるとは言えなかった。

本願の開示する技術は、上記に鑑みてなされたものであって、ＧＵＩ操作を伴うプログラムの動的解析においてコードカバレッジを効率的に高めることができる解析システム、解析装置、解析方法及び解析プログラムを提供することを目的とする。

実施形態に係る解析システムは、実行装置と解析装置とを含む解析システムであって、前記実行装置は、ユーザ操作であるユーザイベントに応じて画面が遷移するアプリケーションを実行する実行部と、前記アプリケーションにより表示される画面毎に、当該画面の構造を示す構造情報を前記解析装置に提供する提供部とを備え、前記解析装置は、前記アプリケーションにおける画面遷移を示す遷移モデルを記憶する記憶部と、前記実行部により前記ユーザイベントが実行されるたびに、前記アプリケーションにより現に表示される現画面に関する構造情報を前記提供部から取得する構造情報取得部と、前記構造情報取得部により取得された構造情報に基づいて、構造情報が取得済みである既知の画面と前記現画面との類似性を判定し、当該既知の画面と類似していない現画面が追加されるように前記遷移モデルを更新する更新部と、前記遷移モデルのうち前記現画面に対応する画面において未実行のユーザイベントを前記実行部に実行させる実行制御部と、前記実行部により前記ユーザイベントが実行されるたびに、前記実行装置からログ情報を取得するログ取得部とを備えたことを特徴とする。

実施形態に係る解析システム、解析装置、解析方法及び解析プログラムは、ＧＵＩ操作を伴うプログラムの動的解析においてコードカバレッジを効率的に高めることができるという効果を奏する。

図１は、第１の実施形態に係る解析システムの構成例を示す図である。 図２は、第１の実施形態に係る解析装置による解析処理の一例を示す図である。 図３は、アプリケーションにより表示される画面の一例を示す図である。 図４は、第１の実施形態に係る構造情報を説明するための図である。 図５は、第１の実施形態に係る遷移モデル記憶部の一例を示す図である。 図６は、第１の実施形態に係る画面状態情報の一例を示す図である。 図７は、第１の実施形態に係る解析装置による解析処理手順を示すフローチャートである。 図８Ａは、第１の実施形態に係る解析処理の具体例を説明するための図である。 図８Ｂは、第１の実施形態に係る解析処理の具体例を説明するための図である。 図８Ｃは、第１の実施形態に係る解析処理の具体例を説明するための図である。 図９は、解析プログラムを実行するコンピュータを示す図である。

以下に、本願に係る解析システム、解析装置、解析方法及び解析プログラムの実施形態を図面に基づいて詳細に説明する。なお、この実施形態により本願に係る解析システム、解析装置、解析方法及び解析プログラムが限定されるものではない。

（第１の実施形態）
［解析システムの構成］
最初に、図１を用いて、第１の実施形態に係る解析システムについて説明する。図１は、第１の実施形態に係る解析システム１の構成例を示す図である。図１に例示した解析システム１には、実行装置１０と、解析装置１００とが含まれる。実行装置１０と解析装置１００とは、互いに通信可能に接続される。なお、実行装置１０と解析装置１００とは、図示しないネットワークを介して通信可能に接続されてもよい。

実行装置１０は、解析装置１００によって解析されるアプリケーションソフトウェア（以下、単に「アプリケーション」と表記する）の実行環境を提供するエミュレータである。かかる実行装置１０は、例えば、ＰＣ（Personal Computer）や携帯電話機やＰＤＡ（Personal Digital Assistant）等の物理マシンによって実現されてもよいし、仮想マシンによって実現されてもよい。

なお、実行装置１０は、解析装置１００によって解析されるアプリケーションとして、図１に示す解析対象アプリケーション１１を実行するものとする。解析対象アプリケーション１１は、解析装置１００によって解析されるアプリケーションであり、例えば、所定のサイト（サーバ装置）からダウンロード可能である。このような解析対象アプリケーション１１は、解析装置１００を利用する解析者が開発したものではなく、解析者にとって仕様が明らかでないものとする。

以下では、解析対象アプリケーション１１は、一例として、スマートフォンやタブレットＰＣ等において、Ａｎｄｒｏｉｄ ＯＳ（Operating System）上で動作するアプリケーションであるものとする。このような解析対象アプリケーション１１は、ＧＵＩを前提としたものが多く、ユーザ操作に応じて画面が遷移する。例えば、解析対象アプリケーション１１は、指や専用器具（例えば、タッチペン）等によって、タッチパネル式の表示画面が押下されることで各種ユーザ操作を受け付ける。ユーザ操作の一例としては、表示画面を指で押下して短時間で離すタップ操作や、表示画面を２回押下するダブルタップ操作や、表示画面を押下した状態で指をスライドさせるドラッグ操作や、表示画面を２本の指で押下した状態で双方の指を近づけたり遠ざけたりするピンチ操作等が挙げられる。また、解析対象アプリケーション１１は、表示画面が押下されるユーザ操作に限らず、スマートフォン等の実機に備えられているハードキーが押下されるユーザ操作も受け付ける。以下、解析対象アプリケーション１１が受け付けることが可能なユーザ操作を「ユーザイベント」と表記する場合がある。

解析装置１００は、実行装置１０に対して解析対象アプリケーション１１を実行させることにより、解析対象アプリケーション１１の動作を解析する。かかる解析装置１００は、例えば、ＰＣ（Personal Computer）等の物理マシンによって実現されてもよいし、仮想マシンによって実現されてもよい。

ここで、図２を用いて、解析装置１００による解析処理について簡単に説明する。図２は、第１の実施形態に係る解析装置１００による解析処理の一例を示す図である。第１の実施形態に係る解析装置１００は、図２に例示するように、画面の遷移モデルを生成しながら、生成した遷移モデルを巡回するようにユーザイベントを実行装置１０に対して模擬的に実行させる。このとき、解析装置１００は、解析対象アプリケーション１１の実行中に実際に表示され得る各画面をそれぞれ異なる画面として扱うのではなく、類似している画面群を同一の画面として扱う。

具体的には、解析装置１００は、実行装置１０にユーザイベントを模擬的に実行させた後に、解析対象アプリケーション１１により表示される画面の構造を解析することにより画面状態を取得する。ここでいう「画面状態」とは、画面構造の特徴的な部品（コンポーネント）等によって表される抽象的な画面構造を示す。すなわち、画面構造の特徴的な部品が同一である画面群は、画面状態も同一となる。

そして、解析装置１００は、図２に示すように、画面状態をノード（「接点」や「頂点」等とも呼ばれる）とし、かつ、ユーザイベントをエッジ（「枝」や「辺」等とも呼ばれる）としたグラフを遷移モデルとして生成する。このようにして、解析装置１００は、画面状態をノードとするグラフを生成し、生成したグラフに含まれる各画面状態において未実行のユーザイベント（エッジ）を実行装置１０に順次実行させる。

例えば、図２では、画面状態ｖ１１においてユーザイベント「ボタンＡをタップ」が実行された場合には、画面状態ｖ１１から遷移しないことを示している。ここで、実際には、ユーザイベント「ボタンＡをタップ」が実行されることで、異なる画面に遷移している可能性もある。しかし、第１の実施形態に係る解析装置１００は、抽象的な画面構造を示す「画面状態」により画面の遷移を判定するので、画面状態ｖ１１においてユーザイベント「ボタンＡをタップ」が実行された場合であっても、画面状態が同一である限り新たな画面状態をグラフに追加しない。

ここで、図３を用いて、類似している画面群を同一の画面として扱う理由について説明する。図３は、アプリケーションにより表示される画面の一例を示す図である。図３は、電卓のアプリケーションにおいて表示される画面例を示す。具体的には、図３（ａ）は、数値や演算子等を入力するための画面例を示す。また、図３（ｂ）は、図３（ａ）の状態において数値「１」が入力された状態の画面例を示す。また、図３（ｃ）は、図３（ａ）の状態において数値「２」が入力された状態の画面例を示す。また、図３（ｄ）は、図３（ａ）〜（ｃ）と異なる演算子を入力するための画面例を示す。

このような各種画面のうち、図３（ａ）〜（ｄ）の全てを異なる画面として扱った上で動的解析を行う場合、図３（ａ）〜（ｃ）のそれぞれにおいて、数値「０」〜「９」や小数点や各種演算子が入力される各種ユーザイベントを実行することとなる。しかし、図３（ａ）〜（ｃ）のそれぞれにおいて、同様のユーザイベントを発生させることは冗長であり、効率的なアプリケーションの動的解析であるとは言えない。

例えば、図３（ｂ）において演算子「＋」が入力された際の電卓アプリケーションの挙動と、図３（ｃ）において演算子「＋」が入力された際の電卓アプリケーションの挙動とは、同一である可能性が高い。また、図３（ｂ）及び（ｃ）では、数値「１」又は「２」が入力されている状態について示したが、これらの数値以外（例えば、「０．１」や「３」や「１０」や「１００」等）が入力されている各状態において、演算子「＋」が入力された際の電卓アプリケーションの挙動についても同一である可能性が高い。仮に、入力されている数値が異なる複数の画面をそれぞれ異なる画面として扱った上で動的解析を行う場合、ユーザイベントを過剰に実行させることとなり、動的解析にかかるコストを増大させることとなる。

そこで、第１の実施形態に係る解析装置１００は、類似している画面群を同一の画面として扱う。例えば、解析装置１００は、図３（ａ）〜（ｃ）に例示されている各画面については同一画面として扱い、図３（ｄ）の画面については図３（ａ）〜（ｃ）の各画面と異なる画面として扱う。この場合、解析装置１００は、図３（ａ）の状態で演算子「＋」を入力するユーザイベントを実行させた後には、図３（ｂ）や（ｃ）の状態で演算子「＋」を入力するユーザイベントを実行させない。なお、この例に限られず、解析装置１００は、図３（ｂ）及び（ｃ）を同一画面として扱い、図３（ａ）については、図３（ｂ）及び（ｃ）と異なる画面として扱ってもよい。

このように、第１の実施形態に係る解析装置１００は、抽象的な画面構造である画面状態をノードとするグラフ（遷移モデル）を生成しながら、各画面状態において未実行のユーザイベントを実行装置１０に実行させる。すなわち、解析装置１００は、類似する各画面を同一の画面状態として扱うことで、実質的に同一である複数の画面において同じようなユーザイベントが実行されることを防止できるので、効率的に解析対象アプリケーション１１を実行することができる。さらに、解析装置１００は、グラフのノードである各画面状態において未実行のユーザイベントを順次実行させるので、解析対象アプリケーション１１を網羅的に実行することができる。このようなことから、第１の実施形態に係る解析装置１００は、ＧＵＩ操作を伴うアプリケーションの動的解析においてコードカバレッジを効率的に高めることができる。以下、このような解析処理を実現する実行装置１０及び解析装置１００について、詳細に説明する。

［実行装置の構成］
まず、図１を用いて、上述した実行装置１０の構成について説明する。図１に例示するように、実行装置１０は、解析対象アプリケーション１１と、構造情報提供部１２と、実行部１３とを有する。解析対象アプリケーション１１については既に説明したのでここでは説明を省略する。

構造情報提供部１２は、解析対象アプリケーション１１により表示される画面毎に、かかる画面の構造を示す構造情報を解析装置１００に提供する。なお、構造情報提供部１２は、例えば「Ｗｉｎｄｏｗ Ｍａｎａｇｅｒ」等によって実現される。ここで、図４を用いて、構造情報について説明する。図４は、第１の実施形態に係る構造情報を説明するための図である。

図４に示したＧＵＩ画面Ｇ１０は、メールアドレスを入力するための画面である。かかるＧＵＩ画面Ｇ１０は、最上位のレイアウトＣ１１の中に、レイアウトＣ２１及びＣ２２が含まれる。また、レイアウトＣ２１には、ユーザとのインタラクションが行われるボタンＣ３１（ＯＫボタン）やボタンＣ３２（Ｃａｎｃｅｌボタン）が含まれる。また、レイアウトＣ２２には、「Ｅｎｔｅｒ ｅ−ｍａｉｌ：」といったテキストＣ３３や、ユーザとのインタラクションが行われるテキストボックスＣ３４が含まれる。

このようなＧＵＩ画面Ｇ１０を表すためのデータ構造として、一般的に、図４に右側に示すような木構造が用いられる。かかる木構造のうち、葉ノード（leaf node）には、実際にユーザとのインタラクションが行われるコンポーネント（ボタンＣ３１、ボタンＣ３２、テキストＣ３３、テキストボックスＣ３４等）が配置される。また、かかる木構造のうち、葉ノード以外の根ノード（root node）や内部ノード（internal node）には、レイアウト等に関するコンポーネント（レイアウトＣ１１、Ｃ２１、Ｃ２２等）が配置される。

構造情報提供部１２は、図４の右側に示されるような木構造により表される構造情報を解析装置１００に提供することとなる。なお、このような木構造により表される構造情報は、Ａｎｄｒｏｉｄアプリケーションにおける「Ｖｉｅｗ Ｈｉｅｒａｒｃｈｙ」や、Ｗｅｂ画面におけるＨＴＭＬ（HyperText Markup Language）等に該当する。

図１の説明に戻って、実行部１３は、解析対象アプリケーション１１を実行する。具体的には、実行部１３は、後述する解析装置１００のイベント実行制御部１３２による指示に従って、解析対象アプリケーション１１に対してユーザイベントを模擬的に実行する。ここでいう「模擬的に実行」とは、例えばユーザイベントがタップ操作である場合に、実行装置１０の表示画面に対して実際にタップ操作を行うのではなく、タップ操作が行われた際の処理を実行するよう解析対象アプリケーション１１に指示することを示す。なお、実行部１３は、例えば、Ａｎｄｒｏｉｄ ＯＳにおける「ａｄｂｄ（ａｄｂデーモン）」等によって実現される。

［解析装置の構成］
次に、上述した解析装置１００の構成について説明する。図１に示すように、解析装置１００は、遷移モデル記憶部１１０と、遷移モデル生成部１２０と、端末制御部１３０とを有する。

遷移モデル記憶部１１０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、又は、ハードディスク、光ディスク等によって実現される。かかる遷移モデル記憶部１１０は、解析対象アプリケーション１１における画面遷移を示す遷移モデルを記憶する。具体的には、第１の実施形態に係る遷移モデル記憶部１１０は、遷移モデルとして、図２に例示したようなグラフを記憶する。

ここで、図５に、第１の実施形態に係る遷移モデル記憶部１１０の一例を示す。図５に示した例では、遷移モデル記憶部１１０は、「ノード」、「エッジ」、「遷移先ノード」、「画面状態情報」、「ログ情報」といった項目を有する。なお、図５では、図２に例示したグラフに対応する各種情報が記憶されている例を示す。

「ノード」は、遷移モデルにおける画面状態を示す。「エッジ」は、遷移モデルにおけるユーザイベントを示す。「遷移先ノード」は、「ノード」によって示される画面状態において「エッジ」によって示されるユーザイベントが実行された場合における遷移先の画面状態を示す。「画面状態情報」は、画面状態を識別するための情報であって、「ノード」によって示される画面状態における画面構造の特徴的な部品（コンポーネント）によって表される抽象的な画面構造の情報を示す。「ログ情報」は、「ノード」によって示される画面状態において「エッジ」によって示されるユーザイベントが実行された際に、後述するログ取得部１３３によって取得されたログを示す。なお、画面状態情報や、ログ取得部１３３によって取得されるログについては後述する。

例えば、図５は、画面状態ｖ１１では、ユーザイベント「ボタンＡのタップ」、「ハードキーＸの押下」、「テキスト入力」が実行可能であることを示している。また、図５は、画面状態ｖ１１においてユーザイベント「ボタンＡのタップ」が実行された場合には、画面状態ｖ１１に遷移し、その際にログ取得部１３３によって取得されたログ情報が「ログＬ１１」であることを示している。また、図５は、画面状態ｖ１１を識別するための画面状態情報が「Ｉ１１」であることを示している。

図１の説明に戻って、遷移モデル生成部１２０は、構造情報提供部１２によって提供される構造情報を解析することにより、遷移モデルを生成する。かかる遷移モデル生成部１２０は、構造情報取得部１２１と、遷移モデル更新部１２２とを有する。

構造情報取得部１２１は、実行装置１０に対して構造情報を要求することにより、かかる要求に応答して構造情報提供部１２により提供される構造情報を取得する。具体的には、構造情報取得部１２１は、実行装置１０の実行部１３によりユーザイベントが実行されるたびに、端末制御部１３０による指示に従って解析対象アプリケーション１１により現に表示される画面（以下、「現画面」と表記する場合がある）に関する構造情報を構造情報提供部１２から取得する。例えば、構造情報取得部１２１は、「Ｗｉｎｄｏｗ Ｍａｎａｇｅｒ」等によって実現される構造情報提供部１２から、「Ｖｉｅｗ Ｈｉｅｒａｒｃｈｙ」のダンプを構造情報として取得する。

遷移モデル更新部１２２は、構造情報取得部１２１によって取得された構造情報に基づいて遷移モデルを生成し、遷移モデル記憶部１１０に記憶されている遷移モデルを更新する。具体的には、遷移モデル更新部１２２は、構造情報取得部１２１によって取得された構造情報から画面状態情報を生成する。そして、遷移モデル更新部１２２は、生成した画面状態情報が、遷移モデル記憶部１１０に記憶されているか否かを判定する。これにより、遷移モデル更新部１２２は、構造情報が取得済みである既知の画面と現画面との類似性を判定することとなる。

そして、遷移モデル更新部１２２は、既知の画面と類似していない現画面が遷移モデルに追加されるように遷移モデル記憶部１１０を更新する。具体的には、遷移モデル更新部１２２は、現画面の画面状態情報を遷移モデル記憶部１１０の「ノード」や「遷移先ノード」に登録する。

ここで、図６を用いて、遷移モデル更新部１２２によって生成される画面状態情報について説明する。図６は、第１の実施形態に係る画面状態情報の一例を示す図である。上記の通り、実行装置１０の構造情報提供部１２によって提供される各画面の構造情報は、木構造により表される。例えば、構造情報提供部１２は、図６の左側に示すように、構造情報をダンプした木構造データＴ１１を提供する。かかる木構造データＴ１１のうち、各行の左に示した数値は、木構造における深さ（根ノードから内部ノードや葉ノードまでのエッジ数）を示す。また、木構造データＴ１１のうち、ユーザイベントの対象となるノードには、数値の右側に「＊」（アスタリスク）が付加されている。なお、図６では図示することを省略したが、構造情報提供部１２によって提供される木構造データＴ１１には、ノード毎に、かかるノード配置位置や、かかるノードが表示されるか否かといった属性情報も含まれる。

遷移モデル更新部１２２は、このような木構造データＴ１１が構造情報取得部１２１により取得された場合に、かかる木構造データＴ１１に含まれるノードの中から、木構造データＴ１１に含まれる各ノードの属性情報や、木構造におけるノードの位置に基づいて、ユーザイベントの対象となるノードを決定する。

具体的には、遷移モデル更新部１２２は、下記の条件（１）〜（４）を満たすノードをユーザイベントの対象ノードとして決定する。なお、遷移モデル更新部１２２は、各ノードの属性情報に基づいて、下記の条件（１）〜（３）を満たすか否かを判定できる。

条件（１）：画面外に配置されていないノード
条件（２）：画面において非表示に指定されていないノード
条件（３）：ユーザイベントに対応するノード
（すなわち、深さを示す数値の右側に「＊」が付加されているノード）
条件（４）：木構造において葉ノードとなっているノード

遷移モデル更新部１２２は、このようにして決定した対象ノードから根ノードまでの経路に存在しない他の全てのノード及びエッジを取り除くことにより、画面状態情報を生成する。

図６に示した例を用いて説明すると、遷移モデル更新部１２２は、木構造データＴ１１に含まれる各ノードのうち、２個の葉ノード「６：［＊］android.widget.Button」をユーザイベントの対象ノードとして決定したものとする。かかる場合に、遷移モデル更新部１２２は、２個の葉ノード「６：［＊］android.widget.Button」から、根ノード「０：com.android.internal.policy.impl.…」までの経路に存在しない他の全てのノード及びエッジを取り除くことにより、図６の右側に示した木構造データＴ１２を生成する。そして、遷移モデル更新部１２２は、木構造データＴ１２から、木構造に関する情報のみを抽出して文字列化したデータ（例えば、「０、１、２、３、４、５、６＊、６＊」）をハッシュ化することにより、画面状態情報を生成する。

このように、遷移モデル更新部１２２は、上記の条件（１）〜（４）を満たすノードをユーザイベントの対象ノードとして画面状態情報を生成することで、各画面における類似性の判定を高精度に行うことができる。すなわち、遷移モデル更新部１２２は、実質的に異なる画面を同一の画面として扱うことを防止できるので、ユーザイベントの実行漏れを防止することができる。また、遷移モデル更新部１２２は、ユーザイベントの対象ノードから根ノードまでの経路に存在しない他の全てのノード及びエッジを取り除くことにより、実質的には同一であるような画面を同一の画面状態として扱うことが可能になる。すなわち、遷移モデル更新部１２２は、実質的に同一である画面を遷移モデルに重複登録することを防止できるので、過剰なユーザイベントの実行を減らすことができる。

なお、遷移モデル更新部１２２は、木構造に関する情報のみを抽出して文字列化したデータ（例えば、「０、１、２、３、４、５、６＊、６＊」）に、パッケージ名、アクティビティ名、テキストボックスの入力状態（例えば、全てのテキストボックスに情報が入力されているか否かの２値）等を連結した後にハッシュ化したデータを画面状態情報として生成してもよい。ここでいう「パッケージ名」とは、例えば、アプリケーションを識別するための名称を示す。また、「アクティビティ名」とは、例えば、アプリケーション開発者等が、画面操作を行うモジュールに付与する名称である。なお、異なる画面であっても同一のモジュールによって制御される場合があるので、同一のアクティビティ名が異なる画面に対応する場合もある。例えば、図３（ａ）〜（ｄ）に示した全ての画面には、同一のアクティビティ名が対応する場合もある。この例に限られず、図３（ａ）〜（ｃ）に示した画面には同一のアクティビティ名が対応し、図３（ｄ）に示した画面には、図３（ａ）〜（ｃ）の画面と異なるアクティビティ名が対応する場合もある。

また、例えば、画面状態情報に、テキストボックスの入力状態（全てのテキストボックスに情報が入力されているか否かの２値）が含まれる場合、図３（ａ）の画面状態は、図３（ｂ）及び（ｃ）の画面状態と異なることとなる。一方、画面状態情報に、テキストボックスの入力状態が含まれない場合、図３（ａ）〜（ｄ）の画面状態は、全て異なることとなる。このような画面状態情報に、パッケージ名、アクティビティ名、テキストボックスの入力状態を含めるか否かは、解析装置１００を利用する解析者によって設定可能である。

図１の説明に戻って、端末制御部１３０は、実行装置１０に対して解析対象アプリケーション１１を実行させるとともに、実行装置１０からログを取得する。かかる端末制御部１３０は、イベント特定部１３１と、イベント実行制御部１３２と、ログ取得部１３３とを有する。

イベント特定部１３１は、遷移モデル記憶部１１０に記憶されている遷移モデルのうち、現画面に対応する画面状態において未実行のユーザイベントを特定する。また、イベント特定部１３１は、現画面に対応する画面状態において未実行のユーザイベントが存在しない場合には、他の画面状態において未実行のユーザイベントを探索する処理を行う。かかるイベント特定部１３１による処理については、図７及び図８Ａ〜図８Ｃを用いて後述する。

イベント実行制御部１３２は、イベント特定部１３１によって特定されたユーザイベントを実行装置１０の実行部１３に模擬的に実行させる。かかるイベント実行制御部１３２による処理については、図７及び図８Ａ〜図８Ｃを用いて後述する。

ログ取得部１３３は、イベント実行制御部１３２による制御に応じて実行部１３によりユーザイベントが実行されるたびに、実行装置１０からログ情報を取得する。例えば、ログ取得部１３３は、実行装置１０から、実行環境に関する情報（アプリケーションの実行ログ、システムログ、通信ログなど）や、実行装置１０の表示画面におけるスクリーンショット等をログとして取得する。かかるログ取得部１３３による処理については、図７及び図８Ａ〜図８Ｃを用いて後述する。

なお、上述してきた遷移モデル生成部１２０及び端末制御部１３０は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、図示しない記憶装置に記憶されているプログラムがＲＡＭを作業領域として実行されることにより実現される。また、例えば、遷移モデル生成部１２０及び端末制御部１３０は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

［解析処理手順］
次に、解析装置１００による解析処理の手順について説明する。なお、以下では、最初に、図７を用いて解析処理の流れを説明し、次に、図８Ａ〜図８Ｃを用いて解析処理の具体例について説明する。図７は、第１の実施形態に係る解析装置１００による解析処理手順を示すフローチャートである。

図７に示すように、解析装置１００の構造情報取得部１２１は、解析対象アプリケーション１１により現に表示されている現画面の構造情報を構造情報提供部１２から取得する（ステップＳ１０１）。

続いて、遷移モデル更新部１２２は、構造情報取得部１２１によって取得された構造情報から画面状態情報を生成する（ステップＳ１０２）。具体的には、遷移モデル更新部１２２は、図６を用いて説明したように、ユーザイベントの対象となるノードから根ノードまでの経路に存在しない他の全てのノード及びエッジを取り除くなどして、画面状態情報を生成する。

続いて、遷移モデル更新部１２２は、ステップＳ１０２において生成した画面状態情報が遷移モデル記憶部１１０に記憶されているか否かを判定することにより、現画面の画面状態が未知の画面状態であるか否かを判定する（ステップＳ１０３）。

そして、遷移モデル更新部１２２は、現画面の画面状態が未知の画面状態である場合には（ステップＳ１０３肯定）、遷移モデル記憶部１１０に記憶されている遷移モデルに、現画面の画面状態をノードとして追加する（ステップＳ１０４）。具体的には、遷移モデル更新部１２２は、遷移モデル記憶部１１０の「ノード」に、現画面の画面状態を識別するための情報を格納するとともに、遷移モデル記憶部１１０の「画面状態情報」に、ステップＳ１０２において生成した画面状態情報を格納する。さらに、遷移モデル更新部１２２は、遷移モデル記憶部１１０の「エッジ」に、画面状態情報から得られるユーザイベントを格納する。

すなわち、遷移モデル記憶部１１０の「ノード」に新たな画面状態が格納される場合には、「エッジ」及び「画面状態情報」も格納されることとなる。これにより、後述するイベント特定部１３１は、「遷移先ノード」に情報が格納されていない「エッジ」が未実行のユーザイベントであると判定することができる。

続いて、遷移モデル更新部１２２は、現画面の画面状態が未知の画面状態でない場合や（ステップＳ１０３否定）、ステップＳ１０４における処理の後に、前回実行したユーザイベントが存在するか否かを判定する（ステップＳ１０５）。すなわち、遷移モデル更新部１２２は、実行部１３によってユーザイベントが実行された後に、ステップＳ１０１〜Ｓ１０４における処理が行われたか否かを判定する。

そして、遷移モデル更新部１２２は、前回実行したユーザイベントが存在する場合には（ステップＳ１０５肯定）、遷移モデル記憶部１１０に記憶されている遷移モデルに、前回の画面状態から現画面の画面状態に対するエッジを追加する（ステップＳ１０６）。具体的には、遷移モデル更新部１２２は、遷移モデル記憶部１１０に記憶されている各レコードのうち、前回の画面状態を識別するための情報が「ノード」に格納されているレコードの「遷移先ノード」に現画面の画面状態を識別するための情報を格納する。

続いて、イベント特定部１３１は、現画面の画面状態において未実行のユーザイベントが存在するか否かを判定する（ステップＳ１０７）。具体的には、イベント特定部１３１は、上記の通り、現画面の画面状態に対応付けて遷移モデル記憶部１１０に記憶されている「エッジ」のうち、「遷移先ノード」に情報が格納されていない「エッジ」が存在する場合には、未実行のユーザイベントが存在すると判定する。

そして、イベント特定部１３１は、未実行のユーザイベントが存在する場合には（ステップＳ１０７肯定）、かかる未実行のユーザイベントを実行装置１０に実行させるユーザイベントとして特定する。ここで、イベント特定部１３１は、未実行のユーザイベントが複数存在する場合には、任意のユーザイベントを実行装置１０に実行させるユーザイベントとして特定する。

続いて、イベント実行制御部１３２は、イベント特定部１３１によって特定されたユーザイベントを実行装置１０の実行部１３に実行させる（ステップＳ１０８）。また、ログ取得部１３３は、実行部１３によってユーザイベントが実行された後に、実行装置１０からログを取得して遷移モデル記憶部１１０に格納する（ステップＳ１０８）。このとき、ログ取得部１３３は、遷移モデル記憶部１１０に記憶されている各レコードのうち、実行部１３によってユーザイベントが実行される前の画面状態が「ノード」に格納されており、かつ、実行部１３によって実行されたユーザイベントが「エッジ」に格納されているレコードの「ログ情報」に、実行装置１０から取得したログを格納する。

そして、解析装置１００は、現画面の画面状態において未実行のユーザイベントが存在する限り（ステップＳ１０７肯定）、ステップＳ１０１〜Ｓ１０８における処理手順を繰り返し行う。

一方、イベント特定部１３１は、現画面の画面状態において未実行のユーザイベントが存在しない場合には（ステップＳ１０７否定）、所定の変数「ｉ」に「１」を設定する（ステップＳ１０９）。

続いて、イベント特定部１３１は、遷移モデル記憶部１１０に記憶されている遷移モデルを参照することにより、現画面において実行可能なユーザイベント毎に、かかるユーザイベントが実行されることで遷移可能となる画面状態であり、かつ、現画面の画面状態から遷移可能な深さ「ｉ」（ここの例では、ｉ＝１）までの画面状態において未実行のユーザイベントの総数（スコア）を算出する（ステップＳ１１０）。言い換えれば、イベント特定部１３１は、現画面において実行可能なユーザイベント毎に、現画面の画面状態からの画面遷移数が「ｉ」までの画面状態において未実行のユーザイベントの総数（スコア）を算出する。

続いて、イベント特定部１３１は、ステップＳ１１０において算出したスコアが「０」でないユーザイベントが存在するか否かを判定する（ステップＳ１１１）。

そして、イベント特定部１３１は、スコアが「０」でないユーザイベントが存在する場合には（ステップＳ１１１肯定）、スコアが最大であるユーザイベントを実行装置１０に実行させるユーザイベントとして特定する。

続いて、イベント実行制御部１３２は、実行装置１０の実行部１３に対して、イベント特定部１３１によって特定されたユーザイベントを実行させる（ステップＳ１１２）。

一方、イベント特定部１３１は、スコアが「０」でないユーザイベントが存在しない場合には（ステップＳ１１１否定）、現画面の画面状態から遷移可能な画面状態までのホップ数（画面の遷移数）の最大値「Ｄｍａｘ」を求め、求めた「Ｄｍａｘ」が「ｉ」よりも大きいか否かを判定する（ステップＳ１１３）。

そして、イベント特定部１３１は、「Ｄｍａｘ」が「ｉ」よりも大きい場合には（ステップＳ１１３肯定）、「ｉ」をインクリメントし（ステップＳ１１４）、ステップＳ１１０の処理に戻る。

一方、イベント特定部１３１は、「Ｄｍａｘ」が「ｉ」よりも大きくない場合には（ステップＳ１１３否定）、現画面の画面状態と、解析対象アプリケーション１１の実行開始時における画面状態とが同一であるか否かを判定する（ステップＳ１１５）。

そして、イベント特定部１３１は、現画面の画面状態と開始時の画面状態とが同一である場合には（ステップＳ１１５肯定）、解析処理を終了する。一方、現画面の画面状態と開始時の画面状態とが同一でない場合には（ステップＳ１１５否定）、イベント実行制御部１３２は、現画面から１個前の画面に戻るユーザイベントを実行部１３に実行させる（ステップＳ１１６）。ここでいう「１個前の画面に戻るユーザイベント」とは、解析対象アプリケーション１１によって提供されるユーザイベントではなく、例えば、ＯＳ等によって提供されるユーザイベントや、解析対象アプリケーション１１を動作させるアプリケーション（ブラウザ等）によって提供されるユーザイベントに該当する。

なお、ログ取得部１３３は、１個前の画面に戻るユーザイベントが実行された後にも、実行装置１０からログを取得して遷移モデル記憶部１１０に格納してもよい。この場合、ログ取得部１３３は、遷移モデル記憶部１１０のエッジに「ＢＡＣＫ」といったユーザイベントを格納するとともに、遷移モデル記憶部１１０のログ情報に実行装置１０から取得したログを格納する。

また、上記図７の説明では、現画面の画面状態と開始時の画面状態とが同一でない場合に、現画面から１個前の画面に戻るユーザイベントを実行部１３に実行させた。しかし、解析装置１００は、現画面の画面状態と開始時の画面状態とが同一でない場合であっても、１個前の画面に戻るユーザイベントを実行させることなく、処理を終了してもよい。

［具体例］
次に、図８Ａ〜図８Ｃを用いて、解析装置１００による解析処理の具体例について説明する。図８Ａ〜図８Ｃは、第１の実施形態に係る解析処理の具体例を説明するための図である。以下では、図７に示したステップ番号と対応付けながら解析処理の具体例について説明する。また、図８Ａ〜図８Ｃにおいて、円形は、画面状態を示すノードであり、点線矢印は、未実行のユーザイベントを示すエッジであり、実線矢印は、実行済みのユーザイベントを示すエッジである。

なお、以下の説明において、初期状態は、実行装置１０において解析対象アプリケーション１１が起動されて、解析対象アプリケーション１１により初期画面が表示されている状態であるものとする。また、解析装置１００による解析処理の開始時には、遷移モデル記憶部１１０には各種情報が記憶されていないものとする。

まず、構造情報取得部１２１は、構造情報提供部１２から現画面（初期画面）の構造情報を取得する（ステップＳ１０１）。そして、遷移モデル更新部１２２は、構造情報取得部１２１によって取得された構造情報に基づいて、現画面の画面状態情報を生成する（ステップＳ１０２）。

ここでは、遷移モデル記憶部１１０には各種情報が記憶されていないので、遷移モデル更新部１２２は、生成した画面状態情報が遷移モデル記憶部１１０に記憶されていないと判定する。すなわち、遷移モデル更新部１２２は、現画面の画面状態（画面状態ｖ０とする）が未知の画面状態であると判定し（ステップＳ１０３肯定）、遷移モデル記憶部１１０の「ノード」に、現画面の画面状態ｖ０を識別するための情報（「ｖ０」とする）を格納するとともに、遷移モデル記憶部１１０の「画面状態情報」に、現画面の画面状態情報を格納する（ステップＳ１０４）。また、遷移モデル更新部１２２は、現画面の画面状態情報に基づいて、現画面の画面状態ｖ０において実行可能な全てのユーザイベントを遷移モデル記憶部１１０の「エッジ」に格納する（ステップＳ１０４）。

これにより、遷移モデル記憶部１１０に記憶されている遷移モデルをグラフで表すと、図８Ａ（ａ）に示す状態となる。図８Ａ（ａ）は、画面状態ｖ０において未実行のユーザイベントｅ１１及びｅ１２が存在していることを示している。すなわち、遷移モデル記憶部１１０には、ノード「ｖ０」と、エッジ「ｅ１１」と、画面状態ｖ０の画面状態情報とが対応付けて記憶されているとともに、ノード「ｖ０」と、エッジ「ｅ１２」と、画面状態ｖ０の画面状態情報とが対応付けて記憶されていることとなる。

続いて、イベント特定部１３１は、図８Ａ（ａ）の遷移モデルを参照することにより、未実行のユーザイベントｅ１１及びｅ１２のいずれか一方を実行装置１０に実行させるユーザイベントとして特定する。ここでは、イベント特定部１３１は、ユーザイベントｅ１１を特定したものとする。したがって、イベント実行制御部１３２は、ユーザイベントｅ１１を実行部１３に実行させる（ステップＳ１０８）。また、ログ取得部１３３は、実行部１３によりユーザイベントｅ１１が実行された後に、実行装置１０からログを取得し、取得したログを、ノード「ｖ０」及びエッジ「ｅ１１」に対応する遷移モデル記憶部１１０のログ情報に格納する（ステップＳ１０８）。

その後に、端末制御部１３０は、構造情報取得部１２１に対して、構造情報を取得するように依頼する。これにより、構造情報取得部１２１は、構造情報提供部１２から現画面の構造情報を取得する（ステップＳ１０１）。そして、遷移モデル更新部１２２は、取得された構造情報に基づいて、現画面の画面状態情報を生成する（ステップＳ１０２）。

ここでは、現画面の画面状態は、ユーザイベントｅ１１を実行する前の画面状態ｖ０と異なるものとする。すなわち、遷移モデル更新部１２２は、現画面の画面状態（画面状態ｖ１とする）が未知の画面状態であると判定し（ステップＳ１０３肯定）、遷移モデル記憶部１１０の「ノード」に「ｖ１」を格納し、「画面状態情報」に現画面の画面状態情報を格納し、「エッジ」に画面状態ｖ１において実行可能なユーザイベントｅ１３、ｅ１４及びｅ１５を格納する（ステップＳ１０４）。

また、遷移モデル更新部１２２は、前回実行したユーザイベントｅ１１が存在するので（ステップＳ１０５肯定）、前回の画面状態ｖ０から現画面の画面状態ｖ１に対するエッジ「ｅ１１」を追加する（ステップＳ１０６）。具体的には、遷移モデル更新部１２２は、ノード「ｖ０」及びエッジ「ｅ１１」に対応する遷移モデル記憶部１１０の「遷移先ノード」に「ｖ１」を格納する。

これにより、遷移モデル記憶部１１０に記憶されている遷移モデルをグラフで表すと、図８Ａ（ｂ）の状態となる。図８Ａ（ｂ）は、画面状態ｖ０においてユーザイベントｅ１１が実行済みであることを示している。また、図８Ａ（ｂ）は、ユーザイベントｅ１１が実行されることで、画面状態ｖ０から画面状態ｖ１に遷移することを示している。また、図８Ａ（ｂ）は、画面状態ｖ１において未実行のユーザイベントｅ１３、ｅ１４及びｅ１５が存在していることを示している。

続いて、イベント特定部１３１は、図８Ａ（ｂ）の遷移モデルを参照することにより、実行装置１０に実行させるユーザイベントを特定する。ここでは、イベント特定部１３１は、未実行のユーザイベントｅ１３、ｅ１４及びｅ１５のうち、ユーザイベントｅ１３を特定したものとする。したがって、イベント実行制御部１３２は、ユーザイベントｅ１３を実行部１３に実行させる（ステップＳ１０８）。なお、以下では、ログ取得部１３３によるログ取得処理については説明を省略するが、ログ取得部１３３は、実行部１３によりユーザイベントが実行されるたびに、実行装置１０からログを取得して遷移モデル記憶部１１０のログ情報に格納する（ステップＳ１０８）。

その後に、構造情報取得部１２１は、構造情報提供部１２から現画面の構造情報を取得し（ステップＳ１０１）、遷移モデル更新部１２２は、取得された構造情報に基づいて、現画面の画面状態情報を生成する（ステップＳ１０２）。

ここでは、現画面の画面状態は、ユーザイベントｅ１３を実行する前の画面状態ｖ１と同一であるものとする。すなわち、遷移モデル更新部１２２は、現画面の画面状態ｖ１が未知の画面状態でないと判定するので（ステップＳ１０３否定）、遷移モデル記憶部１１０の「ノード」に「ｖ１」を追加しない。

ただし、遷移モデル更新部１２２は、前回実行したユーザイベントｅ１３が存在するので（ステップＳ１０５肯定）、前回の画面状態ｖ１から現画面の画面状態ｖ１に対するエッジ「ｅ１３」を追加する（ステップＳ１０６）。具体的には、遷移モデル更新部１２２は、ノード「ｖ１」及びエッジ「ｅ１３」に対応する遷移モデル記憶部１１０の「遷移先ノード」に「ｖ１」を格納する。

続いて、イベント特定部１３１は、現画面の画面状態ｖ１において未実行のユーザイベントｅ１４及びｅ１５のうち、ユーザイベントｅ１４を実行装置１０に実行させるユーザイベントとして特定するものとする。したがって、イベント実行制御部１３２は、ユーザイベントｅ１４を実行部１３に実行させる（ステップＳ１０８）。

その後に、構造情報取得部１２１は、構造情報提供部１２から現画面の構造情報を取得し（ステップＳ１０１）、遷移モデル更新部１２２は、取得された構造情報に基づいて、現画面の画面状態情報を生成する（ステップＳ１０２）。

ここでは、現画面の画面状態は、ユーザイベントｅ１４を実行する前の画面状態ｖ１と異なるものとする。すなわち、遷移モデル更新部１２２は、現画面の画面状態（画面状態ｖ２とする）が未知の画面状態であると判定し（ステップＳ１０３肯定）、遷移モデル記憶部１１０の「ノード」に「ｖ２」を格納し、「画面状態情報」に現画面の画面状態情報を格納し、さらに、「エッジ」に、画面状態ｖ２において実行可能なユーザイベントｅ１６、ｅ１７及びｅ１８を格納する（ステップＳ１０４）。

また、遷移モデル更新部１２２は、前回実行したユーザイベントｅ１４が存在するので（ステップＳ１０５肯定）、ノード「ｖ１」及びエッジ「ｅ１４」に対応する遷移モデル記憶部１１０の「遷移先ノード」に「ｖ２」を格納する（ステップＳ１０６）。これにより、遷移モデル記憶部１１０に記憶されている遷移モデルをグラフで表すと、図８Ａ（ｃ）の状態となる。

上述してきた処理を繰り返し行うことにより、イベント実行制御部１３２は、図８Ｂ（ｄ）に示すように、画面状態ｖ２においてユーザイベントｅ１６を実行させたものとする。これにより、画面状態ｖ２から画面状態ｖ１に遷移する。さらに、イベント実行制御部１３２は、画面状態ｖ１において未実行のユーザイベントｅ１５を実行させたものとする。これにより、画面状態ｖ１から画面状態ｖ３に遷移したものとする。その後に、イベント実行制御部１３２は、画面状態ｖ３において未実行のユーザイベントｅ１９を実行させたものとする。これにより、画面状態ｖ３から画面状態ｖ１に遷移したものとする。

このような順に各ユーザイベントが実行された場合、現画面の画面状態ｖ１において未実行のユーザイベントは存在しないこととなる（ステップＳ１０７否定）。したがって、イベント特定部１３１は、変数「ｉ」に「１」を設定し（ステップＳ１０９）、現画面の画面状態ｖ１において実行可能なユーザイベントｅ１４及びｅ１５のそれぞれについて、かかるユーザイベントが実行されることで遷移可能な画面状態であり、かつ、現画面の画面状態ｖ１からの画面遷移数が「１」までの画面状態において未実行のユーザイベントの総数（スコア）を算出する（ステップＳ１１０）。

ここでは、図８Ｂ（ｄ）に示すように、画面状態ｖ２ではユーザイベントｅ１７及びｅ１８が未実行であり、画面状態ｖ３ではユーザイベントｅ２０、ｅ２１及びｅ２２が未実行である。したがって、イベント特定部１３１は、ユーザイベントｅ１４のスコアとして「２」（画面状態ｖ２における未実行のユーザイベントの総数）を算出し、ユーザイベントｅ１５のスコアとして「３」（画面状態ｖ３における未実行のユーザイベントの総数）を算出することとなる。

なお、ここの例において、イベント特定部１３１は、現画面の画面状態へのユーザイベント（図８Ｂ（ｅ）の例では、ユーザイベントｅ１３）については、スコアを算出しない。これは、各ユーザイベントの遷移先の画面状態からの探索において現画面の画面状態を経由することにより、各ユーザイベントのスコアが類似してしまうことを防止するためである。

続いて、イベント特定部１３１は、スコアが「０」でないユーザイベントが存在するので（ステップＳ１１１肯定）、ユーザイベントｅ１４及びｅ１５のうち、スコアが最大であるユーザイベントｅ１５を特定する。そして、イベント実行制御部１３２は、イベント特定部１３１によって特定されたユーザイベントｅ１５を実行部１３に実行させる（ステップＳ１１２）。

これにより、画面状態ｖ１から画面状態ｖ３に遷移することとなる。そして、現画面の画面状態ｖ３において未実行のユーザイベントｅ２０〜ｅ２２が存在するので（ステップＳ１０７肯定）、イベント特定部１３１がいずれかのユーザイベントを特定し、イベント実行制御部１３２が、イベント特定部１３１によって特定されたユーザイベントを実行部１３に実行させることとなる（ステップＳ１１２）。ここでは、イベント実行制御部１３２が、ユーザイベントｅ２０を実行させたものとする。

これにより、図８Ｂ（ｅ）に示すように、画面状態ｖ３から画面状態ｖ４に遷移するものとする。ここで、画面状態ｖ４においては、未実行のユーザイベントが存在せず（ステップＳ１０７否定）、かつ、画面状態ｖ４から遷移可能な画面状態も存在しないものとする（ステップＳ１１１否定、かつ、ステップＳ１１３否定）。

この場合、現画面の画面状態ｖ４と開始時の画面状態ｖ０とが同一でないので（ステップＳ１１５否定）、イベント実行制御部１３２は、現画面から１個前の画面に戻るユーザイベントを実行部１３に実行させる（ステップＳ１１６）。なお、図８Ｂ（ｅ）において、画面状態ｖ４から画面状態ｖ３への一点鎖線矢印は、画面を戻るユーザイベントを示すものとする。

上述してきた処理を繰り返し行うことにより、イベント実行制御部１３２は、図８Ｃ（ｆ）に示すように、画面状態ｖ３においてユーザイベントｅ２１を実行させ、遷移先の画面状態ｖ５においてユーザイベントｅ２３を実行させたものとする。これにより、現画面の画面状態は、画面状態ｖ３となる。その後に、イベント実行制御部１３２は、画面状態ｖ３においてユーザイベントｅ２２を実行させ、遷移先の画面状態ｖ６においてユーザイベントｅ２９を実行させたものとする。これにより、現画面の画面状態は、画面状態ｖ１となる。

そして、ステップＳ１０９〜Ｓ１１２における処理により、イベント実行制御部１３２は、図８Ｃ（ｇ）に示すように、画面状態ｖ１から画面状態ｖ２に遷移させた後に、画面状態ｖ２においてユーザイベントｅ１７を実行させ、遷移先の画面状態ｖ７においてユーザイベントｅ３０を実行させたものとする。これにより、現画面の画面状態は、画面状態ｖ２となる。その後に、イベント実行制御部１３２は、画面状態ｖ２においてユーザイベントｅ１８を実行させ、遷移先の画面状態ｖ８においてユーザイベントｅ３２を実行させたものとする。これにより、現画面の画面状態は、画面状態ｖ１となる。

このような順に各ユーザイベントが実行された場合、現画面の画面状態ｖ１において未実行のユーザイベントは存在しないこととなる（ステップＳ１０７否定）。したがって、イベント特定部１３１は、変数「ｉ」に「１」を設定し（ステップＳ１０９）、現画面の画面状態ｖ１において実行可能なユーザイベントｅ１４及びｅ１５のそれぞれについて、かかるユーザイベントが実行されることで遷移可能な画面状態であり、かつ、現画面の画面状態ｖ１からの画面遷移数が「１」までの画面状態において未実行のユーザイベントの総数（スコア）を算出する（ステップＳ１１０）。

ここでは、図８Ｃ（ｇ）に示すように、画面状態ｖ２及びｖ３において未実行のユーザイベントが存在しない。したがって、イベント特定部１３１は、ユーザイベントｅ１４及びｅ１５のスコアとして、「０」を算出することとなる。

続いて、イベント特定部１３１は、スコアが「０」でないユーザイベントが存在しないので（ステップＳ１１１否定）、変数「ｉ」に「１」を加算することで、「ｉ」＝「２」にする（ステップＳ１１４）。

そして、イベント特定部１３１は、現画面の画面状態ｖ１において実行可能なユーザイベントｅ１４及びｅ１５のそれぞれについて、かかるユーザイベントが実行されることで遷移可能な画面状態であり、かつ、現画面の画面状態ｖ１からの画面遷移数が「２」までの画面状態において未実行のユーザイベントの総数（スコア）を算出する（ステップＳ１１０）。ここでは、イベント特定部１３１は、ユーザイベントｅ１４のスコアとして「３」（画面状態ｖ７における未実行のユーザイベントの総数「１」と、画面状態ｖ８における未実行のユーザイベントの総数「２」との和）を算出する。また、イベント特定部１３１は、ユーザイベントｅ１５のスコアとして「５」（画面状態ｖ５における未実行のユーザイベントの総数「３」と、画面状態ｖ６における未実行のユーザイベントの総数「２」との和）を算出する。

続いて、イベント特定部１３１は、スコアが「０」でないユーザイベントが存在するので（ステップＳ１１１肯定）、スコアが最大であるユーザイベントｅ１５を実行装置１０に実行させるユーザイベントとして特定する。これにより、イベント実行制御部１３２は、ユーザイベントｅ１５を実行部１３に実行させる（ステップＳ１１２）。この結果、現画面の画面状態は、画面状態ｖ３となる。

そして、図８Ｃ（ｇ）に示すように、画面状態ｖ３においても未実行のユーザイベントが存在しないので（ステップＳ１０７否定）、イベント特定部１３１は、変数「ｉ」に「１」を設定し（ステップＳ１０９）、現画面の画面状態ｖ３において実行可能なユーザイベントｅ２０〜ｅ２２のそれぞれについてスコアを算出する（ステップＳ１１０）。この結果、イベント特定部１３１は、スコアが最大であるユーザイベントｅ２１を特定し、イベント実行制御部１３２は、ユーザイベントｅ２１を実行させることとなる。この後に、イベント特定部１３１は、画面状態ｖ５において未実行のユーザイベントｅ２４〜ｅ２６のいずれかを特定し、イベント実行制御部１３２は、イベント特定部１３１によって特定されたユーザイベントを実行部１３に実行させることとなる。

このようにして、解析装置１００は、画面状態をノードとするグラフ（遷移モデル）を生成しながら、かかるグラフ（遷移モデル）を巡回するように、未実行のユーザイベントを実行装置１０に実行させる。

［第１の実施形態の効果］
上述してきたように、第１の実施形態に係る解析システム１は、実行装置１０と、解析装置１００とを含む。実行装置１０は、構造情報提供部１２と、実行部１３とを有する。そして、実行部１３は、ユーザ操作であるユーザイベントに応じて画面が遷移するアプリケーションを実行する。また、構造情報提供部１２は、アプリケーションにより表示される画面毎に、かかる画面の構造を示す構造情報を解析装置１００に提供する。解析装置１００は、遷移モデル記憶部１１０と、構造情報取得部１２１と、遷移モデル更新部１２２と、イベント実行制御部１３２と、ログ取得部１３３とを有する。そして、遷移モデル記憶部１１０は、アプリケーションにおける画面遷移を示す遷移モデルを記憶する。構造情報取得部１２１は、実行部１３によりユーザイベントが実行されるたびに、アプリケーションにより現に表示される現画面に関する構造情報を構造情報提供部１２から取得する。遷移モデル更新部１２２は、構造情報取得部１２１により取得された構造情報に基づいて、構造情報が取得済みである既知の画面と現画面との類似性を判定し、既知の画面と類似していない現画面が追加されるように遷移モデルを更新する。イベント実行制御部１３２は、遷移モデルのうち現画面に対応する画面において未実行のユーザイベントを実行部１３に実行させる。ログ取得部１３３は、実行部１３によりユーザイベントが実行されるたびに、実行装置１０からログ情報を取得する。

すなわち、第１の実施形態に係る解析システム１は、類似する各画面を同一の画面状態として扱った上で画面の遷移モデルを生成しながら、かかる遷移モデルを参照して未実行のユーザイベントを実行装置１０に実行させる。これにより、第１の実施形態に係る解析システム１は、実質的に同一である複数の画面において同じようなユーザイベントが実行されることを防止できるので、効率的に解析対象アプリケーション１１を実行することができる。さらに、解析システム１は、未実行のユーザイベントを順次実行させるので、解析対象アプリケーション１１を網羅的に実行することができる。このようなことから、第１の実施形態に係る解析システム１は、ＧＵＩ操作を伴うアプリケーションの動的解析においてコードカバレッジを効率的に高めることができる。

例えば、第１の実施形態に係る解析システム１を用いた場合、高いコードカバレッジを実現できるので、解析装置１００を利用する解析者は、遷移モデル記憶部１１０に記憶されているログを参照することにより、解析対象アプリケーション１１がマルウェアであるか否かを高精度に解析することができる。

また、第１の実施形態に係る解析システム１において、構造情報提供部１２は、画面のレイアウトに関するコンポーネント、及び、画面においてユーザイベントに対応するコンポーネントをノードとする木構造により表される構造情報を提供する。また、遷移モデル更新部１２２は、構造情報を表す木構造のうち、根ノードから、ユーザイベントに対応するコンポーネントに対応するノードまでの経路に含まれるノード群が同一であるか否かに基づいて、既知の画面と現画面との類似性を判定する。

これにより、第１の実施形態に係る解析システム１は、各画面における類似性の判定を高精度に行うことができるので、実質的に異なる画面を同一の画面として扱うことを防止できる。この結果、解析システム１は、ユーザイベントの実行漏れを防止することができる。また、解析システム１は、実質的に同一である画面を遷移モデルに重複登録することを防止できるので、過剰なユーザイベントの実行を減らすことができる。

また、第１の実施形態に係る解析システム１において、解析装置１００が有するイベント特定部１３１は、現画面に対応する画面において未実行のユーザイベントが存在しない場合に、遷移モデルに基づいて、現画面において実行可能なユーザイベント毎に、当該ユーザイベントが実行されることで遷移可能となる画面であり、かつ、現画面からの画面遷移数が最小である画面において未実行のユーザイベントの総数を算出し、算出した総数が最大であるユーザイベントを特定する。また、イベント実行制御部１３２は、イベント特定部１３１により特定されたユーザイベントを実行部１３に実行させる。

これにより、第１の実施形態に係る解析システム１は、現画面からの画面遷移数が少ない画面であり、かつ、未実行のユーザイベントが多い画面を優先して、未実行のユーザイベントを実行させるので、遷移モデルを効率的に巡回することができる。

また、第１の実施形態に係る解析システム１において、イベント実行制御部１３２は、イベント特定部１３１によりユーザイベントが特定されない場合に、現画面から１個前の画面に戻るユーザイベントを実行部１３に実行させる。

これにより、第１の実施形態に係る解析システム１は、現画面が画面遷移のない画面状態（完了画面等）になった場合であっても、未実行のユーザイベントを探索することが可能となるので、ＧＵＩ操作を伴うアプリケーションの動的解析においてコードカバレッジを効率的に高めることができる。

（第２の実施形態）
上述した解析システム１は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、第２の実施形態では、上記の解析システム１の他の実施形態について説明する。

［システム構成］
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

例えば、図１に示した例において、構造情報取得部１２１と遷移モデル更新部１２２とは統合されてもよい。また、例えば、イベント特定部１３１とイベント実行制御部１３２とは統合されてもよい。

［プログラム］
また、上記実施形態において説明した解析装置１００が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、解析装置１００が実行する処理をコンピュータが実行可能な言語で記述した解析プログラムを作成することもできる。この場合、コンピュータが解析プログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかる解析プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された解析プログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、一例として、図１に示した解析装置１００と同様の機能を実現する解析プログラムを実行するコンピュータの一例を説明する。

図９は、解析プログラムを実行するコンピュータ１０００を示す図である。図９に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、図９に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図９に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図９に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース１０５０は、図９に例示するように、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、図９に例示するように、例えばディスプレイ１０６１に接続される。

ここで、図９に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の解析プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０３１に記憶される。例えば、図１に例示した構造情報取得部１２１と同様の情報処理を実行する構造情報取得手順と、遷移モデル更新部１２２と同様の情報処理を実行する遷移モデル更新手順と、イベント特定部１３１と同様の情報処理を実行するイベント特定手順と、イベント実行制御部１３２と同様の情報処理を実行するイベント実行制御手順と、ログ取得部１３３と同様の情報処理を実行するログ取得手順とが記述されたプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。

また、上記実施形態で説明した遷移モデル記憶部１１０が保持する各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、構造情報取得手順、遷移モデル更新手順、イベント特定手順、イベント実行制御手順、ログ取得手順を実行する。

なお、解析プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、解析プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１ 解析システム
１０ 実行装置
１１ 解析対象アプリケーション
１２ 構造情報提供部
１３ 実行部
１００ 解析装置
１１０ 遷移モデル記憶部
１２１ 構造情報取得部
１２２ 遷移モデル更新部
１３１ イベント特定部
１３２ イベント実行制御部
１３３ ログ取得部

Claims (7)

1. 実行装置と解析装置とを含む解析システムであって、
   前記実行装置は、
   ユーザ操作であるユーザイベントに応じて画面が遷移するアプリケーションを実行する実行部と、
   前記アプリケーションにより表示される画面毎に、当該画面の構造を示す構造情報として、少なくとも当該画面においてユーザイベントに対応するコンポーネントをノードとする木構造により表される構造情報を前記解析装置に提供する提供部とを備え、
   前記解析装置は、
   前記アプリケーションにおける画面遷移を示す遷移モデルを記憶する記憶部と、
   前記実行部により前記ユーザイベントが実行されるたびに、前記アプリケーションにより現に表示される現画面に関する構造情報を前記提供部から取得する構造情報取得部と、
   前記構造情報取得部により取得された構造情報を表す木構造のうち、根ノードから、前記ユーザイベントに対応するコンポーネントに対応するノードまでの経路に含まれるノード群が同一であるか否かに基づいて、構造情報が取得済みである既知の画面と前記現画面との類似性を判定し、当該既知の画面と類似していない現画面が追加されるように前記遷移モデルを更新する更新部と、
   前記遷移モデルのうち前記現画面に対応する画面において未実行のユーザイベントを前記実行部に実行させる実行制御部と、
   前記実行部により前記ユーザイベントが実行されるたびに、前記実行装置からログ情報を取得するログ取得部と
   を備えたことを特徴とする解析システム。
2. 前記解析装置は、
   前記現画面に対応する画面において未実行のユーザイベントが存在しない場合に、前記遷移モデルに基づいて、当該現画面において実行可能なユーザイベント毎に、当該ユーザイベントが実行されることで遷移可能となる画面であり、かつ、当該現画面からの画面遷移数が最小である画面において未実行のユーザイベントの総数を算出し、算出した総数が最大であるユーザイベントを特定する特定部をさらに備え、
   前記実行制御部は、
   前記特定部により特定されたユーザイベントを前記実行部に実行させる
   ことを特徴とする請求項１に記載の解析システム。
3. 前記実行制御部は、
   前記特定部によりユーザイベントが特定されない場合に、当該現画面から１個前の画面に戻るユーザイベントを前記実行部に実行させる
   ことを特徴とする請求項２に記載の解析システム。
4. ユーザ操作であるユーザイベントに応じて画面が遷移するアプリケーションにおける画面遷移を示す遷移モデルを記憶する記憶部と、
   前記アプリケーションの実行環境において前記ユーザイベントが実行されるたびに、当該アプリケーションにより現に表示される現画面に関する構造情報として、少なくとも当該画面においてユーザイベントに対応するコンポーネントをノードとする木構造により表される構造情報を前記実行環境から取得する構造情報取得部と、
   前記構造情報取得部により取得された構造情報を表す木構造のうち、根ノードから、前記ユーザイベントに対応するコンポーネントに対応するノードまでの経路に含まれるノード群が同一であるか否かに基づいて、構造情報が取得済みである既知の画面と前記現画面との類似性を判定し、当該既知の画面と類似していない現画面が追加されるように前記遷移モデルを更新する更新部と、
   前記遷移モデルのうち前記現画面に対応する画面において未実行のユーザイベントを前記実行環境において実行させる実行制御部と、
   前記ユーザイベントが実行されるたびに、前記実行環境からログ情報を取得するログ取得部と
   を備えたことを特徴とする解析装置。
5. 実行装置と解析装置とを含む解析システムにより実行される解析方法であって、
   前記実行装置が、ユーザ操作であるユーザイベントに応じて画面が遷移するアプリケーションを実行する実行工程と、
   前記実行装置が、前記アプリケーションにより表示される画面毎に、当該画面の構造を示す構造情報として、少なくとも当該画面においてユーザイベントに対応するコンポーネントをノードとする木構造により表される構造情報を前記解析装置に提供する提供工程と、
   前記解析装置が、前記実行装置により前記ユーザイベントが実行されるたびに、前記アプリケーションにより現に表示される現画面に関する構造情報を前記実行装置から取得する構造情報取得工程と、
   前記解析装置が、前記構造情報取得工程により取得された構造情報を表す木構造のうち、根ノードから、前記ユーザイベントに対応するコンポーネントに対応するノードまでの経路に含まれるノード群が同一であるか否かに基づいて、構造情報が取得済みである既知の画面と前記現画面との類似性を判定し、前記アプリケーションにおける画面遷移を示す遷移モデルに当該既知の画面と類似していない現画面が追加されるように当該遷移モデルを更新する更新工程と、
   前記解析装置が、前記遷移モデルのうち前記現画面に対応する画面において未実行のユーザイベントを前記実行装置に実行させる実行制御工程と、
   前記解析装置が、前記実行装置により前記ユーザイベントが実行されるたびに、前記実行装置からログ情報を取得するログ取得工程と
   を含んだことを特徴とする解析方法。
6. 解析装置が実行する解析方法であって、
   ユーザ操作であるユーザイベントに応じて画面が遷移するアプリケーションの実行環境において前記ユーザイベントが実行されるたびに、当該アプリケーションにより現に表示される現画面に関する構造情報として、少なくとも当該画面においてユーザイベントに対応するコンポーネントをノードとする木構造により表される構造情報を前記実行環境から取得する構造情報取得工程と、
   前記構造情報取得工程により取得された構造情報を表す木構造のうち、根ノードから、前記ユーザイベントに対応するコンポーネントに対応するノードまでの経路に含まれるノード群が同一であるか否かに基づいて、構造情報が取得済みである既知の画面と前記現画面との類似性を判定し、前記アプリケーションにおける画面遷移を示す遷移モデルに当該既知の画面と類似していない現画面が追加されるように当該遷移モデルを更新する更新工程と、
   前記遷移モデルのうち前記現画面に対応する画面において未実行のユーザイベントを前記実行環境において実行させる実行制御工程と、
   前記ユーザイベントが実行されるたびに、前記実行環境からログ情報を取得するログ取得工程と
   を含んだことを特徴とする解析方法。
7. ユーザ操作であるユーザイベントに応じて画面が遷移するアプリケーションの実行環境において前記ユーザイベントが実行されるたびに、当該アプリケーションにより現に表示される現画面に関する構造情報として、少なくとも当該画面においてユーザイベントに対応するコンポーネントをノードとする木構造により表される構造情報を前記実行環境から取得する構造情報取得手順と、
   前記構造情報取得手順により取得された構造情報を表す木構造のうち、根ノードから、前記ユーザイベントに対応するコンポーネントに対応するノードまでの経路に含まれるノード群が同一であるか否かに基づいて、構造情報が取得済みである既知の画面と前記現画面との類似性を判定し、前記アプリケーションにおける画面遷移を示す遷移モデルに当該既知の画面と類似していない現画面が追加されるように当該遷移モデルを更新する更新手順と、
   前記遷移モデルのうち前記現画面に対応する画面において未実行のユーザイベントを前記実行環境において実行させる実行制御手順と、
   前記ユーザイベントが実行されるたびに、前記実行環境からログ情報を取得するログ取得手順と
   をコンピュータに実行させることを特徴とする解析プログラム。

Images