JPWO2015198473A1 - 試験プログラム、試験装置及び試験方法 - Google Patents

Abstract

システムの機能変更前の処理が記述された第１のソースコードに所定の表記を付加した第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと所定の表記とを含んだ第１のシナリオ修正用データを作成し、システムの機能変更後の処理が記述された第２のソースコードに所定の表記を付加した第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと所定の表記とを含んだ第２のシナリオ修正用データを作成し、第１のシナリオ修正用データと第２のシナリオ修正用データとに含まれる所定の表記が一致する位置に応じて第１のＸPathと第２のＸPathとの対応情報を抽出し、抽出した対応情報に基づき、第１のウェブ画面の操作手順を示す第１のテストシナリオから第２のウェブ画面の操作手順を示す第２のテストシナリオを作成する、処理をコンピュータに実行させるための試験プログラムが提供される。

Description

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

ウェブシステムは、監視対象のシステムの稼働状況等の情報をウェブ画面に表示して提供するサービスを行っている。サーバ／ストレージシステムのある機能が変更すると、これに伴いウェブ画面のレイアウトが変更される場合がある。一例としては、サーバ／ストレージシステムに新機能が追加された場合、サーバ／ストレージシステムに追加された機能に関する情報を表示するためにウェブ画面のレイアウトが変わる場合がある。同様に、サーバ／ストレージシステムからある機能が削除された場合、サーバ／ストレージシステムから削除した機能に関する情報を削除するために画面のレイアウトが変わることがある。

サーバ／ストレージシステムでは、このような機能の変更以外の機能についての処理に変更はない。よって、ウェブシステムは、追加又は削除した機能以外の機能に関しては、機能変更の前後においてウェブ画面上で同じ動作が行われ、結果が表示されることを保証しなければならない。そのためのテスト方法としてリグレッションテストが知られている。

リグレッションテストはウェブテストシステムにより実行される。ウェブテストシステムはテストシナリオを実行して、変更した機能以外の機能に関し機能変更の前後でウェブ画面の結果が同じことを確認する。テストシナリオは、ウェブ画面のテスト用の操作手順を示す。テストシナリオには、ウェブ画面を記述するＨＴＭＬ(Hyper Text Markup Language)上の要素が指定される。ウェブ画面とそれに対するテストシナリオの一例を図３４及び図３５に示す。ＨＴＭＬ上の各要素の位置指定にはウェブ画面上の位置を指定するＸPathが用いられる。

特開２００９−１４０１５５号公報 特開２００５−２６６９５４号公報

しかしながら、ＸPathは、ウェブ画面のレイアウトが変化するとそれに応じて変化する。よって、ウェブ画面のレイアウトが変わると機能変更前のＸPathを、同じ要素の位置を指定する機能変更後のＸPathとして使用することができない場合がある。

つまり、テストシナリオにはＸPathが記述されている。このため、サーバ／ストレージシステムの機能変更に応じてウェブ画面のレイアウトが変わると、機能変更前のＸPathを含むテストシナリオを機能変更後のリグレッションテストのテストシナリオとしてそのまま使用することができなくなる。

そこで、図１のフローチャート及び図２（ａ）に示すように、機能変更前後のサーバ／ストレージシステムの機能仕様書１，２から差分を抽出し、差分に基づき機能変更前の第１のテストシナリオを手動で修正して、機能変更後の第２のテストシナリオを作成することが行われている。しかし、この方法は、手動によるテストシナリオの修正であるため、修正に手間がかかる。加えて、その複雑さは、ウェブ画面の中の表示項目数、画面の数の多さに比例し、今後ますます多機能化するシステムのテストシナリオの修正にはさらに大きな手間がかかることが予想される。

さらに、連続性のあるテストシナリオに対しては、テストシナリオの修正漏れのためにテストが実行できない場合、修正漏れによるエラー箇所以降のテストが正しく実行されない可能性が高いため、エラーの修正とテストの実行とを手動で繰り返し行わなければならず、追加工数が発生する。

そこで、一側面では、本発明は、ウェブ画面をテストするための機能変更前のテストシナリオに基づき、機能変更後のテストシナリオを自動作成することを目的とする。

一つの案では、システムの機能変更前の処理が記述された第１のソースコードに所定の表記を付加した第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと前記所定の表記とを含んだ第１のシナリオ修正用データを作成し、システムの機能変更後の処理が記述された第２のソースコードに所定の表記を付加した第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと前記所定の表記とを含んだ第２のシナリオ修正用データを作成し、前記第１のシナリオ修正用データと前記第２のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第１のＸPathと前記第２のＸPathとの対応情報を抽出し、前記抽出した対応情報に基づき、前記第１のウェブ画面の操作手順を示す第１のテストシナリオから前記第２のウェブ画面の操作手順を示す第２のテストシナリオを作成する、処理をコンピュータに実行させるための試験プログラムが提供される。

一態様によれば、ウェブ画面をテストするための機能変更前のテストシナリオに基づき、機能変更後のテストシナリオを自動作成することができる。

機能仕様書の差分情報からテストシナリオを手動で作成する例を示すフローチャート。 図２（ａ）はテストシナリオの手動作成を説明するための比較図、図２（ｂ）は一実施形態にかかるテストシナリオの自動作成を説明するための図。 一実施形態にかかるシステムの全体構成の一例を示す図。 ＨＴＭＬ上の各要素とＸPathの位置指定の例を示す図。 ＸPathを使用したテストシナリオの一例を示す図。 ウェブ画面のレイアウト変更例を示す図。 図４に対してウェブ画面のレイアウト変更後のＸPathの一例を示す図。 図４に対してウェブ画面のレイアウト変更後のＸPathの他の例を示す図。 一実施形態にかかるウェブテストシステムの機能構成の一例を示す図。 一実施形態にかかる関数リストの一例を示す図。 図１０の関数リストの本体の一例を示す図。 一実施形態にかかるテスト実行処理の一例を示すフローチャート。 一実施形態にかかる関数付加処理の一例を示すフローチャート。 一実施形態にかかる関数リスト生成処理の一例を示すフローチャート。 一実施形態にかかるソースコードの一例を示す図。 一実施形態にかかるリスト化されたソースコードの一例を示す図。 図１６の構文解析結果を示す図。 一実施形態にかかる修正ソースコードの一例を示す図。 一実施形態にかかる修正ソースコードを元のソースコードに戻した例を示す図。 一実施形態にかかるテストシナリオの自動作成処理の詳細を示すフローチャート。 一実施形態にかかるシナリオ修正用データ（機能変更前）の作成例を示す図。 一実施形態にかかるシナリオ修正用データの作成処理を示すフローチャート。 一実施形態にかかるシナリオ修正用データ（機能変更後）の作成例を示す図。 一実施形態にかかるテストシナリオの自動作成処理を示すフローチャート。 一実施形態にかかるシナリオ修正用データ（機能変更前後）の一致検出例を示す図。 一実施形態にかかるＸPathの検出例を示す図。 図２７（ａ）は、機能変更前のシステムに対するテストシナリオを示し、図２７（ｂ）は、機能変更後のシステムに対するテストシナリオを示す図。 機能変更前のＨＴＭＬを示す図。 機能変更前のシステムに対する第１のテストシナリオを適用するウェブ画面例を示す図。 機能変更後のＨＴＭＬを示す図。 機能変更後のシステムに対する第２のテストシナリオを適用するウェブ画面例を示す図。 第１のテストシナリオを使用したテスト例を示す図。 第２のテストシナリオを使用したテスト例を示す図。 機能変更前のテストシナリオの実行例を示す図。 機能変更後のテストシナリオの実行例を示す図。 一実施形態にかかるウェブテストシステムのハードウェア構成例を示す図。

