JP2019101889A - テスト実行装置及びプログラム - 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）の構成において、クライアントサイドからのリクエストに対して実行する処理を決定するコントローラに着目する。例えば、サーブレットがコントローラの一例である。コントローラが割り振る遷移を静的解析で全て把握し、その後の動的解析でそれらの遷移を網羅することで、テスト対象を構成する画面と画面間の繋がり、各画面に到達するための手段を漏れなくリバースすることができる。従来手法との違いとして、本実施の形態ではコントローラにのみ着目するため、クライアントサイドの情報からコントローラの示す遷移先をどの程度網羅できたかを推測することができ、ログを取得するための環境を用意する稼働を不要、又は少なくすることができるといった利点が挙げられる。従来のプログラムの実行パスを取得する方法では、実行パスの詳細な情報をクライアントサイドから推測することは不可能である。

［技術課題２：画面遷移を実現するための適切な入力値生成方法の検討］
＜従来技術と問題点＞
画面遷移を実現するための適切な入力値を生成するための方法として、Search Based Software Testing（以下「ＳＢＳＴ」という。）を用いた手法が存在する（N. Alshahwan and M. Harman, "Automated web application testing using search based software engineering," 2011 26th IEEE/ACM International Conference on Automated Software Engineering (ASE 2011), Lawrence, KS, 2011, pp. 3-12.）。ＳＢＳＴを用いた入力値生成では、達成したい要件に対する達成度合いを定量的に評価できるように設計された評価関数に基づいて、ヒューリスティック探索アルゴリズムを用いて、達成したい要件を満足するテスト入力値を生成する。例えば入力値ａに対して「ａ＞１０」の場合にのみ遷移する画面遷移が存在した場合、評価関数を「ａ−１０」と置く。この時、評価関数の値が０より大きい場合に所望の画面遷移を実現することができる。最初に入力値ａ＝０とした場合、評価関数の値は、−１０となる。次に入力値ａ＝２とした場合、評価関数の値は、−８となり、所望の画面遷移を実現するための条件である、評価関数の値が０より大きいという条件に近づく。したがって入力値ａの値が大きい方が良いと判断し、徐々に入力値ａの値を大きくしていくことで、ａ＝１２等の所望の画面遷移を実現するための値を生成することができる。

ＳＢＳＴを用いた入力値生成は、上記の数値型の例のように、所望の画面遷移を実現するための条件を、定量的な評価が可能な評価関数と置くことができる単純な場合には有効である。しかし、入力フォームにどのような入力値が求められているのかを判断し、判断結果に基づいて適切な入力値を与える必要がある場合には、定量的な評価が可能な評価関数を設計することが困難なため、有効ではない。具体的には、氏名やメールアドレスなどの文字列型を入力とし、型チェックを行って問題なければ正常系の画面に遷移する場合においては、型チェックの条件（メールアドレスであればアットマークを含んでいるかどうかなど）を、定量的な評価が可能な評価関数と置くことが困難なため、適切な入力値を生成することは難しい。また、適切な入力値が生成できなかった場合、当該入力値の入力フォームが存在する画面に対するテストについては、ユーザがすべて人手で実施する必要があり、その画面に遷移までの画面操作の手間なども含めると、多くの稼働がかかってしまう。具体的には、図２に示される画面ｇ１の入力フォームの入力値は、メールアドレスであるべきところ、当該入力フォームに対して適切な入力値を生成するのは困難である。したがって、画面ｇ２への遷移は容易だが、画面ｇ３への遷移には多くの稼動がかかってしまう。

＜本実施の形態における提案：入力フォームの周辺情報を用いたテスト入力値生成とユーザによる補助技術＞
本実施の形態は、２つのステップから構成される。第１ステップでは、ラベル等の入力フォームの周辺情報（すなわち、画面の記述情報のうち入力フォームに対応する記述部分から抽出される情報）を用いて、どのような種類の入力値が求められているのか判断し、求められている内容に対応する具体的な単語を予め用意された辞書から取得し、当該単語を入力値として与えることで、各入力フォームに合った適切な入力値を与えることができる。

