JP2018116496A - 差異検出装置及びプログラム - Google Patents

Abstract

【課題】Ｗｅｂアプリケーションに関して自動生成されるテストスクリプトでは実現できない画面遷移を検出できる装置を提供する。【解決手段】クライアント装置１０は、サーバ装置のＷｅｂアプリケーションのテストを支援する。画面遷移抽出部１１は、アプリケーションのソースコードを静的解析し、各リクエストに対する遷移先の数を取得する。テストシナリオ生成部１２は、テストにおいて表示された各画面に対するテストシナリオとテスト入力値を生成する。画面自動操作部１３は、生成されたテストシナリオとテスト入力値をテストケースとして、画面操作を自動的に実行し、動的解析する。画面評価部１４は、画面操作の実行により遷移した画面が既に遷移したことのある画面か否かを判定する。テスト資材生成部１５は、静的解析及び動的解析により得られた情報に基づいて、画面遷移図を生成し、テストシナリオとテスト入力値をテストスクリプトの形式で出力する。【選択図】図５

Description

本発明は、差異検出装置及びプログラムに関する。

近年、ニーズに合ったサービスを迅速に提供するため、サービスを短いサイクルで提供する開発スタイルが増加しており、それに伴いソフトウェアテストの頻度も増加している。このような中、Ｗｅｂアプリケーションにおいて、機能テストにおける画面遷移テストに稼働がかかることが問題となっている。機能テストとはＪＳＴＱＢ（非特許文献１）によると「コンポーネント（独立してテストできるソフトウェアの最小単位）やシステム（コンポーネントのセット）の機能仕様の分析に基づいて実施するテスト」と定義され、コンポーネントレベルの機能を確認するテストから、システムレベルの機能を確認するテストまで存在する。

機能テストにおける画面遷移テストは、機能テストの中でも、「クライアントサイドからのインタラクションに対し、クライアントサイドに表示される画面から、仕様通りに実装されているかどうかを確認することができる機能に対するテスト」とここでは定義する。

機能テストにおける画面遷移テストに稼働がかかるのは、クライアントサイドからのインタラクションとして、画面にあるリンクやボタンをクリックしたり、フォームに適切な値を入力するなどの人間の操作が求められるためである。このような画面遷移テストを自動化し、稼働削減を狙う方法として、テストケースのスクリプト化し、自動実行する手法が広く知られている。

テストケースを人手でスクリプト化するには稼働がかかるため、以下の２つのテストスクリプト自動生成技術が存在する。
・Capture and Replay技術を用いたテストスクリプトの自動生成（非特許文献２）
・モデルベーステストによるテストスクリプトの自動生成（非特許文献３）

"JSTQB"、［online］、インターネット＜ＵＲＬ：http://jstqb.jp/syllabus.html＞ "Selenium IDE"、［online］、インターネット＜ＵＲＬ：https://addons.mozilla.org/ja/firefox/addon/selenium-ide/＞ "結合テストにおけるテスト項目自動生成手法の提案と評価"、丹野 治門，張 暁晶，星野 隆、電子情報通信学会技術研究報告、Oct 2010

Capture and Replay技術では、仕様から人手で作成したテストケースをユーザが実行することで、ユーザの画面に対する操作を記録してテストスクリプトとして出力することができる。しかし、Capture and Replay技術を用いた場合、画面操作を記録するためのツール操作といった追加の稼働が発生するため、一般的に３回以上同等のテストを実施しない場合は、稼働の元が取れないという欠点が存在する。

モデルベーステストでは、仕様をマシンが読み取れる形式のモデルで記述することで、読み取った仕様からテストケースを自動生成し、テストスクリプトとして出力することができる。しかし、モデルを記述するための追加の稼働がかかるという欠点が存在する。

以上より、既存のテストスクリプト自動生成技術では、テストスクリプトを生成するための追加の稼働が発生することが問題であるということがいえる。

一方で、追加の稼動を削減することでテストスクリプトの自動生成の効率化を図ろうとした場合、テスト対象の仕様として定義されている全ての画面遷移を抽出できているか否かが問題となる。すなわち、仕様として定義されちる画面遷移の抽出に漏れが有る場合、自動生成されたテストスクリプトにおいて一部の画面遷移に関するテストが漏れてしまう可能性が有る。したがって、自動生成されたテストスクリプトでは実現できない画面遷移の検出技術が望まれる。

本発明は、上記の点に鑑みてなされたものであって、Ｗｅｂアプリケーションに関して自動生成されるテストスクリプトでは実現できない画面遷移の検出を可能とすることを目的とする。

そこで上記課題を解決するため、差異検出装置は、Ｗｅｂアプリケーションのソースコードから、前記ソースコードにおいて定義された第１の画面遷移の情報を抽出する抽出部と、前記Ｗｅｂアプリケーションに関して表示される画面を自動的に操作する操作部と、自動的な操作によって実現される第２の画面遷移の情報を生成する生成部と、前記第１の画面遷移の情報と前記第２の画面遷移の情報との差異を検出する検出部と、を有する。

Ｗｅｂアプリケーションに関して自動生成されるテストスクリプトでは実現できない画面遷移の検出を可能とすることができる。

同一ＵＲＬでも異なる画面としてテストしたい画面の例を示す図である。 Tree Edit Distanceの一例を示す図である。 本発明の実施の形態におけるシステム構成例を示す図である。 本発明の実施の形態におけるクライアント装置１０のハードウェア構成例を示す図である。 本発明の実施の形態におけるクライアント装置１０の機能構成例を示す図である。 クライアント装置１０が実行する処理手順の一例を説明するためのフローチャートである。 静的解析の一例を示す図である。 画面遷移図の一例を示す図である。 辞書の生成処理の処理手順の一例を説明するためのフローチャートである。 画面遷移情報の抽出処理の処理手順の一例を説明するためのフローチャートである。 テストケースの生成及び実行処理の処理手順の一例を説明するためのフローチャートである。 フォームの一例を示す図である。 テスト入力値の生成処理の処理手順の一例を説明するためのフローチャートである。 遷移先画面の判定処理の処理手順の一例を説明するためのフローチャートである。 ＤＯＭツリーの一例を示す図である。 画面遷移図の生成処理の処理手順の一例を説明するためのフローチャートである。 テストスクリプトの出力処理の処理手順の一例を説明するためのフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。本実施の形態では、テスト対象から仕様をリバースし、リバースした仕様に基づいて網羅的なテストケースを自動生成し、テストスクリプトとして出力するといったアプローチを提案する。本アプローチによって、追加の稼働を必要とせずに網羅的なテストスクリプトを自動生成することができる。