以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。

［システムの全体構成］
まず、。本発明の一実施形態に係るサーバ／ストレージシステム１、ウェブシステム２０及びウェブテストシステム３０の関係について、図３を参照しながら説明する。ウェブシステム２０は、監視対象のサーバ／ストレージシステム１の稼働状況等の情報をウェブ画面に表示して提供する。

本実施形態にかかるサーバ／ストレージシステム１において、サーバ／ストレージ装置１０の機能構成の情報は、ウェブ画面１１を用いて入力される。ウェブ画面１１への入力及びウェブ画面１１の更新は、ウェブシステム２０により制御される。

サーバ／ストレージシステム１において機能の追加や機能の削除が行われた場合、ウェブシステムは、追加又は削除した機能以外の機能に関しては、機能変更の前後において同じ動作が行われウェブ画面上に表示されることを保証しなければならない。そのためのテスト方法としてリグレッションテストが知られている。

リグレッションテストは、ウェブテストシステム３０により実行される。ウェブテストシステム３０は、まず、サーバ／ストレージ装置１０の機能仕様書からウェブ画面１１のテスト用の操作手順を作成する。ウェブ画面１１のテスト用の操作手順を、以下「テストシナリオ」という。

ウェブテストシステム３０は、テストシナリオを入力し、テストシナリオの操作手順に基づきウェブ画面１１を操作してテストを実行し、その実行結果を検証する。このとき、ウェブテストシステム３０は、テストシナリオに従ってウェブ画面１１の操作を自動で行う。

テストシナリオには、ウェブ画面を記述するＨＴＭＬ上の各要素が指定される。ＨＴＭＬの要素の位置指定には、ＸPathによる位置指定方法が用いられる。図４は、ＨＴＭＬ上の各要素とＸPathの位置指定の例を示す。ＸPathは、ＨＴＭＬなどのＸＭＬ(Extensible Markup Language)文書の中の特定の要素を指し示す記述方法を定めた規格であり、Ｗ３Ｃ（World Wide Web Consortium）が勧告した標準仕様に基づく。図４（ｂ）に示すＨＴＭＬファイルの要素（Ｅ１）に対して、図４（ａ）のウェブ画面１１に対応するテーブルの（１）で示される位置、は、図４（ｃ）の（１）のＸPathで示される。図４（ｂ）に示すＨＴＭＬファイルの要素（Ｅ２）に対して、図４（ａ）のテーブルの（２）で示される位置は、図４（ｃ）の（２）のＸPathで示される。図４（ｂ）に示すＨＴＭＬファイルの要素（Ｅ３）に対して、図４（ａ）のテーブルの（３）で示される位置は、図４（ｃ）の（３）のＸPathで示される。

テストシナリオでは、指定したウェブ画面を記述するＨＴＭＬファイルの要素に対する操作を記載する。ＸPathを使用したテストシナリオの一例を図５に示す。テストシナリオに記載されるコマンドには、文字入力（ｉｎｐｕｔ）、クリック（Ｃｌｉｃｋ）、任意のデータとの比較（Ｃｈｅｃｋ）等がある。テストシナリオに記載のＸPathには、そのコマンドを実行する場所が指定される。

図５に示すようにテストシナリオには場所の指定であるＸPathが記述されており、ウェブ画面１１のレイアウトが変わるとＨＴＭＬファイルの要素の位置指定、つまりＸPathが変わってしまう。このため、機能変更に応じてウェブ画面１１のレイアウトが変わると、機能変更前のＸPathを含むテストシナリオをそのまま機能変更後のテストシナリオとして使用することは困難である。

例えば、図６の上図のウェブ画面１１の「注釈２」が削除され、下図のウェブ画面１１に示すようにレイアウトが変更した場合、レイアウト変更と共にＸPathも変更される。このため、レイアウト変更後のウェブ画面１１に対して元のテストシナリオをそのまま使用してテストを行うことはできない。

図４のウェブ画面１１のレイアウト変更後のＸPathの一例を図７及び図８に示す。図７は、図４に対して画面要素（Ｄｅ）が削除されたためＸPathが変更になった例、図８は、図４に対して画面要素（Ａｄ）が追加されたためＸPathが変更になった例である。

図４（ｂ）に示すＨＴＭＬファイルの要素（Ｅ３）に対する変更前の図４（ｃ）の（３）に示すＸPathは「/html/body/table/tr[3]/td[2]」である。これに対して、図７（ｂ）に示すＨＴＭＬファイルの要素（Ｄｅ）で示す部分が削除された場合、図７（ｂ）に要素（Ｅ３）に対する変更後の図７（ｃ）の（５）に示すＸPathは「/html/body/table/tr[2]/td[2]」である。

また、図８（ｂ）に示すＨＴＭＬファイルの要素（Ａｄ）で示す部分が追加された場合、図８（ｂ）に要素（Ｅ３）に対する変更後の図８（ｃ）の（６）に示すＸPathは「/html/body/table/tr[4]/td[2]」である。このように、ウェブ画面１１のレイアウトが変更され、ＨＴＭＬファイルの要素が変更になるとＸPathで示されるウェブ画面１１上の位置の指定が変更される。

以下に説明する一実施形態にかかるウェブテストシステム３０は、機能変更前のウェブ画面１１のテストに使用したテストシナリオから機能変更後のウェブ画面１１のテストに使用するテストシナリオを自動作成する。これにより、ウェブテストシステム３０が使用するテストシナリオを、機能仕様書に基づき手動で変更することを不要とする。なお、一実施形態にかかるウェブテストシステム３０は、ウェブ画面１１をテストする試験装置の一例である。ウェブテストシステム３０は、例えばＰＣ上で動くテストシステムであり、テストシナリオを入力してテストシナリオの操作手順に従いウェブ画面１１のテストを行う。

［ウェブテストシステムの機能構成］
本発明の一実施形態に係るウェブテストシステム３０の機能構成について、図９を参照しながら説明する。図９は、一実施形態に係るウェブテストシステム３０の機能構成の一例を示す。一実施形態に係るウェブテストシステム３０は、ソースコード読込部３１、修正ソースコード作成部３２、テストシナリオ読込部３３、修正用データ作成部３４、ＸPath抽出部３５、テストシナリオ作成部３６、テスト実行処理部３７及び記憶部４０を有する。

記憶部４０は、ソースコードＤＢ（Ｄａｔａ Ｂａｓｅ）４１、修正ソースコードＤＢ４２、テストシナリオＤＢ４３、シナリオ修正用ＤＢ４４及びテスト実行結果ＤＢ４５を有する。

