JP7211228B2 - 解析装置、解析方法、及びプログラム - Google Patents

Description

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

多様化する消費者ニーズに合ったサービスを迅速に提供するために、近年、ソフトウェア開発を短いサイクルで実施し、頻繁にサービスをリリースする開発スタイルが増加している。短いサイクルでサービスを提供することに伴い、ソフトウェアの動作の正常性を確認するためのソフトウェアテストの頻度も増加している。

ソフトウェアテストでは、テスト対象となるＷｅｂアプリケーションが、設計者の意図した通りに動作するかどうかを確認する機能テストが行われる。機能テストの中でも、画面遷移（Ｗｅｂページの遷移）に関わるテスト（以下、「画面遷移テスト」という。）に膨大な時間がかかることが問題となっている。ここでは、画面遷移テストを、「クライアントサイドからのインタラクションに対し、クライアントサイドに表示される画面から、Ｗｅｂアプリケーションが仕様通りに実装されているかどうかを確認するためのテスト」と定義する。

画面遷移テストが時間を要する理由は、クライアントサイドからのインタラクションとして、画面にあるリンクやボタンのクリック操作や、入力フォームに適切な値を入力するなどの人手を介する操作が求められるからである。これらの操作を全ての画面で繰り返し実施するため、膨大な時間を要しており、省力化が求められている。

画面遷移テストに要する時間を削減する方法として、テストケースをスクリプトで記述することで、画面遷移テストを自動実行する方法が知られている。しかし、テストスクリプトを作成する作業自体にも時間がかかるため、作成したテストスクリプトを使用した自動テストを３回以上実施しないと、作業時間の効果は表れないとも言われている。また、既存の機能に変更が加わることで、作成したテストスクリプトが使用できなくなるため、仕様変更が施されるたびにテストスクリプトを作り直す必要が出てくる。

このような課題を解決するために、テスト対象のＷｅｂアプリケーションのソースコードを解析することで仕様情報を復元し、復元された仕様情報からテストスクリプトを自動生成する、リバースベースのテストスクリプト自動生成技術（以下、「リバースベーステスト技術」という。）が考案されている（非特許文献１参照）。

倉林 利行, 伊山 宗吉, 切貫 弘之, 丹野 治門: "画面操作を伴うテストにおけるテストスクリプトの自動生成手法", ソフトウェアエンジニアリングシンポジウム2017論文集 pp. 260-264, 2017年9月

上述したとおり、リバースベーステスト技術は、テスト対象となるＷｅｂアプリケーションの画面を動的に解析しながら仕様をリバースし、網羅的なテストケースを生成することで、テストスクリプトを自動生成する方法である。この技術により、人手によるテストスクリプト作成の作業を必要とせずに画面遷移テストの自動化を実現することができる。

しかし、リバースベーステスト技術では、Ｗｅｂアプリケーションの画面に含まれる全ての画面要素（ボタン、リンクなど）を機械的に網羅的に自動操作しながら仕様をリバースしているため、網羅的な画面遷移テストが必ずしも必要ではない仕様情報についてまでも仕様を復元し、テストスクリプトとして生成してしまうという欠点が存在する。

その結果、仕様復元に要する時間が増大し、テストスクリプト自動生成のメリットを損なってしまったり、生成したテストスクリプトの中に不要なものが混じってしまったりするといった課題がある。

本発明は上記の点に鑑みてなされたものであり、リバースベーステスト技術において、網羅的な仕様復元を行うことで生じる仕様復元にかかる時間の増大を回避することを可能とする技術を提供することを目的とする。

開示の技術によれば、Ｗｅｂアプリケーションにより表示される画面を基準画面まで遷移させるスクリプトを実行するスクリプト実行手段と、
テストシナリオを生成するために、前記基準画面からの画面遷移のホップ数が予め定めた上限値以下となる範囲内で、前記Ｗｅｂアプリケーションに対する画面遷移を起こさせる画面の操作を実行する解析手段と
を備える解析装置が提供される。

開示の技術によれば、リバースベーステスト技術において、網羅的な仕様復元を行うことで生じる仕様復元にかかる時間の増大を回避することを可能とする技術が提供される。