第２ステップでは、第１ステップで適切な入力値を生成できなかった入力フォームの情報をユーザに提示し、入力値の補助をユーザに求めることで、入力値だけを与えるという必要最低限の稼働で、自動生成できなかった箇所の補完を行うことができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

続いて、テスト資材生成部１５は、画面遷移図において、遷移できなかった箇所の有無を判定する（Ｓ１１０）。すなわち、図９において、破線の矩形に該当する箇所の有無が判定される。

該当箇所が無い場合（Ｓ１１０でＮｏ）、テスト資材生成部１５は、各画面遷移が発生したときのテストシナリオとテスト入力値とをテストスクリプトの形式で出力する（Ｓ１１２）。

一方、該当箇所が有る場合（Ｓ１１０でＹｅｓ）、テスト資材生成部１５は、テストケースに対する入力値の補助をユーザから受けるための処理を実行する（Ｓ１１１）。ステップＳ１１１に続いて、ステップＳ１０１以降が再実行される。

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

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

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

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

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

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

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

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

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

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

動的遷移数が、静的遷移数に等しい場合（Ｓ４１３でＹｅｓ）、対象テストシナリオについては、図１１の処理が終了する。動的遷移数が、静的遷移数に達していない場合、すなわち、動的遷移が静的遷移に対して不足する場合（Ｓ４１３でＮｏ）、画面評価部１４は、対象画面の各フォームに対するテスト入力値としてテストシナリオ生成部１２が生成しうる全ての入力値が生成されたか否かを判定する（Ｓ４１４）。テストシナリオ生成部１２が生成しうる全ての入力値が生成されていない場合、すなわち、テストシナリオ生成部１２によって、異なる入力値の生成の余地が有る場合（Ｓ４１４でＮｏ）、ステップＳ４０６以降が繰り返される。この場合、対象テストシナリオについて、異なるテスト入力値の組み合わせが生成されてテストケースが実行される。

一方、対象画面の各フォームに対するテスト入力値としてテストシナリオ生成部１２が生成しうる全ての入力値が生成された場合（Ｓ４１４でＹｅｓ）、テスト資材生成部１５は、入力情報補助ファイルに、対象画面のＵＲＬ及びタイトルと、対象画面の各フォームの周辺情報（ラベル、ｉｄ及びｎａｍｅ）等を追加（記録）する（Ｓ４１５）。すなわち、入力情報補助ファイルには、全ての画面遷移を網羅する入力値を生成できなかった画面ごとに、ＵＲＬ、タイトル、各フォームの周辺情報が記録される。ここで入力情報補助ファイルに登録されたフォームに対する入力値の入力が、図７のステップＳ１１１においてユーザによって補助される。

なお、入力情報補助ファイルの形式は所定のものに限定されないが、例えば、表形式ファイルが好適である。また、入力情報補助ファイルは、例えば、補助記憶装置１０２に記憶される。

なお、ステップＳ４１４の判定は、ステップＳ４０６以降の繰り返し回数が上限に達したか否かに基づいて行われてもよい。

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

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

ステップＳ５０２において、テストシナリオ生成部１２は、対象フォームの周辺情報（又は属性情報）を対象ＨＴＭＬから取得する。本実施の形態では、対象フォームのラベル（ｌａｂｅｌ）、ｉｄ及びｎａｍｅ等が周辺情報として取得される。例えば、対象フォームが、図１２の３つ目のフォーム（メールアドレスの入力フォーム）である場合に、当該フォームに関するＨＴＭＬの記述情報が図１４の通りであったとすると、ラベル（ｌａｂｅｌ）として「メールアドレスを入力して下さい」、ｉｄとして「ｍａ」、ｎａｍｅとして「ｍａｉｌ」が取得される。

続いて、テストシナリオ生成部１２は、当該周辺情報と、対象画面のＵＲＬ及びタイトルとの組み合わせが、入力情報補助ファイルに登録されているか否かを判定する（Ｓ５０３）。すなわち、対象フォームが入力情報補助ファイルに登録されているか否かが判定される。