本実施の形態では、機能テストにおける画面遷移テストを対象としているため、以下のステップで処理が実行される。
（１）テスト対象を解析し、仕様としてテスト対象を構成する画面と画面間の繋がり、各画面に到達するための手段を抽出する。
（２）（１）で取得した仕様から機能テストにおける画面遷移テストに適した画面遷移図を生成する。
（３）（２）で生成した画面遷移図の各遷移に対応するテストスクリプトを、（１）で抽出した画面に到達するための手段の情報に基づいて、出力したいスクリプト形式に合わせて出力する。

（１）ではテスト対象を構成する画面とその画面に到達するための手段を抽出する。Ｗｅｂアプリケーションでは、ｊｓｐファイル等の画面（ＨＴＭＬ）の元となるファイルから、クライアントサイドからのリクエストに応じて、動的に画面を生成するケースが一般的である。したがって、テスト対象がどのような画面で構成されていて、それらがどのように繋がっているかの情報は、ソースコードに直接記述されていないため、適切な解析が必要となる（技術課題１：テスト対象から仕様をリバースする方法の検討）。

また、画面に到達するための手段の抽出においても、Ｗｅｂアプリケーションでは、特定の入力値を与えないと遷移することができない画面遷移が存在する。例えば、電話番号を登録するようなシステムにおいて、１１桁の半角数字でないと登録完了画面に遷移できないケースが挙げられる。このような画面遷移に対して、適切な入力値を生成する必要がある（技術課題２：画面遷移を実現するための適切な入力値生成方法の検討）。

（２）では、（１）で取得したテスト対象を構成する画面情報を用いて、機能テストにおける画面遷移テストに適した画面遷移図を生成する。機能テストにおける画面遷移テストでは、機能の粒度で画面を識別する必要がある。一般的に画面はＵＲＬで識別されるが、同一ＵＲＬの画面同士でも、機能テストでは異なる画面と判別されることがある。例えば、検索サイトにおいて、検索結果が無かったときの画面と検索結果が有ったときの画面はＵＲＬで見た場合、同一となることがあるが、機能テストの観点では別々の画面としてみなされる。したがって、機能テストの観点に合った、適切な画面識別を行う必要がある（技術課題３：機能テストにおける適切な画面識別方法の検討）。

（３）は、出力したいスクリプト形式に合わせてテストスクリプトを生成するステップである。（１）で抽出した画面に到達するための手段（リンクやボタンのクリック、フォームへの入力等）を、出力したいスクリプト形式で記述する。本ステップについては、抽出した手段をそれに対応するメソッドで記述するだけなので技術的課題はないと考えられる。

以上より、本アプローチには以下の３つの技術的課題があると考えられる。
技術課題１：テスト対象から仕様をリバースする方法の検討。
技術課題２：画面遷移を実現するための適切な入力値生成方法の検討。
技術課題３：機能テストにおける適切な画面識別方法の検討。

［技術課題１：テスト対象から仕様をリバースする方法の検討］
＜従来技術と問題点＞
アプリケーションから仕様をリバースする技術として、静的解析を用いた技術が存在する（例えば、「"Reconstructing Software Architecture for J2EE Web Applications" Minmin Han, Christine Hofmeister, Robert L. Nord,Proceedings of the 10th Working Conference on Reverse Engineering 2003」）。しかし、ｊｓｐファイルから動的に生成されるＨＴＭＬのように、実行しないと生成できない情報を取得することができないため、仕様を完全にリバースすることができない。このような欠点を補うため、静的解析と動的解析を組み合わせた技術も存在する（例えば、「Silva CE, Campos JC. 2013. "Combining Static and Dynamic Analysis for the Reverse Engineering of Web Applications". Proceedings of the 5th Symposium on Engineering Interactive Computing Systems - EICS. :107-112.」）。本技術では静的解析でプログラム中のパスを洗い出し、動的解析でそれらのパスを全て網羅するようなテストケースを生成することでＷｅｂアプリケーションの振る舞いの網羅を目指している。しかし、動的解析で通過したパスを取得するためには入力値が通過しうる全ての箇所にログが取得できるようなコードを挿入する必要があり、ユーザは、クライアントサイドからサーバサイドまで、システム構成を正確に把握し、プログラムが通過した場所を表すログを出力するための環境を用意しなくてはならないため、ツール導入のための追加稼働の削減を目指している本実施の形態の目的とは合致しない。また、テスト対象に手を加えることで振る舞いが変わる可能性もあり、そのようなテスト対象から生成したテストケースを実際のテストに用いた場合、想定していたテストシナリオと異なる内容のテストをしてしまうリスクが存在する。

＜本実施の形態における提案：コントローラに着目した静的解析と動的解析を用いた仕様のリバース技術＞
本実施の形態では、Ｗｅｂアプリケーションにおいて一般的に用いられているデザインパターンであるＭＶＣ（Model View Controller）の構成において、クライアントサイドからのリクエストに対して実行する処理を決定するコントローラに着目する。例えば、サーブレットがコントローラの一例である。コントローラが割り振る遷移を静的解析で全て把握し、その後の動的解析でそれらの遷移を網羅することで、テスト対象を構成する画面と画面間の繋がり、各画面に到達するための手段を漏れなくリバースすることができる。従来手法との違いとして、本実施の形態ではコントローラにのみ着目するため、クライアントサイドの情報からコントローラの示す遷移先をどの程度網羅できたかを推測することができ、ログを取得するための環境を用意する稼働を不要、又は少なくすることができるといった利点が挙げられる。従来のプログラムの実行パスを取得する方法では、実行パスの詳細な情報をクライアントサイドから推測することは不可能である。