テスト不要範囲を説明するための図である。 本発明の実施の形態の概要を説明するための図である。 本発明の実施の形態におけるシステム構成例を示す図である。 本発明の実施の形態におけるクライアント装置１０のハードウェア構成例を示す図である。 本発明の実施の形態におけるクライアント装置１０の機能構成例を示す図である。 クライアント装置１０の全体動作例を説明するためのフローチャートである。 クライアント装置１０の詳細動作例を説明するための擬似コードである。 ホップ数判定部１７の処理を示すフローチャートである。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

（実施の形態の概要）
本実施の形態では、非特許文献１に記載された既存のリバースベーステスト技術における動的解析の技術をベースとする。後述するクライアント装置１０は、当該ベースとなる技術に基づき、基本的には、以下のステップの処理を実行する。
（１）テスト対象のＷｅｂアプリケーションを解析し、仕様としてテスト対象を構成する画面と画面間の繋がり、各画面に到達するための手段を抽出する。
（２）（１）で取得した仕様から機能テストにおける画面遷移テストに適した画面遷移図を生成する。
（３）（２）で生成した画面遷移図の各遷移に対応するテストスクリプトを、（１）で抽出した画面に到達するための手段の情報に基づいて、出力したいスクリプト形式に合わせて出力する。

前述したように、既存のリバースベーステスト技術では、Ｗｅｂアプリケーションの画面に含まれる全ての画面要素（ボタン、リンクなど）を機械的に網羅的に自動操作しながら仕様をリバースしているため、網羅的な画面遷移テストが必ずしも必要ではない仕様情報についてまでも仕様を復元し、テストスクリプトとして生成してしまうという課題がある。

網羅的な画面遷移テストが不要な場合の例を図１を参照して説明する。図１に示す例は、Ｗｅｂアプリケーションによりクライアントに表示される様々な画面のうち、ログイン以降のメイン画面を基準とし、メイン画面からの遷移に注目したテストを実施したい場合の例を示している（図１における"テストしたい範囲"）。

それ以外の画面（図１における"テスト不要範囲"）については、仕様復元を回避することが時間削減のために重要である。これを実現するためには、例えば、メイン画面において"ログアウト"ボタンがある場合も考慮し、ボタン押下によってログイン画面まで遷移してしまい、テスト不要な範囲まで際限なく解析することを回避する必要がある。

図２は、テスト不要範囲についての仕様復元を回避することを実現するための技術のポイントを示している。図２に示すように、本実施の形態では、ポイント１として、基準となるメイン画面までの遷移をクライアントで実行するスクリプトで実現し、基準画面から解析を開始することとしている。また、ポイント２として、画面遷移のホップ数に上限を設定することで解析範囲を制限することとしている。以下、本実施の形態に係る技術をより詳細に説明する。

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

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

クライアント装置１０は、サーバ装置２０が有するＷｅｂアプリケーションを解析し、テストスクリプトを生成する装置である。クライアント装置１０を「解析装置」と称してもよい。また、テスト対象のＷｅｂアプリケーションがサーバ装置２０に存在せずに、クライアント装置１０に存在してもよい。

図４は、本発明の実施の形態におけるクライアント装置１０のハードウェア構成例を示す図である。図４に示すように、クライアント装置１０は、コンピュータとして実現できる。

図４のクライアント装置１０（コンピュータ）は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。

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

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

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

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

テストスクリプト実行部１２は、テスト対象のＷｅｂアプリケーションに対し、基準画面に到達するまでのシナリオが記述されたテストスクリプトを実行し、到達画面を初期ＵＲＬとする。

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

画面自動操作部１４は、生成されたテストシナリオとテスト入力値とをテストケースとして、画面操作を、ホップ数が上限値以下という範囲内で、自動的に実行することで、動的解析を実現する。ホップ数が上限値以下かどうかの判定はホップ数判定部１７により行われる。

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

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

（クライアント装置１０の全体動作例）
以下、クライアント装置１０が実行する処理手順の例について説明する。図６は、クライアント装置１０が実行する処理手順の一例を説明するためのフローチャートである。なお、図６では、主に、図５の機能構成におけるテストスクリプト出力までの全体動作を説明する。

以下で説明する動作の前に、クライアント装置１０には、テスト対象のＷｅｂアプリケーションのソースコード、Ｗｅｂアプリケーションの初期ＵＲＬの画面（例：図２のログイン画面）から基準画面（例：図２のメイン画面）に到達するまでのシナリオを記述したテストスクリプト、基準画面からのホップ数の上限値等が入力される。

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

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