ソースコード読込部３１は、ソースコードＤＢ４１に格納された所定のソースコードを読み込む。ソースコードＤＢ４１は、ウェブシステム２０が提供する機能変更前のウェブ画面１１（第１のウェブ画面）を記述する。

修正ソースコード作成部３２は、ソースコードに、所定の表記を付加した修正ソースコードを作成する。例えば、修正ソースコード作成部３２は、第１のソースコードに所定の関数又は固定値の表記を付加して第１の修正ソースコードを作成する（図２（ｂ）：（１）関数追加）。また、例えば、修正ソースコード作成部３２は、第２のソースコードに所定の関数又は固定値の表記を付加して第２の修正ソースコードを作成する（図２（ｂ）：（３）関数追加）。

第１のソースコードには、サーバ／ストレージシステム１の機能変更前の内部処理が記述されている。第２のソースコードには、サーバ／ストレージシステム１の機能変更後の内部処理が記述されている。

所定の表記の一例を示した関数リスト１００を図１０に示す。関数リスト１００は、外部から入力する。関数リスト１００は、関数の表記として変数対象関数名１０１及び挿入関数名１０２を有する。関数リスト１００は、固定値の表記として第１のデバッグ出力情報１０３、第２のデバッグ出力情報１０４、第３のデバッグ出力情報１０５、第４のデバッグ出力情報１０６・・・を有する。なお、図１１は、図１０の関数リストの本体の一例を示す。所定の表記には、関数の表記、固定値（固定文字等）の表記、関数に記載された引数を含む。

テストシナリオ読込部３３は、テストシナリオＤＢ４３に格納された所定のテストシナリオを読み込む。

修正用データ作成部３４は、第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと前記所定の表記とを含んだ第１のシナリオ修正用データを作成する。修正用データ作成部３４は、第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと前記所定の表記とを含んだ第２のシナリオ修正用データを作成する。

例えば、図６の上図に示すウェブ画面１１を第１のウェブ画面とし、システムの機能変更に応じて図６の下図に示すようにウェブ画面１１のレイアウトの一部が変更された、ウェブ画面１１を第２のウェブ画面とする。

第２のウェブ画面をテストする場合、修正用データ作成部３４は、第１の修正ソースコードに基づく処理を実行してシナリオ修正用データを作成する（図２（ｂ）：（２）実行）。作成されたシナリオ修正用データは、第１のウェブ画面のレイアウトを表記するための第１のＸPathを含み、以下、「第１のシナリオ修正用データ」ともいう。

また、例えば、修正用データ作成部３４は、第２の修正ソースコードに基づく処理を実行してシナリオ修正用データを作成する（図２（ｂ）：（４）実行）。作成されたシナリオ修正用データは、第２のウェブ画面のレイアウトを表記するための第２のＸPathを含み、以下、「第２のシナリオ修正用データ」ともいう。第１のシナリオ修正用データ及び第２のシナリオ修正用データは、シナリオ修正用ＤＢ４４に格納される。

ＸPath抽出部３５は、第１のシナリオ修正用データと第２のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて第１のＸPathと第２のＸPathとの対応情報を抽出する。

テストシナリオ作成部３６は、対応情報に基づき、第１のウェブ画面のテスト用の操作手順を示す第１のテストシナリオから第２のウェブ画面のテスト用の操作手順を示す第２のテストシナリオを作成する（図２（ｂ）：（５）作成）。

テスト実行処理部３７は、第２のテストシナリオの操作手順に従い機能変更後の第２のウェブ画面のテストを行う。テストの実行結果のデータは、テスト実行結果ＤＢ４５に保存される。

［テストシナリオ自動作成の前提条件］
以上に説明したテストシナリオ自動作成のための前提条件１〜３について説明する。

前提条件１：ＨＴＭＬファイルの生成前にウェブシステム２０で実行する処理（関数）に変更がないこと
前提条件２：ＨＴＭＬファイルの生成後にウェブシステム２０で実行される処理（関数）に変更がないこと
前提条件３：ウェブテストシステム３０においてテストシナリオの適用順序に変更がないこと
本実施形態に係るウェブテストシステム３０によれば、上記前提条件の元、以下の仕組みでテストシナリオの再利用を可能とする。
（１）機能変更前と機能変更後のウェブシステム２０のソースコードを書き換えて以下の情報を出力する。

・ＨＴＭＬファイルの生成前に実行した内部処理
・ＨＴＭＬファイルの生成
・ＨＴＭＬファイルの生成後に実行した内部処理
上記の生成したＨＴＭＬファイルからＸPathが生成される。ＨＴＭＬファイルの生成前後の内部処理を付加したＸPath（シナリオ修正用データ中のＸPath）により、第１のウェブ画面用の機能変更前のテストシナリオから第２のウェブ画面用の機能変更後のテストシナリオが作成される。
（２）特定のＨＴＭＬファイル生成時の機能変更前処理と機能変更後処理の組み合わせは、同じ情報については、サーバ／ストレージシステム１のの機能変更の前後で変わらない。このことを前提として、ＨＴＭＬファイル生成前と、ＨＴＭＬファイル生成後に実行した内部処理の組み合わせが同じとなるものを見つけ出し、サーバ／ストレージシステム１の機能変更前後で変更のあるＸPathを見つけ出す。
（３）第１のシナリオ修正用データと第２のシナリオ修正用データとに含まれる所定の関数又は固定値の表記が一致する位置に応じて変更前の第１のＸPathと変更後の第２のＸPathとの対応情報を抽出する。これにより、サーバ／ストレージシステム１のの機能変更の前後でＸPathがどのように変わったかを取得できる。
（４）対応情報に基づき、機能変更前のテストシナリオから機能変更後のテストシナリオを書き換える。

これにより、図２（ｂ）に示すように、サーバ／ストレージシステム１において機能変更前のウェブ画面１１のテスト用に作成した第１のテストシナリオを使用して、機能変更後のテスト用に第２のテストシナリオを自動作成することができる。ウェブテストシステム３０では、テストシナリオの自動作成とテストシナリオによるテストの実行とが繰り返し実施される。

［テストシナリオの自動作成処理］
次に、本実施形態に係るテストシナリオの自動作成処理について図１２を参照しながら説明する。図１２は、本実施形態にかかるテスト実行処理の一例を示すフローチャートである。以下のテストシナリオの自動作成処理は、左側がウェブシステム２０において提供される機能変更前のウェブ画面１１のテスト実行処理、右側がウェブシステム２０において提供される機能変更後のウェブ画面１１のテスト実行処理を示す。テストシナリオの自動作成処理は、右側に示す機能変更後のウェブ画面１１のテスト実行処理前に実行される。

図１２の左側の機能変更前の処理が開始されると、ソースコード読込部３１は、機能変更前のソースコードを読み込む（ステップＳ１０）。以下、機能変更前のソースコードを第１のソースコードともいう。