対象フォームが入力情報補助ファイルに登録されていない場合（Ｓ５０３でＮｏ）、テストシナリオ生成部１２は、ステップＳ５０２において取得された周辺情報としての各文字列を形態素解析技術を用いて単語に分割する（Ｓ５０４）。上記の例によれば、例えば、［"メールアドレス"、"入力"、"ｍａｉｌ"、"ｍａ"］といった単語群が得られる。

続くステップＳ５０５〜Ｓ５０７では、当該単語群に含まれる単語ごとに、ステップＳ５０６が実行される。以下、処理対象の単語を「対象単語」という。ステップＳ５０６において、テストシナリオ生成部１２は、予め用意された辞書から対象単語に対応する値を検索し、検索された値を対象フォームに対する入力値とする。

図１５は、辞書の一例を示す図である。図１５に示されるように、辞書は、項目ごとに項目名と、当該項目に関する具体的な値とを含む情報であり、例えば、補助記憶装置１０２等に記憶されている。又は、何らかのシステムのユーザの属性情報を記憶したＤＢが辞書として利用されてもよい。

ステップＳ５０６において、テストシナリオ生成部１２は、対象単語に一致する項目名を辞書から検索する。但し、同意語辞書を用いて、対象単語に類似した意味を有する項目名が検索されてもよい。該当する項目名が検索された場合、テストシナリオ生成部１２は、当該項目名に係る項目に登録されている具体的な値を入力値として取得する。該当する項目名が検索されない場合、入力値は取得されない。

例えば、［"メールアドレス"、"入力"、"ｍａｉｌ"、"ｍａ"］の中では、"メールアドレス"が対象単語である場合に、入力値として、例えば「ｘｘｘ＠ｘｘｘ．ｘｘ」が取得される。なお、［"メールアドレス"、"入力"、"ｍａｉｌ"、"ｍａ"］の例では、１つの入力値しか取得されないが、それぞれ別の項目名に一致するような複数の単語が周辺情報から抽出されたフォームに関しては、複数の入力値が生成される可能性も有る。

一方、対象フォームが入力情報補助ファイルに登録されている場合（Ｓ５０３でＹｅｓ）、テストシナリオ生成部１２は、対象フォームの周辺情報等に対応付けられて入力情報補助ファイルに記録されている値を入力値として取得する（Ｓ５０９）、この場合、対象フォームに関する処理は終了する。なお、対象フォームに関して図１９のステップＳ１１１が実行されていれば、対象フォームに対する入力値が入力情報補助ファイルに記録されている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

続いて、図７のステップＳ１１１の詳細について説明する。図１９は、テストケースに対する入力値の補助処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ８０１において、テスト資材生成部１５は、入力情報補助ファイルを表示装置１０６に表示する。

図２０は、入力情報補助ファイルの表示例を示す図である。図２０に示されるように、入力情報補助ファイルは、全ての画面遷移を達成することの出来なかった画面ごとに「ＵＲＬ」及び「タイトル」と、当該画面のフォームごとに、「ラベル」、「ｉｄ」、「ｎａｍｅ」、「値」等を記憶可能な形式を有する。このうち、「ＵＲＬ」、「タイトル」、「ラベル」、「ｉｄ」及び「ｎａｍｅ」の値は、図１１のステップＳ４１５において登録されている。

続いて、テスト資材生成部１５は、入力情報補助ファイルを介して、各フォームの「値」の入力をユーザから受け付ける（Ｓ８０２）。すなわち、ユーザは、入力情報補助ファイルに登録されている各フォームについて、「ラベル」、「ｉｄ」及び「ｎａｍｅ」等を手がかりとして、該フォームに対して適切な値を推測し、当該値を各フォームの「値」に入力する。

続いて、テスト資材生成部１５は、「値」が入力された状態の入力情報補助ファイルを保存する（Ｓ８０３）。

なお、入力情報補助ファイルの「値」に対して値が入力された後で、ステップＳ１０１が実行された場合、図１３のステップＳ５０３では、入力情報補助ファイルに登録された各フォームに関してＹｅｓの判定となる。したがて、ステップＳ５０９において、当該各フォームについては、入力情報補助ファイルから入力値が取得される。その結果、前回では実現できなかった画面遷移を実現できる可能性が高まる。

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

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