続いて、Ｓ１０３において、テストスクリプト実行部１２が、テスト対象のＷｅｂアプリケーションによりクライアント装置１０に表示される画面が、初期ＵＲＬの画面から基準画面に到達するまでのシナリオを記述したテストスクリプトを実行する。ここで到達した基準画面のＵＲＬを、以降の「初期ＵＲＬ」とする。

続いて、画面自動操作部１４は、初期ＵＲＬ（上記の基準画面）にアクセスして、初期ＵＲＬに対応するＨＴＭＬデータ等を取得する（Ｓ１０４）。その結果、当該ＨＴＭＬデータ等に基づく画面が表示装置１０６に表示される。

続くステップＳ１０５～Ｓ１１０では、初期ＵＲＬに対応するＨＴＭＬデータ、及び当該ＨＴＭＬデータに係る画面を起点として遷移するＨＴＭＬデータに関して、動的解析等が実行される。ただし、遷移は、基準画面（初期ＵＲＬ）からのホップ数が上限値以内の範囲で行われ、ホップ数が上限値を超える場合には、遷移を行わない。

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

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

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

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

ステップＳ１０８において、テストシナリオ＆入力値生成部１３が、対象テストシナリオに基づいてテストケース（これを"アクション"と呼んでもよい）を生成し、画面自動操作部１４が、当該テストケースを対象画面に対して実行する。その結果、画面遷移が発生する。なお、対象テストシナリオが、入力値を必要とする場合、ステップＳ１０８において、テスト入力値の生成が行われる。

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

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

（クライアント装置１０の詳細動作例）
次に、クライアント装置１０において、最初に基準画面まで遷移し、ホップ数の上限値の範囲内で画面遷移を行うという動作に着目した詳細動作例を説明する。

前述したように、クライアント装置１０は、図４に示すようなコンピュータであり、当該コンピュータにおいてプログラムが実行されることで、本実施の形態に係る動作が実現される。以下、クライアント装置１０のコンピュータとしての動作例を、図７に示す疑似コード（当該コンピュータ上で動作するプログラムに相当）に基づいて説明する。図７の疑似コードに示す処理は、図６におけるＳ１０３～Ｓ１１０に概ね対応する。また、図７には、図２に示したポイント１、２に対応する部分が示されている。

前述したように、クライアント装置１０には、テスト対象のＷｅｂアプリケーションにおいて、初期画面から基準画面まで遷移するテストスクリプト、及び、画面遷移数（ホップ数）の上限値等が入力される。

第１行において、クライアント装置１０は、テスト対象のＷｅｂアプリケーションに対し、初期画面から基準画面まで到達するテストスクリプトを実行する。クライアント装置１０は、到達した基準画面を対象画面とし、当該対象画面までのホップ数を０とする（第２行、第３行）。なお、以下では、「画面」は、クライアント装置１０において画面を表示するためのデータ（ＨＴＭＬデータ等）を意味するものとする。

第４行において、クライアント装置１０は、対象画面を画面スタックに格納する。画面スタックとは、解析対象となる遷移先の画面を格納するスタックであり、先入れ先出しのスタックである。

第５行～第１５行は、画面スタックが空でない限り実行される。第６行において、クライアント装置１０は、画面スタックから１つポップさせた画面を以降の対象画面とする。

第７行において、クライアント装置１０は、対象画面の要素から、画面の遷移を発生させるアクション群を取得する。アクションとは、対象画面の要素（入力フォーム、ボタン、リンク等）における、入力フォーム等の要素と画面遷移が起こる要素（ボタン、リンク等）の組み合わせである。画面遷移を起こす要素（ボタン、リンク等）が複数あればアクションが複数取得される。複数のアクションをアクション群と呼んでいる。

第８行～第１４行は、対象画面において遷移を起こさせるアクション群の中のそれぞれのアクションに対して実行される。第９行において、クライアント装置１０は、対象画面まで遷移する事前手順を実行後、対象画面において当該アクションを実行して、遷移先の新たな画面を取得し、これを次画面とする。

第１０行において、クライアント装置１０は、次画面までのホップ数を、「対象画面までのホップ数＋１」とする。

第１１行において、クライアント装置１０は、当該次画面までのホップ数が、ホップ数の上限値以下であるかどうかを判定し、上限値以下であれば、第１２行において、画面スタックに次画面をプッシュする。もしも、ホップ数が上限値よりも大きければ、画面スタックに次画面をプッシュしない。