次に、修正ソースコード作成部３２は、第１のソースコードに関数及び固定値の表記を付加する処理（以下、「関数付加処理」ともいう。）を実行し、関数及び固定値の表記を付加した第１のソースコード（以下、「第１の修正ソースコード」ともいう。）を作成する（ステップＳ１２）。なお、後述されるステップＳ１２、Ｓ２４、Ｓ３２、Ｓ４４の関数等の付加処理は図１３に示され、付加する関数リストの生成処理は図１４に示され、後述される。

次に、修正用データ作成部３４は、第１の修正ソースコードに基づき第１のシナリオ修正用データを作成し（ステップＳ１４）、テストシナリオ読込部３３は、テストシナリオ（以下、「第１のテストシナリオ」ともいう。）を読み込む（ステップＳ１６）。次に、ウェブシステム２０は、生成した最新のＨＴＭＬファイルに従いウェブ画面１１を表示する（ステップＳ１８）。ここでは、第１のソースコードに基づき第１のウェブ画面が表示される。第１のウェブ画面には、機能変更前のサーバ／ストレージシステム１の稼働情報などの情報が表示されている。

次に、テスト実行処理部３７は、第１のテストシナリオを読み込み、第１のテストシナリオに基づきリグレッションテストを実行する（ステップＳ２０）。記憶部４０は、テストの実行処理結果をテスト実行結果ＤＢ４５に保存する。次に、ソースコード読込部３１は、機能変更前のウェブシステム２０の次の第１のソースコードを読み込み（ステップＳ２２）、修正ソースコード作成部３２は、第１のソースコードに関数及び固定値の表記を付加する関数付加処理を実行し、次の第１の修正ソースコードを作成する（ステップＳ２４）。次に、修正用データ作成部３４は、第１の修正ソースコードに基づき次の第１のシナリオ修正用データを作成する（ステップＳ２６）。

次に、テスト実行処理部３７は、次の第１のテストシナリオがないかを判定し（ステップＳ２８）、次の第１のテストシナリオはないと判定した場合、本処理は終了する。一方、次の第１のテストシナリオがあると判定した場合、テスト実行処理部３７は、次の第１のテストシナリオを読み込む（ステップＳ２９）。次に、テスト実行処理部３７は、次の第１のテストシナリオに基づきステップＳ２０にてリグレッションテストを実行し、記憶部４０はテストの実行処理結果をテスト実行結果ＤＢ４５に保存する。ステップＳ２８にて次の第１のテストシナリオがないと判定されるまで、ステップＳ１８〜Ｓ２９の処理が繰り返される。

図１２の右側の処理が開始されると、ソースコード読込部３１は、機能変更後のソースコードを読み込む（ステップＳ３０）。以下、機能変更後のソースコードを第２のソースコードともいう。次に、修正ソースコード作成部３２は、第２のソースコードに関数付加処理を実行し、関数及び固定値の表記を付加した第２のソースコード（以下、「第２の修正ソースコード」ともいう。）を作成する（ステップＳ３２）。

次に、修正用データ作成部３４は、第２の修正ソースコードに基づき第１のシナリオ修正用データを作成する（ステップＳ３４）。テストシナリオ作成部３６は、第１のシナリオ修正用データ及び第２のシナリオ修正用データに基づき第１のテストシナリオを修正した第２のテストシナリオを自動作成する（ステップＳ３６）。

次に、ウェブシステム２０は、生成した最新のＨＴＭＬファイルに従いウェブ画面１１を表示する（ステップＳ３８）。ここでは、第２のソースコードに基づき第２のウェブ画面が表示される。第２のウェブ画面には、機能変更後のサーバ／ストレージシステム１の稼働情報などの情報が表示されている。

次に、テスト実行処理部３７は、自動作成した第２のテストシナリオに基づきリグレッションテストを実行する（ステップＳ４０）。記憶部４０は、テストの実行処理結果をテスト実行結果ＤＢ４５に保存する。次に、ソースコード読込部３１は、次の第２のソースコードを読み込み（ステップＳ４２）、修正ソースコード作成部３２は、第１のソースコードに関数及び固定値の表記を付加する関数付加処理を実行する（ステップＳ４４）。次に、修正用データ作成部３４は、生成した第２の修正ソースコードに基づき次の第２のシナリオ修正用データを作成する（ステップＳ４６）。

次に、テスト実行処理部３７は、次のテストシナリオがないかを判定し（ステップＳ４８）、次のテストシナリオはないと判定した場合、本処理は終了する。一方、次の第２のテストシナリオがあると判定した場合、テスト実行処理部３７は、次の第２のテストシナリオを修正（自動作成）し（ステップＳ４９）、ステップＳ４０にてリグレッションテストを実行する。記憶部４０は、テストの実行処理結果をテスト実行結果ＤＢ４５に保存する。ステップＳ４８にて次の第２のテストシナリオがないと判定されるまで、ステップＳ３８〜Ｓ４９の処理が繰り返される。

［関数付加処理］
本実施形態にかかる関数付加処理について、図１３及び図１４を参照しながら説明する。図１３は、本実施形態にかかる関数付加処理を示すフローチャートである。図１４は、本実施形態にかかる関数リストの生成処理を示すフローチャートである。本処理は、図２（ｂ）の（１）に示す関数付加により第１のソースコードから第１の修正ソースコードを作成する処理である。また、図２（ｂ）の（３）に示す関数付加により、第２のソースコードから第２の修正ソースコードを作成する処理である。

図１３の処理が開始されると、修正ソースコード作成部３２が関数リストの生成処理（図１４）を実行する（ステップＳ５０）。
（関数リスト生成処理）
図１４の関数リストの生成処理では、修正ソースコード作成部３２は、ウェブシステム２０のソースコードを{,}、(,)、空白、カンマ、';' 、'=' 、改行コードで分割し、リスト化する（ステップＳ７０）。但し"…"、"//〜改行"内は分割しない。

次に、修正ソースコード作成部３２は、リスト化されたソースコードに含まれる関数を判定し（ステップＳ７１）、関数呼び出し部（関数Ｃａｌｌ）を走査する（ステップＳ７２）。修正ソースコード作成部３２は、走査が完了したかを判定し（ステップＳ７３）、走査が完了したと判定した場合、本処理を終了し、図１３の関数付加処理のステップＳ５１に戻る。

一方、修正ソースコード作成部３２は、走査が完了していないと判定した場合、関数の種類によってソースコード内の関数を下記の３つに分ける（ステップＳ７４）。ステップＳ７５〜Ｓ７７にてリストを生成した後、ステップＳ７２に戻り、ステップＳ７２〜Ｓ７７の処理を走査が完了するまで繰り返す。
（１）ＨＴＭＬ出力関数リスト生成（ステップＳ７５）
・関数名 関数タイプ 関数引数
（２）データベース書き込み関数リスト生成（ステップＳ７６）
・関数名 関数タイプ 関数引数
（３）データベース読み込み関数リスト生成（ステップＳ７７）
・関数名 関数タイプ 関数引数
図１３の付加処理（ステップＳ５１）に戻ると、修正ソースコード作成部３２は、ウェブシステム２０のソースコードを{,}、(,)、空白、カンマ、';' 、'=' 、改行コードで分割し、リスト化する。但し"…"、"//〜改行"内は分割しない。なお、修正ソースコード作成部３２は、ステップＳ５１において、ステップＳ７０にてリスト化されたソースコードを取得してもよい。図１５はソースコードの一例を示す。図１６は図１５のソースコードを分割し、リスト化した一例を示す。