上述したように、本実施の形態によれば、Ｗｅｂアプリケーションの仕様として予定された画面遷移の情報（静的な画面遷移の情報）をソースコードから抽出し、Ｗｅｂアプリケーションに対する操作を自動的に実行して画面遷移を繰り返すことで発生した画面遷移の情報（動的な画面遷移の情報）を自動的に抽出し、静的な画面遷移の情報と動的な画面遷移の情報との差異を検出することができる。その結果、ソースコード上で定義されていながらテストスクリプトでは発生させることができない画面遷移を検出することができる。この際に、本実施の形態では、テストスクリプトでは発生させることができなかった画面遷移の遷移元の画面の各入力領域（各フォーム）に関する周辺情報が、入力情報補助ファイルに記録される。その後、入力情報補助ファイルが表示され、当該各入力領域に対する入力値がユーザによって入力される。

したがって、ユーザによる入力値の入力負担を出来るだけ小さくすることができると共に、テストスクリプトでは発生させることができなかった画面遷移が実現される可能性を高めることができる。その結果、Ｗｅｂアプリケーションに関するテストの実行を効率化することができる。

また、ユーザから入力値を受け付ける際には、各入力フォームの周辺情報が表示される。したがって、ユーザは、当該周辺情報を手がかりとして、各入力フォームに適した値を推測することができる。

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

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

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

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

なお、本実施の形態において、クライアント装置１０は、テスト実行装置の一例である。画面遷移情報抽出部１１は、抽出部の一例である。テストシナリオ生成部１２は、第１の生成部の一例である。画面自動操作部１３は、操作部の一例である。画面評価部１４は、第２の生成部の一例である。テスト資材生成部１５は、受付部及び記録部、の一例である。ＨＴＭＬデータは、画面の記述情報の一例である。画面遷移情報リストは、第１の画面遷移の情報の一例である。遷移リストは、第２の画面遷移の情報の一例である。入力情報補助ファイル（補助記憶装置１０２）は、記憶部の一例である。

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

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

Claims (4)

1. Ｗｅｂアプリケーションのソースコードから、前記ソースコードにおいて定義された第１の画面遷移の情報を抽出する抽出部と、
   前記Ｗｅｂアプリケーションに関して表示される画面に対する入力値を生成する第１の生成部と、
   前記第１の生成部が生成した入力値を前記画面に入力し、前記画面を自動的に操作する操作部と、
   自動的な操作によって実現される第２の画面遷移の情報を生成する第２の生成部と、
   前記第２の画面遷移が前記第１の画面遷移に対して不足する場合に、不足する画面遷移の遷移元の画面に対する各入力領域に対する値の入力をユーザから受け付ける受付部とを有し、
   前記操作部は、前記受付部が受け付けた値を前記遷移元の画面に対して入力する、
   ことを特徴とするテスト実行装置。
2. 前記不足する画面遷移の遷移元の画面の各入力領域に関する情報を記憶部に記録する記録部を有し、
   前記受付部は、前記記憶部に記録された情報を当該情報に係る入力領域ごとに表示して、当該入力領域に対する値の入力をユーザから受け付ける、
   ことを特徴とする請求項１記載のテスト実行装置。
3. 前記入力領域に関する情報は、当該入力領域を含む画面の記述情報において、当該入力領域に関する記述部分から抽出される情報である、
   ことを特徴とする請求項２記載のテスト実行装置。
4. Ｗｅｂアプリケーションのソースコードから、前記ソースコードにおいて定義された第１の画面遷移の情報を抽出する抽出手順と、
   前記Ｗｅｂアプリケーションに関して表示される画面に対する入力値を生成する第１の生成手順と、
   前記第１の生成手順が生成した入力値を前記画面に入力し、前記画面を自動的に操作する操作手順と、
   自動的な操作によって実現される第２の画面遷移の情報を生成する第２の生成手順と、
   前記第２の画面遷移が前記第１の画面遷移に対して不足する場合に、不足する画面遷移の遷移元の画面に対する各入力領域に対する値の入力をユーザから受け付ける受付手順とをコンピュータに実行させ、
   前記操作手順は、前記受付手順が受け付けた値を前記遷移元の画面に対して入力する、
   ことを特徴とするプログラム。

Images