現在の対象画面に対して、第８行～第１４行の処理が、アクション群の全てに対して実行された後、第５行に戻り、画面スタックが空でない限り、上述した処理が再び実行される。

上記の処理に中で、クライアント装置１０は、各アクション、アクションで遷移した画面の情報等、解析において得られる情報をメモリ等に記録する。記録された情報が、最終的に出力するテストスクリプト等の生成に利用される。

図８は、ホップ数判定に関わる処理のフローチャートである。Ｓ２０１において、クライアント装置１０は、基準画面から遷移先画面（上述した次画面）までのホップ数が上限値以下であるかどうかを判定する。上限値以下であれば、Ｓ２０２において、画面スタックに遷移先画面を追加する。

なお、図７を参照して説明したような解析手法は、テストスクリプトの自動生成以外の目的に使用することとしてもよい。

（実施の形態の効果）
以上、説明した実施の形態に係る技術により、既存のリバースベーステスト技術で発生する、網羅的な画面遷移が不要な箇所についても仕様復元を実施してしまうという課題に対して、基準画面に到達するためのテストスクリプトの利用及び画面遷移数に上限を設けることで、必要な画面のみに仕様復元の範囲を限定することができる。

不要な仕様復元処理を削減することで、仕様復元に要する時間を大幅に削減することができる、という効果が生じる。

（実施の形態のまとめ）
本実施の形態において、少なくとも、下記の各項に記載された解析装置、解析方法、及びプログラムが提供される。
（第１項）
Ｗｅｂアプリケーションにより表示される画面を基準画面まで遷移させるスクリプトを実行するスクリプト実行手段と、
前記基準画面からの画面遷移のホップ数が予め定めた上限値以下となる範囲内で、前記Ｗｅｂアプリケーションに対する画面遷移の解析を実行する解析手段と
を備える解析装置。
（第２項）
前記解析手段は、前記基準画面からの画面遷移のホップ数が前記上限値以下となる範囲内で、画面遷移を起こさせる操作を繰り返し実行する
第１項に記載の解析装置。
（第３項）
前記解析手段は、ある対象画面の要素の中から、画面遷移を起こさせる要素をアクションとして取得し、当該対象画面において前記アクションの操作を実行することにより次画面を取得する処理を、最初の対象画面である前記基準画面からの画面遷移のホップ数が前記上限値以下となる範囲内で、次画面を新たな対象画面とすることにより繰り返し実行する
第１項又は第２項に記載の解析装置。
（第４項）
解析装置が実行する解析方法であって、
Ｗｅｂアプリケーションにより表示される画面を基準画面まで遷移させるスクリプトを実行するスクリプト実行ステップと、
前記基準画面からの画面遷移のホップ数が予め定めた上限値以下となる範囲内で、前記Ｗｅｂアプリケーションに対する画面遷移の解析を実行する解析ステップと
を備える解析方法。
（第５項）
コンピュータを、第１項ないし第３項のうちいずれか１項に記載の解析装置における各手段として機能させるためのプログラム。

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

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

Claims (4)

1. Ｗｅｂアプリケーションにより表示される画面を基準画面まで遷移させるスクリプトを実行するスクリプト実行手段と、
   テストシナリオを生成するために、前記基準画面からの画面遷移のホップ数が予め定めた上限値以下となる範囲内で、前記Ｗｅｂアプリケーションに対する画面遷移を起こさせる画面の操作を実行する解析手段と
   を備える解析装置。
2. 前記解析手段は、ある対象画面の要素の中から、画面遷移を起こさせる要素をアクションとして取得し、当該対象画面において前記アクションの操作を実行することにより次画面を取得する処理を、最初の対象画面である前記基準画面からの画面遷移のホップ数が前記上限値以下となる範囲内で、次画面を新たな対象画面とすることにより繰り返し実行する
   請求項１に記載の解析装置。
3. 解析装置が実行する解析方法であって、
   Ｗｅｂアプリケーションにより表示される画面を基準画面まで遷移させるスクリプトを実行するスクリプト実行ステップと、
   テストシナリオを生成するために、前記基準画面からの画面遷移のホップ数が予め定めた上限値以下となる範囲内で、前記Ｗｅｂアプリケーションに対する画面遷移を起こさせる画面の操作を実行する解析ステップと
   を備える解析方法。
4. コンピュータを、請求項１又は２に記載の解析装置における各手段として機能させるためのプログラム。

Images