次に、修正ソースコード作成部３２は、リスト化されたソースコードから関数を判定し（ステップＳ５２）、関数呼び出し部（関数Ｃａｌｌ）を走査する（ステップＳ５３）。修正ソースコード作成部３２は、走査が完了したかを判定し（ステップＳ５４）、走査が完了したと判定した場合、リスト化されたソースコードを元のソースコードに戻し（ステップＳ６３）、本処理を終了する。

一方、修正ソースコード作成部３２は、ステップＳ５４にて走査が完了していないと判定した場合、関数呼び出し部の関数の種類が図１４にて生成した関数リストの対象関数と一致するかを判定する（ステップＳ５５）。修正ソースコード作成部３２は、関数呼び出し部の関数の種類が関数リストの対象関数と一致すると判定した場合、対象関数の直後に挿入関数名を挿入する（ステップＳ５６）。図１０は、上記の関数リスト生成のステップで使用する関数リストの一例を示す。

修正ソースコード作成部３２は、図４の（ｂ）のソースコードをリスト化し（図１６）、リスト化したソースコードを構文解析し（図１７）、対象関数の直後に挿入関数名を挿入する（図１８）。

次に、図１３のステップＳ５７にて、修正ソースコード作成部３２は、関数リストからデバッグ出力情報を取得する。修正ソースコード作成部３２は、デバッグ出力情報の取得が完了したかを判定し（ステップＳ５８）、デバッグ出力情報の取得が完了したと判定した場合、ステップＳ６２に進む。一方、修正ソースコード作成部３２は、デバッグ出力情報の取得が完了していないと判定した場合、固定文字かを判定する（ステップＳ５９）。固定文字の場合、修正ソースコード作成部３２は、その固定文字を挿入する（ステップＳ６０）。図１８には、ステップＳ６０の実行により挿入関数名の挿入後に固定文字が設定されている。一方、固定文字でない場合、修正ソースコード作成部３２は、関数引数を挿入する（ステップＳ６１）。図１８には、挿入関数名及び固定文字の挿入後に関数引数（デバッグ出力情報１０３〜１０６の"ａｒｇ"の関数引数）が設定されている。ステップＳ５７に戻り、修正ソースコード作成部３２は、ステップＳ５７〜Ｓ６１の処理を繰り返した後、ステップＳ５８にてデバッグ出力情報の取得が完了したと判定したとき、ステップＳ６２に進み、関数の終端表記を挿入し、ステップＳ５３に戻る。修正ソースコード作成部３２は、ステップＳ５３に続くステップＳ５４にて関数呼び出し部の走査が完了したと判定するまでＳ５３〜Ｓ６２の処理を繰り返し、走査が完了したと判定したときリスト化したソースコードを元の状態に戻し（ステップＳ６３）、本処理を終了する。図１９は、リスト化したソースコードから元の状態に戻されたソースコードを示す。なお、ステップＳ６３の処理は省略できる。

これにより、図１８に示すように、一のソースコードから修正ソースコードが作成される。以上、図２（ｂ）の（１）及び（３）の関数追加により修正ソースコードを作成する処理の詳細を説明した。図２では、修正ソースコード作成部３２は、機能変更前の第１のソースコードから第１の修正ソースコードを作成し、機能変更前の第２のソースコードから第２の修正ソースコードを作成する。

次に、図２（ｂ）の（２）及び（４）の第１及び第２の修正ソースコードから第１及び第２のシナリオ修正用データを作成する処理の詳細、及び図２（ｂ）の（５）第１のテストシナリオから第２のテストシナリオを自動作成する処理の詳細を説明する。図２０は、本実施形態にかかるテストシナリオの自動作成処理の詳細を示すフローチャートである。

図２０の処理が開始されると、修正ソースコード作成部３２は、シナリオ修正用ＤＢ４４にシナリオ修正用データが存在するかを判定する（ステップＳ８０）。図２（ｂ）の（１）の時点では、シナリオ修正用データは存在しない。よって、修正用データ作成部３４は、ソースコードに所定の関数等の表記を付加して修正ソースコードを作成する（ステップＳ８１）。ここでは、修正ソースコード作成部３２は、機能変更前のソースコードである第１のソースコードに所定の関数等の表記を付加して機能変更前の修正ソースコードである第１の修正ソースコードを作成する。

次に、ウェブシステム２０が起動され（ステップＳ８２）、第１の修正ソースコードに基づく処理の実行によりＨＴＭＬファイルが生成され、修正用データ作成部３４は、ＨＴＭＬファイルに応じた第１のシナリオ修正用データを作成する（ステップＳ８３）。図２１の左側に機能変更前のＨＴＭＬファイルの例を示し、図２１の右側に作成した第１のシナリオ修正用データの例を示す。第１のシナリオ修正用データは、テストシナリオを修正するために使用される。
（シナリオ修正用データの作成処理）
シナリオ修正用データの作成処理の詳細について、図２２を参照しながら説明する。図２２は、本実施形態にかかるシナリオ修正用データの作成処理を示すフローチャートである。まず、修正用データ作成部３４は、ＨＴＭＬファイルの上から順に一行を取得する（ステップＳ１０１）。例えば、図２１では、行番号「１」の一行が取得される。次に、修正用データ作成部３４は、ＨＴＭＬファイルの全行の処理が済んだかを判定する（ステップＳ１０２）。修正用データ作成部３４は、全行の処理が済んだと判定した場合、本処理を終了する。一方、修正用データ作成部３４は、全行の処理が済んでいないと判定した場合、取得した一行からタグの記述を取り出す（ステップＳ１０３）。タグの記述は、"＜・・・＞"又は"＜／・・・＞"で示される。次に、修正用データ作成部３４は、取得した一行に含まれる全データの処理が済んだかを判定する（ステップＳ１０４）。修正用データ作成部３４は、取得した一行に含まれる全データの処理が済んだと判定した場合、ステップＳ１０１に戻り、ステップＳ１０１以降の処理を繰り返す。

一方、修正用データ作成部３４は、取得した一行に含まれる全データの処理が済んでいないと判定した場合、取り出したデータの種類を判定する（ステップＳ１０５）。修正用データ作成部３４は、取り出したデータがタグ以外と判定した場合、ステップＳ１０２に戻る。

修正用データ作成部３４は、取り出したデータがタグの終端（＜／タグ名＞）と判定した場合、ステップＳ１１６に進み、ツリー情報に"／ "が入っているかを判定する（ステップＳ１１６）。ツリー情報は、ＨＴＭＬファイルのタグ構造を示す。修正用データ作成部３４は、ツリー情報に"／ "が入っていると判定した場合、ツリー情報終端の"/タグ名[タグ出現回数］"を除去し（ステップＳ１１７）、ステップＳ１０２に戻る。一方、修正用データ作成部３４は、ツリー情報に"／ "が入っていないと判定した場合、ツリー情報を空にし（ステップＳ１１８）、ステップＳ１０２に戻る。

