電文処理システムのテストデータの生成装置、方法、及びプログラム
【課題】 複数のサーバなどの装置が協調して動作するシステムに新たに追加された装置について、網羅性の高いテストデータを自動的に生成する。
【解決手段】 アプリケーションシステム１内のテスト対象サーバのテストデータを生成する管理サーバ１５は、アプリケーションシステム１の一つ以上のサーバから、各サーバに蓄積されているログデータを収集するログデータ収集部１６１と、パラメータを含むリクエスト電文テンプレートと、前記リクエスト電文テンプレートに対応するリプライ電文テンプレートとを含むテンプレート８０の登録、及びパラメータに設定されるパラメータ値７０の入力を受け付けるユーザ登録部１７１と、テンプレート８０に含まれるパラメータに、入力を受け付けたパラメータ値を設定してテストデータを生成するテストデータ生成部１７３と、を備える。
【解決手段】 アプリケーションシステム１内のテスト対象サーバのテストデータを生成する管理サーバ１５は、アプリケーションシステム１の一つ以上のサーバから、各サーバに蓄積されているログデータを収集するログデータ収集部１６１と、パラメータを含むリクエスト電文テンプレートと、前記リクエスト電文テンプレートに対応するリプライ電文テンプレートとを含むテンプレート８０の登録、及びパラメータに設定されるパラメータ値７０の入力を受け付けるユーザ登録部１７１と、テンプレート８０に含まれるパラメータに、入力を受け付けたパラメータ値を設定してテストデータを生成するテストデータ生成部１７３と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の装置が電文を送受信しながら協調して動作する電文処理システムのテストデータの生成及びテストの実施のための技術に関する。
【背景技術】
【０００２】
複数のサーバなどの装置が協調して動作する大規模コンピュータシステムに、新たにサーバを設置して、このサーバにプログラムのインストール、初期設定などを自動的に行うプロビジョニング技術が知られている（例えば特許文献１）。
【特許文献１】特開平２−２０１６５７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、プロビジョニングによって自動的に追加されたサーバを実際に稼動させる（リリースする）ためには、以下のようなことを確認しなければならない。例えば、追加されたサーバが単独で正常に動作をするか否かや、追加されたサーバを経由したときにシステム全体として正常に動作するか否かなどをテストして確認する必要がある。これらは、従来、テスト実施者が作成したテストデータを流し、その結果をテスト実施者が確認しているため、網羅性に欠けるものであったり、見誤りがあったりして、完璧を期しがたいものであった。
【０００４】
さらには、プロビジョニングによって同時に複数のサーバが追加されると、従来はこれらを一括してリリースしていた。この結果、新たにリリースしたサーバのうちの複数で同時に不具合が発生すると、システム全体に与える影響が大きい。
【０００５】
そこで、本発明の目的は、複数のサーバなどの装置が協調して動作するシステムに新たに追加された装置について、網羅性の高いテストデータを自動的に生成するための技術を提供することである。
【０００６】
本発明のさらなる目的は、自動的に生成されたテストデータを用いたテストの実施、及びその結果の検証を自動的に行うための技術を提供することである。
【課題を解決するための手段】
【０００７】
本発明の一つの実施態様に従うテストデータの生成装置は、複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内のテスト対象装置のテストデータを生成する装置であって、前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得する手段と、パラメータを含む電文テンプレートを登録する手段と、前記パラメータに設定されるパラメータ値の入力を受け付けるパラメータ入力手段と、前記登録手段により登録された電文テンプレートに含まれるパラメータに、前記パラメータ入力手段が入力を受け付けたパラメータ値を設定してテストデータを生成する手段と、を備える。
【０００８】
本発明の一つの実施態様に従うテストデータの生成装置は、複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内の、前段の装置からの入力リクエストに基づいて出力リクエストを後段の装置へ出力し、前記後段の装置からの入力リプライに基づいて出力リプライを前記前段の装置へ出力するテスト対象装置のテストデータを生成する装置であって、パラメータを含む入力リクエスト電文テンプレートと、前記入力リクエスト電文テンプレートに対応する出力リプライ電文テンプレートとを含む第１テンプレートの登録を受け付ける第１の登録手段と、パラメータを含む入力リクエスト電文テンプレート、及び前記入力リクエスト電文テンプレートに対応する出力リクエスト電文テンプレートと、パラメータを含む入力リプライ電文テンプレート、及び前記入力リプライ電文テンプレートに対応する出力リプライ電文テンプレートと、を含む第２テンプレートの登録を受け付ける第２の登録手段と、前記パラメータに設定されるパラメータ値の入力を受け付けるパラメータ入力手段と、前記第１登録手段により登録された第１テンプレートに含まれるパラメータに、前記パラメータ入力手段により入力されたパラメータ値を設定して入力リクエストテストデータと出力リプライテストデータとを含む中間テストデータを生成する手段と、前記中間テストデータと前記第２登録手段により登録された第２テンプレートに基づいて、前記入力リクエストテストデータに対応する出力リクエストテストデータと、前記出力リプライテストデータに対応する入力リプライテストデータとを生成し、最終テストデータを生成する手段と、を備える。
【０００９】
好適な実施形態では、前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得する手段をさらに備える。そして、前記中間テストデータを生成する手段は、前記パラメータ入力手段により入力されたパラメータ値、または前記取得手段により取得されたログデータから抽出した値を設定して前記中間テストデータを生成するようにしてもよい。
【００１０】
好適な実施形態では、前記中間テストデータ生成手段は、前記パラメータ入力手段により入力されたパラメータ値を、前記ログデータから抽出した値よりも優先させて設定するようにしてもよい。
【００１１】
好適な実施形態では、前記入力リクエストテストデータを前記テスト対象装置へ入力して、前記電文処理システムを動作させてテストを実行する手段と、前記テスト実行手段が前記電文処理システムを動作させることにより生成された出力リクエスト、入力リプライ及び出力リプライを含む実行結果データを収集する手段と、前記最終テストデータ生成手段により生成されたテストデータと前記収集手段により収集された実行結果データとを比較して、テスト結果を検証する手段と、をさらに備えるようにしてもよい。
【００１２】
好適な実施形態では、前記電文処理システムの環境を変更させ、及び変更後の環境を変更前へ復帰させる変更復帰手段をさらに備えるようにしてもよい。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の一実施形態に係るアプリケーションシステム及びその管理を行う管理装置（管理サーバ）について、図面を参照して説明する。
【００１４】
図１は、本実施形態に係るシステムの全体構成を示す図である。本システムは、所定の業務処理を実行するアプリケーションシステム１と、顧客が使用するクライアント２とがネットワーク９を介して接続されている。そして、アプリケーションシステム１には、このシステムを管理するための管理サーバ１５が接続されている。
【００１５】
アプリケーションシステム１は、クライアント２からのリクエストを振り分けて負荷分散をするロードバランサ１０と、クライアント２に対する入出力インタフェースを提供する複数のＰＬサーバ１１を含むＰＬサーバ群１１Ａと、様々な業務処理（ビジネスロジック、ＢＬ）を実行する複数のＢＬサーバ１２を含むＢＬサーバ群１２Ａ（第１のグループ）と、データベース１４の参照、更新などを行う複数のＤＢサーバ１３を含むＤＢサーバ群１３Ａ（第２のグループ）と、データベース（ＤＢ）１４とを備える。ＰＬサーバ１１が、クライアント２へ表示する画面の制御（プレゼンテーションロジック、ＰＬ）などのインタフェースを提供するインタフェース装置である。ＢＬサーバ１２（第１の装置）及びＤＢサーバ１３（第２の装置）が、アプリケーションシステム１の内部処理を実行する内部装置である。
【００１６】
クライアント２、各ＰＬサーバ１１、各ＢＬサーバ１２、各ＤＢサーバ１３および管理サーバ１５は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ等２，１１，１２，１３，１５内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。
【００１７】
ＰＬサーバ群１１Ａの各ＰＬサーバ１１，ＢＬサーバ群１２Ａの各ＢＬサーバ１２及びＤＢサーバ群１３Ａの各ＤＢサーバ１３は、それぞれ共通の構成を備え、同じ処理を実行するようになっている（図２参照）。つまり、サーバ群１１Ａ，１２Ａ，１３Ａがそれぞれ複数のサーバにより多重化されている。これは、耐障害性及び処理性能を確保するためである。そして、各サーバ群１１Ａ，１２Ａ，１３Ａの中では、それぞれどのサーバに処理を実行させても、同じ処理が行われる。この結果、各ＰＬサーバ１１，各ＢＬサーバ１２及び各ＤＢサーバ１３を、それぞれ比較的安価なパーソナルコンピュータなどを用いて実現するとともに、ロードバランサ１０によって負荷分散することにより、本システム１は、高額の高速コンピュータを導入することなく、低コストでハイパフォーマンスを得ることができる。さらには、本システムは、処理するデータ量の増減に伴って、各サーバ１１，１２，１３の台数を容易に増減させることができ、これにより容易に処理能力を調整することができる。本実施形態では、管理サーバ１５が、アプリケーションシステム１の動作の正常性を確認し、新たに追加されたサーバ１１，１２，１３をテストするための処理を実行し、そのサーバをリリースするための処理を実行する。
【００１８】
なお、本システムにおけるＰＬサーバ１１の台数、ＢＬサーバ１２の台数、及びＤＢサーバ１３の台数は、同じ台数でもよいし、それぞれ異なる台数でもよい。
【００１９】
アプリケーションシステム１では、クライアント２からのリクエストがＰＬサーバ群１１Ａ、ＢＬサーバ群１２Ａ、及びＤＢサーバ群１３Ａの順に伝達され、このリクエストに対するリプライがＤＢサーバ群１３ＡからＢＬサーバ群１２Ａ、ＰＬサーバ群１１Ａへと伝達されて、クライアント２へ送信される。詳細に説明すれば、リクエスト及びリプライは、例えば以下のように伝達される。
【００２０】
ＰＬサーバ群１１Ａは、前段であるクライアント２からリクエスト電文２１（図２参照）を受け付けると、１台のＰＬサーバ１１が所定の処理を実行後、後段のＢＬサーバ群１２Ａに対するサーバ間リクエスト電文Ａ２３（図２参照）を生成して、出力する。
【００２１】
ＢＬサーバ群１２Ａは、前段のＰＬサーバ群１１Ａからサーバ間リクエスト電文Ａ２３を受け付けると、１台のＢＬサーバ１２が所定の処理を実行後、後段のＤＢサーバ群１３Ａに対するサーバ間リクエスト電文Ｂ２５（図２参照）を生成して、出力する。
【００２２】
ＤＢサーバ群１３Ａは、前段のＢＬサーバ群１２Ａからサーバ間リクエスト電文Ｂ２５を受け付けると、１台のＤＢサーバ１３がＤＢ１４に対する所定の処理を実行する。そして、前段のＢＬサーバ群１２Ａに対するサーバ間リプライ電文Ｂ３５（図２参照）を生成して、出力する。
【００２３】
ＢＬサーバ群１２Ａでは、１台のＢＬサーバ１２が後段のＤＢサーバ群１３Ａからのサーバ間リプライ電文Ｂ３５に基づいて、前段のＰＬサーバ群１１Ａに対するサーバ間リプライ電文Ａ３３（図２参照）を生成して、出力する。
【００２４】
ＰＬサーバ群１１Ａでは、１台のＰＬサーバ１１が後段のＢＬサーバ群１２Ａからのサーバ間リプライ電文Ａ３３に基づいて、前段のクライアント２に対するクライアントリプライ電文３１（図２参照）を生成して、出力する。
【００２５】
図２には、ＰＬサーバ１１，ＢＬサーバ１２及びＤＢサーバ１３の詳細な構成図を示す。
【００２６】
ＰＬサーバ１１は、ロードバランサ１０を介してクライアント２から送られてくるクライアントリクエスト電文２１を受信し、これをサーバ間リクエスト電文Ａ２３に変換していずれかのＢＬサーバ１２へ出力する。また、いずれかのＢＬサーバ１２からサーバ間リプライ電文Ａ３３を受信すると、これをクライアントリプライ電文３１に変換して、ロードバランサ１０を介してクライアント２へ送信する。
【００２７】
ＰＬサーバ１１は、同図（ａ）に示すように、電文識別子付与部１１１と、ＰＬ処理部１１３と、ステータス記憶部１１４と、電文記録部１１５と、ＰＬログ１１７とを備える。
【００２８】
電文識別子付与部１１１は、クライアントリクエスト電文２１を受信すると、これに電文識別子を付与する。電文識別子は、それぞれのＰＬサーバ１１が生成するユニークな数字または文字列等である。例えば、ＰＬサーバ１１に割り当てられているＩＰアドレスと、そのサーバ１１内でのカウンタ値（シリアル番号）とを組み合わせて、電文識別子を生成してもよい。
【００２９】
ＰＬ処理部１１３は、クライアントリクエスト電文２１及びサーバ間リプライ電文Ａ３３に従って、所定の処理を実行する。例えば、クライアントリクエスト電文２１に対しては、その電文に含まれるデータの整合性チェックなどを行い、サーバ間リクエスト電文Ａ２３を生成する。ここで、サーバ間リクエスト電文Ａ２３に、電文識別子付与部１１１によってクライアントリクエスト電文２１に付与された電文識別子が付与され、クライアントリクエスト電文２１とサーバ間リクエスト電文Ａ２３とが関連づけられる。また、サーバ間リプライ電文Ａ３３に対しては、クライアント２に表示される画面（Ｗｅｂページ）の合成を行い、それを含むクライアントリプライ電文３１を生成する。ここで、サーバ間リプライ電文Ａ３３に付与されている電文識別子が、クライアントリプライ電文３１には含まれない。しかし、電文記録部１１５がＰＬログ１１７に格納するクライアントリプライ電文３１のログデータには付与される。
【００３０】
ステータス記憶部１１４については後述する。
【００３１】
電文記録部１１５は、クライアントリクエスト電文２１を受信したとき、及びクライアントリプライ電文３１を出力するときに、それぞれの電文２１，３１の電文識別子を含む、各電文に関連する情報をＰＬログ１１７に格納する。
【００３２】
図３に、ＰＬログ１７のデータ構造の一例を示す。ＰＬログ１１７には、ＰＬサーバ１１がクライアント２に対して送受信した電文の送受信履歴が記憶されている。例えば、ＰＬログ１１７は、データ項目として、電文識別子５１と、送信サーバ名５２と、受信サーバ名５３と、電文内容５４とを有する。
【００３３】
図２（ｂ）には、ＢＬサーバ１２の構成を示す。ＢＬサーバ１２は、ＰＬサーバ１１から送られてくるサーバ間リクエスト電文Ａ２３を受信し、これをサーバ間リクエスト電文Ｂに変換して、いずれかのＤＢサーバ１３へ出力する。また、いずれかのＤＢサーバ１３からサーバ間リプライ電文Ｂ３５を受信すると、これをサーバ間リプライ電文Ａ３３に変換して、ＰＬサーバ１１へ送信する。なお、サーバ間リプライ電文Ａ３３の送信先は、サーバ間リクエスト電文Ａ２３の送信元のＰＬサーバ１１である。
【００３４】
ＢＬサーバ１２は、内部の構成として、ＢＬ処理部１２３と、ステータス記憶部１２４と、電文記録部１２５と、ＢＬログ１２７とを備える。
【００３５】
ＢＬ処理部１２３は、サーバ間リクエスト電文Ａ２３及びサーバ間リプライ電文Ｂ３５に従って、所定の処理を実行する。例えば、サーバ間リクエスト電文Ａ２３を受信したときは、その電文の内容に従って所定の業務処理を実行し、サーバ間リクエスト電文Ｂ２５を生成する。ここで、サーバ間リクエスト電文Ｂ２５には、サーバ間リクエスト電文Ａ２３に付与されている電文識別子が付与され、サーバ間リクエスト電文Ａ２３とサーバ間リクエスト電文Ｂ２５とが関連づけられる。また、サーバ間リプライ電文Ｂ３５を受信したときは、その電文の内容に従って所定の業務処理を実行し、サーバ間リプライ電文Ａ３３を生成する。この場合も同様に、サーバ間リプライ電文Ａ３３には、サーバ間リプライ電文Ｂ３５に付与されている電文識別子が付与され、サーバ間リプライ電文Ａ３３とサーバ間リプライ電文Ｂ３５とが関連づけられる。
【００３６】
ステータス記憶部１２４については後述する。
【００３７】
電文記録部１２５は、サーバ間リクエスト電文Ａ２３を受信したとき、及びサーバ間リプライ電文Ａ３３を出力するときに、それぞれの電文２３，３３の電文識別子を含む、各電文に関連する情報をＢＬログ１２７に格納する。
【００３８】
ＢＬログ１２７には、ＢＬサーバ１２がＰＬサーバ１１に対して送受信した電文の送受信履歴が記憶されている。ＢＬログ１２７のデータ構造は、ＰＬログ１１７と共通である。
【００３９】
図２（ｃ）には、ＤＢサーバ１３の構成を示す。ＤＢサーバ１３は、ＢＬサーバ１２から送られてくるサーバ間リクエスト電文Ｂ２５を受信し、これに基づいてＤＢ１４の参照、更新などのＤＢ処理を実行する。そして、この実行結果に基づいてサーバ間リプライ電文Ｂ３５を生成し、これをサーバ間リクエスト電文Ｂ２５の送信元のＢＬサーバ１２へ送信する。
【００４０】
ＤＢサーバ１３は、内部の構成として、ＤＢ処理部１３３と、ステータス記憶部１３４電文記録部１３５と、ＤＢログ１３７とを備える。
【００４１】
ＤＢ処理部１３３は、サーバ間リクエスト電文Ｂ２５を受信すると、その電文の内容に従ってＤＢ１４の参照、更新などの処理を実行する。そして、その処理結果に基づいてサーバ間リプライ電文Ｂ３５を生成する。ここで、サーバ間リプライ電文Ｂ３５には、サーバ間リクエスト電文Ｂ２５に付与されている電文識別子が付与され、サーバ間リプライ電文Ｂ３５とサーバ間リクエスト電文Ｂ２５とが関連づけられる。
【００４２】
ステータス記憶部１３４については後述する。
【００４３】
電文記録部１３５は、サーバ間リクエスト電文Ｂ２５を受信したとき、及びサーバ間リプライ電文Ｂ３５を出力するときに、それぞれの電文２５，３５の電文識別子を含む、各電文に関連する情報をＤＢログ１３７に格納する。
【００４４】
ＤＢログ１３７には、ＤＢサーバ１３がＢＬサーバ１２に対して送受信した電文の送受信履歴が記憶されている。ＤＢログ１３７のデータ構造は、ＰＬログ１１７及びＢＬログ１２７と共通である。
【００４５】
ここで、図４にそれぞれの電文フォーマットを示す。同図（ａ）に示すように、クライアントリクエスト電文２１は、ＨＴＭＬなどで記述されたクライアントリクエスト本文を含んでいる。同図（ｂ）に示すように、クライアントリプライ電文３１は、ＨＴＭＬなどで記述されたクライアントリプライ本文を含んでいる。同図（ｃ）に示すサーバ間リクエスト電文２３、２５には、それぞれのリクエスト内容を示すサーバ間リクエスト本文と、電文識別子とが含まれ、同様に同図（ｄ）に示すサーバ間リプライ電文３３、３５には、それぞれのリプライ内容を示すサーバ間リプライ本文と、電文識別子とが含まれる。
【００４６】
図５に、管理サーバ１５の構成図を示す。管理サーバ１５には、キーボードまたはポインティングデバイスなどの入力装置７と液晶ディスプレイなどの表示装置８が接続されている。そして、管理サーバ１５は、外部インタフェースとして、これらの入出力装置を制御する入出力装置制御部１５３と、アプリケーションシステム１とのインタフェースであるシステムインタフェース１５１とを有する。
【００４７】
管理サーバ１５は、各サーバ１１，１２，１３からログデータを収集し、その解析などを行う。さらに、管理サーバ１５は、プロビジョニングなどによりアプリケーションシステム１に自動的に配備されたサーバ１１，１２，１３に対し、テストデータの生成、テストの実行及びテスト結果の検証などの自動テスト処理を行う。さらに、管理サーバ１５は、プロビジョニングにより配備されたサーバ１１，１２，１３を実際に稼働させるリリース制御を行う。
【００４８】
これらの機能を実現するために、管理サーバ１５は、例えば、以下のような構成を備える。管理サーバ１５は、まず、主にログの処理に関する構成として、ログデータ収集部１６１と、収集したログを保存しておく収集ログ記憶部１６３と、収集したログデータを解析するログデータ解析部１６５とを備える。また、管理サーバ１５は、主に自動テストのための構成として、ユーザ登録部１７１と、登録情報記憶部１７２と、テストデータ生成部１７３と、テストデータ記憶部１７４と、テスト実行部１７５と、テスト結果記憶部１７６と、テスト結果処理部１７７と、ＤＢ設定変更部１７８とを備える。そして、主にリリース制御に関する構成として、リリース管理部１８１と、リリース条件表１８２と、ステータス表１８３とを備える。以下、各構成について詳細に説明する。
【００４９】
ログデータ収集部１６１は、システムインタフェース１５１を介して、アプリケーションシステム１の各サーバ１１，１２，１３がそれぞれ保持しているログデータを収集し、収集ログ記憶部１６３に格納する。
【００５０】
図６に収集ログ記憶部１６３に記憶されているログデータの一例を示す。収集ログ記憶部１６３のデータ項目は、ＰＬログ１１７、ＢＬログ１２７及びＤＢログ１３７と同一である。収集されたログデータには、クライアントリクエスト電文２１，クライアントリプライ電文３１，サーバ間リクエスト電文２３，２５及びサーバ間リプライ電文３３，３５のすべてのログが含まれているが、それらは互いに電文識別子５１により関連づけが可能である。例えば、図６のレコード１６３ａ〜ｆは、いずれも電文識別子５１が共通であるから、一つのクライアントリクエスト電文２１及びそれから派生した各電文のログであることがわかる。さらに、この例では、送信サーバ名５２及び受信サーバ名５３により、レコード１６３ａがクライアントリクエスト電文２１，レコード１６３ｂがサーバ間リクエスト電文Ａ２３，レコード１６３ｃがサーバ間リクエスト電文Ｂ２５，レコード１６３ｄがサーバ間リプライ電文Ｂ３５，レコード１６３ｅがサーバ間リプライ電文Ａ３３，及びレコード１６３ｆがクライアントリプライ電文３１であることがわかる。
【００５１】
なお、各リプライ電文３１，３３，３５は、各リクエスト電文２１，２３，２５が通ったＰＬサーバ、ＢＬサーバ及びＤＢサーバと同一のＰＬサーバ、ＢＬサーバ及びＤＢサーバを通るようになっている。つまり、同じ電文識別子を有する電文は、ＰＬサーバからＤＢサーバへ向かう昇り方向とＤＢサーバからＰＬサーバへ向かう下り方向とでは、同一のパスを通る。
【００５２】
ログデータ解析部１６５は、収集ログ記憶部１６３に格納されているログデータを解析し、アプリケーションシステム１の動作の正常性の確認をする。例えば、ログデータ解析部１６５は、電文識別子５１をキーにして収集したログデータのレコードをソートし、あるいは、同一の電文識別子５１を有する複数のレコードを１グループとしてまとめる。さらに、ログデータ解析部１６５は、同一の電文識別子５１を有するレコード間で、電文内容５４の整合性チェックを行う。そして、これらの解析結果を、入出力装置制御部１５３が表示装置８に表示する。
【００５３】
図７は、ログデータ解析部１６５がログデータの各レコードを電文識別子５１でソートした結果の一例を示す図である。
【００５４】
図８は、ログデータ解析部１６５によって抽出された電文識別子「192.168.0.102-0845」のレコード群を示す。ログデータ解析部１６５は、このレコード群に対して、さらに、整合性チェックを行う。例えば、「送信サーバ名５２→受信サーバ名５３」のペアにおいて、「client→ＰＬ*」「ＰＬ*→ＢＬ*」「ＢＬ*→ＤＢ*」「ＤＢ*→ＢＬ*」「ＢＬ*→ＰＬ*」「ＰＬ*→client」のすべてが存在することを確認する。これにより、入力されたクライアントリクエスト電文２１が途中で消失せずに、最終的なクライアントリプライ電文３１を返しているか否かを確認できる。
【００５５】
さらに、昇り電文と降り電文では同一パスを経由するようになっているため、ログデータ解析部１６５は、ＰＬサーバ及びＢＬサーバのサーバ名が同一であるか否かをチェックする。また、電文内容５４において、特定のパラメータに同一の値が設定されているか（例えばkozaID=1234567）などをチェックする。これにより、入力されたクライアントリクエスト電文２１の内容が、その後生成される各電文に受け継がれているかを確認できる。
【００５６】
また、ログデータ解析部１６５は、予め登録されている電文確認表６０を参照し、同一電文識別子５１を有するレコード群が、この表６０に登録されているリクエスト電文とリプライ電文の対応パターンに合致するか否かを判定する。電文確認表６０は、予めユーザによって登録されて、登録情報記憶部１７２に格納されている。
【００５７】
図９に、電文確認表６０の一例を示す。電文確認表６０は、対象サーバ６１と、対象サーバ６１が受信するリクエスト電文内容６２と、対象サーバが出力するリプライ電文内容６３とが対応付けられている。一つのリクエスト電文６２に対して、生じ得るリプライ電文６３は複数存在することがある。図９の場合、ＰＬサーバに対するリクエスト電文内容６０１に対するリプライとしては、リプライ電文内容６１１〜６１３があり得ることを示している。また、ＢＬサーバが受信するリクエスト電文内容６０２に対するリプライとしては、リプライ電文内容６１４，６１５があり得ることを示している。さらに、ＤＢサーバのリクエスト電文内容６０３に対するリプライとしては、リプライ電文内容６１６，６１７があり得ることを示している。
【００５８】
そして、ログデータ解析部１６５は、同じ電文識別子５１を有するレコードの中から、ＰＬサーバが受信したクライアントリクエスト電文２１のレコード（つまり、送信サーバ５２がクライアント、受信サーバ５３がＰＬサーバであるレコード１６３ａ）と、クライアントリプライ電文３１のレコード（つまり、送信サーバ５２がＰＬサーバ、受信サーバ５３がクライアントであるレコード１６３ｆ）を抽出する。そして、ここで抽出したレコードのペアが、電文確認表６０のリクエスト電文内容６０１とリプライ電文内容６１１〜６１３のペアのいずれかに合致するかを判定する。
【００５９】
ログデータ解析部１６５は、ＢＬサーバに対するリクエスト及びリプライのペア、とＤＢサーバに対するリクエスト及びリプライのペアについても同様に抽出し、電文確認表６０に登録されているペアと合致するか否かを判定する。
【００６０】
これにより、各リクエスト電文に対し、予め定められている所定のリプライ電文が生成されているか否かを確認できる。
【００６１】
次に、再び図５を参照し、自動テスト処理に関する構成及び処理について説明する。
【００６２】
ユーザ登録部１７１は、入力装置７を用いてユーザが入力するユーザ設定情報の登録を受け付ける。ユーザ登録部１７１が受け付けたユーザ設定情報は、登録情報記憶部１７２及びリリース条件表１８２に登録される。
【００６３】
登録情報記憶部１７２には、ユーザが設定した情報が記憶されている。図５の場合、ユーザ設定情報として、既に説明した電文確認表６０と、テストデータに設定されるパラメータ値が記憶されているパラメータ表７０と、テンプレート８０と、ＤＢ設定表９０とが記憶されている。
【００６４】
図１０には、パラメータ表７０の一例を示す。すなわち、パラメータ表７０は、クライアントリクエスト電文２１に含まれるパラメータ７１と、それに設定される複数のパラメータ値７２とが対応付けて登録されている。
【００６５】
図１１には、テンプレート８０の例を示す。すなわち、同図（ａ）には、送受信サーバを特定する通信パターン８１ごとに、入力リクエスト電文８２とそれに対する生成リプライ電文８３とが対応付けられているテンプレートＡを示す。例えば、テスト対象サーバに入出力する電文を同図（ｃ）に示すようにＸ，Ｙ，Ｚ，Ｗとすれば、テンプレートＡでは、ＸとＷとの対応関係が示されている。また、同図（ｂ）には、送受信サーバを特定する通信パターン８５ごとに、あるサーバの前段に対する電文８４と後段に対する電文８６とが対応付けられているテンプレートＢを示す。例えば同図（ｃ）と対応させると、前段に対する電文８４がＸまたはＷであり、後段に対する電文８６がＹまたはＺであり、ＸとＹまたはＷとＺがそれぞれ対応付けられている。
【００６６】
図１２には、ＤＢ設定表９０の一例を示す。ＤＢ設定表９０には、同図（ａ）に示すデータ設定表９０１と同図（ｂ）に示すデータ戻し表９０２とがある。データ設定表９０１及びデータ戻し表９０２は、いずれも、値を設定する表名９１と、値を設定する条件９２と、値を設定する列名９３と、設定値９４とを、データ項目として有する。
【００６７】
テストを実行する場合、所定の条件下でテストを実行するために、ＤＢ１４の設定を一時的に変更したいときがある。このような場合のために、データ設定表９０１の設定値９４にはユーザが入力した値が記憶されている。また、ＤＢ１４の設定を一時的に変更してテストを実行した後は、その設定を元に戻す必要がある。そこで、データ戻し表９０２の表名９１、条件９２及び列名９３には、設定を変更する際の表名、条件及び列名が記憶されるとともに、設定値９４には、設定を変更する際に取得した変更前のＤＢ１４の値が記憶される。
【００６８】
テストデータ生成部１７３は、パラメータ表７０、テンプレート８０及び収集ログ記憶部１６３に格納されているログデータに基づいてテストデータを生成し、テストデータ記憶部１７４に格納する。例えば、テンプレート８０に含まれているパラメータに、パラメータ表７０に設定されているパラメータ値７２を優先させて設定し、パラメータ表７０にパラメータ値が設定されていないパラメータについては、ログデータから抽出して設定する。これにより、テスト実施者は、自らが着目するパラメータについてだけパラメータ値を登録しておけばよい。この場合、特に着目しないパラメータについてはログデータから自動設定される。従って、テンプレート８０内のすべてのパラメータに値が設定されるので、テストデータの不備によりテストが滞ってしまうようなことがない。
【００６９】
一方、パラメータ表７０にすべてのパラメータの値が設定されていれば、ログデータは不要である。また、パラメータ表７０がないとき、あるいはパラメータ表７０にはパラメータ値が何も設定されていないときは、ログデータからすべてのパラメータ値を取得してテストデータを生成してもよい。
【００７０】
本実施形態では、まず、テンプレートＡ、パラメータ表７０及びログデータに基づいて中間的なテストデータであるテストデータＡ（図１３参照）が生成される。そして、テストデータＡとテンプレートＢに基づいて最終的なテストデータであるテストデータＢ（図１４参照）が生成される。以下、具体的に説明する。
【００７１】
まず、図１１（ａ）のテンプレートＡは、各サーバに対するリクエスト電文（Ｘ）と各サーバから出力され得るリプライ電文（Ｗ）とのペアを定義している。そこで、テストデータ生成部１７３は、テンプレートＡの各パラメータに図１０に示すパラメータ表７０に登録されている値を設定する。この例では、支店ＩＤ（sitenID）、口座ＩＤ（kozaID）、パスワード（passward）、口数（item_count）及び残高（zandaka）に、パラメータ表７０に登録されているそれぞれの値がセットされる。
【００７２】
この段階では、テンプレートＡにおけるパラメータitemには値がセットされていない。そこで、テストデータ生成部１７３は、パラメータitemに設定すべき値を、ログデータのいずれかのレコードから抽出してセットする。このようにして、図１３に示すテストデータＡが生成される。
【００７３】
図１３のテストデータＡは、サーバＡ４０１からサーバＢ４０２へのリクエスト電文（Ｘ）４０３及びそのリクエスト電文（Ｘ）４０３に対するサーバＢからサーバＡへのリプライ電文（Ｗ）４０４からなる。図１３の例では、テストデータ４３１及び４３２のリクエスト電文（Ｘ）４０３は共通であり、これに対するリプライ電文（Ｗ）４０４として異なるパターンがセットされたものである。
【００７４】
次に、図１１（ｂ）のテンプレートＢは、リクエスト電文（Ｘ）とそれにより生成される後段へのリクエスト電文（Ｙ）、及びリプライ電文（Ｗ）とそれが生成される前の後段からのリプライ電文（Ｚ）とのペアを定義している。そこで、テストデータ生成部１７３は、テンプレートＢに図１３のテストパターンＡのリクエスト電文（Ｘ）４０３及びリプライ電文（Ｗ）４０４を適用し、それぞれに対応する電文Ｙ，Ｚを生成する。このとき、テストパターンＡにおいて既に設定されているパラメータは、それぞれ対応する電文Ｙ，Ｚに設定される。この処理により生成されたテストデータＢを図１４に示す。
【００７５】
図１４のテストデータＢは、テスト対象サーバ４１１に対するリクエスト電文（Ｘ）４１２と，これに対応するリプライ電文（Ｗ）４１３と、後段に対するリクエスト電文（Ｙ）４１４と、後段からのリプライ電文（Ｚ）４１５とがワンセットになっている。ここで、テストデータ４４１，４４２，４４３はいずれもリクエスト電文（Ｘ）４１２は共通である。これは、同じリクエスト電文（Ｘ）４１２を入力した場合でも、そこから派生する電文Ｙ，Ｚ，Ｗについては複数のパターンが生じ得るので、正常に動作する場合のすべてのパターンが用意されているからである。
【００７６】
テストデータ記憶部１７４には、上記のようにして生成されたテストデータＢが記憶される。
【００７７】
テスト実行部１７５は、テストデータ記憶部１７４からテストデータを取得してテストを実行し、そのテスト結果をテスト結果記憶部１７６に格納する。例えば、テスト実行部１７５は、テストデータ記憶部１７４からテストデータＢのテストデータを１つずつ読み出し、システムインタフェース１５１を介して、テスト対象サーバ４１１にリクエスト電文（Ｘ）４１２を入力する。テスト対象サーバ４１１は、リクエスト電文（Ｘ）４１２が入力されると、この電文４１２に基づいて所定の処理を実行する。その結果、テスト対象サーバ４１１から後段のサーバへリクエスト電文（Ｙ）が出力され、後段の各サーバもこれに従って動作する。そして、最終的にテスト対象サーバからリプライ電文（Ｗ）が出力される。ここで、テスト実行部１７５は、入力したリクエスト電文（Ｘ）４１２に基づく電文Ｙ，Ｚ，Ｗを、テスト対象サーバ及び後段のサーバのログファイルからそれぞれ取得して、これらを関連づけた形でテスト結果記憶部１７６に格納する。
【００７８】
テスト結果処理部１７７は、テスト結果記憶部１７６に記憶されているテスト結果の電文と、テストデータ記憶部１７４に記憶されているテストデータＢとを対比してテスト結果の解析などを行う。この解析結果は、表示装置８に出力される。
【００７９】
例えば、テスト結果処理部１７７は、入力されたリクエスト電文（Ｘ）及びこれに対するサーバの処理結果として得られた電文Ｙ，Ｚ，Ｗの組が、テストデータ記憶部１７４に記憶されているテストデータＢのいずれかと一致するか否かを判定する。いずれかと一致すれば、アプリケーションシステム１は正常に動作していると考えられる。一方、いずれとも一致しない場合は、テスト対象サーバまたはその後段のサーバに何らかの異常があると考えられる。これらの解析結果は、例えば表示装置８に一覧表示される。
【００８０】
これにより、テンプレート及び必要なパラメータを設定するだけで、網羅的なテストデータの生成、テストの実施及びその結果の解析を自動的に行うことができる。さらに、テスト実施者は、表示装置８にテストの解析結果が表示されるので、システムが正常であるかを直ちに知ることができる。
【００８１】
ＤＢ設定変更部１７８は、テストを実施するために、アプリケーションシステム１の動作環境の変更及びその復帰を行う。例えば、ＤＢ設定変更部１７８は、ＤＢ設定表９０を参照して、システムインタフェース１５１を介してＤＢ１４の内容を一時的に変更する。例えば、ＤＢ設定変更部１７８は、データ設定表９０１（図１２（ａ））に基づいてＤＢ１４を更新する。また、上記の設定変更をする際に、ＤＢ設定変更部１７８は、変更前の状態をデータ戻し表９０２（図１２（ｂ））に設定する。そして、テスト終了後に、データ戻し表９０２を参照して前の状態へ戻す。
【００８２】
例えば、図１２（ａ）に示すデータ設定表９０１の場合、ＤＢ設定変更部１７８は、表名９１に設定されている表から、条件９２を満たすレコードを抽出する。そして、そのレコードの列名９３に合致する列を設定値９４に設定されている値に変更する。これにより、テストを行うときのＤＢの設定を自在に変更することができる。
【００８３】
次に、リリース制御に関する構成及び処理について説明する。
【００８４】
リリース管理部１８１は、システムインタフェース１５１を介して、アプリケーションシステム１内の各サーバ１１，１２，１３のステータスを照会する。例えば、各サーバ内のステータス記憶部１１４、１２４，１３４に記憶されている各サーバのステータスを取得する。ここで取得した各サーバ１１，１２，１３のステータスは、ステータス表１８３に格納される。
【００８５】
ここで、各サーバ内のステータス記憶部１１４、１２４，１３４に格納されるステータス情報について説明する。
【００８６】
アプリケーションシステム１に新たに追加されたサーバの場合、ステータス記憶部にはプロビジョニングが終了した時点で「未テスト」というステータスが設定される。その後、上述したテストが実行されているときは、テスト実行部１７５によりステータスが「テスト中」に変更される。そして、表示装置８に表示されたテスト結果などにより、すべてのテストが正常終了したことが確認され、テスト実施者によりテスト完了を示す入力がなされると、そのサーバのステータス記憶部には、アプリケーションシステム１の一部として正式に稼働可能であることを示す「リリース可」というステータスが設定される。さらに、後述するように、リリース管理部１８１がリリースしたときは、リリースされたサーバ内のステータス記憶部には、「リリース済み」というステータスが設定される。
【００８７】
図１５には、ステータス表１８３の一例を示す。すなわち、ステータス表１８３には、サーバ名１８３１とステータス１８３２とが対応付けて登録されている。ステータス１８３２には、各サーバのステータス記憶部１１４、１２４，１３４から取得したステータスが格納される。
【００８８】
また、リリース管理部１８１は、ステータス表１８３のステータス１８３２が「リリース可」であるサーバについて、リリース条件表１８２に設定された条件が満たされているか否かを判定し、条件が満たされている場合にそのサーバをリリースする。ここで、サーバのリリースを実行するためには、リリース管理部１８１がリリース対象のサーバを指定して、所定のリリース処理コマンドを発行する。リリース処理コマンドは、例えば、リリース管理部１８１が有するコマンド表１８４を参照して取得する。
【００８９】
図１６には、コマンド表１８４の一例を示す。コマンド表１８４には、サーバ種別１８４１ごとにリリース処理コマンド１８４２が登録されている。リリース管理部１８１は、リリースするサーバの種別に応じて、リリース処理コマンドを取得して、実行する。
【００９０】
図１７には、リリース条件表１８２の一例を示す。すなわち、リリース条件表１８２には、リリース対象サーバ１８２１と依存サーバ１８２２とが対応付けて記憶されている。ここで、依存サーバ１８２２とは、リリース対象サーバ１８２１をリリースするためにはリリース済みでなければならないサーバである。つまり、リリース対象サーバ１８２１がリリース可能な状態であっても、依存サーバ１８２２がリリース済みでなければリリース対象サーバ１８２１をリリースすることができない。リリース条件表１８２は、システム管理者等によって予め設定される。
【００９１】
つぎに、上記のような構成を備えたシステムにおける種々の処理手順について、図１８〜図２０のフローチャートを用いて説明する。
【００９２】
まず、図１８には、ログの収集及び解析を行う場合の管理サーバ１５の処理手順を示す。
【００９３】
ログデータ収集部１６１がアプリケーションシステム１内の各サーバ１１，１２，１３から、それぞれに蓄積されているログデータを収集し、収集ログ記憶部１６３に格納する（Ｓ１０１）。ログデータ解析部１６５は、収集ログ記憶部１６３に格納されているログデータを、各レコードに含まれている電文識別子をキーにして分類し、電文識別子別に抽出する（Ｓ１０２）。ログデータ解析部１６５は、登録情報記憶部１７２に予め登録されている電文確認表６０を参照して、同じ電文識別子を有する電文間の整合性をチェックする（Ｓ１０３）。ここでは、例えば、リクエストに対するリプライが予め定められているパターンと一致するか否かを判定する。そして、その解析結果を表示装置８に表示出力する（Ｓ１０４）。
【００９４】
これにより、複数のサーバ間で電文を送受信して動作するアプリケーションシステム１において、各サーバ間で送受信される電文が正常であるか否かを自動的に確認することができる。さらに、各サーバ群でそれぞれ複数のサーバを有し、様々な経路で電文がやりとりされる場合であっても、すべての電文のやりとりをもれなくチェックすることができ、網羅性の高いテストを行うことができる。
【００９５】
次に、図１９には、テストデータの生成及びテストの実施を自動的に行う場合の管理サーバ１５の処理手順を示す。
【００９６】
テスト実施者が、テストデータの基となるテストパターンのテンプレート及びそのテンプレートにセットされるパラメータ値を登録する（Ｓ２０１）。ログデータ収集部１６１は、アプリケーションシステム１の各サーバ１１，１２，１３からログデータを収集し、収集ログ記憶部１６３に格納する（Ｓ２０２）。
【００９７】
そして、テストデータ生成部１７３は、上述の処理で登録されたテンプレート及びパラメータ値と、ログデータとに基づいて、中間的なテストデータであるテストデータＡを生成する（Ｓ２０３）。このとき、テスト実施者が登録したパラメータ値をまず設定し、テスト実施者が設定していないパラメータについては、ログデータから取得した値を設定する。次に、テストデータ生成部１７３は、テストデータＡとテンプレートとを用いて、最終的なテストデータであるテストデータＢを生成する（Ｓ２０４）。
【００９８】
ここで、テストデータを流してテストを実施するに当たり、テスト環境であるＤＢ１４の設定を変更する必要がある場合には、ＤＢ設定変更部１７８が、予め登録されているＤＢ設定表９０を参照して設定変更を行う（Ｓ２０５，２０６）。
【００９９】
そして、テスト実行部１７５がテスト対象サーバにテストデータのリクエスト電文を入力して、アプリケーションシステム１を動作させて、テストを実施する（Ｓ２０７）。
【０１００】
テストの実施が終了すると、ステップＳ２０６でＤＢの設定変更を行っている場合は、その変更を元に戻し、変更前の状態に復帰させる（Ｓ２０８，２０９）。
【０１０１】
テスト結果処理部１７７は、テスト結果記憶部１７６に格納されているテスト結果を、テストデータ記憶部１７４に記憶されているテストデータと比較して検証する（Ｓ２１０）。そして、検証結果が、表示装置８に表示される。
【０１０２】
これにより、テスト実施者は、数多くのテストデータそのものを作成しなくても、テンプレートとしてテストしたいパターンを登録し、重要なパラメータ値を登録しておくことにより、テストデータが自動的に生成され、かつ、テスト及びその結果検証も自動的に行うことができる。さらに、パラメータ値の設定も、すべてのパラメータについて行う必要がない。つまり、テスト実施者が特に指定しないパラメータはログデータから抽出して自動的に補われるので、テスト実施者は、パラメータ値を網羅的に設定しなくてもテストデータを生成することができる。これにより、テスト実施者の負担が軽減される。
【０１０３】
図２０には、管理サーバ１５が行うリリース制御の処理手順を示す。
【０１０４】
まず、システム管理者が、新規に追加されたサーバをリリースするためのリリース条件を登録する（Ｓ３０１）。登録されたリリース条件は、リリース条件表１８２に格納される。リリース管理部１８１は、リリース判定を行う対象のサーバから、そのサーバのステータスを取得し、ステータス管理表１８３に格納する（Ｓ３０２）。対象のサーバが複数ある場合は、すべての対象サーバから取得する。
【０１０５】
リリース管理部１８１は、ステータス管理表１８３を参照し、「リリース可」であるサーバの有無を判定する（Ｓ３０３）。そして、「リリース可」であるサーバがないときは、終了する（Ｓ３０３：Ｎｏ）。
【０１０６】
一方、「リリース可」であるサーバがあるときは（Ｓ３０３：Ｙｅｓ）、リリース管理部１８１は、リリース条件表１８２を参照し、そのサーバのリリース条件が満たされているか否かを判定する（Ｓ３０４）。そして、リリース条件が満たされていないときは、終了する（Ｓ３０４：Ｎｏ）。
【０１０７】
リリース条件が満たされているときは（Ｓ３０４：Ｙｅｓ）、リリース管理部１８１は、リリース対象サーバの種別に応じて、コマンド表１８４からリリースコマンドを取得し、それをリリース対象サーバへ送信して、リリースを実行する（Ｓ３０５，３０６）。
【０１０８】
ステップＳ３０３以降の処理を繰り返すことにより、リリース対象サーバが複数ある時は、順次リリース判定及びリリースを実施することができる。
【０１０９】
これにより、システム管理者が定めたリリース対象サーバごとのリリース条件に従って、サーバごとにリリース判定が行われる。
【０１１０】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【０１１１】
例えば、上述の実施形態では、アプリケーションシステム１がＰＬサーバ群１１Ａ，ＢＬサーバ群１２Ａ，及びＤＢサーバ群１３Ａの３層構造になっているが、２層、あるいは４層以上であってもよい。さらには、アプリケーションシステム１は、必ずしも層構造になっていなくてもよい。
【図面の簡単な説明】
【０１１２】
【図１】本実施形態に係るシステムの全体構成図。
【図２】ＰＬサーバ１１，ＢＬサーバ１２及びＤＢサーバ１３の詳細な構成図。
【図３】ＰＬログ１１７、ＢＬログ１２７、ＤＢログ１３７のデータ構造の一例。
【図４】各電文フォーマットの一例。
【図５】管理サーバ１５の構成図。
【図６】収集ログ記憶部１６３に記憶されているログデータの一例。
【図７】ログデータ解析部１６５がログデータの各レコードを電文識別子５１でソートした結果の一例。
【図８】電文識別子「192.168.0.102-0845」のレコード群。
【図９】電文確認表６０の一例。
【図１０】パラメータ表７０の一例。
【図１１】テンプレート８０の一例。
【図１２】ＤＢ設定表９０の一例。
【図１３】テストデータＡの一例。
【図１４】テストデータＢの一例。
【図１５】ステータス表１８３の一例。
【図１６】コマンド表１８４の一例。
【図１７】リリース条件表１８２の一例。
【図１８】ログの収集及び解析を行う場合の処理手順を示すフローチャート。
【図１９】テストデータの生成及びテストの実施を自動的に行う場合の処理手順を示すフローチャート。
【図２０】リリース制御の処理手順を示すフローチャート。
【符号の説明】
【０１１３】
１ アプリケーションシステム
２ クライアント
１０ ロードバランサ
１１ ＰＬサーバ
１２ ＢＬサーバ
１３ ＤＢサーバ
１４ ＤＢ
１５ 管理サーバ
２１ クライアントリクエスト電文
２３，２５ サーバ間リクエスト電文
３１ クライアントリプライ電文
３３，３５ サーバ間リプライ電文
【技術分野】
【０００１】
本発明は、複数の装置が電文を送受信しながら協調して動作する電文処理システムのテストデータの生成及びテストの実施のための技術に関する。
【背景技術】
【０００２】
複数のサーバなどの装置が協調して動作する大規模コンピュータシステムに、新たにサーバを設置して、このサーバにプログラムのインストール、初期設定などを自動的に行うプロビジョニング技術が知られている（例えば特許文献１）。
【特許文献１】特開平２−２０１６５７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、プロビジョニングによって自動的に追加されたサーバを実際に稼動させる（リリースする）ためには、以下のようなことを確認しなければならない。例えば、追加されたサーバが単独で正常に動作をするか否かや、追加されたサーバを経由したときにシステム全体として正常に動作するか否かなどをテストして確認する必要がある。これらは、従来、テスト実施者が作成したテストデータを流し、その結果をテスト実施者が確認しているため、網羅性に欠けるものであったり、見誤りがあったりして、完璧を期しがたいものであった。
【０００４】
さらには、プロビジョニングによって同時に複数のサーバが追加されると、従来はこれらを一括してリリースしていた。この結果、新たにリリースしたサーバのうちの複数で同時に不具合が発生すると、システム全体に与える影響が大きい。
【０００５】
そこで、本発明の目的は、複数のサーバなどの装置が協調して動作するシステムに新たに追加された装置について、網羅性の高いテストデータを自動的に生成するための技術を提供することである。
【０００６】
本発明のさらなる目的は、自動的に生成されたテストデータを用いたテストの実施、及びその結果の検証を自動的に行うための技術を提供することである。
【課題を解決するための手段】
【０００７】
本発明の一つの実施態様に従うテストデータの生成装置は、複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内のテスト対象装置のテストデータを生成する装置であって、前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得する手段と、パラメータを含む電文テンプレートを登録する手段と、前記パラメータに設定されるパラメータ値の入力を受け付けるパラメータ入力手段と、前記登録手段により登録された電文テンプレートに含まれるパラメータに、前記パラメータ入力手段が入力を受け付けたパラメータ値を設定してテストデータを生成する手段と、を備える。
【０００８】
本発明の一つの実施態様に従うテストデータの生成装置は、複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内の、前段の装置からの入力リクエストに基づいて出力リクエストを後段の装置へ出力し、前記後段の装置からの入力リプライに基づいて出力リプライを前記前段の装置へ出力するテスト対象装置のテストデータを生成する装置であって、パラメータを含む入力リクエスト電文テンプレートと、前記入力リクエスト電文テンプレートに対応する出力リプライ電文テンプレートとを含む第１テンプレートの登録を受け付ける第１の登録手段と、パラメータを含む入力リクエスト電文テンプレート、及び前記入力リクエスト電文テンプレートに対応する出力リクエスト電文テンプレートと、パラメータを含む入力リプライ電文テンプレート、及び前記入力リプライ電文テンプレートに対応する出力リプライ電文テンプレートと、を含む第２テンプレートの登録を受け付ける第２の登録手段と、前記パラメータに設定されるパラメータ値の入力を受け付けるパラメータ入力手段と、前記第１登録手段により登録された第１テンプレートに含まれるパラメータに、前記パラメータ入力手段により入力されたパラメータ値を設定して入力リクエストテストデータと出力リプライテストデータとを含む中間テストデータを生成する手段と、前記中間テストデータと前記第２登録手段により登録された第２テンプレートに基づいて、前記入力リクエストテストデータに対応する出力リクエストテストデータと、前記出力リプライテストデータに対応する入力リプライテストデータとを生成し、最終テストデータを生成する手段と、を備える。
【０００９】
好適な実施形態では、前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得する手段をさらに備える。そして、前記中間テストデータを生成する手段は、前記パラメータ入力手段により入力されたパラメータ値、または前記取得手段により取得されたログデータから抽出した値を設定して前記中間テストデータを生成するようにしてもよい。
【００１０】
好適な実施形態では、前記中間テストデータ生成手段は、前記パラメータ入力手段により入力されたパラメータ値を、前記ログデータから抽出した値よりも優先させて設定するようにしてもよい。
【００１１】
好適な実施形態では、前記入力リクエストテストデータを前記テスト対象装置へ入力して、前記電文処理システムを動作させてテストを実行する手段と、前記テスト実行手段が前記電文処理システムを動作させることにより生成された出力リクエスト、入力リプライ及び出力リプライを含む実行結果データを収集する手段と、前記最終テストデータ生成手段により生成されたテストデータと前記収集手段により収集された実行結果データとを比較して、テスト結果を検証する手段と、をさらに備えるようにしてもよい。
【００１２】
好適な実施形態では、前記電文処理システムの環境を変更させ、及び変更後の環境を変更前へ復帰させる変更復帰手段をさらに備えるようにしてもよい。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の一実施形態に係るアプリケーションシステム及びその管理を行う管理装置（管理サーバ）について、図面を参照して説明する。
【００１４】
図１は、本実施形態に係るシステムの全体構成を示す図である。本システムは、所定の業務処理を実行するアプリケーションシステム１と、顧客が使用するクライアント２とがネットワーク９を介して接続されている。そして、アプリケーションシステム１には、このシステムを管理するための管理サーバ１５が接続されている。
【００１５】
アプリケーションシステム１は、クライアント２からのリクエストを振り分けて負荷分散をするロードバランサ１０と、クライアント２に対する入出力インタフェースを提供する複数のＰＬサーバ１１を含むＰＬサーバ群１１Ａと、様々な業務処理（ビジネスロジック、ＢＬ）を実行する複数のＢＬサーバ１２を含むＢＬサーバ群１２Ａ（第１のグループ）と、データベース１４の参照、更新などを行う複数のＤＢサーバ１３を含むＤＢサーバ群１３Ａ（第２のグループ）と、データベース（ＤＢ）１４とを備える。ＰＬサーバ１１が、クライアント２へ表示する画面の制御（プレゼンテーションロジック、ＰＬ）などのインタフェースを提供するインタフェース装置である。ＢＬサーバ１２（第１の装置）及びＤＢサーバ１３（第２の装置）が、アプリケーションシステム１の内部処理を実行する内部装置である。
【００１６】
クライアント２、各ＰＬサーバ１１、各ＢＬサーバ１２、各ＤＢサーバ１３および管理サーバ１５は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ等２，１１，１２，１３，１５内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。
【００１７】
ＰＬサーバ群１１Ａの各ＰＬサーバ１１，ＢＬサーバ群１２Ａの各ＢＬサーバ１２及びＤＢサーバ群１３Ａの各ＤＢサーバ１３は、それぞれ共通の構成を備え、同じ処理を実行するようになっている（図２参照）。つまり、サーバ群１１Ａ，１２Ａ，１３Ａがそれぞれ複数のサーバにより多重化されている。これは、耐障害性及び処理性能を確保するためである。そして、各サーバ群１１Ａ，１２Ａ，１３Ａの中では、それぞれどのサーバに処理を実行させても、同じ処理が行われる。この結果、各ＰＬサーバ１１，各ＢＬサーバ１２及び各ＤＢサーバ１３を、それぞれ比較的安価なパーソナルコンピュータなどを用いて実現するとともに、ロードバランサ１０によって負荷分散することにより、本システム１は、高額の高速コンピュータを導入することなく、低コストでハイパフォーマンスを得ることができる。さらには、本システムは、処理するデータ量の増減に伴って、各サーバ１１，１２，１３の台数を容易に増減させることができ、これにより容易に処理能力を調整することができる。本実施形態では、管理サーバ１５が、アプリケーションシステム１の動作の正常性を確認し、新たに追加されたサーバ１１，１２，１３をテストするための処理を実行し、そのサーバをリリースするための処理を実行する。
【００１８】
なお、本システムにおけるＰＬサーバ１１の台数、ＢＬサーバ１２の台数、及びＤＢサーバ１３の台数は、同じ台数でもよいし、それぞれ異なる台数でもよい。
【００１９】
アプリケーションシステム１では、クライアント２からのリクエストがＰＬサーバ群１１Ａ、ＢＬサーバ群１２Ａ、及びＤＢサーバ群１３Ａの順に伝達され、このリクエストに対するリプライがＤＢサーバ群１３ＡからＢＬサーバ群１２Ａ、ＰＬサーバ群１１Ａへと伝達されて、クライアント２へ送信される。詳細に説明すれば、リクエスト及びリプライは、例えば以下のように伝達される。
【００２０】
ＰＬサーバ群１１Ａは、前段であるクライアント２からリクエスト電文２１（図２参照）を受け付けると、１台のＰＬサーバ１１が所定の処理を実行後、後段のＢＬサーバ群１２Ａに対するサーバ間リクエスト電文Ａ２３（図２参照）を生成して、出力する。
【００２１】
ＢＬサーバ群１２Ａは、前段のＰＬサーバ群１１Ａからサーバ間リクエスト電文Ａ２３を受け付けると、１台のＢＬサーバ１２が所定の処理を実行後、後段のＤＢサーバ群１３Ａに対するサーバ間リクエスト電文Ｂ２５（図２参照）を生成して、出力する。
【００２２】
ＤＢサーバ群１３Ａは、前段のＢＬサーバ群１２Ａからサーバ間リクエスト電文Ｂ２５を受け付けると、１台のＤＢサーバ１３がＤＢ１４に対する所定の処理を実行する。そして、前段のＢＬサーバ群１２Ａに対するサーバ間リプライ電文Ｂ３５（図２参照）を生成して、出力する。
【００２３】
ＢＬサーバ群１２Ａでは、１台のＢＬサーバ１２が後段のＤＢサーバ群１３Ａからのサーバ間リプライ電文Ｂ３５に基づいて、前段のＰＬサーバ群１１Ａに対するサーバ間リプライ電文Ａ３３（図２参照）を生成して、出力する。
【００２４】
ＰＬサーバ群１１Ａでは、１台のＰＬサーバ１１が後段のＢＬサーバ群１２Ａからのサーバ間リプライ電文Ａ３３に基づいて、前段のクライアント２に対するクライアントリプライ電文３１（図２参照）を生成して、出力する。
【００２５】
図２には、ＰＬサーバ１１，ＢＬサーバ１２及びＤＢサーバ１３の詳細な構成図を示す。
【００２６】
ＰＬサーバ１１は、ロードバランサ１０を介してクライアント２から送られてくるクライアントリクエスト電文２１を受信し、これをサーバ間リクエスト電文Ａ２３に変換していずれかのＢＬサーバ１２へ出力する。また、いずれかのＢＬサーバ１２からサーバ間リプライ電文Ａ３３を受信すると、これをクライアントリプライ電文３１に変換して、ロードバランサ１０を介してクライアント２へ送信する。
【００２７】
ＰＬサーバ１１は、同図（ａ）に示すように、電文識別子付与部１１１と、ＰＬ処理部１１３と、ステータス記憶部１１４と、電文記録部１１５と、ＰＬログ１１７とを備える。
【００２８】
電文識別子付与部１１１は、クライアントリクエスト電文２１を受信すると、これに電文識別子を付与する。電文識別子は、それぞれのＰＬサーバ１１が生成するユニークな数字または文字列等である。例えば、ＰＬサーバ１１に割り当てられているＩＰアドレスと、そのサーバ１１内でのカウンタ値（シリアル番号）とを組み合わせて、電文識別子を生成してもよい。
【００２９】
ＰＬ処理部１１３は、クライアントリクエスト電文２１及びサーバ間リプライ電文Ａ３３に従って、所定の処理を実行する。例えば、クライアントリクエスト電文２１に対しては、その電文に含まれるデータの整合性チェックなどを行い、サーバ間リクエスト電文Ａ２３を生成する。ここで、サーバ間リクエスト電文Ａ２３に、電文識別子付与部１１１によってクライアントリクエスト電文２１に付与された電文識別子が付与され、クライアントリクエスト電文２１とサーバ間リクエスト電文Ａ２３とが関連づけられる。また、サーバ間リプライ電文Ａ３３に対しては、クライアント２に表示される画面（Ｗｅｂページ）の合成を行い、それを含むクライアントリプライ電文３１を生成する。ここで、サーバ間リプライ電文Ａ３３に付与されている電文識別子が、クライアントリプライ電文３１には含まれない。しかし、電文記録部１１５がＰＬログ１１７に格納するクライアントリプライ電文３１のログデータには付与される。
【００３０】
ステータス記憶部１１４については後述する。
【００３１】
電文記録部１１５は、クライアントリクエスト電文２１を受信したとき、及びクライアントリプライ電文３１を出力するときに、それぞれの電文２１，３１の電文識別子を含む、各電文に関連する情報をＰＬログ１１７に格納する。
【００３２】
図３に、ＰＬログ１７のデータ構造の一例を示す。ＰＬログ１１７には、ＰＬサーバ１１がクライアント２に対して送受信した電文の送受信履歴が記憶されている。例えば、ＰＬログ１１７は、データ項目として、電文識別子５１と、送信サーバ名５２と、受信サーバ名５３と、電文内容５４とを有する。
【００３３】
図２（ｂ）には、ＢＬサーバ１２の構成を示す。ＢＬサーバ１２は、ＰＬサーバ１１から送られてくるサーバ間リクエスト電文Ａ２３を受信し、これをサーバ間リクエスト電文Ｂに変換して、いずれかのＤＢサーバ１３へ出力する。また、いずれかのＤＢサーバ１３からサーバ間リプライ電文Ｂ３５を受信すると、これをサーバ間リプライ電文Ａ３３に変換して、ＰＬサーバ１１へ送信する。なお、サーバ間リプライ電文Ａ３３の送信先は、サーバ間リクエスト電文Ａ２３の送信元のＰＬサーバ１１である。
【００３４】
ＢＬサーバ１２は、内部の構成として、ＢＬ処理部１２３と、ステータス記憶部１２４と、電文記録部１２５と、ＢＬログ１２７とを備える。
【００３５】
ＢＬ処理部１２３は、サーバ間リクエスト電文Ａ２３及びサーバ間リプライ電文Ｂ３５に従って、所定の処理を実行する。例えば、サーバ間リクエスト電文Ａ２３を受信したときは、その電文の内容に従って所定の業務処理を実行し、サーバ間リクエスト電文Ｂ２５を生成する。ここで、サーバ間リクエスト電文Ｂ２５には、サーバ間リクエスト電文Ａ２３に付与されている電文識別子が付与され、サーバ間リクエスト電文Ａ２３とサーバ間リクエスト電文Ｂ２５とが関連づけられる。また、サーバ間リプライ電文Ｂ３５を受信したときは、その電文の内容に従って所定の業務処理を実行し、サーバ間リプライ電文Ａ３３を生成する。この場合も同様に、サーバ間リプライ電文Ａ３３には、サーバ間リプライ電文Ｂ３５に付与されている電文識別子が付与され、サーバ間リプライ電文Ａ３３とサーバ間リプライ電文Ｂ３５とが関連づけられる。
【００３６】
ステータス記憶部１２４については後述する。
【００３７】
電文記録部１２５は、サーバ間リクエスト電文Ａ２３を受信したとき、及びサーバ間リプライ電文Ａ３３を出力するときに、それぞれの電文２３，３３の電文識別子を含む、各電文に関連する情報をＢＬログ１２７に格納する。
【００３８】
ＢＬログ１２７には、ＢＬサーバ１２がＰＬサーバ１１に対して送受信した電文の送受信履歴が記憶されている。ＢＬログ１２７のデータ構造は、ＰＬログ１１７と共通である。
【００３９】
図２（ｃ）には、ＤＢサーバ１３の構成を示す。ＤＢサーバ１３は、ＢＬサーバ１２から送られてくるサーバ間リクエスト電文Ｂ２５を受信し、これに基づいてＤＢ１４の参照、更新などのＤＢ処理を実行する。そして、この実行結果に基づいてサーバ間リプライ電文Ｂ３５を生成し、これをサーバ間リクエスト電文Ｂ２５の送信元のＢＬサーバ１２へ送信する。
【００４０】
ＤＢサーバ１３は、内部の構成として、ＤＢ処理部１３３と、ステータス記憶部１３４電文記録部１３５と、ＤＢログ１３７とを備える。
【００４１】
ＤＢ処理部１３３は、サーバ間リクエスト電文Ｂ２５を受信すると、その電文の内容に従ってＤＢ１４の参照、更新などの処理を実行する。そして、その処理結果に基づいてサーバ間リプライ電文Ｂ３５を生成する。ここで、サーバ間リプライ電文Ｂ３５には、サーバ間リクエスト電文Ｂ２５に付与されている電文識別子が付与され、サーバ間リプライ電文Ｂ３５とサーバ間リクエスト電文Ｂ２５とが関連づけられる。
【００４２】
ステータス記憶部１３４については後述する。
【００４３】
電文記録部１３５は、サーバ間リクエスト電文Ｂ２５を受信したとき、及びサーバ間リプライ電文Ｂ３５を出力するときに、それぞれの電文２５，３５の電文識別子を含む、各電文に関連する情報をＤＢログ１３７に格納する。
【００４４】
ＤＢログ１３７には、ＤＢサーバ１３がＢＬサーバ１２に対して送受信した電文の送受信履歴が記憶されている。ＤＢログ１３７のデータ構造は、ＰＬログ１１７及びＢＬログ１２７と共通である。
【００４５】
ここで、図４にそれぞれの電文フォーマットを示す。同図（ａ）に示すように、クライアントリクエスト電文２１は、ＨＴＭＬなどで記述されたクライアントリクエスト本文を含んでいる。同図（ｂ）に示すように、クライアントリプライ電文３１は、ＨＴＭＬなどで記述されたクライアントリプライ本文を含んでいる。同図（ｃ）に示すサーバ間リクエスト電文２３、２５には、それぞれのリクエスト内容を示すサーバ間リクエスト本文と、電文識別子とが含まれ、同様に同図（ｄ）に示すサーバ間リプライ電文３３、３５には、それぞれのリプライ内容を示すサーバ間リプライ本文と、電文識別子とが含まれる。
【００４６】
図５に、管理サーバ１５の構成図を示す。管理サーバ１５には、キーボードまたはポインティングデバイスなどの入力装置７と液晶ディスプレイなどの表示装置８が接続されている。そして、管理サーバ１５は、外部インタフェースとして、これらの入出力装置を制御する入出力装置制御部１５３と、アプリケーションシステム１とのインタフェースであるシステムインタフェース１５１とを有する。
【００４７】
管理サーバ１５は、各サーバ１１，１２，１３からログデータを収集し、その解析などを行う。さらに、管理サーバ１５は、プロビジョニングなどによりアプリケーションシステム１に自動的に配備されたサーバ１１，１２，１３に対し、テストデータの生成、テストの実行及びテスト結果の検証などの自動テスト処理を行う。さらに、管理サーバ１５は、プロビジョニングにより配備されたサーバ１１，１２，１３を実際に稼働させるリリース制御を行う。
【００４８】
これらの機能を実現するために、管理サーバ１５は、例えば、以下のような構成を備える。管理サーバ１５は、まず、主にログの処理に関する構成として、ログデータ収集部１６１と、収集したログを保存しておく収集ログ記憶部１６３と、収集したログデータを解析するログデータ解析部１６５とを備える。また、管理サーバ１５は、主に自動テストのための構成として、ユーザ登録部１７１と、登録情報記憶部１７２と、テストデータ生成部１７３と、テストデータ記憶部１７４と、テスト実行部１７５と、テスト結果記憶部１７６と、テスト結果処理部１７７と、ＤＢ設定変更部１７８とを備える。そして、主にリリース制御に関する構成として、リリース管理部１８１と、リリース条件表１８２と、ステータス表１８３とを備える。以下、各構成について詳細に説明する。
【００４９】
ログデータ収集部１６１は、システムインタフェース１５１を介して、アプリケーションシステム１の各サーバ１１，１２，１３がそれぞれ保持しているログデータを収集し、収集ログ記憶部１６３に格納する。
【００５０】
図６に収集ログ記憶部１６３に記憶されているログデータの一例を示す。収集ログ記憶部１６３のデータ項目は、ＰＬログ１１７、ＢＬログ１２７及びＤＢログ１３７と同一である。収集されたログデータには、クライアントリクエスト電文２１，クライアントリプライ電文３１，サーバ間リクエスト電文２３，２５及びサーバ間リプライ電文３３，３５のすべてのログが含まれているが、それらは互いに電文識別子５１により関連づけが可能である。例えば、図６のレコード１６３ａ〜ｆは、いずれも電文識別子５１が共通であるから、一つのクライアントリクエスト電文２１及びそれから派生した各電文のログであることがわかる。さらに、この例では、送信サーバ名５２及び受信サーバ名５３により、レコード１６３ａがクライアントリクエスト電文２１，レコード１６３ｂがサーバ間リクエスト電文Ａ２３，レコード１６３ｃがサーバ間リクエスト電文Ｂ２５，レコード１６３ｄがサーバ間リプライ電文Ｂ３５，レコード１６３ｅがサーバ間リプライ電文Ａ３３，及びレコード１６３ｆがクライアントリプライ電文３１であることがわかる。
【００５１】
なお、各リプライ電文３１，３３，３５は、各リクエスト電文２１，２３，２５が通ったＰＬサーバ、ＢＬサーバ及びＤＢサーバと同一のＰＬサーバ、ＢＬサーバ及びＤＢサーバを通るようになっている。つまり、同じ電文識別子を有する電文は、ＰＬサーバからＤＢサーバへ向かう昇り方向とＤＢサーバからＰＬサーバへ向かう下り方向とでは、同一のパスを通る。
【００５２】
ログデータ解析部１６５は、収集ログ記憶部１６３に格納されているログデータを解析し、アプリケーションシステム１の動作の正常性の確認をする。例えば、ログデータ解析部１６５は、電文識別子５１をキーにして収集したログデータのレコードをソートし、あるいは、同一の電文識別子５１を有する複数のレコードを１グループとしてまとめる。さらに、ログデータ解析部１６５は、同一の電文識別子５１を有するレコード間で、電文内容５４の整合性チェックを行う。そして、これらの解析結果を、入出力装置制御部１５３が表示装置８に表示する。
【００５３】
図７は、ログデータ解析部１６５がログデータの各レコードを電文識別子５１でソートした結果の一例を示す図である。
【００５４】
図８は、ログデータ解析部１６５によって抽出された電文識別子「192.168.0.102-0845」のレコード群を示す。ログデータ解析部１６５は、このレコード群に対して、さらに、整合性チェックを行う。例えば、「送信サーバ名５２→受信サーバ名５３」のペアにおいて、「client→ＰＬ*」「ＰＬ*→ＢＬ*」「ＢＬ*→ＤＢ*」「ＤＢ*→ＢＬ*」「ＢＬ*→ＰＬ*」「ＰＬ*→client」のすべてが存在することを確認する。これにより、入力されたクライアントリクエスト電文２１が途中で消失せずに、最終的なクライアントリプライ電文３１を返しているか否かを確認できる。
【００５５】
さらに、昇り電文と降り電文では同一パスを経由するようになっているため、ログデータ解析部１６５は、ＰＬサーバ及びＢＬサーバのサーバ名が同一であるか否かをチェックする。また、電文内容５４において、特定のパラメータに同一の値が設定されているか（例えばkozaID=1234567）などをチェックする。これにより、入力されたクライアントリクエスト電文２１の内容が、その後生成される各電文に受け継がれているかを確認できる。
【００５６】
また、ログデータ解析部１６５は、予め登録されている電文確認表６０を参照し、同一電文識別子５１を有するレコード群が、この表６０に登録されているリクエスト電文とリプライ電文の対応パターンに合致するか否かを判定する。電文確認表６０は、予めユーザによって登録されて、登録情報記憶部１７２に格納されている。
【００５７】
図９に、電文確認表６０の一例を示す。電文確認表６０は、対象サーバ６１と、対象サーバ６１が受信するリクエスト電文内容６２と、対象サーバが出力するリプライ電文内容６３とが対応付けられている。一つのリクエスト電文６２に対して、生じ得るリプライ電文６３は複数存在することがある。図９の場合、ＰＬサーバに対するリクエスト電文内容６０１に対するリプライとしては、リプライ電文内容６１１〜６１３があり得ることを示している。また、ＢＬサーバが受信するリクエスト電文内容６０２に対するリプライとしては、リプライ電文内容６１４，６１５があり得ることを示している。さらに、ＤＢサーバのリクエスト電文内容６０３に対するリプライとしては、リプライ電文内容６１６，６１７があり得ることを示している。
【００５８】
そして、ログデータ解析部１６５は、同じ電文識別子５１を有するレコードの中から、ＰＬサーバが受信したクライアントリクエスト電文２１のレコード（つまり、送信サーバ５２がクライアント、受信サーバ５３がＰＬサーバであるレコード１６３ａ）と、クライアントリプライ電文３１のレコード（つまり、送信サーバ５２がＰＬサーバ、受信サーバ５３がクライアントであるレコード１６３ｆ）を抽出する。そして、ここで抽出したレコードのペアが、電文確認表６０のリクエスト電文内容６０１とリプライ電文内容６１１〜６１３のペアのいずれかに合致するかを判定する。
【００５９】
ログデータ解析部１６５は、ＢＬサーバに対するリクエスト及びリプライのペア、とＤＢサーバに対するリクエスト及びリプライのペアについても同様に抽出し、電文確認表６０に登録されているペアと合致するか否かを判定する。
【００６０】
これにより、各リクエスト電文に対し、予め定められている所定のリプライ電文が生成されているか否かを確認できる。
【００６１】
次に、再び図５を参照し、自動テスト処理に関する構成及び処理について説明する。
【００６２】
ユーザ登録部１７１は、入力装置７を用いてユーザが入力するユーザ設定情報の登録を受け付ける。ユーザ登録部１７１が受け付けたユーザ設定情報は、登録情報記憶部１７２及びリリース条件表１８２に登録される。
【００６３】
登録情報記憶部１７２には、ユーザが設定した情報が記憶されている。図５の場合、ユーザ設定情報として、既に説明した電文確認表６０と、テストデータに設定されるパラメータ値が記憶されているパラメータ表７０と、テンプレート８０と、ＤＢ設定表９０とが記憶されている。
【００６４】
図１０には、パラメータ表７０の一例を示す。すなわち、パラメータ表７０は、クライアントリクエスト電文２１に含まれるパラメータ７１と、それに設定される複数のパラメータ値７２とが対応付けて登録されている。
【００６５】
図１１には、テンプレート８０の例を示す。すなわち、同図（ａ）には、送受信サーバを特定する通信パターン８１ごとに、入力リクエスト電文８２とそれに対する生成リプライ電文８３とが対応付けられているテンプレートＡを示す。例えば、テスト対象サーバに入出力する電文を同図（ｃ）に示すようにＸ，Ｙ，Ｚ，Ｗとすれば、テンプレートＡでは、ＸとＷとの対応関係が示されている。また、同図（ｂ）には、送受信サーバを特定する通信パターン８５ごとに、あるサーバの前段に対する電文８４と後段に対する電文８６とが対応付けられているテンプレートＢを示す。例えば同図（ｃ）と対応させると、前段に対する電文８４がＸまたはＷであり、後段に対する電文８６がＹまたはＺであり、ＸとＹまたはＷとＺがそれぞれ対応付けられている。
【００６６】
図１２には、ＤＢ設定表９０の一例を示す。ＤＢ設定表９０には、同図（ａ）に示すデータ設定表９０１と同図（ｂ）に示すデータ戻し表９０２とがある。データ設定表９０１及びデータ戻し表９０２は、いずれも、値を設定する表名９１と、値を設定する条件９２と、値を設定する列名９３と、設定値９４とを、データ項目として有する。
【００６７】
テストを実行する場合、所定の条件下でテストを実行するために、ＤＢ１４の設定を一時的に変更したいときがある。このような場合のために、データ設定表９０１の設定値９４にはユーザが入力した値が記憶されている。また、ＤＢ１４の設定を一時的に変更してテストを実行した後は、その設定を元に戻す必要がある。そこで、データ戻し表９０２の表名９１、条件９２及び列名９３には、設定を変更する際の表名、条件及び列名が記憶されるとともに、設定値９４には、設定を変更する際に取得した変更前のＤＢ１４の値が記憶される。
【００６８】
テストデータ生成部１７３は、パラメータ表７０、テンプレート８０及び収集ログ記憶部１６３に格納されているログデータに基づいてテストデータを生成し、テストデータ記憶部１７４に格納する。例えば、テンプレート８０に含まれているパラメータに、パラメータ表７０に設定されているパラメータ値７２を優先させて設定し、パラメータ表７０にパラメータ値が設定されていないパラメータについては、ログデータから抽出して設定する。これにより、テスト実施者は、自らが着目するパラメータについてだけパラメータ値を登録しておけばよい。この場合、特に着目しないパラメータについてはログデータから自動設定される。従って、テンプレート８０内のすべてのパラメータに値が設定されるので、テストデータの不備によりテストが滞ってしまうようなことがない。
【００６９】
一方、パラメータ表７０にすべてのパラメータの値が設定されていれば、ログデータは不要である。また、パラメータ表７０がないとき、あるいはパラメータ表７０にはパラメータ値が何も設定されていないときは、ログデータからすべてのパラメータ値を取得してテストデータを生成してもよい。
【００７０】
本実施形態では、まず、テンプレートＡ、パラメータ表７０及びログデータに基づいて中間的なテストデータであるテストデータＡ（図１３参照）が生成される。そして、テストデータＡとテンプレートＢに基づいて最終的なテストデータであるテストデータＢ（図１４参照）が生成される。以下、具体的に説明する。
【００７１】
まず、図１１（ａ）のテンプレートＡは、各サーバに対するリクエスト電文（Ｘ）と各サーバから出力され得るリプライ電文（Ｗ）とのペアを定義している。そこで、テストデータ生成部１７３は、テンプレートＡの各パラメータに図１０に示すパラメータ表７０に登録されている値を設定する。この例では、支店ＩＤ（sitenID）、口座ＩＤ（kozaID）、パスワード（passward）、口数（item_count）及び残高（zandaka）に、パラメータ表７０に登録されているそれぞれの値がセットされる。
【００７２】
この段階では、テンプレートＡにおけるパラメータitemには値がセットされていない。そこで、テストデータ生成部１７３は、パラメータitemに設定すべき値を、ログデータのいずれかのレコードから抽出してセットする。このようにして、図１３に示すテストデータＡが生成される。
【００７３】
図１３のテストデータＡは、サーバＡ４０１からサーバＢ４０２へのリクエスト電文（Ｘ）４０３及びそのリクエスト電文（Ｘ）４０３に対するサーバＢからサーバＡへのリプライ電文（Ｗ）４０４からなる。図１３の例では、テストデータ４３１及び４３２のリクエスト電文（Ｘ）４０３は共通であり、これに対するリプライ電文（Ｗ）４０４として異なるパターンがセットされたものである。
【００７４】
次に、図１１（ｂ）のテンプレートＢは、リクエスト電文（Ｘ）とそれにより生成される後段へのリクエスト電文（Ｙ）、及びリプライ電文（Ｗ）とそれが生成される前の後段からのリプライ電文（Ｚ）とのペアを定義している。そこで、テストデータ生成部１７３は、テンプレートＢに図１３のテストパターンＡのリクエスト電文（Ｘ）４０３及びリプライ電文（Ｗ）４０４を適用し、それぞれに対応する電文Ｙ，Ｚを生成する。このとき、テストパターンＡにおいて既に設定されているパラメータは、それぞれ対応する電文Ｙ，Ｚに設定される。この処理により生成されたテストデータＢを図１４に示す。
【００７５】
図１４のテストデータＢは、テスト対象サーバ４１１に対するリクエスト電文（Ｘ）４１２と，これに対応するリプライ電文（Ｗ）４１３と、後段に対するリクエスト電文（Ｙ）４１４と、後段からのリプライ電文（Ｚ）４１５とがワンセットになっている。ここで、テストデータ４４１，４４２，４４３はいずれもリクエスト電文（Ｘ）４１２は共通である。これは、同じリクエスト電文（Ｘ）４１２を入力した場合でも、そこから派生する電文Ｙ，Ｚ，Ｗについては複数のパターンが生じ得るので、正常に動作する場合のすべてのパターンが用意されているからである。
【００７６】
テストデータ記憶部１７４には、上記のようにして生成されたテストデータＢが記憶される。
【００７７】
テスト実行部１７５は、テストデータ記憶部１７４からテストデータを取得してテストを実行し、そのテスト結果をテスト結果記憶部１７６に格納する。例えば、テスト実行部１７５は、テストデータ記憶部１７４からテストデータＢのテストデータを１つずつ読み出し、システムインタフェース１５１を介して、テスト対象サーバ４１１にリクエスト電文（Ｘ）４１２を入力する。テスト対象サーバ４１１は、リクエスト電文（Ｘ）４１２が入力されると、この電文４１２に基づいて所定の処理を実行する。その結果、テスト対象サーバ４１１から後段のサーバへリクエスト電文（Ｙ）が出力され、後段の各サーバもこれに従って動作する。そして、最終的にテスト対象サーバからリプライ電文（Ｗ）が出力される。ここで、テスト実行部１７５は、入力したリクエスト電文（Ｘ）４１２に基づく電文Ｙ，Ｚ，Ｗを、テスト対象サーバ及び後段のサーバのログファイルからそれぞれ取得して、これらを関連づけた形でテスト結果記憶部１７６に格納する。
【００７８】
テスト結果処理部１７７は、テスト結果記憶部１７６に記憶されているテスト結果の電文と、テストデータ記憶部１７４に記憶されているテストデータＢとを対比してテスト結果の解析などを行う。この解析結果は、表示装置８に出力される。
【００７９】
例えば、テスト結果処理部１７７は、入力されたリクエスト電文（Ｘ）及びこれに対するサーバの処理結果として得られた電文Ｙ，Ｚ，Ｗの組が、テストデータ記憶部１７４に記憶されているテストデータＢのいずれかと一致するか否かを判定する。いずれかと一致すれば、アプリケーションシステム１は正常に動作していると考えられる。一方、いずれとも一致しない場合は、テスト対象サーバまたはその後段のサーバに何らかの異常があると考えられる。これらの解析結果は、例えば表示装置８に一覧表示される。
【００８０】
これにより、テンプレート及び必要なパラメータを設定するだけで、網羅的なテストデータの生成、テストの実施及びその結果の解析を自動的に行うことができる。さらに、テスト実施者は、表示装置８にテストの解析結果が表示されるので、システムが正常であるかを直ちに知ることができる。
【００８１】
ＤＢ設定変更部１７８は、テストを実施するために、アプリケーションシステム１の動作環境の変更及びその復帰を行う。例えば、ＤＢ設定変更部１７８は、ＤＢ設定表９０を参照して、システムインタフェース１５１を介してＤＢ１４の内容を一時的に変更する。例えば、ＤＢ設定変更部１７８は、データ設定表９０１（図１２（ａ））に基づいてＤＢ１４を更新する。また、上記の設定変更をする際に、ＤＢ設定変更部１７８は、変更前の状態をデータ戻し表９０２（図１２（ｂ））に設定する。そして、テスト終了後に、データ戻し表９０２を参照して前の状態へ戻す。
【００８２】
例えば、図１２（ａ）に示すデータ設定表９０１の場合、ＤＢ設定変更部１７８は、表名９１に設定されている表から、条件９２を満たすレコードを抽出する。そして、そのレコードの列名９３に合致する列を設定値９４に設定されている値に変更する。これにより、テストを行うときのＤＢの設定を自在に変更することができる。
【００８３】
次に、リリース制御に関する構成及び処理について説明する。
【００８４】
リリース管理部１８１は、システムインタフェース１５１を介して、アプリケーションシステム１内の各サーバ１１，１２，１３のステータスを照会する。例えば、各サーバ内のステータス記憶部１１４、１２４，１３４に記憶されている各サーバのステータスを取得する。ここで取得した各サーバ１１，１２，１３のステータスは、ステータス表１８３に格納される。
【００８５】
ここで、各サーバ内のステータス記憶部１１４、１２４，１３４に格納されるステータス情報について説明する。
【００８６】
アプリケーションシステム１に新たに追加されたサーバの場合、ステータス記憶部にはプロビジョニングが終了した時点で「未テスト」というステータスが設定される。その後、上述したテストが実行されているときは、テスト実行部１７５によりステータスが「テスト中」に変更される。そして、表示装置８に表示されたテスト結果などにより、すべてのテストが正常終了したことが確認され、テスト実施者によりテスト完了を示す入力がなされると、そのサーバのステータス記憶部には、アプリケーションシステム１の一部として正式に稼働可能であることを示す「リリース可」というステータスが設定される。さらに、後述するように、リリース管理部１８１がリリースしたときは、リリースされたサーバ内のステータス記憶部には、「リリース済み」というステータスが設定される。
【００８７】
図１５には、ステータス表１８３の一例を示す。すなわち、ステータス表１８３には、サーバ名１８３１とステータス１８３２とが対応付けて登録されている。ステータス１８３２には、各サーバのステータス記憶部１１４、１２４，１３４から取得したステータスが格納される。
【００８８】
また、リリース管理部１８１は、ステータス表１８３のステータス１８３２が「リリース可」であるサーバについて、リリース条件表１８２に設定された条件が満たされているか否かを判定し、条件が満たされている場合にそのサーバをリリースする。ここで、サーバのリリースを実行するためには、リリース管理部１８１がリリース対象のサーバを指定して、所定のリリース処理コマンドを発行する。リリース処理コマンドは、例えば、リリース管理部１８１が有するコマンド表１８４を参照して取得する。
【００８９】
図１６には、コマンド表１８４の一例を示す。コマンド表１８４には、サーバ種別１８４１ごとにリリース処理コマンド１８４２が登録されている。リリース管理部１８１は、リリースするサーバの種別に応じて、リリース処理コマンドを取得して、実行する。
【００９０】
図１７には、リリース条件表１８２の一例を示す。すなわち、リリース条件表１８２には、リリース対象サーバ１８２１と依存サーバ１８２２とが対応付けて記憶されている。ここで、依存サーバ１８２２とは、リリース対象サーバ１８２１をリリースするためにはリリース済みでなければならないサーバである。つまり、リリース対象サーバ１８２１がリリース可能な状態であっても、依存サーバ１８２２がリリース済みでなければリリース対象サーバ１８２１をリリースすることができない。リリース条件表１８２は、システム管理者等によって予め設定される。
【００９１】
つぎに、上記のような構成を備えたシステムにおける種々の処理手順について、図１８〜図２０のフローチャートを用いて説明する。
【００９２】
まず、図１８には、ログの収集及び解析を行う場合の管理サーバ１５の処理手順を示す。
【００９３】
ログデータ収集部１６１がアプリケーションシステム１内の各サーバ１１，１２，１３から、それぞれに蓄積されているログデータを収集し、収集ログ記憶部１６３に格納する（Ｓ１０１）。ログデータ解析部１６５は、収集ログ記憶部１６３に格納されているログデータを、各レコードに含まれている電文識別子をキーにして分類し、電文識別子別に抽出する（Ｓ１０２）。ログデータ解析部１６５は、登録情報記憶部１７２に予め登録されている電文確認表６０を参照して、同じ電文識別子を有する電文間の整合性をチェックする（Ｓ１０３）。ここでは、例えば、リクエストに対するリプライが予め定められているパターンと一致するか否かを判定する。そして、その解析結果を表示装置８に表示出力する（Ｓ１０４）。
【００９４】
これにより、複数のサーバ間で電文を送受信して動作するアプリケーションシステム１において、各サーバ間で送受信される電文が正常であるか否かを自動的に確認することができる。さらに、各サーバ群でそれぞれ複数のサーバを有し、様々な経路で電文がやりとりされる場合であっても、すべての電文のやりとりをもれなくチェックすることができ、網羅性の高いテストを行うことができる。
【００９５】
次に、図１９には、テストデータの生成及びテストの実施を自動的に行う場合の管理サーバ１５の処理手順を示す。
【００９６】
テスト実施者が、テストデータの基となるテストパターンのテンプレート及びそのテンプレートにセットされるパラメータ値を登録する（Ｓ２０１）。ログデータ収集部１６１は、アプリケーションシステム１の各サーバ１１，１２，１３からログデータを収集し、収集ログ記憶部１６３に格納する（Ｓ２０２）。
【００９７】
そして、テストデータ生成部１７３は、上述の処理で登録されたテンプレート及びパラメータ値と、ログデータとに基づいて、中間的なテストデータであるテストデータＡを生成する（Ｓ２０３）。このとき、テスト実施者が登録したパラメータ値をまず設定し、テスト実施者が設定していないパラメータについては、ログデータから取得した値を設定する。次に、テストデータ生成部１７３は、テストデータＡとテンプレートとを用いて、最終的なテストデータであるテストデータＢを生成する（Ｓ２０４）。
【００９８】
ここで、テストデータを流してテストを実施するに当たり、テスト環境であるＤＢ１４の設定を変更する必要がある場合には、ＤＢ設定変更部１７８が、予め登録されているＤＢ設定表９０を参照して設定変更を行う（Ｓ２０５，２０６）。
【００９９】
そして、テスト実行部１７５がテスト対象サーバにテストデータのリクエスト電文を入力して、アプリケーションシステム１を動作させて、テストを実施する（Ｓ２０７）。
【０１００】
テストの実施が終了すると、ステップＳ２０６でＤＢの設定変更を行っている場合は、その変更を元に戻し、変更前の状態に復帰させる（Ｓ２０８，２０９）。
【０１０１】
テスト結果処理部１７７は、テスト結果記憶部１７６に格納されているテスト結果を、テストデータ記憶部１７４に記憶されているテストデータと比較して検証する（Ｓ２１０）。そして、検証結果が、表示装置８に表示される。
【０１０２】
これにより、テスト実施者は、数多くのテストデータそのものを作成しなくても、テンプレートとしてテストしたいパターンを登録し、重要なパラメータ値を登録しておくことにより、テストデータが自動的に生成され、かつ、テスト及びその結果検証も自動的に行うことができる。さらに、パラメータ値の設定も、すべてのパラメータについて行う必要がない。つまり、テスト実施者が特に指定しないパラメータはログデータから抽出して自動的に補われるので、テスト実施者は、パラメータ値を網羅的に設定しなくてもテストデータを生成することができる。これにより、テスト実施者の負担が軽減される。
【０１０３】
図２０には、管理サーバ１５が行うリリース制御の処理手順を示す。
【０１０４】
まず、システム管理者が、新規に追加されたサーバをリリースするためのリリース条件を登録する（Ｓ３０１）。登録されたリリース条件は、リリース条件表１８２に格納される。リリース管理部１８１は、リリース判定を行う対象のサーバから、そのサーバのステータスを取得し、ステータス管理表１８３に格納する（Ｓ３０２）。対象のサーバが複数ある場合は、すべての対象サーバから取得する。
【０１０５】
リリース管理部１８１は、ステータス管理表１８３を参照し、「リリース可」であるサーバの有無を判定する（Ｓ３０３）。そして、「リリース可」であるサーバがないときは、終了する（Ｓ３０３：Ｎｏ）。
【０１０６】
一方、「リリース可」であるサーバがあるときは（Ｓ３０３：Ｙｅｓ）、リリース管理部１８１は、リリース条件表１８２を参照し、そのサーバのリリース条件が満たされているか否かを判定する（Ｓ３０４）。そして、リリース条件が満たされていないときは、終了する（Ｓ３０４：Ｎｏ）。
【０１０７】
リリース条件が満たされているときは（Ｓ３０４：Ｙｅｓ）、リリース管理部１８１は、リリース対象サーバの種別に応じて、コマンド表１８４からリリースコマンドを取得し、それをリリース対象サーバへ送信して、リリースを実行する（Ｓ３０５，３０６）。
【０１０８】
ステップＳ３０３以降の処理を繰り返すことにより、リリース対象サーバが複数ある時は、順次リリース判定及びリリースを実施することができる。
【０１０９】
これにより、システム管理者が定めたリリース対象サーバごとのリリース条件に従って、サーバごとにリリース判定が行われる。
【０１１０】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【０１１１】
例えば、上述の実施形態では、アプリケーションシステム１がＰＬサーバ群１１Ａ，ＢＬサーバ群１２Ａ，及びＤＢサーバ群１３Ａの３層構造になっているが、２層、あるいは４層以上であってもよい。さらには、アプリケーションシステム１は、必ずしも層構造になっていなくてもよい。
【図面の簡単な説明】
【０１１２】
【図１】本実施形態に係るシステムの全体構成図。
【図２】ＰＬサーバ１１，ＢＬサーバ１２及びＤＢサーバ１３の詳細な構成図。
【図３】ＰＬログ１１７、ＢＬログ１２７、ＤＢログ１３７のデータ構造の一例。
【図４】各電文フォーマットの一例。
【図５】管理サーバ１５の構成図。
【図６】収集ログ記憶部１６３に記憶されているログデータの一例。
【図７】ログデータ解析部１６５がログデータの各レコードを電文識別子５１でソートした結果の一例。
【図８】電文識別子「192.168.0.102-0845」のレコード群。
【図９】電文確認表６０の一例。
【図１０】パラメータ表７０の一例。
【図１１】テンプレート８０の一例。
【図１２】ＤＢ設定表９０の一例。
【図１３】テストデータＡの一例。
【図１４】テストデータＢの一例。
【図１５】ステータス表１８３の一例。
【図１６】コマンド表１８４の一例。
【図１７】リリース条件表１８２の一例。
【図１８】ログの収集及び解析を行う場合の処理手順を示すフローチャート。
【図１９】テストデータの生成及びテストの実施を自動的に行う場合の処理手順を示すフローチャート。
【図２０】リリース制御の処理手順を示すフローチャート。
【符号の説明】
【０１１３】
１ アプリケーションシステム
２ クライアント
１０ ロードバランサ
１１ ＰＬサーバ
１２ ＢＬサーバ
１３ ＤＢサーバ
１４ ＤＢ
１５ 管理サーバ
２１ クライアントリクエスト電文
２３，２５ サーバ間リクエスト電文
３１ クライアントリプライ電文
３３，３５ サーバ間リプライ電文
【特許請求の範囲】
【請求項１】
複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内の、前段の装置からの入力リクエストに基づいて出力リクエストを後段の装置へ出力し、前記後段の装置からの入力リプライに基づいて出力リプライを前記前段の装置へ出力するテスト対象装置のテストデータを生成する装置であって、
パラメータを含む入力リクエスト電文テンプレートと、前記入力リクエスト電文テンプレートに対応する出力リプライ電文テンプレートとを含む第１テンプレートの登録を受け付ける第１の登録手段と、
パラメータを含む入力リクエスト電文テンプレート、及び前記入力リクエスト電文テンプレートに対応する出力リクエスト電文テンプレートと、パラメータを含む入力リプライ電文テンプレート、及び前記入力リプライ電文テンプレートに対応する出力リプライ電文テンプレートと、を含む第２テンプレートの登録を受け付ける第２の登録手段と、
前記パラメータに設定されるパラメータ値の入力を受け付けるパラメータ入力手段と、
前記第１登録手段により登録された第１テンプレートに含まれるパラメータに、前記パラメータ入力手段により入力されたパラメータ値を設定して入力リクエストテストデータと出力リプライテストデータとを含む中間テストデータを生成する手段と、
前記中間テストデータと前記第２登録手段により登録された第２テンプレートに基づいて、前記入力リクエストテストデータに対応する出力リクエストテストデータと、前記出力リプライテストデータに対応する入力リプライテストデータとを生成し、最終テストデータを生成する手段と、を備えることを特徴とするテストデータの生成装置。
【請求項２】
前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得する手段をさらに備え、
前記中間テストデータを生成する手段は、前記パラメータ入力手段により入力されたパラメータ値、または前記取得手段により取得されたログデータから抽出した値を設定して前記中間テストデータを生成することを特徴とする請求項１記載のテストデータの生成装置。
【請求項３】
前記中間テストデータ生成手段は、前記パラメータ入力手段により入力されたパラメータ値を、前記ログデータから抽出した値よりも優先させて設定することを特徴とする請求項２記載のテストデータ生成装置。
【請求項４】
前記入力リクエストテストデータを前記テスト対象装置へ入力して、前記電文処理システムを動作させてテストを実行する手段と、
前記テスト実行手段が前記電文処理システムを動作させることにより生成された出力リクエスト、入力リプライ及び出力リプライを含む実行結果データを収集する手段と、
前記最終テストデータ生成手段により生成されたテストデータと前記収集手段により収集された実行結果データとを比較して、テスト結果を検証する手段と、をさらに備える請求項１乃至請求項３のいずれか一項に記載のテストデータ生成装置。
【請求項５】
前記電文処理システムの環境を変更させ、及び変更後の環境を変更前へ復帰させる変更復帰手段をさらに備える請求項１乃至請求項４のいずれか一項に記載のテストデータ生成装置。
【請求項６】
複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内のテスト対象装置のテストデータを生成する装置であって、
前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得する手段と、
パラメータを含む電文テンプレートを登録する手段と、
前記パラメータに設定されるパラメータ値の入力を受け付けるパラメータ入力手段と、
前記登録手段により登録された電文テンプレートに含まれるパラメータに、前記パラメータ入力手段が入力を受け付けたパラメータ値を設定してテストデータを生成する手段と、を備えることを特徴とするテストデータの生成装置。
【請求項７】
複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内のテスト対象装置のテストデータを生成する方法であって、
前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得するステップと、
パラメータを含むリクエスト電文テンプレートと、前記リクエスト電文テンプレートに対応するリプライ電文テンプレートとを含むテンプレートを登録するステップと、
前記パラメータに設定されるパラメータ値の入力を受け付けるステップと、
前記登録されたテンプレートに含まれるパラメータに、前記入力を受け付けたパラメータ値を設定してテストデータを生成するステップと、を有することを特徴とするテストデータの生成方法。
【請求項８】
複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内のテスト対象装置のテストデータを生成するためのコンピュータプログラムであって、
前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得するステップと、
パラメータを含むリクエスト電文テンプレートと、前記リクエスト電文テンプレートに対応するリプライ電文テンプレートとを含むテンプレートを登録するステップと、
前記パラメータに設定されるパラメータ値の入力を受け付けるステップと、
前記登録されたテンプレートに含まれるパラメータに、前記入力を受け付けたパラメータ値を設定してテストデータを生成するステップと、をコンピュータに実行させるためのコンピュータプログラム。
【請求項１】
複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内の、前段の装置からの入力リクエストに基づいて出力リクエストを後段の装置へ出力し、前記後段の装置からの入力リプライに基づいて出力リプライを前記前段の装置へ出力するテスト対象装置のテストデータを生成する装置であって、
パラメータを含む入力リクエスト電文テンプレートと、前記入力リクエスト電文テンプレートに対応する出力リプライ電文テンプレートとを含む第１テンプレートの登録を受け付ける第１の登録手段と、
パラメータを含む入力リクエスト電文テンプレート、及び前記入力リクエスト電文テンプレートに対応する出力リクエスト電文テンプレートと、パラメータを含む入力リプライ電文テンプレート、及び前記入力リプライ電文テンプレートに対応する出力リプライ電文テンプレートと、を含む第２テンプレートの登録を受け付ける第２の登録手段と、
前記パラメータに設定されるパラメータ値の入力を受け付けるパラメータ入力手段と、
前記第１登録手段により登録された第１テンプレートに含まれるパラメータに、前記パラメータ入力手段により入力されたパラメータ値を設定して入力リクエストテストデータと出力リプライテストデータとを含む中間テストデータを生成する手段と、
前記中間テストデータと前記第２登録手段により登録された第２テンプレートに基づいて、前記入力リクエストテストデータに対応する出力リクエストテストデータと、前記出力リプライテストデータに対応する入力リプライテストデータとを生成し、最終テストデータを生成する手段と、を備えることを特徴とするテストデータの生成装置。
【請求項２】
前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得する手段をさらに備え、
前記中間テストデータを生成する手段は、前記パラメータ入力手段により入力されたパラメータ値、または前記取得手段により取得されたログデータから抽出した値を設定して前記中間テストデータを生成することを特徴とする請求項１記載のテストデータの生成装置。
【請求項３】
前記中間テストデータ生成手段は、前記パラメータ入力手段により入力されたパラメータ値を、前記ログデータから抽出した値よりも優先させて設定することを特徴とする請求項２記載のテストデータ生成装置。
【請求項４】
前記入力リクエストテストデータを前記テスト対象装置へ入力して、前記電文処理システムを動作させてテストを実行する手段と、
前記テスト実行手段が前記電文処理システムを動作させることにより生成された出力リクエスト、入力リプライ及び出力リプライを含む実行結果データを収集する手段と、
前記最終テストデータ生成手段により生成されたテストデータと前記収集手段により収集された実行結果データとを比較して、テスト結果を検証する手段と、をさらに備える請求項１乃至請求項３のいずれか一項に記載のテストデータ生成装置。
【請求項５】
前記電文処理システムの環境を変更させ、及び変更後の環境を変更前へ復帰させる変更復帰手段をさらに備える請求項１乃至請求項４のいずれか一項に記載のテストデータ生成装置。
【請求項６】
複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内のテスト対象装置のテストデータを生成する装置であって、
前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得する手段と、
パラメータを含む電文テンプレートを登録する手段と、
前記パラメータに設定されるパラメータ値の入力を受け付けるパラメータ入力手段と、
前記登録手段により登録された電文テンプレートに含まれるパラメータに、前記パラメータ入力手段が入力を受け付けたパラメータ値を設定してテストデータを生成する手段と、を備えることを特徴とするテストデータの生成装置。
【請求項７】
複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内のテスト対象装置のテストデータを生成する方法であって、
前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得するステップと、
パラメータを含むリクエスト電文テンプレートと、前記リクエスト電文テンプレートに対応するリプライ電文テンプレートとを含むテンプレートを登録するステップと、
前記パラメータに設定されるパラメータ値の入力を受け付けるステップと、
前記登録されたテンプレートに含まれるパラメータに、前記入力を受け付けたパラメータ値を設定してテストデータを生成するステップと、を有することを特徴とするテストデータの生成方法。
【請求項８】
複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システム内のテスト対象装置のテストデータを生成するためのコンピュータプログラムであって、
前記電文処理システム内の一つ以上の装置から、各装置に蓄積されているログデータを取得するステップと、
パラメータを含むリクエスト電文テンプレートと、前記リクエスト電文テンプレートに対応するリプライ電文テンプレートとを含むテンプレートを登録するステップと、
前記パラメータに設定されるパラメータ値の入力を受け付けるステップと、
前記登録されたテンプレートに含まれるパラメータに、前記入力を受け付けたパラメータ値を設定してテストデータを生成するステップと、をコンピュータに実行させるためのコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２００６−２５２１５８（Ｐ２００６−２５２１５８Ａ）
【公開日】平成１８年９月２１日（２００６．９．２１）
【国際特許分類】
【出願番号】特願２００５−６７４４２（Ｐ２００５−６７４４２）
【出願日】平成１７年３月１０日（２００５．３．１０）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成１８年９月２１日（２００６．９．２１）
【国際特許分類】
【出願日】平成１７年３月１０日（２００５．３．１０）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]