［技術課題２：画面遷移を実現するための適切な入力値生成方法の検討］
＜従来技術と問題点＞
画面遷移を実現するための適切な入力値を生成するための方法として、Concolic Testingという手法が存在する（例えば、"Concolic testing" Koushik Sen. 2007. In Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering (ASE '07). ACM, New York, NY, USA, 571-572.」）。Concolic Testingでは、入力値を記号と置き、プログラムを実行しながらパスを通るための制約情報（パス式）を入手する。得られたパス式を反転させて生成される新たなパス式を制約ソルバで解くことで、所望のパスを通るために必要なテスト入力値を生成することができる。しかし、Concolic Testingは、入力値を記号と置いて追跡していく手法であるため、記号と置いた入力値がどこでどのような処理がされたのかのログを取得する必要がある。そのような情報を取得するためには、入力値が通過しうる箇所全てにログが取得できるようなコードを挿入する必要があり、ユーザは、クライアントサイドからサーバサイドまで、システム構成を正確に把握し、ログを出力するための環境を用意しなくてはならないため、導入の敷居が高いという欠点が存在する。特に、サーバサイドにおいては、業務用のＷｅｂアプリケーションでは、Ｗｅｂサーバ、アプリケーションサーバ、ＤＢサーバなど、様々なシステムから構成されていることが一般的であり、それら全てのシステムに対し、ログを取得するための環境を用意することは多くの稼働がかかるため、ツール導入のための追加稼働の削減を目指している本実施の形態の目的とは合致しない。

＜本実施の形態における提案：クライアントサイドの情報を用いたテスト入力値生成技術＞
一般的にＷｅｂアプリケーションにおいて、入力値によって画面遷移が決定されるパターンとしては以下の２通りが存在する。
（１）仕様に対して適切な入力値が入力された場合の正常系画面遷移
（２）仕様に対して不適切な入力値が入力された場合の準正常系画面遷移
（２）に対しては、無作為な値を入力、又は入力値を与えないことで実現できるケースが多くを占めることが経験的にわかる。しかし、（１）に対しては適切な入力値を与える必要があるため、無作為なテスト入力値を与えるだけでは画面遷移を実現できない可能性が高い。本実施の形態では、クライアントサイドの情報を用いて、入力フォームに対してどのような種類の入力値が求められているのかを推測し、適切な入力値を与えることで（１）に対するテスト入力値生成を実現する。

［技術課題３：機能テストにおける適切な画面識別方法の検討］
＜従来技術と問題点＞
本実施の形態では、機能テストにおける画面遷移テストを、機能テストの中でも、「クライアントサイドからのインタラクションに対し、クライアントサイドに表示される画面から、仕様通りに実装されているかどうかを確認することができる機能に対するテスト」と定義する。一般的に画面はＵＲＬで識別されるが、本定義における画面遷移テストでは、同一ＵＲＬの画面同士でも画面によっては異なる画面としてテストすることが重要である。例えば、検索サイトにおいて、図１のように検索結果が無かったときの画面と検索結果が有ったときの画面はＵＲＬで見た場合、同一となることがあるが、機能テストの観点では別々の画面としてみなす。このような場合、ＵＲＬではなく、表示される画面から識別するべきである。しかし、単純に表示された画面同士を画像として比較すると、確認したい機能部分が同一でも、それ以外の箇所が異なっていた場合、異なる画面と判別されてしまう。したがって、画面全体ではなく、画面を構成する要素の一部を比較する必要がある。画面は主にＨＴＭＬ、ＤＯＭ（Document Object Model ）構造、テキスト、画像、ＣＳＳ（Cascading Style Sheets）等の要素で構成されている。

試験観点によって着目すべき箇所は異なるが、本実施の形態では機能の違いがＨＴＭＬのＤＯＭ構造に表れるケースを対象とする。ＨＴＭＬのＤＯＭ構造比較の既存手法として、Tree Edit Distance（以下「ＴＥＤ」という。）を用いた手法が存在する（例えば、「"A survey on tree edit distance and related problems" Philip Bille. 2004. Theoretical Computer Science. Volume 337, Issues 1-3, 9 June 2005, Pages 217-239.」）。

ＴＥＤとは、両ＤＯＭツリーが一致するまでノードの削除・挿入を行ったときの削除・挿入の回数となる。例えば、図２においてＤＯＭツリー１とＤＯＭツリー２を一致させるには、ＤＯＭツリー２の＜ｐ＞、＜ｓｔｒｏｎｇ＞、＜Ｕ＞の３つのノードを削除し、＜ｉｍｇ＞ノードを挿入する必要があるため、ＴＥＤの値は４となる。閾値が３以下の場合、ＤＯＭツリー１とＤＯＭツリー２の構造は不一致と判断することができ、閾値が４以上の場合、ＤＯＭツリー１とＤＯＭツリー２の構造は一致すると判断することができる。

ＴＥＤを用いた画面の構造比較の欠点として、画面ごとに適切な閾値が異なるため、閾値の設定が困難であるといった点が挙げられる。閾値（ＴＥＤに対する許容範囲）を必要とする原因として、以下の２つが考えられる。
原因１：機能テストにおける画面の識別に影響を与えないノードの存在
原因２：並列化されたノードの存在
原因１については、太字タグ＜ｂ＞など、機能テストにおいて画面の識別に影響を与えないノードが存在することが挙げられる。原因２については、見出しタグなどが挙げられる。例えば、ニュースサイトにおいて、見出しの数が異なっている場合でもニュースを表示するという機能は同一であるため、見出しの数は機能に影響を与えないということがいえる。このように画面の識別に影響を与えないノードが存在し、それらのノードによってＴＥＤの値が増加するため、閾値を設ける必要がある。

＜本実施の形態における提案：ＨＴＭＬのＤＯＭ構造の類似度を利用した画面識別技術＞
本実施の形態では、原因１に関わるノードを削除し、原因２に関わるノードを集約することでＨＴＭＬを抽象化し、抽象化されたＨＴＭＬを比較することで、閾値の設定を必要とせずに機能テストにおける適切な画面識別を可能とする。

以下、上記を実現するための具体例について説明する。図３は、本発明の実施の形態におけるシステム構成例を示す図である。図３において、サーバ装置２０及びクライアント装置１０は、例えば、ＬＡＮ（Local Area Network）又はインターネット等のネットワークを介して接続される。

サーバ装置２０は、Ｗｅｂアプリケーションを含むテスト対象のシステムを含む１以上のコンピュータである。

クライアント装置１０は、サーバ装置２０が有するＷｅｂアプリケーションについてのテスト（検証）を支援する装置である。

図４は、本発明の実施の形態におけるクライアント装置１０のハードウェア構成例を示す図である。図４のクライアント装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。

クライアント装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってクライアント装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。

図５は、本発明の実施の形態におけるクライアント装置１０の機能構成例を示す図である。図５において、クライアント装置１０は、画面遷移情報抽出部１１、テストシナリオ生成部１２、画面自動操作部１３、画面評価部１４及びテスト資材生成部１５等を有する。これら各部は、クライアント装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

画面遷移情報抽出部１１は、Ｗｅｂアプリケーションのコントローラのソースコードに基づいて、静的解析技術を用いてコントローラを解析し、各リクエストに対する遷移先の数を取得する。

テストシナリオ生成部１２は、テストにおいて表示された各画面に対するテストシナリオとテスト入力値とを生成する。或る画面の各フォームに対するテスト入力値は、当該画面に係るＨＴＭＬのＤＯＭツリーにおける当該フォームの周辺情報を用いて生成される。当該フォームの周辺情報とは、ＨＴＭＬにおいて当該フォームに関して定義された情報の一例である。

画面自動操作部１３は、生成されたテストシナリオとテスト入力値とをテストケースとして、画面操作を自動的に実行することで、動的解析を実現する。

画面評価部１４は、画面操作の実行により遷移した画面が既に遷移したことのある画面か否かをＵＲＬやＨＴＭＬ等の情報を用いて判定する。画面評価部１４は、画面操作の実行により遷移した画面のＨＴＭＬデータと、既に遷移したことのある画面のＨＴＭＬデータとについて、それぞれを抽象化するための編集処理を行って、編集後のＨＴＭＬデータを比較する。

テスト資材生成部１５は、静的解析及び動的解析により得られた情報に基づいて、画面遷移図を生成する。テスト資材生成部１５は、また、テストシナリオ生成部１２によって生成されたテストシナリオとテスト入力値をテストスクリプトの形式で出力する。

以下、クライアント装置１０が実行する処理手順について説明する。図６は、クライアント装置１０が実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ１０１において、テストシナリオ生成部１２は、テスト入力値の生成に利用される辞書を生成する。辞書は、単語ごとに、当該単語の上位語がタグとして付与された構成を有するデータである。本実施の形態では、例えば、予め用意された辞書と、サーバ装置２０においてＷｅｂアプリケーションがアクセスするＤＢデータから生成される辞書の２種類とが利用される。ステップＳ１０１では後者の辞書が生成される。ＤＢに登録された値をテスト入力値とすることで、検索表示画面等の、ＤＢに登録されたテスト入力値でないと遷移することの出来ない画面への遷移を可能とすることができる。ユーザは、ＤＢデータを入力として与えなくてもテスト入力値を生成することは可能だが、ＤＢデータを入力として与えない場合、ＤＢに登録されたデータが画面遷移の条件に影響を与える場合に、適切な入力値を生成できない可能性がある。

続いて、画面遷移情報抽出部１１は、静的解析技術を用いてコントローラのソースコードを解析し、画面の遷移先を決定するコントローラの情報から、各リクエストに対する遷移先の数を取得する（Ｓ１０２）。１つのリクエストに対する遷移先の数を示す情報を「画面遷移情報」といい、画面遷移情報のリストを「画面遷移情報リスト」という。

図７は、静的解析の一例を示す図である。図７には、コントローラのソースコードの一部が示されている。図７において記述ｄ１は、リクエストを示す。記述ｄ２及び記述ｄ３は、当該リクエストに対応した遷移先を示す。ステップＳ１０２では、記述ｄ１、ｄ２、及びｄ３から、「ｏｗｎｅｒｓ／ｎｅｗ」というリクエストに対して２つの遷移先が有ることが抽出される。このような抽出が、ソースコードに定義されている全てのリクエストについて実行される。

続いて、画面自動操作部１３は、初期ＵＲＬにアクセスして、初期ＵＲＬに対応するＨＴＭＬデータ等を取得する（Ｓ１０３）。その結果、当該ＨＴＭＬデータ等に基づく画面が表示装置１０６に表示される。初期ＵＲＬは、例えば、ユーザによって入力されてもよいし、補助記憶装置１０２に予め記憶されていてもよい。

続くステップＳ１０４〜Ｓ１０９では、初期ＵＲＬに対応するＨＴＭＬデータ、及び当該ＨＴＭＬデータに係る画面を起点として遷移可能な全てのＨＴＭＬデータに関して、動的解析等が実行される。具体的には、静的解析で取得された各リクエストに対する遷移先を全て網羅するように、動的解析として、初期ＵＲＬに対応する画面を起点として実際にテスト対象の画面操作が自動的に実施される。動的解析では、各画面上の全てのリンクに対してクリックを実施し、入力フォームとそれに対応するサブミットボタンが有る場合には、サブミットボタンを押したときのリクエストに対して、静的解析で取得したそのリクエストの遷移先の数を満たすまで、テスト入力値が生成され、画面操作が繰り返される。リクエストの遷移先の数を満たしたか否かについては、遷移先の画面について、既に遷移した画面との比較を行い、新規に遷移した画面かどうかの判断を行って、到達画面数をカウントする。以上の動的解析によって遷移先画面の情報（ＨＴＭＬ、ＵＲＬ等）と画面間の繋がり、画面に到達するための手段が取得される。また、コントローラを通らない画面遷移が動的解析で発見された場合、その画面遷移の情報も追加される。コントローラを通らない画面遷移とは、例えば、ａタグでのリンクがクリックされた場合に発生する画面遷移である。

以下、ステップＳ１０４〜Ｓ１０９の間で処理対象とされているＨＴＭＬデータを、「対象ＨＴＭＬ」という。

ステップＳ１０５において、テストシナリオ生成部１２は、対象ＨＴＭＬに係る画面（以下、「対象画面」という。）に対するテストシナリオを生成する。すなわち、対象画面において画面の遷移を発生させる画面要素（リンクやサブミットボタン等）ごとに、操作及びロケータの組からなるテストシナリオが生成される。操作は、クリック等の操作である。ロケータは、操作の対象とされる画面要素の識別情報である。

続くステップＳ１０６〜Ｓ１０８は、ステップＳ１０５において生成されたテストシナリオごとに実行される。Ｓ１０６〜Ｓ１０８において処理対象とされているテストシナリオを、以下「対象テストシナリオ」という。

ステップＳ１０７において、テストシナリオ生成部１２が、対象テストシナリオに基づいてテストケースを生成し、画面自動操作部１３が、当該テストケースを対象画面に対して実行する。その結果、画面遷移が発生する。なお、対象テストシナリオが、入力値を必要とする場合、ステップＳ１０７において、テスト入力値の生成が行われる。

遷移先の全ての画面（ＨＴＭＬ）に対してステップＳ１０４〜Ｓ１０９が実行されると、テスト資材生成部１５は、画面遷移図を生成する（Ｓ１１０）。具体的には、テスト資材生成部１５は、生成された画面遷移情報リストと、ステップＳ１０４〜Ｓ１０９において実際に発生した画面遷移とを比較して、テストにおいて発生しなかった画面遷移が有れば当該画面遷移を抽出（検出）し、遷移することのできた画面遷移と遷移することのできなかった画面遷移の情報を合わせた画面遷移図を生成する。遷移することができなかった画面遷移に対しては、テストスクリプトも生成できていないため、人手で作成する等のサポートが行われてもよい。

図８は、画面遷移図の一例を示す図である。図８では、画面Ａから画面Ｂ及び画面Ｃに遷移し、画面Ｃから画面Ｂに遷移することが示されている。また、破線の矩形は、仕様では遷移する予定であるが、テストにおいて遷移が発生しなかった画面を示す。すなわち、ソースコードでは、画面Ｃから遷移する画面が有ることが定義されているが、動的解析では当該画面への遷移が発生しなかったことを示す。

続いて、テスト資材生成部１５は、各画面遷移が発生したときのテストシナリオとテスト入力値とをテストスクリプトの形式で出力する（Ｓ１１１）。

続いて、ステップＳ１０１の詳細について説明する。図９は、辞書の生成処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ２０１において、テストシナリオ生成部１２は、サーバ装置２０におけるＤＢデータを読み込む。当該ＤＢデータは、ネットワークを介して取得されてもよい。

続いて、テストシナリオ生成部１２は、ＤＢデータの各カラム（各列）についてステップＳ２０２〜Ｓ２１０を実行する。以下、処理対象とされているカラムを「対象カラム」という。

続いて、テストシナリオ生成部１２は、ＤＢデータの行方向の各レコードの対象カラムの値ごとに、ステップＳ２０３〜Ｓ２０５を実行する。ステップＳ２０４において、テストシナリオ生成部１２は、処理対象の値のカテゴリや型等を分析して、当該値の上位語を抽出する。上位語の抽出は、例えば、ＷｏｒｄＮｅｔ（"日本語 WordNet"、http://nlpwww.nict.go.jp/wn-ja/）等の単語のデータベースを用いて行うことができる。例えば、当該値が「電信 太郎」であれば、「名字、名前」といった上位語が抽出される。また、当該値が電話番号であれば、「電話番号」といった上位語が抽出される。

全てのレコードについて対象カラムの値の上位語が抽出されると、テストシナリオ生成部１２は、対象カラムについて最も多く抽出された上位語を、対象カラムに対するタグとして特定する（Ｓ２０６）。

続くステップＳ２０７〜Ｓ２０９において、テストシナリオ生成部１２は、各レコードの対象カラムの値を処理対象として、ステップＳ２０８を実行する。ステップＳ２０８において、テストシナリオ生成部１２は、処理対象の値とステップＳ２０６において特定されたタグとをセットとし、当該セットを辞書に追加する。

続いて、図６のステップＳ１０２の詳細について説明する。図１０は、画面遷移情報の抽出処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ３０１において、画面遷移情報抽出部１１は、コントローラのソースコードを読み込む。当該ソースコードは、予め補助記憶装置１０２に記憶されていてもよい。

続いて、画面遷移情報抽出部１１は、ソースコードから検出されるリクエストごとにステップＳ３０２〜３０４を実行する。ステップＳ３０３において、画面遷移情報抽出部１１は、処理対象のリクエストに対する遷移先の数をソースコードを参照して特定し、当該リクエストと当該数との組を、画面遷移情報リストに追加する。したがって、画面遷移情報リストには、ソースコード（仕様）において予定されている全ての画面遷移の情報が登録される。

続いて、図６のステップＳ１０７の詳細について説明する。図１１は、テストケースの生成及び実行処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ４０１において、テストシナリオ生成部１２は、対象テストシナリオの操作にフォームへの入力操作が含まれているか否かを判定する。対象テストシナリオの操作にフォームへの入力操作が含まれていない場合（Ｓ４０１でＮｏ）、テストシナリオ生成部１２は、対象テストシナリオをそのままテストケースとする（Ｓ４０２）。続いて、画面自動操作部１３は、当該テストケースを対象画面に対して実行する（Ｓ４０３）。当該テストケースの実行により、画面遷移が発生する。続いて、画面評価部１４は、テストケースの実行によるリンクのクリックやボタンの押下により発生したリクエストを「リクエストＡ」として記憶する（Ｓ４０５）。

続いて、画面評価部１４は、ステップＳ４０３で遷移した画面が既に遷移したことのある画面か否かをＵＲＬやＨＴＭＬ等の情報を用いて判定する（Ｓ４０５）。この際、ステップＳ４０３で遷移した画面が未だ遷移したことのない画面である場合、当該遷移に関する情報が、遷移リストの要素として追加される。遷移リストとは、動的解析において発生した画面間の遷移に関する情報を要素とするリストである。当該要素は、遷移前画面のＵＲＬ、遷移後画面のＵＲＬ、リクエストＡ、遷移後画面のＨＴＭＬ、及びテストケース等を含む。

一方、対象テストシナリオの操作にフォームへの入力操作が含まれている場合（Ｓ４０１でＹｅｓ）、テストシナリオ生成部１２は、フォームへの入力値（テスト入力値）を生成する（Ｓ４０６）。例えば、対象画面が図１２に示される通りであれば、対象テストシナリオには、姓に対応するフォームへの入力操作、名に対応するフォームへの入力操作、メールアドレスに対応するフォームへの入力操作、及び登録ボタンの押下等が含まれている。したがって、この場合、フォームごとにテスト入力値が生成される。１つのフォームに対して複数のテスト入力値が生成される可能性が有る。そこで、続くステップＳ４０７〜Ｓ４１２は、各フォームに対するテスト入力値の組み合わせごとに実行される。当該組み合わせは、全通りの組合せであってもよいし、全通りの中から所定数の組み合わせが抽出されたものであってもよい。全通りの組み合わせとは、例えば、姓についてＮ個のテスト入力値が生成され、名についてＭ個のテスト入力値が生成され、メールアドレスについてＬ個のテスト入力値が生成された場合、Ｎ×Ｍ×Ｌ通りの組み合わせをいう。以下、処理対象の組み合わせを、「対象組み合わせ」という。

ステップＳ４０８において、テストシナリオ生成部１２は、対象組み合わせに属する各テスト入力値がそれぞれに対応するフォームへの入力対象とされたテストケースを、対象テストシナリオに基づいて生成する。続いて、画面自動操作部１３は、当該テストケースを対象画面に対して実行する（Ｓ４０９）。すなわち、対象テストシナリオにおいて値の入力先とされている各フォームに対して対象組み合わせに属するテスト入力値が入力され、対象テストシナリオにおいて押下対象とされているサブミットボタンが押下される。その結果、画面遷移が発生する。

続いて、画面評価部１４は、ボタンの押下により発生したリクエストを「リクエストＡ」として記憶する（Ｓ４１０）。続いて、画面評価部１４は、ステップＳ４０５と同様の処理を実行する（Ｓ４１１）。

全ての組み合わせについてステップＳ４０７〜Ｓ４１２が実行されると、画面評価部１４は、遷移リストにおけるリクエストＡに対する遷移後画面のＵＲＬの数（すなわち、リクエストＡを含む要素の数、以下「動的遷移数」という。）が、画面遷移情報リストにおいてリクエストＡに対応する遷移先ＵＲＬの数（以下、「静的遷移数」という。）に等しいか否かを判定する（Ｓ４１３）。すなわち、ステップＳ４１３では、リクエストＡに関してソースコードに定義されている全ての遷移が検出されたか否かが判定される。

動的遷移数が、静的遷移数に等しい場合（Ｓ４１３でＹｅｓ）、対象テストシナリオについては、図１１の処理が終了する。動的遷移数が、静的遷移数に達していない場合（Ｓ４１３でＮｏ）、ステップＳ４０６以降が繰り返される。すなわち、対象テストシナリオについて、異なるテスト入力値の組み合わせが生成されてテストケースが実行される。なお、静的遷移数を網羅するテスト入力値を生成できるとは限らない。したがって、ステップＳ４１３がＮｏの場合のループの回数には上限が設けられてもよい。

続いて、ステップＳ４０６の詳細について説明する。図１３は、テスト入力値の生成処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ５０１〜Ｓ５０６は、対象テストシナリオにおいて入力対象とされるフォームごとに実行される。以下、処理対象のフォームを「対象フォーム」という。

続くステップＳ５０２〜Ｓ５０５では、対象フォームの周辺情報に基づいて、対象フォームに対するテスト入力値が生成される。対象フォームの周辺情報とは、例えば、対象ＨＴＭＬのＤＯＭツリーにおける対象フォームの周辺要素群である。フォームの周辺要素とは、例えば、フォームのｉｄ、ｎａｍｅ、ｃｌａｓｓ、ｖａｌｕｅ、テキスト等の付随情報又は属性情報等である。すなわち、１つのフォームに対して周辺要素は複数存在しうる。したがって、ステップＳ５０２〜Ｓ５０５は、対象フォームの周辺要素ごとに実行される。以下、処理対象の周辺要素を「対象周辺要素」という。

ステップＳ５０３において、テストシナリオ生成部１２は、対象周辺要素の値の上位語を抽出する。具体的には、テストシナリオ生成部１２は、対象フォームの項目名を正規表現マッチング技術等を用いて推測する。例えば、対象周辺要素がｉｄであり、「ｉｄ＝ａｄｄｒｅｓｓ」であれば、テストシナリオ生成部１２は、対象フォームが「住所」を入れるフォームである（対象フォームの項目名が「住所」である）と推測する。この場合「住所」が対象周辺要素の値の上位語として抽出される。

続いて、テストシナリオ生成部１２は、抽出された上位語に一致するタグに対応付けられている値を辞書から抽出し、当該値を対象フォームに対するテスト入力値の一つとする（Ｓ５０４）。ステップＳ５０２〜Ｓ５０５が対象フォームの各周辺要素について実行されると、対象フォームについて１以上のテスト入力値が生成される。

続いて、図１１のステップＳ４０５及びＳ４１１の詳細について説明する。図１４は、遷移先画面の判定処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ６０１において、画面評価部１４は、遷移リストの中のリクエストＡを含むいずれかの要素の中に、現在の遷移先画面（すなわち、対象画面）のＵＲＬが遷移後画面のＵＲＬとして含まれているか否かを判定する。現在の遷移先画面のＵＲＬがリクエストＡの遷移後画面のＵＲＬとして遷移リストに含まれていない場合（Ｓ６０１でＮｏ）、画面評価部１４は、リクエストＡ、遷移前画面のＵＲＬ、現在の遷移先画面のＵＲＬ、現在の遷移先画面のＨＴＭＬ（対象ＨＴＭＬ）、及び対象テストシナリオに係るテストケースをセットとする要素を遷移リストに追加する（Ｓ６０２）。

一方、現在の遷移先画面のＵＲＬがリクエストＡの遷移後画面のＵＲＬとして遷移リストに含まれている場合（Ｓ６０１でＹｅｓ）、画面評価部１４は、遷移リストにおいてリクエストＡを含み、かつ、現在の遷移先画面のＵＲＬを遷移後画面のＵＲＬとして含む要素の遷移後画面のＨＴＭＬデータごとに、ステップＳ６０３〜Ｓ６１１を実行する。以下、処理対象とされているＨＴＭＬを「対象遷移済みＨＴＭＬ」という。また、現在の遷移先画面のＨＴＭＬを、上記において定義した通り「対象ＨＴＭＬ」という。

続いて、画面評価部１４は、対象遷移済みＨＴＭＬ及び対象ＨＴＭＬのそれぞれについて、ステップＳ６０４〜Ｓ６０８を実行する。対象遷移済みＨＴＭＬ及び対象ＨＴＭＬのうち、処理対象とされているＨＴＭＬを、「着目ＨＴＭＬ」という。

ステップＳ６０５において、画面評価部１４は、着目ＨＴＭＬのＤＯＭツリーを生成する。図１５にＤＯＭツリーの一例を示す。図１５に示されるように、ＤＯＭツリーは、各ノード（各画面要素）の階層構造を示す。

続いて、画面評価部１４は、画面の役割に影響を与えない（すなわち、画面の識別に影響を与えない）ノードを、ＤＯＭツリーから削除する（Ｓ６０６）。画面の役割に影響を与えないノードとは、属性ノード、テキストノード、及び文字の大きさや字体、位置を表すノード（Ｃｅｎｔｅｒタグ、Ｕタグなど）等の３種類である。したがって、図１５において破線の矩形で示されているノードが削除される。

続いて、画面評価部１４は、ＤＯＭツリーにおいて並列関係を有するノード（並列ノード）を１つのノードに集約する（Ｓ６０７）。並列ノードとは、ＤＯＭツリーの階層構造において同じ階層に属する同じタグ名の複数のノードをいう。図１５では、１点鎖線で囲まれている２つの＜ｈ１＞タグに対応するノードが並列ノードに該当する。ノードの集約は、並列ノードのうちの１つを残して他を削除することによって実現されてもよいし、各ノードを抽象化した１つのノードによって、並列ノードを置換することによって実現されてもよい。

ステップＳ６０４〜Ｓ６０８が対象遷移済みＨＴＭＬ及び対象ＨＴＭＬのそれぞれについて実行されることにより、それぞれについて抽象化されたＤＯＭツリーが生成される。

続いて、画面評価部１４は、抽象化された２つのＤＯＭツリーのそれぞれをＨＴＭＬに変換し、変換結果を比較して、比較結果を出力する（Ｓ６０９）。すなわち、対象遷移済みＨＴＭＬに係る画面と、対象ＨＴＭＬに係る画面との同一性が判定される。比較されたＨＴＭＬが一致する場合、「一致」が比較結果として出力される。そうでない場合、「不一致」が比較結果として出力される。なお、比較されたＨＴＭＬの一致には、完全一致が要求されなくてもよい。例えば、同一タグの出現順等が異なることが許容されてもよい。

比較結果が「一致」である場合（Ｓ６１０でＹｅｓ）、対象遷移済みＨＴＭＬに関する処理は終了する。比較結果が「不一致」である場合（Ｓ６１０でＮｏ）、画面評価部１４は、ステップＳ６０２と同じ処理を実行して（Ｓ６１２）、図１４の処理を終了する。

続いて、図６のステップＳ１１０の詳細について説明する。図１６は、画面遷移図の生成処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ７０１〜Ｓ７０３は、遷移リストに含まれている要素（遷移前画面のＵＲＬ、遷移後画面のＵＲＬ、リクエスト、遷移後画面のＨＴＭＬ、及びテストケースのセット）ごとに実行される。以下、処理対象の要素を「対象要素」という。

ステップＳ７０２において、テスト資材生成部１５は、画面遷移図リストに、対象要素のリクエスト、対象要素の遷移前画面のＵＲＬ、対象要素の遷移後画面のＵＲＬを含む要素を追加する。すなわち、画面遷移図リストは、リクエスト、遷移前画面のＵＲＬ、遷移後画面のＵＲＬのセットを一つの要素とするリストである。

ステップＳ７０４〜Ｓ７０９は、画面遷移図リストの要素ごとに実行される。以下、処理対象の要素を「対象要素」という。

ステップＳ７０５において、テスト資材生成部１５は、画面遷移図リストにおいて、リクエスト及び遷移前画面のＵＲＬが対象要素と共通する要素数をカウントする。当該要素数は、動的解析において同じ画面（遷移前画面）から同じリクエストに基づいて遷移した画面の数である。以下、当該要素数を「動的遷移数ｎ」という。

続いて、テスト資材生成部１５は、対象要素のリクエストに対応する遷移先の数を画面遷移情報リストから取得する（Ｓ７０６）。当該遷移先の数は、静的解析においてソースコードから抽出された当該リクエストの遷移先の数である。以下、当該遷移先の数を「静的遷移数ｍ」という。

続いて、テスト資材生成部１５は、動的遷移数ｎが静的遷移数ｍ以上であるか否かを判定する（Ｓ７０７）。動的遷移数ｎが静的遷移数ｍ以上である場合（Ｓ７０７でＹｅｓ）、対象要素に対する処理は終了する。動的遷移数ｎが静的遷移数ｍ未満である場合（Ｓ７０７でＹｅｓ）、テスト資材生成部１５は、動的な遷移と静的な遷移との差異を検出する。すなわち、動的解析において遷移していない画面の存在が検出される。そこで、テスト資材生成部１５は、対象要素のリクエストと対象要素の遷移前画面のＵＲＬとを含む要素を、ｍ−ｎの数だけ画面遷移図リストに追加する（Ｓ７０８）。すなわち、図８の破線の矩形に対応する遷移に係る要素が追加される。

画面遷移図リストの全ての要素に対してステップＳ７０４〜Ｓ７０９が実行されると、テスト資材生成部１５は、画面遷移図リストに基づいて、画面遷移図を生成する（Ｓ７１０）。この際、遷移後画面のＵＲＬが無い要素については、破線の矩形等、遷移できなかった画面として表現される。なお、生成された画面遷移図は、表示装置１０６に表示されてもよいし、画面遷移図を示すデータが、補助記憶装置１０２に保存されてもよい。

続いて、図６のステップＳ１１１の詳細について説明する。図１７は、テストスクリプトの出力処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ８０１〜Ｓ８０３において、テスト資材生成部１５は、遷移リストの各要素に含まれているテストケースをスクリプトの形式で出力することで、テストスクリプトを出力する。

上述したように、本実施の形態によれば、Ｗｅｂアプリケーションの仕様として予定された画面遷移の情報（静的な画面遷移の情報）をソースコードから抽出し、Ｗｅｂアプリケーションに対する操作を自動的に実行して画面遷移を繰り返すことで発生した画面遷移の情報（動的な画面遷移の情報）を自動的に抽出し、静的な画面遷移の情報と動的な画面遷移の情報との差異を検出することができる。その結果、ソースコード上で定義されていながらテストスクリプトでは発生させることができない画面遷移を検出することができる。すなわち、Ｗｅｂアプリケーションに関して自動生成されるテストスクリプトでは実現できない画面遷移の検出を可能とすることができる。したがって、例えば、Ｗｅｂアプリケーションの不具合を市場流出前において検知できる可能性と高めることができ、短期開発をも可能とすることができる。

また、本実施の形態によれば、テスト対象から仕様をリバースし、リバースした仕様に基づいてテストケースを自動生成し、テストスクリプトとして出力することができる。これによりＷｅｂアプリケーションにおける網羅的な画面遷移テストのテストスクリプト生成を追加の稼働を必要とせずに自動で行うことができる。その結果、例えば、ソフトウェアテストにかかる費用を削減することができる。

また、本実施の形態によれば、技術課題１に関して、テスト対象から自動で、テスト対象を構成する画面と画面間の繋がり、各画面に到達するための手段を漏れなくリバースすることができる。また、静的解析によって、予めリクエストに対する画面遷移数の情報が入手できるため、動的解析中に探索打切りの判断を下しやすくなり、現実的な時間内で処理を行うことができる。本実施の形態ではサーバサイドの情報は必要としないため、ユーザはサーバサイドの情報を取得できるようにする環境を整える必要が無く、ツール導入のための追加稼働を抑えることができる。

また、本実施の形態によれば、技術課題２に関して、クライアントサイドの情報（ＨＴＭＬ）を用いて、画面遷移を実現するための適切なテスト入力値を生成することができる。従来技術と異なり、サーバサイドの情報は必要としないため、ユーザはサーバサイドの情報を取得できるようにする環境を整える必要が無く、ツール導入のための追加稼働を抑えることができる。

更に、本実施の形態によれば、技術課題３に関して、閾値の設定を必要とせずに機能テストにおける適切な画面識別が可能となり、検証パターンの質を向上させることができる。

なお、本実施の形態において、クライアント装置１０は、差異検出装置の一例である。画面遷移情報抽出部１１は、抽出部の一例である。画面自動操作部１３は、操作部の一例である。画面評価部１４は、生成部の一例である。テスト資材生成部１５は、検出部の一例である。テストシナリオ生成部１２は、生成部の一例である。ＨＴＭＬデータは、画面の記述情報の一例である。画面遷移情報リストは、第１の画面遷移の情報の一例である。遷移リストは、第２の画面遷移の情報の一例である。ＨＴＭＬデータは、記述情報の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ クライアント装置
１１ 画面遷移情報抽出部
１２ テストシナリオ生成部
１３ 画面自動操作部
１４ 画面評価部
１５ テスト資材生成部
２０ サーバ装置
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
Ｂ バス

Claims (6)

1. Ｗｅｂアプリケーションのソースコードから、前記ソースコードにおいて定義された第１の画面遷移の情報を抽出する抽出部と、
   前記Ｗｅｂアプリケーションに関して表示される画面を自動的に操作する操作部と、
   自動的な操作によって実現される第２の画面遷移の情報を生成する生成部と、
   前記第１の画面遷移の情報と前記第２の画面遷移の情報との差異を検出する検出部と、
   を有することを特徴とする差異検出装置。
2. 前記生成部は、前記第２の画面遷移の情報に係る第１の画面の記述情報と第２の画面の記述情報とのそれぞれに対して所定の編集を行い、編集後の記述情報を比較して、前記第１の画面と前記第２の画面との同一性を判定する、
   ことを特徴とする請求項１記載の差異検出装置。
3. 前記所定の編集は、並列関係を有する画面要素を集約することである、
   ことを特徴とする請求項２記載の差異検出装置。
4. 前記所定の編集は、画面の識別に影響を与えない画面要素を削除することである、
   ことを特徴とする請求項２記載の差異検出装置。
5. 前記Ｗｅｂアプリケーションに関して表示される画面において値の入力先とされる画面要素について、当該画面の記述情報において当該画面要素について定義されている情報に基づいて、入力値を生成する生成部を有し、
   前記操作部は、前記生成部によって生成された入力値を入力する、
   ことを特徴とする請求項１乃至４いずれか一項記載の差異検出装置。
6. Ｗｅｂアプリケーションのソースコードから、前記ソースコードにおいて定義された第１の画面遷移の情報を抽出する抽出部と、
   前記Ｗｅｂアプリケーションに関して表示される画面を自動的に操作する操作部と、
   自動的な操作によって実現される第２の画面遷移の情報を生成する生成部と、
   前記第１の画面遷移の情報と前記第２の画面遷移の情報との差異を検出する検出部と、
   としてコンピュータを機能させることを特徴とするプログラム。

Images