ステップＳ１０５において、修正用データ作成部３４は、取り出したデータがタグの開始（つまり、＜タグ名＞）と判定した場合、前回削除したタグ名と今回のタグ名とが同じかを判定する（ステップＳ１０６）。修正用データ作成部３４は、同じでないと判定した場合、タグの出現回数を「１」とし（ステップＳ１０７）、同じと判定した場合、タグの出現回数を「＋１」する（ステップＳ１０８）。

次に、修正用データ作成部３４は、ツリー情報は何かを判定する（ステップＳ１０９）。修正用データ作成部３４は、ツリー情報が空であると判定した場合、ツリー情報に"／タグ名[タグ出現回数]"を保存する（ステップＳ１１０）。例えば、図２１では、行番号が「１」のとき、ツリー情報に"／ｈｔｍｌ[１]"が保存される。なお、タグ出現回数が１のときの[１]は省略されるため、ツリー情報に保存されるデータは、"／ｈｔｍｌ"となる。一方、修正用データ作成部３４は、ツリー情報に"／"が入っていると判定した場合、ツリー情報に"タグ名[タグ出現回数]"を保存する（ステップＳ１１１）。

次に、修正用データ作成部３４は、ツリー情報をシナリオ修正用データのＸPathに保存する（ステップＳ１１２）。ツリー情報は、機能変更前の場合、第１のシナリオ修正用データのＸPathに保存され、機能変更後の場合、第２のシナリオ修正用データのＸPathに保存される。

次に、修正用データ作成部３４は、タグの終端（つまり、＜／タグ名＞）かを判定する（ステップＳ１１３）。修正用データ作成部３４は、タグの終端でないと判定した場合、ステップＳ１０２に戻る。一方、修正用データ作成部３４は、タグの終端であると判定した場合、タグの出現回数から１を減算し（ステップＳ１１４）、ツリー情報終端の"/タグ名[タグ出現回数］"を除去し（ステップＳ１１５）、ステップＳ１０２に戻る。例えば、図２１では、行番号「１３」のとき、ツリー情報に保存されるデータは、"／ｈｔｍｌ／ｂｏｄｙ／ｔａｂｌｅ／ｔｒ"となる。

以上、図２２を参照しながら、図２０のステップＳ８３で呼び出されるシナリオ修正用データの作成処理の一例を説明した。次に、図２０のステップＳ８４に進み、テストシナリオ読込部３３は、テストシナリオＤＢ４３から次に実行するテストシナリオを読み込む。次に、テスト実行処理部３７は、テストシナリオのすべてについてテストが完了したかを判定する（ステップＳ８５）。テスト実行処理部３７は、テストシナリオのすべてについてテストが完了していないと判定した場合、テストシナリオを実行し（ステップＳ８６）、ステップＳ８３に戻り、テストシナリオのすべてについてテストが完了するまで、ステップＳ８３〜Ｓ８６の処理を繰り返す。ここでは、第１のテストシナリオの操作手順に従い機能変更前のウェブ画面１１のテストが行われる。テストの実行結果のデータは、テスト実行結果ＤＢ４５に保存される。

ステップＳ８５において第１のテストシナリオのすべてについてテストが完了したと判定された場合、又は、ステップＳ８０においてシナリオ修正用データが存在すると判定された場合、修正用データ作成部３４は、ステップＳ８７に進む。修正用データ作成部３４は、ソースコードに所定の表記を付加して修正ソースコードを作成する。この時点では、サーバ／ストレージシステム１において機能変更がされている。よって、修正ソースコード作成部３２は、機能変更後のソースコードである第２のソースコードに所定の表記を付加して機能変更後の修正ソースコードである第２の修正ソースコードを作成する。

次に、ウェブシステム２０が起動され（ステップＳ８８）、第２の修正ソースコードに基づく処理の実行によりＨＴＭＬファイルが生成され、修正用データ作成部３４は、ＨＴＭＬファイルに応じた第２のシナリオ修正用データを作成する（ステップＳ８９）。図２３の左側に機能変更後のＨＴＭＬファイルの例を示し、図２３の右側に作成した第２のシナリオ修正用データの例を示す。第２のシナリオ修正用データは、テストシナリオを修正するために使用される。

次に、テストシナリオ作成部３６は、シナリオ修正用ＤＢ４４から、対応する機能変更前の第１のシナリオ修正用データを取得する（ステップＳ９０）。テストシナリオ作成部３６は、第１のシナリオ修正用データ及び第２のシナリオ修正用データに基づき、第１のテストシナリオから第２のテストシナリオを自動作成する（ステップＳ９１）。つまり、ＸPath抽出部３５は、第１のシナリオ修正用データと第２のシナリオ修正用データとに含まれる所定の表記が一致する位置に応じて第１のＸPathと第２のＸPathとの対応情報を抽出する。テストシナリオ作成部３６は、対応情報に基づき、第１のウェブ画面のテスト用の操作手順を示す第１のテストシナリオから第２のウェブ画面のテスト用の操作手順を示す第２のテストシナリオを作成する。
（テストシナリオの自動作成処理）
テストシナリオの自動作成処理の詳細について、図２４を参照しながら説明する。図２４は、本実施形態にかかるテストシナリオの自動作成処理を示すフローチャートである。まず、テストシナリオ作成部３６は、第１のシナリオ修正用データから"ＨＴＭＬ"で始まる行を取り除く（ステップＳ１２０）。これにより、図２５の左図の斜線で示す"ＨＴＭＬ"で始まる行が取り除かれる。

次に、テストシナリオ作成部３６は、第２のシナリオ修正用データから"ＨＴＭＬ"で始まる行を取り除く（ステップＳ１２１）。これにより、図２５の右図の斜線で示す"ＨＴＭＬ"で始まる行が取り除かれる。

次に、テストシナリオ作成部３６は、第１のシナリオ修正用データから一行を取得する（ステップＳ１２２）。これにより、図２５の左図の行番号「９」の一行が取得される。次に、テストシナリオ作成部３６は、第１のシナリオ修正用データのすべての処理が済んだかを判定する（ステップＳ１２３）。テストシナリオ作成部３６は、第１のシナリオ修正用データのすべての処理が済んだと判定した場合、本処理を終了する。一方、テストシナリオ作成部３６は、第１のシナリオ修正用データのすべての処理は済んでいないと判定した場合、第１のシナリオ修正用データから次の一行を取得する（ステップＳ１２４）。これにより、図２５の左図の行番号「１１」の一行が取得される。

次に、テストシナリオ作成部３６は、第２のシナリオ修正用データから一行を取得する（ステップＳ１２５）。これにより、図２５の右図の行番号「１６」の一行が取得される。次に、テストシナリオ作成部３６は、第２のシナリオ修正用データのすべての処理が済んだかを判定する（ステップＳ１２６）。テストシナリオ作成部３６は、第２のシナリオ修正用データのすべての処理が済んだと判定した場合、ステップＳ１３１に進む。一方、テストシナリオ作成部３６は、第２のシナリオ修正用データのすべての処理は済んでいないと判定した場合、第１のシナリオ修正用データ及び第２のシナリオ修正用データから取得した最初の一行が一致するかを判定する（ステップＳ１２７）。

テストシナリオ作成部３６は、第１のシナリオ修正用データ及び第２のシナリオ修正用データから取得した最初の一行が一致しないと判定した場合、ステップＳ１２５に戻る。一方、テストシナリオ作成部３６は、一致すると判定した場合、第２のシナリオ修正用データから次の一行を取得する（ステップＳ１２８）。これにより、図２５の右図の行番号「１８」の一行が取得される。

次に、ＸPath抽出部３５は、第１のシナリオ修正用データ及び第２のシナリオ修正用データから取得した次の一行が一致するかを判定する（ステップＳ１２９）。テストシナリオ作成部３６は、第１及び第２のシナリオ修正用データから取得した次の一行が一致しないと判定し場合、ステップＳ１２５に戻る。一方、ＸPath抽出部３５は、一致すると判定した場合、第１のシナリオ修正用データに含まれる第１のＸPathと第２のシナリオ修正用データに含まれる第２のＸPathとの対応情報を抽出する。ＸPath抽出部３５は、第１のシナリオ修正用データ及び第２のシナリオ修正用データに含まれる所定の表記が一致する位置に応じて第１のＸPathと第２のＸPathとの対応情報を抽出する。本実施形態では、対応情報を抽出するために所定の表記が一致する位置は、第１のシナリオ修正用データ及び第２のシナリオ修正用データから取得した最初の一行と次の一行との複数位置である。ただし、所定の表記が一致する位置は、これに限らず、第１のシナリオ修正用データ及び第２のシナリオ修正用データから取得した最初の一行のみであってもよいし、次の一行のみであってもよい。

テストシナリオ作成部３６は、第１のシナリオ修正用データの取得した最初の行から次の行までの間のＸPathと、第２のシナリオ修正用データの取得した最初の行から次の行までの間のＸPathとの対応関係（対応情報）に基づき、第１のテストシナリオのＸPathを置き換え、第２のテストシナリオを自動作成する（ステップＳ１３０）。

例えば、図２５の例では、第１のシナリオ修正用データの取得した二行の間（最初の行から次の行の間）と、第２のシナリオ修正用データの取得した二行の間（最初の行から次の行の間）との対応情報１に基づき、第１のテストシナリオのＸPathが置き換えられ、第２のテストシナリオが自動作成される。対応情報２についても同様に第１のテストシナリオのＸPathが置き換えられ、第２のテストシナリオが自動作成される。

これにより、図２６に示すように、第１のテストシナリオの対応情報１のＸPathは、図２１の第１のシナリオ修正用データのＸPath（Ａ）から、図２３の第２のシナリオ修正用データのＸPath（ａ）に置き換えられる。また、第１のテストシナリオの対応情報２のＸPathは、図２１の第１のシナリオ修正用データのＸPath（Ｂ）から、図２３の第２のシナリオ修正用データのＸPath（ｂ）に置き換えられる。このようにして、システムの機能変更前の第１のテストシナリオから機能変更後の第２のテストシナリオを自動作成することができる。

図２６の対応情報１では、図２７（ａ）の第１のテストシナリオのコマンドｉｎｐｕｔ（入力）において、値「１＋２」を入力する場所（Ｘpath）は「/html/body/table/tr/td/input」で示されている。これに対して、本実施形態では、図２７（ｂ）の第２のテストシナリオのコマンドｉｎｐｕｔにおいて、値「１＋２」を入力する場所（Ｘpath）が「/html/body/table/tr［2］/td/input」に自動変更される。

また、図２６の対応情報２では、図２７（ａ）の第１のテストシナリオのコマンドＣｈｅｃｋ（チェック）において、値「３」が場所（Ｘpath）「/html/body/table/tr/td［2］」に表示されていることをチェックする。これに対して、本実施形態では、図２７（ｂ）の第２のテストシナリオのコマンドＣｈｅｃｋにおいて、値「３」が表示されていることをチェックする場所（Ｘpath）が「/html/body/table/tr［2］/td［2］」に自動変更される。

図２８に示す機能変更前のＨＴＭＬファイルに基づき生成した図２９のウェブ画面１１（第１のウェブ画面例）において、図２８の「Ｐ」で示すテストシナリオの入力コマンドが実行されると、値「１＋２」が図２９に示す「注釈」の入力エリア（Ｘpathで示した場所）に入力される。また、図２８の「Ｑ」で示すテストシナリオの表示コマンドが実行されると、図２９に示す「結果」（Ｘpathで示した場所）に表示された値「３」がチェックされる。

これに対して、機能変更後のＨＴＭＬファイルには、図３０の「Ｒ」で示す「注釈２」が追加される。これにより、機能変更後の図３１のウェブ画面１１（第２のウェブ画面例）では、機能変更前の図２９のウェブ画面１１に対して「注釈」の前に「注釈２」が表示される。

機能変更後の図３１のウェブ画面１１に対して、図２７（ａ）に示す第１のテストシナリオのＸpathが示す画面上の場所に値を表示しようとすると、テストでは、図３２のように「注釈２」に値「１＋２」を入力しようとしてしまう。また、図３２のように「注釈」に値「３」が表示されていることを確認してしまう。

しかしながら、本実施形態では、自動作成された第２のテストシナリオに基づき、図３３に示したように、自動作成した第２のテストシナリオの図２７（ｂ）に示すＸpathに基づき、「注釈」に値「１＋２」が入力され、「結果」に値「３」が表示されていることが確認される。このようにして、第１のテストシナリオの機能変更前のＸpathと機能変更後のＸpathとを対応させて第２のテストシナリオを自動作成することで、機能変更後のテストシナリオのコマンドを機能変更後のウェブ画面１１のレイアウトに合致させて実行できる。

以上に説明したように、テストは、第１のテストシナリオから自動作成された第２のテストシナリオに基づき繰り返し実行される。すべてのテストシナリオが実行された後、テストが終了される。

図３４は機能変更前のテストシナリオの実行例を示し、図３５は機能変更後のテストシナリオの実行例を示す。図３４及び図３５では、左上図のログイン画面でウェブシステム２０が起動され、ログイン後に図３４及び図３５の左下図のウェブ画面１１に画面が遷移する。図３４の左下図のウェブ画面１１に対する第１のテストシナリオから、図３５の左下図のウェブ画面１１に新たな機能表示（ディスク使用量）が追加された場合の第２のテストシナリオが自動作成された一例が示されている。

以上に説明したように、一実施形態に係るウェブテストシステム３０によれば、システムに機能変更が生じた場合、機能変更前のテストシナリオに基づきシステムの機能変更後のウェブ画面をテストするためのテストシナリオを自動作成することができる。つまり、システムの機能変更前後でウェブ画面１１のレイアウトが変更されても、機能変更前後におけるテストシナリオに記述されたＸpathの対応情報を抽出することで機能変更前のウェブ画面１１をテストするためのテストシナリオから機能変更後のウェブ画面１１をテストするためのテストシナリオを自動作成できる。これにより、手動によるテストシナリオの変更が不要になり、また、ＯＳやブラウザに依存せずに画面のテストを行うことができる。

（ハードウェア構成例）
最後に、本実施形態に係るウェブテストシステム３０のハードウェア構成例について、図３６を参照して説明する。図３６は、本実施形態に係るウェブテストシステム３０のハードウェア構成例を示す図である。

図３６に示すように、ウェブテストシステム３０は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０４、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０５、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１０８などを備え、それぞれがバスＢで相互に接続されている。

入力装置１０１は、キーボードやマウスなどを含み、ウェブテストシステム３０に各操作信号を入力するのに用いられる。表示装置１０２は、各種の処理結果を表示する。

通信Ｉ／Ｆ１０７は、ウェブテストシステム３０をネットワークに接続するインタフェースである。これにより、ウェブテストシステム３０は、通信Ｉ／Ｆ１０７を介してウェブシステム２０とデータ通信を行うことができる。

ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、装置全体を制御する基本ソフトウェア及びアプリケーションソフトウェアがある。例えば、ＨＤＤ１０８には、ソースコードＤＢ４１、修正ソースコードＤＢ４２、テストシナリオＤＢ４３、シナリオ修正用ＤＢ４４及びテスト実行結果ＤＢ４５が格納されている。

外部Ｉ／Ｆ１０３は、外部装置とのインタフェースである。外部装置には、記録媒体１０３ａなどがある。これにより、ウェブテストシステム３０は、外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。

記録媒体１０３ａには、フロッピー（登録商標）ディスク、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｋ）、及びＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ならびに、ＳＤメモリカード（ＳＤ Ｍｅｍｏｒｙ ｃａｒｄ）やＵＳＢメモリ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ ｍｅｍｏｒｙ）などがある。

ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１０５には、ネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＣＰＵ１０６は、上記記憶装置（例えば「ＨＤＤ１０８」や「ＲＯＭ１０５」など）から、プログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する演算装置である。

上記ハードウェア構成により、例えば、ＣＰＵ１０６が、ＲＯＭ１０５やＨＤＤ１０８内に格納されたデータ及びプログラムを用いてテストシナリオの操作手順に基づきウェブ画面１１のテストを実行する。

なお、ソースコードＤＢ４１、修正ソースコードＤＢ４２、テストシナリオＤＢ４３、シナリオ修正用ＤＢ４４及びテスト実行結果ＤＢ４５に関する情報は、ＲＡＭ１０４、ＨＤＤ１０８に格納されてもよい。これらのＤＢは、ネットワークを介してウェブテストシステム３０に接続されるクラウド上のサーバー等に格納されてもよい。

以上、試験プログラム、試験装置及び試験方法を上記実施形態により説明したが、本発明にかかる試験プログラム、試験装置及び試験方法は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。

例えば、上記実施形態に係る試験プログラム、試験装置及び試験方法の構成は一例であり、本発明の範囲を限定するものではなく、用途や目的に応じて様々なシステム構成例があることは言うまでもない。

１：サーバ／ストレージシステム
１０：サーバ／ストレージ装置
１１：ウェブ画面
２０：ウェブシステム
３０：ウェブテストシステム
３１：ソースコード読込部
３２：修正ソースコード作成部
３３：テストシナリオ読込部
３４：修正用データ作成部
３５：ＸPath抽出部
３６：テストシナリオ作成部
３７：テスト実行処理部
４０：記憶部
４１：ソースコードＤＢ
４２：修正ソースコードＤＢ
４３：テストシナリオＤＢ
４４：シナリオ修正用ＤＢ
４５：テスト実行結果ＤＢ

Claims (6)

1. システムの機能変更前の処理が記述された第１のソースコードに所定の表記を付加した第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと前記所定の表記とを含んだ第１のシナリオ修正用データを作成し、
   システムの機能変更後の処理が記述された第２のソースコードに所定の表記を付加した第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと前記所定の表記とを含んだ第２のシナリオ修正用データを作成し、
   前記第１のシナリオ修正用データと前記第２のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第１のＸPathと前記第２のＸPathとの対応情報を抽出し、
   前記抽出した対応情報に基づき、前記第１のウェブ画面の操作手順を示す第１のテストシナリオから前記第２のウェブ画面の操作手順を示す第２のテストシナリオを作成する、
   処理をコンピュータに実行させるための試験プログラム。
2. 前記抽出する処理は、
   前記所定の表記が一致する位置に応じたＨＴＭＬファイルのタグ構造から前記第１のＸPathと前記第２のＸPathとの対応情報を抽出する、
   請求項１に記載の試験プログラム。
3. システムの機能変更前の処理が記述された第１のソースコードに所定の表記を付加して第１の修正ソースコードを作成し、システムの機能変更後の処理が記述された第２のソースコードに所定の表記を付加して第２の修正ソースコードを作成する修正ソースコード作成部と、
   前記第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと前記所定の表記とを含んだ第１のシナリオ修正用データを作成し、前記第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと前記所定の表記とを含んだ第２のシナリオ修正用データを作成する修正用データ作成部と、
   前記第１のシナリオ修正用データと前記第２のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第１のＸPathと前記第２のＸPathとの対応情報を抽出する抽出部と、
   前記抽出した対応情報に基づき、前記第１のウェブ画面の操作手順を示す第１のテストシナリオから前記第２のウェブ画面の操作手順を示す第２のテストシナリオを作成するテストシナリオ作成部と、
   を有する試験装置。
4. 前記抽出部は、
   前記所定の表記が一致する位置に応じたＨＴＭＬファイルのタグ構造から前記第１のＸPathと前記第２のＸPathとの対応情報を抽出する、
   請求項３に記載の試験装置。
5. システムの機能変更前の処理が記述された第１のソースコードに所定の表記を付加した第１の修正ソースコードに基づき、機能変更前の第１のウェブ画面の位置を指定する第１のＸPathと前記所定の表記とを含んだ第１のシナリオ修正用データを作成し、
   システムの機能変更後の処理が記述された第２のソースコードに所定の表記を付加した第２の修正ソースコードに基づき、機能変更後の第２のウェブ画面の位置を指定する第２のＸPathと前記所定の表記とを含んだ第２のシナリオ修正用データを作成し、
   前記第１のシナリオ修正用データと前記第２のシナリオ修正用データとに含まれる前記所定の表記が一致する位置に応じて前記第１のＸPathと前記第２のＸPathとの対応情報を抽出し、
   前記抽出した対応情報に基づき、前記第１のウェブ画面の操作手順を示す第１のテストシナリオから前記第２のウェブ画面の操作手順を示す第２のテストシナリオを作成する、
   処理をコンピュータが実行する試験方法。
6. 前記抽出する処理は、
   前記所定の表記が一致する位置に応じたＨＴＭＬファイルのタグ構造から前記第１のＸPathと前記第２のＸPathとの対応情報を抽出する、
   請求項５に記載の試験方法。

Images