JP5304449B2 - シナリオ作成プログラム、シナリオ作成装置およびシナリオ作成方法 - Google Patents

Description

本発明は、シナリオ作成プログラム、シナリオ作成装置およびシナリオ作成方法に関する。

情報処理システムのテスト担当者などは、例えば、情報処理システムのバグが修正された場合や、情報処理システムに新しい機能が追加された場合に、修正や追加されたアプリが他のアプリに影響を与えていないことを検証するためにテストを行う。このため、テスト担当者は、情報処理システムが改修されるたびに同じようなテストを行うことになる。このようなテストは、「再帰テスト」、「回帰テスト」、「リグレッションテスト」などと呼ばれている。

ここで、図２３を用いて従来のテスト手法の一例について説明する。図２３は、従来のテスト手法の一例を説明するための図である。図２３に示した例において、情報処理システム９は、Ｗｅｂサーバ１３と、ＡＰ（Application）サーバ１４と、ＤＢ（Data Base）サーバ１５とを有する。また、情報処理システム９は、ネットワーク３１を介して、テスト端末１１と接続されている。

図２３に示した例において、テスト担当者Ｈ１は、テストを実施する場合に、テスト端末１１に対して、予め決められている操作を行う。例えば、テスト担当者Ｈ１は、Ｗｅｂブラウザを開いて、Ｗｅｂブラウザ上に、テスト仕様書において定められている情報を入力する。

テスト端末１１は、テスト担当者Ｈ１による操作に応じて、ＨＴＴＰ（HyperText Transfer Protocol）リクエスト等をＷｅｂサーバ１３へ送信する。ＨＴＴＰリクエスト等を受け付けたＷｅｂサーバ１３は、ＡＰサーバ１４との間でリクエストやレスポンスを送受する。また、その間に、ＡＰサーバ１４は、ＤＢサーバ１５との間でリクエストやレスポンスを送受する。なお、以下では、リクエストとレスポンスとを総称して「メッセージ」と呼ぶことがある。

そして、テスト端末１１は、例えば、Ｗｅｂサーバ１３からレスポンスを受信し、受信したレスポンスに応じた情報をＷｅｂブラウザ上に出力する。そして、テスト担当者Ｈ１は、Ｗｅｂブラウザ上に出力された情報を確認することにより、テストの合否を判定する。

このようにして、テスト担当者Ｈ１は、情報処理システム９のテストを行う。そして、テスト担当者Ｈ１は、再帰テストを行う場合、以前に行った操作と同様の操作を行い、以前に行った確認と同様の確認を行う。なお、図２３では、１人のテスト担当者によってテストが行われる例を示したが、一般に、このようなテストは複数のテスト担当者によって行われる。

近年では、再帰テストにかかる工数を低減することを目的として、再帰テストの一部を自動的に実施する自動テスト技術が提案されている。かかる自動テスト技術について、図２３に示した例を用いて説明する。ここでは、テスト端末１１に自動テスト技術が適用されているものとする。かかる場合、テスト端末１１は、例えば、テスト担当者Ｈ１によって行われた操作手順と、Ｗｅｂサーバ１３から受信したレスポンスとを含む情報（以下、「テストデータ」と言う）を生成する。

そして、テスト担当者Ｈ１は、再帰テストを行う場合、例えば、ＤＢサーバ１５が保持する各種データベースを初期化した後に、テストデータを読み出す操作を行う。テスト端末１１は、読み出し操作が行われた場合に、テストデータに含まれる操作手順を実行して、Ｗｅｂサーバ１３へリクエストを送信する。そして、テスト端末１１は、Ｗｅｂサーバ１３からレスポンスを受信し、受信したレスポンスと、テストデータに含まれるレスポンスとが一致するか否かを判定することによりテストの合否判定を行う。このように、テスト担当者Ｈ１は、自動テスト技術を用いることにより、予め決められている操作手順を行うことなく、再帰テストを行う。

特開平１１−１８４９００号公報 特開２００７−２６４８１０号公報

しかしながら、上述した従来の自動テスト技術には、テストの合否判定を正しく行えない場合があるという問題があった。図２４を用いて具体的に説明する。図２４は、従来のテスト手法における問題点を説明するための図である。

図２４では、２人のテスト担当者Ｈ１１およびＨ１２によってテストが行われる例を示している。なお、図２４において、実線の矢印は、テスト担当者Ｈ１１によってテストが行われた場合にサーバ間で送受されるメッセージを示し、破線の矢印は、テスト担当者Ｈ１２によってテストが行われた場合にサーバ間で送受されるメッセージを示している。

具体的には、図２４に示した例において、テスト担当者Ｈ１１によってテストＴ１１が行われた場合、テスト端末は、時刻ｔ１１にＷｅｂサーバ１３へリクエストを送信している（ステップＳ１１）。その後、Ｗｅｂサーバ１３は、時刻ｔ１２にＡＰサーバ１４へリクエストを送信し（ステップＳ１２）、ＡＰサーバ１４は、時刻ｔ１７にＤＢサーバ１５へリクエストを送信している（ステップＳ１７）。そして、ＤＢサーバ１５は、ＡＰサーバ１４から受信したリクエストに応答してデータベースを参照または更新し、参照結果や更新結果をＡＰサーバ１４へ送信する。図２４に示した例では、ＤＢサーバ１５は、時刻ｔ１８に参照結果や更新結果を含むレスポンスをＡＰサーバ１４へ送信している（ステップＳ１８）。そして、ＡＰサーバ１４は、時刻ｔ２１にＷｅｂサーバ１３へレスポンスを送信し（ステップＳ２１）、Ｗｅｂサーバ１３は、時刻ｔ２２にテスト端末へレスポンスを送信している（ステップＳ２２）。

また、図２４に示した例において、テスト担当者Ｈ１２によってテストＴ１２が実施された場合、テスト端末は、時刻ｔ１３にＷｅｂサーバ１３へリクエストを送信している（ステップＳ１３）。その後、Ｗｅｂサーバ１３は、時刻ｔ１４にＡＰサーバ１４へリクエストを送信し（ステップＳ１４）、ＡＰサーバ１４は、時刻ｔ１５にＤＢサーバ１５へリクエストを送信している（ステップＳ１５）。そして、ＤＢサーバ１５は、時刻ｔ１６にＡＰサーバ１４へレスポンスを送信し（ステップＳ１６）、ＡＰサーバ１４は、時刻ｔ１９にＷｅｂサーバ１３へレスポンスを送信している（ステップＳ１９）。その後、Ｗｅｂサーバ１３は、時刻ｔ２０にテスト端末へレスポンスを送信している（ステップＳ２０）。

図２４に示した例において、上述した従来の自動テスト技術がテスト端末に適用されている場合、テスト端末は、テストＴ１１に対応するテストデータＤ１１と、テストＴ１２に対応するテストデータＤ１２とを生成することになる。ここで、テスト担当者は、テストデータＤ１１を用いて再帰テストを行う場合、ＤＢサーバ１５の状態を、テストＴ１１およびＴ１２が実施される前の状態に戻す。

ここで、図２４に示すように、テストＴ１１では、テストＴ１２においてＤＢサーバ１５へアクセスされた後に、ＤＢサーバ１５へアクセスする処理が行われる。このとき、テストＴ１２によってＤＢサーバ１５のデータが更新される可能性がある。すなわち、テストＴ１１では、テストＴ１２において更新されたテーブルにアクセスする可能性がある。このため、テストＴ１２においてＤＢサーバ１５が更新された場合、テストＴ１１には、更新後のＤＢサーバ１５に対してアクセスすることが求められる。

しかし、テストデータＤ１１を用いてテストＴ１１を実行した場合、テストＴ１２において更新されたＤＢサーバ１５に対してアクセスすることができない。このため、テスト端末は、テストデータＤ１１に含まれるレスポンスと異なるレスポンスをＷｅｂサーバ１３から受信するおそれがある。このことは、情報処理システムが正常に動作しているにも関わらず、テストの合否判定を正しく行えないという問題を招く。

なお、テストデータＤ１１およびＤ１２の生成時と同様の順序でテストＴ１１およびＴ１２を実行することにより、図２４に示した各サーバの動作を再現できるとも考えられる。しかし、各サーバ間でメッセージが送受される順序は、サーバの状況やネットワークの状況によって変動するため、各サーバの動作を再現できるとは限らない。このため、テストデータの生成時と同様の順序でテストを実行した場合であっても、テストの合否判定を正しく行えない場合がある。

上述したように、情報処理システムの分野では、再帰テストが行われることが多いため、再帰テストにかかる工数は増大している。このような状況下で、テストの合否判定を正しく行うことができるテストデータをいかにして作成するかが課題となっていた。

開示の技術は、上記に鑑みてなされたものであって、テストの合否判定を正しく行うことができるテストデータを作成するシナリオ作成プログラム、シナリオ作成装置およびシナリオ作成方法を提供することを目的とする。

本願の開示するシナリオ作成プログラムは、一つの態様において、データベースサーバを含む複数のサーバが接続された情報処理システムの動作を検証するためのシナリオを作成するシナリオ作成プログラムであって、動作検証を行う端末装置によって前記情報処理システムの動作検証が行われている場合に、前記複数のサーバ間で送受されるメッセージを収集する収集手順と、前記収集手順によって収集されたメッセージを関連付ける関連付け手順と、前記関連付け手順によって関連付けられたメッセージ群である業務モデルを、前記データベースサーバにアクセスした時刻の昇順にソートするソート手順と、前記ソート手順によってソートされた業務モデルに基づいてシナリオを作成するシナリオ作成手順とをコンピュータに実行させる。

本願の開示するシナリオ作成プログラムの一つの態様によれば、テストの合否判定を正しく行うことが可能になるシナリオを作成することができるという効果を奏する。

図１は、実施例１における情報処理システムの構成例を示す図である。 図２は、実施例１に係るシナリオ作成装置の構成例を示す図である。 図３は、収集部によるメッセージ収集処理の一例を示す図である。 図４は、収集部によって収集されるメッセージの一例を示す図である。 図５は、関連付け部による関連付け処理の一例を示す図である。 図６は、関連付け部による関連付け処理の一例を示す図である。 図７−１は、更新処理時の排他制御を説明するための図である。 図７−２は、共有ロックを伴う参照処理時の排他制御を説明するための図である。 図７−３は、共有ロックを伴わない参照処理時の排他制御を説明するための図である。 図８−１は、ソート部によるソート処理の一例を示す図である。 図８−２は、ソート部によるソート処理の一例を示す図である。 図９は、入替部によって業務モデルが入れ替えられる条件を示す図である。 図１０は、入替部による入替処理の一例を示す図である。 図１１は、多重化部によって業務モデルが多重化される条件を示す図である。 図１２−１は、多重化部による多重化処理の一例を示す図である。 図１２−２は、多重化部による同期情報付与処理の一例を示す図である。 図１３は、シナリオ作成装置によるシナリオ作成処理手順を示すフローチャートである。 図１４は、ソート部によるソート処理手順を示すフローチャートである。 図１５は、入替部による入替処理手順を示すフローチャートである。 図１６は、入替部による入替判定処理手順を示すフローチャートである。 図１７は、多重化部による多重化処理手順を示すフローチャートである。 図１８−１は、多重化部による多重化処理の一例を説明するための図である。 図１８−２は、多重化部による多重化処理の一例を説明するための図である。 図１８−３は、多重化部による多重化処理の一例を説明するための図である。 図１８−４は、多重化部による多重化処理の一例を説明するための図である。 図１９は、多重化部による初期化処理手順を示すフローチャートである。 図２０は、多重化部による多重化判定処理手順を示すフローチャートである。 図２１は、多重化部による同期設定処理手順を示すフローチャートである。 図２２は、シナリオ作成プログラムを実行するコンピュータを示す図である。 図２３は、従来のテスト手法の一例を説明するための図である。 図２４は、従来のテスト手法における問題点を説明するための図である。

以下に、本願の開示するシナリオ作成プログラム、シナリオ作成装置およびシナリオ作成方法の実施例を図面に基づいて詳細に説明する。なお、この実施例により本願の開示するシナリオ作成プログラム、シナリオ作成装置およびシナリオ作成方法が限定されるものではない。

［実施例１における情報処理システムの構成］
まず、図１を用いて、実施例１に係るシナリオ作成装置１００を含む情報処理システム１の構成について説明する。図１は、実施例１における情報処理システム１の構成例を示す図である。図１に示した例において、情報処理システム１は、負荷分散装置１２と、Ｗｅｂサーバ１３と、ＡＰサーバ１４と、ＤＢサーバ１５とを有する。なお、図１に示した例において、Ｗｅｂサーバ１３は、複数台存在するものとする。

図１に示すように、負荷分散装置１２、Ｗｅｂサーバ１３、ＡＰサーバ１４、ＤＢサーバ１５は、それぞれルータ２２〜２５を介して接続されている。また、図１に示した例において、Ｗｅｂサーバ１３とＡＰサーバ１４との間に、ファイアーウォール３２が設置されている。また、図１に示した例において、テスト端末１１は、ルータ２１およびネットワーク３１を介して負荷分散装置１２と接続されている。また、図１に示した例において、シナリオ作成装置１００は、ＡＰサーバ１４および負荷分散装置１２と接続されている。

テスト端末１１は、テスト担当者によって操作されるパーソナルコンピュータ等の端末装置である。負荷分散装置１２は、テスト端末１１からリクエストを受信し、受信したリクエストをＷｅｂサーバ１３へ転送する。例えば、負荷分散装置１２は、複数のＷｅｂサーバ１３の負荷が均等になるようにリクエストを転送する。Ｗｅｂサーバ１３は、テスト端末１１からのリクエストに応じて、ＨＴＭＬ（HyperText Markup Language）データや画像データなどを含むレスポンスをテスト端末１１へ送信する。

ＡＰサーバ１４は、情報処理システム１によって提供される各種サービスを実現するためのアプリケーションを有する。図１に示した例において、ＡＰサーバ１４は、Ｗｅｂサーバ１３からリクエストを受信し、受信したリクエストに応じて各種処理を行う。具体的には、ＡＰサーバ１４は、ＤＢサーバ１５へリクエストを送信することにより、ＤＢサーバ１５から各種データを取得したり、ＤＢサーバ１５に保持されている各種データを更新したりする。

ＤＢサーバ１５は、各種情報を記憶する。図１に示した例において、ＤＢサーバ１５は、ＡＰサーバ１４からデータベースへのアクセス要求を受信し、データベースへのアクセスを制御する。具体的には、ＤＢサーバ１５は、ＡＰサーバ１４から受信したリクエストに応じて、データベースを参照または更新し、参照結果や更新結果を含むレスポンスをＡＰサーバ１４へ送信する。

このような構成の下、実施例１に係るシナリオ作成装置１００は、テスト担当者によって情報処理システム１のテストが実施された場合に、かかるテストを再現するためのテスト用のシナリオを作成する。

具体的には、シナリオ作成装置１００は、テスト担当者によって情報処理システム１のテストが実施された場合に、テスト端末１１や各サーバ間で送受される各種メッセージを収集する。図１に示した例では、シナリオ作成装置１００は、負荷分散装置１２が接続されているルータ２２からポートモニタリング（キャプチャと表現される場合もある）機能を利用して、テスト端末１１と負荷分散装置１２との間で送受されるメッセージや、負荷分散装置１２とＷｅｂサーバ１３との間で送受されるメッセージを収集する。また、シナリオ作成装置１００は、ＡＰサーバ１４が接続されているルータ２４からポートモニタリング機能を利用して、Ｗｅｂサーバ１３とＡＰサーバ１４との間で送受されるメッセージや、ＡＰサーバ１４とＤＢサーバ１５との間で送受されるメッセージを収集する。

続いて、シナリオ作成装置１００は、収集したメッセージのうち、関連するメッセージを関連付けて記憶する。ここで言う「関連するメッセージ」とは、所定のリクエストやレスポンスに応じて各サーバ間で送受されたリクエストやレスポンスを示す。

例えば、負荷分散装置１２からＷｅｂサーバ１３へリクエストＲｅｑ１が送信され、かかるリクエストＲｅｑ１に応じてＷｅｂサーバ１３からＡＰサーバ１４へリクエストＲｅｑ２が送信された場合、リクエストＲｅｑ１およびＲｅｑ２は関連する。また、リクエストＲｅｑ２に応じてＡＰサーバ１４からＤＢサーバ１５へリクエストＲｅｑ３が送信され、かかるリクエストＲｅｑ３に応じてＤＢサーバ１５からＡＰサーバ１４へレスポンスＲｅｓ１が送信されたものとする。かかる場合、リクエストＲｅｑ１およびＲｅｑ２およびＲｅｑ３、レスポンスＲｅｓ１は関連する。

なお、以下では、テスト端末１１から負荷分散装置１２へリクエストが送信されてから、かかるリクエストに応じて負荷分散装置１２からテスト端末１１へレスポンスが送信されるまでの間を「トランザクション」と呼ぶこととする。また、以下では、シナリオ作成装置１００によって関連付けされた同一トランザクション内のメッセージ群を「業務モデル」と呼ぶこととする。

続いて、シナリオ作成装置１００は、生成した業務モデルを、ＤＢサーバ１５へアクセスを開始した時刻の昇順にソートする。そして、シナリオ作成装置１００は、ソートした業務モデルに基づいてシナリオを作成する。

図２４に示した例を用いて説明すると、シナリオ作成装置１００は、テストＴ１１が実施された場合に、ステップＳ１１、Ｓ１２、Ｓ１７、Ｓ１８、Ｓ２１、Ｓ２２において送受されたメッセージを収集する。そして、シナリオ作成装置１００は、収集したメッセージを関連付けて業務モデルＭ１を生成する。また、シナリオ作成装置１００は、テストＴ１２が実施された場合に、ステップＳ１３、Ｓ１４、Ｓ１５、Ｓ１６、Ｓ１９、Ｓ２０において送受されたメッセージを収集し、業務モデルＭ２を生成する。

そして、シナリオ作成装置１００は、テストＴ１１よりもテストＴ１２の方が先にＤＢサーバ１５にアクセスを開始しているので、業務モデルＭ２、業務モデルＭ１の順にソートする。そして、シナリオ作成装置１００は、ソートした業務モデルＭ２、Ｍ１に基づいてシナリオを作成する。

このようにして作成されたシナリオは、テストＴ１１、テストＴ１２の順にテストを実施するテストデータとなる。具体的には、テスト端末１１によって上記シナリオが実行された場合、まず、業務モデルＭ２が実行され、続いて、業務モデルＭ１が実行される。すなわち、業務モデルＭ１は、業務モデルＭ２によってＤＢサーバ１５にアクセスされた後に、ＤＢサーバ１５にアクセスすることになる。このため、テスト端末１１は、情報処理システム１が正常に動作している場合に上記シナリオを実行すると、テストＴ１１およびＴ１２が行われた際に受信したレスポンスと同一のレスポンスをＷｅｂサーバ１３から受信することができる。このため、テスト端末１１は、シナリオ作成装置１００によって生成されたシナリオを用いて、テストの合否判定を正しく行うことができる。

このように、実施例１に係るシナリオ作成装置１００は、各サーバ間で送受されるメッセージを収集し、同一のトランザクション内で送受されたメッセージを関連付けて業務モデルを生成する。そして、シナリオ作成装置１００は、生成した業務モデルを、ＤＢサーバ１５へのアクセス開始時刻の昇順にソートすることによりシナリオを作成する。

すなわち、シナリオ作成装置１００は、テスト担当者によるテスト実施時におけるＤＢサーバ１５へのアクセス順序と、シナリオ実行時におけるＤＢサーバ１５へのアクセス順序とが同一になるように、シナリオを生成する。これにより、シナリオ作成装置１００によって生成されたシナリオは、テストの合否判定を正しく行うことができる。

なお、実施例１に係るシナリオ作成装置１００は、上述した処理以外にも種々の処理を行う。例えば、シナリオ作成装置１００は、業務モデルをソートした後に、並行して実施しても問題が発生しない業務モデルを多重化してシナリオを作成する。一例を挙げて説明すると、図２４に示した例において、テストＴ１１においてアクセスされるデータベースのテーブルと、テストＴ１２においてアクセスされるテーブルとが異なる場合、テストＴ１１とテストＴ１２とは、並行して実施されても問題ない。かかる場合、シナリオ作成装置１００は、テストＴ１１に対応する業務モデルと、テストＴ１２に対応する業務モデルとを多重化してシナリオを作成する。以下に、シナリオ作成装置１００の構成を説明するとともに、かかる多重化処理等を含めた各種処理について具体的に説明する。

［実施例１に係るシナリオ作成装置の構成］
次に、図２を用いて、実施例１に係るシナリオ作成装置１００の構成について説明する。図２は、実施例１に係るシナリオ作成装置１００の構成例を示す図である。図２に示した例において、シナリオ作成装置１００は、インタフェース（以下、「ＩＦ」と言う）部１１０と、入力部１２０と、出力部１３０と、制御部１４０と、業務モデル記憶部１５１と、シナリオ記憶部１５２とを有する。

ＩＦ部１１０は、外部装置との間で各種データを送受する。図１に示した例では、シナリオ作成装置１００のＩＦ部１１０は、負荷分散装置１２が接続されているルータ２２およびＡＰサーバ１４が接続されているルータ２４からポートモニタリング機能を利用して、各サーバ間で送受されるメッセージを受信する。

入力部１２０は、各種情報や操作指示を入力するための入力デバイスであり、例えば、キーボードやマウスである。テスト担当者は、入力部１２０を操作することにより、テストを行う。出力部１３０は、各種情報を出力する出力デバイスであり、例えば、液晶ディスプレイやスピーカである。テスト担当者は、例えば、出力部１３０に表示される情報を確認することで、テストの合否判定を行う。

制御部１４０は、制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、シナリオ作成装置１００を全体制御する。実施例１における制御部１４０は、図２に示した例のように、収集部１４１と、関連付け部１４２と、ソート部１４３と、入替部１４４と、多重化部１４５と、シナリオ作成部１４６とを有する。

収集部１４１は、テスト担当者によって情報処理システム１の動作検証が行われている場合に、各サーバ間で送受されるメッセージを収集する。具体的には、収集部１４１は、テスト端末１１によって負荷分散装置１２へリクエストが送信された場合に、負荷分散装置１２やＷｅｂサーバ１３などのサーバ間で送受される各種メッセージを、ＩＦ部１１０を介して収集する。

図３を用いて、収集部１４１によるメッセージ収集処理を説明する。図３は、収集部１４１によるメッセージ収集処理の一例を示す図である。図３に示した例では、テスト端末１１ａ〜１１ｃを用いてテストが行われている。図３に示すように、テスト端末１１ａ〜１１ｃを用いてテストが行われている場合、テスト端末１１ａ〜１１ｃから負荷分散装置１２へリクエストが送信される。これにより、負荷分散装置１２とＷｅｂサーバ１３との間や、Ｗｅｂサーバ１３とＡＰサーバ１４との間や、ＡＰサーバ１４とＤＢサーバ１５との間において、リクエストやレスポンスが送受される。収集部１４１は、各サーバ間で送受されるリクエストやレスポンスを収集し、キャプチャデータとして保持する。

ここで、図４を用いて、収集部１４１によって収集されるメッセージについて説明する。図４は、収集部１４１によって収集されるメッセージの一例を示す図である。図４に示した例のように、収集部１４１は、負荷分散装置１２からＷｅｂサーバ１３へ送信されるリクエストとして、例えば、ＨＴＴＰリクエストや、ＨＴＴＰリクエストが送信された時刻（タイムスタンプ）などを収集する。また、収集部１４１は、Ｗｅｂサーバ１３から負荷分散装置１２へ送信されるレスポンスとして、例えば、ＨＴＴＰレスポンスや、ＨＴＴＰレスポンスが送信されたタイムスタンプ、ＨＴＴＰステータスコードなどを収集する。

また、図４に示すように、収集部１４１は、Ｗｅｂサーバ１３からＡＰサーバ１４へ送信されるリクエストとして、例えば、アプリケーションを識別する情報を含むメッセージや、タイムスタンプなどを収集する。また、収集部１４１は、ＡＰサーバ１４からＷｅｂサーバ１３へ送信されるレスポンスとして、例えば、戻り値や、タイムスタンプなどを収集する。

また、図４に示すように、収集部１４１は、ＡＰサーバ１４からＤＢサーバ１５へ送信されるリクエストとして、例えば、ＳＱＬ文や、制御文、タイムスタンプなどを収集する。また、収集部１４１は、ＤＢサーバ１５からＡＰサーバ１４へ送信されるレスポンスとして、例えば、ＳＱＬの実行結果や、戻り値、タイムスタンプなどを収集する。

図２の説明に戻って、関連付け部１４２は、収集部１４１によって収集されたメッセージのうち、同一トランザクション内で送受されたメッセージを関連付けて業務モデルを生成する。また、関連付け部１４２は、生成した業務モデルに対して、ＤＢサーバ１５への処理態様を識別するための属性を付与する。そして、関連付け部１４２は、属性を付与した業務モデルを業務モデル記憶部１５１に記憶させる。

図５および図６を用いて、関連付け部１４２による関連付け処理について説明する。図５および図６は、関連付け部１４２による関連付け処理の一例を示す図である。図５に例示した各メッセージは、同一トランザクション内で送受されたものとする。かかる場合、関連付け部１４２は、負荷分散装置１２とＷｅｂサーバ１３との間で送受されたメッセージと、Ｗｅｂサーバ１３とＡＰサーバ１４との間で送受されたメッセージと、ＡＰサーバ１４とＤＢサーバ１５との間で送受されたメッセージとを関連付ける。

図６に示した例を用いて説明する。図６に示した例では、テスト端末１１は、負荷分散装置１２を介して、Ｗｅｂサーバ１３へリクエストＲｅｑ１１を送信している。また、Ｗｅｂサーバ１３は、負荷分散装置１２を介して、テスト端末１１へレスポンスＲｅｓ１１を送信している。図６に示した例では、テスト端末１１からリクエストＲｅｑ１１が送信されてから、テスト端末１１へレスポンスＲｅｓ１１が送信されるまでの間が１個のトランザクションとなる。

かかる場合に、関連付け部１４２は、図６に示したリクエストＲｅｑ１１〜Ｒｅｑ１６と、レスポンスＲｅｓ１１〜Ｒｅｓ１６を関連付けて業務モデルを生成する。そして、関連付け部１４２は、生成した業務モデルに属性を付与して業務モデル記憶部１５１に記憶させる。

ここで、業務モデルに付与される属性について補足説明する。実施例１において、関連付け部１４２は、ＤＢサーバ１５に対して更新処理を行う業務モデルに対して、属性「更新系」を付与する。また、関連付け部１４２は、ＤＢサーバ１５に対して更新処理を行わず、かつ、共有ロックを伴う参照処理を行う業務モデルに対して、属性「参照系（共有）」を付与する。また、関連付け部１４２は、ＤＢサーバ１５に対して共有ロックを伴わない参照処理だけを行う業務モデルに対して、属性「参照系（ロックなし）」を付与する。

例えば、業務モデルＭ３において更新処理と参照処理とが行われる場合、関連付け部１４２は、業務モデルＭ３に属性「更新系」を付与する。また、例えば、業務モデルＭ４において共有ロックを伴う参照処理と、共有ロックを伴わない参照処理とが行われる場合、関連付け部１４２は、業務モデルＭ４に属性「参照系（共有）」を付与する。また、例えば、業務モデルＭ５において共有ロックを伴わない参照処理だけが行われる場合、関連付け部１４２は、業務モデルＭ５に属性「参照系（ロックなし）」を付与する。

図７−１〜図７−３を用いて、上述した「更新系」、「参照系（共有ロック）」、「参照系（ロックなし）」について簡単に説明する。図７−１は、更新処理時の排他制御を説明するための図である。また、図７−２は、共有ロックを伴う参照処理時の排他制御を説明するための図である。また、図７−３は、共有ロックを伴わない参照処理時の排他制御を説明するための図である。

図７−１に示すように、任意のトランザクションは、テーブルに対して更新処理を行う場合、排他ロック（EXCLUSIVE LOCK）を取得する。実施例１では、任意のトランザクションによって排他ロックが取得されている場合、他のトランザクションは、同一のテーブルに対して、参照処理および更新処理を行うことができないものとする。

また、図７−２に示すように、任意のトランザクションは、テーブルに対して参照処理を行う場合、共有ロック（SHARED LOCK）を取得することができる。実施例１では、任意のトランザクションによって共有ロックが取得されている場合、他のトランザクショは、同一のテーブルに対して、参照処理を行うことができるが、更新処理を行うことができないものとする。

また、図７−３に示すように、任意のトランザクションは、テーブルに対して参照処理を行う場合、ロックを取得しないこともできる。実施例１では、任意のトランザクションによってロックが取得されずに参照処理が行われている場合、他のトランザクションは、同一のテーブルに対して、参照処理および更新処理を行うことができるものとする。

図２の説明に戻って、ソート部１４３は、関連付け部１４２によって生成された業務モデルを、ＤＢサーバ１５へのアクセスを開始した時刻の昇順にソートする。具体的には、ソート部１４３は、業務モデル記憶部１５１から業務モデルを取得して、取得した業務モデルを結合する。そして、ソート部１４３は、結合した業務モデルを、ＤＢサーバ１５へのアクセス開始時刻の昇順にソートする。

図８−１および図８−２を用いて、ソート部１４３によるソート処理について説明する。図８−１および図８−２は、ソート部１４３によるソート処理の一例を示す図である。図８−１の上段は、３個の業務モデルＭ１１〜Ｍ１３を示している。これは、１回のテストにおいて３個のトランザクションが発生した例を示している。また、図８−１の下段は、２個の業務モデルＭ２１およびＭ２２を示している。これは、１回のテストにおいて２個のトランザクションが発生した例を示している。

なお、図８−１に示した例において、業務モデルの矩形内に示した「（Ｘ表更新）」は、業務モデルにおいて、テーブルＸに対して更新処理が行われることを示している。また、業務モデルの矩形内に示した「（Ｘ表共有）」は、業務モデルにおいて、テーブルＸに対して共有ロックを伴う参照処理が行われることを示している。また、業務モデルの矩形内に示した「（Ｘ表参照）」は、業務モデルにおいて、テーブルＸに対して共有ロックを伴わない参照処理が行われることを示している。また、業務モデルの矩形内に示した「開始」よりも後の部分に示した数値は、ＤＢサーバ１５へのアクセスを開始した時刻を示し、「終了」よりも後の部分に示した数値は、ＤＢサーバ１５へのアクセスを終了した時刻を示す。

すなわち、図８−１に示した業務モデルＭ１１は、テーブルＡに対して参照処理を行い、「１２時００分００秒」にＤＢサーバ１５へのアクセスを開始し、「１２時００分０１秒」にＤＢサーバ１５へのアクセスを終了したことを示している。また、図８−１に示した業務モデルＭ１２は、テーブルＢに対して更新処理を行い、「１２時０２分００秒」にＤＢサーバ１５へのアクセスを開始し、「１２時０２分０１秒」にＤＢサーバ１５へのアクセスを終了したことを示している。

ここで、業務モデル記憶部１５１に、図８−１に示した業務モデルＭ１１〜Ｍ１３、Ｍ２１およびＭ２２が記憶されているものとする。かかる場合に、ソート部１４３は、図８−２に示す例のように、業務モデル記憶部１５１から取得した業務モデルＭ１１〜Ｍ１３、Ｍ２１およびＭ２２をマージした後に、業務モデルＭ１１、Ｍ１２、Ｍ２１、Ｍ２２、Ｍ１３の順にソートする。これにより、業務モデルＭ１１、Ｍ１２、Ｍ２１、Ｍ２２、Ｍ１３は、ＤＢサーバ１５へのアクセス開始時刻の昇順に並び替えられる。

図２の説明に戻って、入替部１４４は、後述する多重化部１４５によって多重化処理が効率的に行われることを目的として、属性が同一である業務モデル同士が隣接するように、ソート部１４３によってソートされた業務モデルの順序を入れ替える。具体的には、入替部１４４は、参照系の業務モデル同士を隣接させ、かつ、更新系の業務モデル同士を隣接させる。このとき、入替部１４４は、更新系の業務モデルの後に、かかる更新系の業務モデルによって更新されるテーブルを参照する参照系の業務モデルが配置されている場合には、更新系の業務モデルと参照系の業務モデルとの順序を入れ替えない。

実施例１において、入替部１４４は、隣接交換法を用いて、隣り合う２個の業務モデルを比較しながら、業務モデルの順序を入れ替える。具体的には、入替部１４４は、アクセス開始時刻が現在時刻に近い業務モデルから入替処理を行うものとする。例えば、入替部１４４は、図８−２に示した業務モデルに対して入替処理を行う場合、まず、最後尾に配置されている業務モデルＭ１３と、最後から２番目に配置されている業務モデルＭ２２とを比較する。続いて、入替部１４４は、最後から２番目と３番目に配置されている業務モデルを比較し、続いて、最後から３番目と４番目に配置されている業務モデルを比較する。

図９に、入替部１４４によって業務モデルが入れ替えられる条件を示す。図９の例は、参照系の業務モデルを、更新系の業務モデルよりも前に配置する条件を示している。図９に示した例において、「現在の業務モデル」は、比較対象の２個の業務モデルのうち、後方に配置されている業務モデルを示し、「直前の業務モデル」は、比較対象の２個の業務モデルのうち、前方に配置されている業務モデルを示す。言い換えれば、「現在の業務モデル」は、比較対象の２個の業務モデルのうち、現在時刻に近い業務モデルを示す。また、図９に示した例において、「参照先／更新先テーブル」は、「現在の業務モデル」と、「直前の業務モデル」とにおいて参照または更新されるテーブルが同一であるか否かを示す。

例えば、入替部１４４は、図９に示すように、現在の業務モデルの属性が「更新系」である場合、直前の業務モデルの属性に関わらず、比較対象の業務モデルを入れ替えない。これは、上述したように、図９に示した例は、参照系の業務モデルを、更新系の業務モデルよりも前に配置するための条件であるからである。

また、例えば、入替部１４４は、図９に示すように、現在の業務モデルの属性が「参照系」であり、直前の業務モデルの属性が「更新系」である場合、双方の業務モデルの「参照先／更新先テーブル」が同一であるか否かを判定する。そして、双方の業務モデルの更新先テーブルが同一である場合、入替部１４４は、双方の業務モデルを入れ替えない。

これは、同一のテーブルに対してアクセスする業務モデルが「更新系、参照系」の順に整列している場合、双方の業務モデルは、かかる順に処理することが求められるからである。例えば、テーブルＡに対して更新処理を行う業務モデルＭ６の後に、テーブルＡに対して参照処理を行う業務モデルＭ７が配置されている場合、業務モデルＭ７は、業務モデルＭ６によってテーブルＡが更新された後に実行されることが求められる。したがって、入替部１４４は、上記例の場合には、業務モデルＭ６およびＭ７の順序を入れ替えない。

一方、上記例において、双方の業務モデルの「参照先／更新先テーブル」が異なる場合、入替部１４４は、双方の業務モデルを入れ替える。これは、上述したように、実施例１における入替部１４４は、参照系の業務モデルを、更新系の業務モデルよりも前に配置するからである。

ここで、図１０を用いて、入替部１４４による入替処理について説明する。図１０は、入替部１４４による入替処理の一例を示す図である。図１０の上段は、ソート部１４３によってソートされた業務モデルの例を示す。なお、図１０の上段に示した業務モデルは、図８−２に示した業務モデルと同様である。入替部１４４は、図１０の上段に例示した業務モデルを、図９に示した条件にしたがって入れ替える。具体的には、入替部１４４は、図１０の下段に示すように、業務モデルＭ１１、Ｍ２１、Ｍ１２、Ｍ２２、Ｍ１３の順に入れ替える。このように、入替部１４４は、図９に示した条件にしたがって、ソート部１４３によってソートされた業務モデルの順序を入れ替える。

図２の説明に戻って、多重化部１４５は、入替部１４４によって入替処理が行われた業務モデルを多重化する。具体的には、多重化部１４５は、入替部１４４によって入替処理が行われた業務モデルのうち、並行して実行してもよい業務モデルを並列に並び替える。実施例１において、多重化部１４５は、隣接交換法を用いて、隣り合う２個の業務モデルを比較しながら、業務モデルの順序を入れ替える。具体的には、多重化部１４５は、入替部１４４によって入替処理が行われた業務モデルのうち、後方に配置されている業務モデルから多重化処理を行う。

図１１に、多重化部１４５によって業務モデルが多重化される条件を示す。多重化部１４５は、図１１に示した条件にしたがって、入替部１４４によって入れ替えされた業務モデルを多重化する。

例えば、多重化部１４５は、図１１に示すように、比較対象の２個の業務モデルの「参照先／更新先テーブル」が異なる場合に、かかる２個の業務モデルを並列に並び替える。これは、２個の業務モデルの「参照先／更新先テーブル」が異なる場合、かかる２個の業務モデルを並行して実行してもよいからである。

また、多重化部１４５は、図１１に示すように、比較対象の２個の業務モデルが共に「参照系」である場合に、「参照先／更新先テーブル」が同一であるか否かに関わらず、比較対象の２個の業務モデルを並列に並び替える。これは、２個の業務モデルが「参照系」である場合、「参照先／更新先テーブル」が同一であるか否かに関わらず、かかる２個の業務モデルを並行して実行してもよいからである。

ここで、図１２−１を用いて、多重化部１４５による多重化処理について説明する。図１２−１は、多重化部１４５による多重化処理の一例を示す図である。図１２−１の上段は、入替部１４４によって入替処理が行われた業務モデルの例を示す。なお、図１２−１の上段に示した業務モデルは、図１０の下段に示した業務モデルと同様である。

多重化部１４５は、図１２−１の上段に例示した業務モデルを、図１１に示した条件にしたがって入れ替える。具体的には、多重化部１４５は、図１２−１の下段に示すように、業務モデルＭ１１、Ｍ２１およびＭ１２を並列に並び替え、また、業務モデルＭ２２およびＭ１３を並列に並び替える。図１２−１の下段に示した業務モデルは、業務モデルＭ１１、Ｍ２１およびＭ１２が並行に実行され、業務モデルＭ２２およびＭ１３が並行に実行されることを示している。

また、多重化部１４５は、上述した多重化処理の他に、同期処理を行うことを示す情報（以下、「同期情報」と言う）を付与する処理を行う。具体的には、多重化部１４５は、図１１の備考に示した条件を満たす場合に、同期情報を付与する処理を行う。

かかる処理について例を挙げて説明する。例えば、隣接する２個の業務モデルが、「業務モデルＭ８、業務モデルＭ９」の順に配置されているものとする。そして、業務モデルＭ８が参照系であり、業務モデルＭ９が更新系であるものとする。かかる場合に、多重化部１４５は、業務モデルＭ８の実行が終了した後に、業務モデルＭ９が実行されるように、業務モデルＭ８と業務モデルＭ９との間に、同期情報を付与する。これは、参照系の業務モデルＭ８が実行されている途中で、業務モデルＭ９が実行されることを防止するためである。

図１２−２を用いて、多重化部１４５による同期情報付与処理について説明する。図１２−２は、多重化部１４５による同期情報付与処理の一例を示す図である。図１２−２の上段は、入替部１４４によって入替処理が行われた業務モデルの例を示す。なお、図１２−２に示した業務モデルのうち、業務モデルＭ３１〜Ｍ３７およびＭ３９は、全て同一のテーブルに対して参照または更新を行うものとする。また、すなわち、図１２−２に示した業務モデルのうち、業務モデルＭ３８は、業務モデルＭ３１〜Ｍ３７およびＭ３９と異なるテーブルに対して更新処理を行う。

かかる場合に、多重化部１４５は、図１１に示した条件にしたがって、図１２−２の上段に例示した業務モデルを、図１２−２の下段に示すように、業務モデルを並び替える。そして、多重化部１４５は、業務モデルＭ３１〜Ｍ３３と、業務モデルＭ３４との間に、同期情報を付与する。すなわち、多重化部１４５は、業務モデルＭ３１〜Ｍ３３の実行が終了するまで、業務モデルＭ３４を実行させないことを示す同期情報を付与する。これにより、多重化部１４５は、業務モデルＭ３１〜Ｍ３３の実行が終了する前に、業務モデルＭ３４が実行されることを防止することができる。

また、多重化部１４５は、業務モデルＭ３５およびＭ３６と、業務モデルＭ３７およびＭ３８との間に、同期情報を付与する。これにより、多重化部１４５は、業務モデルＭ３５およびＭ３６の実行が終了する前に、業務モデルＭ３７およびＭ３８が実行されることを防止することができる。

図２の説明に戻って、シナリオ作成部１４６は、多重化部１４５によって多重化処理が行われた業務モデルに基づいてシナリオを作成し、作成したシナリオをシナリオ記憶部１５２に格納する。シナリオ作成部１４６によって作成されたシナリオは、テスト担当者によってテストが行われた際にＤＢサーバ１５へアクセスされた順序と同一の順序でＤＢサーバ１５へアクセスを行う。このため、シナリオ作成部１４６によって作成されたシナリオは、テストの合否判定を正しく行うことができる。また、シナリオ作成部１４６によって作成されたシナリオは、図１１に示した条件を満たす業務モデルが並行して実行される。このため、シナリオ作成部１４６によって作成されたシナリオは、テストを実行する時間を短くすることができる。

なお、シナリオ作成部１４６は、テストを実行する時間を短くすることが求められていない場合などには、ソート部１４３によってソートされた業務モデルに基づいてシナリオを作成してもよい。

［シナリオ作成処理手順］
次に、図１３を用いて、シナリオ作成装置１００によるシナリオ作成処理の手順について説明する。図１３は、シナリオ作成装置１００によるシナリオ作成処理手順を示すフローチャートである。

図１３に示すように、テスト担当者によって情報処理システム１の動作検証が行われている場合に（ステップＳ１１肯定）、シナリオ作成装置１００の収集部１４１は、各サーバ間で送受されるメッセージを収集する（ステップＳ１２）。

続いて、関連付け部１４２は、収集部１４１によって収集されたメッセージのうち、同一トランザクション内で送受されたメッセージを関連付けて業務モデルを生成する（ステップＳ１３）。

続いて、ソート部１４３は、ソート処理を行う（ステップＳ１４）。具体的には、ソート部１４３は、関連付け部１４２によって生成された業務モデルを、ＤＢサーバ１５へのアクセスを開始した時刻の昇順にソートする。なお、ソート部１４３によるソート処理については、図１４を用いて後述する。

続いて、入替部１４４は、入替処理を行う（ステップＳ１５）。具体的には、入替部１４４は、属性が同一である業務モデル同士が隣接するように、ソート部１４３によってソートされた業務モデルの順序を入れ替える。なお、入替部１４４による入替処理については、図１５および図１６を用いて後述する。

続いて、多重化部１４５は、多重化処理を行う（ステップＳ１６）。具体的には、多重化部１４５は、入替部１４４によって入替処理が行われた業務モデルを多重化する。なお、多重化部１４５による多重化処理については、図１７〜図２１を用いて後述する。

そして、シナリオ作成部１４６は、多重化部１４５によって多重化処理が行われた業務モデルに基づいてシナリオを作成し、作成したシナリオをシナリオ記憶部１５２に格納する（ステップＳ１７）。

［ソート処理手順］
次に、図１４を用いて、図１３のステップＳ１４に示したソート処理の手順について説明する。図１４は、ソート部１４３によるソート処理手順を示すフローチャートである。なお、以下では、図８−１および図８−２に示した例を用いながら説明する。

まず、図１４に示した例において、ソート部１４３は、業務モデル記憶部１５１に記憶されている業務モデルを結合した後に、結合した業務モデルを配列Ｚ（ｉ）に代入する。例えば、業務モデル記憶部１５１が図８−１に示した状態である場合、ソート部１４３は、Ｚ（１）〜Ｚ（５）に、それぞれ業務モデルＭ２２、Ｍ２１、Ｍ１３、Ｍ１２、Ｍ１１を代入する。

そして、ソート部１４３は、図１４に示すように、変数ｎに要素数を代入する（ステップＳ１０１）。ここで言う「要素数」とは、業務モデル記憶部１５１に記憶されている業務モデルの数を示す。例えば、業務モデル記憶部１５１が図８−１に示した状態である場合、業務モデルの数は「５」であるので、ソート部１４３は、ｎに「５」を代入する。

続いて、ソート部１４３は、条件「ｎ≦１」が満たされるまで、ステップＳ１０２〜Ｓ１１０における処理手順を繰り返し行う。ここでは、「ｎ＝５」であるため、条件「ｎ≦１」を満たしていない。したがって、ソート部１４３は、変数ｉに「１」を代入する（ステップＳ１０３）。

そして、ソート部１４３は、条件「ｉ＝ｎ」が満たされるまで、ステップＳ１０４〜Ｓ１０８における処理手順を繰り返し行う。ここでは、「ｎ＝５」、かつ、「ｉ＝１」であるので、条件「ｉ＝ｎ」を満たしていない。したがって、ソート部１４３は、Ｚ（ｉ）の業務モデルにおけるＤＢサーバ１５へのアクセス開始時刻と、Ｚ（ｉ＋１）の業務モデルにおけるＤＢサーバ１５へのアクセス開始時刻とを比較する（ステップＳ１０５）。

そして、Ｚ（ｉ）におけるアクセス開始時刻が、Ｚ（ｉ＋１）におけるアクセス開始時刻以下である場合、ソート部１４３は、Ｚ（ｉ）に代入されている業務モデルと、Ｚ（ｉ＋１）に代入されている業務モデルとを入れ替える（ステップＳ１０６）。具体的には、ソート部１４３は、図１４に示すように、Ｚ（ｉ）に代入されている業務モデルを、ワーク変数ｗに代入した後に、Ｚ（ｉ＋１）に代入されている業務モデルをＺ（ｉ）に代入し、ワーク変数ｗに代入した業務モデルをＺ（ｉ＋１）に代入する。

なお、本明細書において、「時刻Ａが時刻Ｂよりも大きい」と表記する場合、時刻Ａが時刻Ｂよりも現在時刻に近い時刻であることを示すものとする。言い換えれば、「時刻Ａが時刻Ｂよりも小さい」と表記する場合、時刻Ａが時刻Ｂよりも過去であることを示す。

一方、Ｚ（ｉ）におけるアクセス開始時刻が、Ｚ（ｉ＋１）におけるアクセス開始時刻よりも大きい場合、ソート部１４３は、Ｚ（ｉ）に代入されている業務モデルと、Ｚ（ｉ＋１）に代入されている業務モデルとを入れ替えない。

ここでは、「ｉ＝１」であるので、ソート部１４３は、Ｚ（１）とＺ（２）とを比較する。すなわち、上記例の場合、ソート部１４３は、業務モデルＭ２２のアクセス開始時刻と、業務モデルＭ２１のアクセス開始時刻とを比較する。図８−１に示すように、業務モデルＭ２２のアクセス開始時刻は、業務モデルＭ２１のアクセス開始時刻よりも大きいので、ソート部１４３は、業務モデルＭ２２と、業務モデルＭ２１との順序を入れ替えない。

続いて、ソート部１４３は、変数ｉをインクリメントする（ステップＳ１０７）。ここでは、ソート部１４３は、変数ｉを「２」に更新する。すなわち、「ｎ＝５」、かつ、「ｉ＝２」であるので、ステップＳ１０４における条件「ｉ＝ｎ」を満たしていない。したがって、ソート部１４３は、ステップＳ１０５〜Ｓ１０７における処理を行う。具体的には、ソート部１４３は、Ｚ（２）とＺ（３）とを比較する。

すなわち、上記例の場合、ソート部１４３は、業務モデルＭ２１のアクセス開始時刻と、業務モデルＭ１３のアクセス開始時刻とを比較する。図８−１に示すように、業務モデルＭ２１のアクセス開始時刻は、業務モデルＭ１３のアクセス開始時刻以下であるので、ソート部１４３は、業務モデルＭ２１と、業務モデルＭ１３との順序を入れ替える。

このように、ソート部１４３は、ステップＳ１０４における条件「ｉ＝ｎ」が満たされるまで、ステップＳ１０４〜Ｓ１０８における処理手順を繰り返し行う。そして、条件「ｉ＝ｎ」を満たした場合、ソート部１４３は、変数ｎをデクリメントする（ステップＳ１０９）。そして、ソート部１４３は、ステップＳ１０２における条件「ｎ≦１」が満たされるまで、ステップＳ１０２〜Ｓ１１０における処理手順を繰り返し行う。

［入替処理手順］
次に、図１５を用いて、図１３のステップＳ１５に示した入替処理の手順について説明する。図１５は、入替部１４４による入替処理手順を示すフローチャートである。なお、図１５では、図１０に示した例を用いながら説明する。また、図１５において、配列Ｚ（ｉ）には、図１４に示した処理手順が実行された後の業務モデルが代入されているものとする。すなわち、ここでは、Ｚ（１）〜Ｚ（５）には、それぞれ業務モデルＭ１３、Ｍ２２、Ｍ２１、Ｍ１２、Ｍ１１が代入されている。

まず、入替部１４４は、図１５に示すように、変数ｎに要素数を代入する（ステップＳ２０１）。上記例の場合、業務モデルの数は「５」であるので、入替部１４４は、ｎに「５」を代入する。

続いて、入替部１４４は、条件「ｎ≦１」が満たされるまで、ステップＳ２０２〜Ｓ２１１における処理手順を繰り返し行う。ここでは、「ｎ＝５」であるため、条件「ｎ≦１」を満たしていない。したがって、入替部１４４は、変数ｉに「１」を代入する（ステップＳ２０３）。

そして、入替部１４４は、条件「ｉ＝ｎ」が満たされるまで、ステップＳ２０４〜Ｓ２０９における処理手順を繰り返し行う。ここでは、「ｎ＝５」、かつ、「ｉ＝１」であるので、条件「ｉ＝ｎ」を満たしていない。したがって、入替部１４４は、Ｚ（ｉ）とＺ（ｉ＋１）とを比較して入替判定処理を行う（ステップＳ２０５）。なお、入替部１４４により入替判定処理については図１６を用いて後述する。

入替判定処理の結果、「入替処理を行う」と判定した場合（ステップＳ２０６肯定）、入替部１４４は、Ｚ（ｉ）に代入されている業務モデルと、Ｚ（ｉ＋１）に代入されている業務モデルとを入れ替える（ステップＳ２０７）。具体的には、入替部１４４は、図１５に示すように、Ｚ（ｉ）に代入されている業務モデルを、ワーク変数ｗに代入した後に、Ｚ（ｉ＋１）に代入されている業務モデルをＺ（ｉ）に代入し、ワーク変数ｗに代入した業務モデルをＺ（ｉ＋１）に代入する。

入替判定処理の結果、「入替処理を行わない」と判定した場合（ステップＳ２０６否定）、入替部１４４は、Ｚ（ｉ）に代入されている業務モデルと、Ｚ（ｉ＋１）に代入されている業務モデルとを入れ替えない。

続いて、入替部１４４は、変数ｉをインクリメントする（ステップＳ２０８）。ここでは、入替部１４４は、変数ｉを「２」に更新する。すなわち、「ｎ＝５」、かつ、「ｉ＝２」であるので、ステップＳ２０４における条件「ｉ＝ｎ」を満たしていない。したがって、入替部１４４は、ステップＳ２０５〜Ｓ２０８における処理を行う。

このように、入替部１４４は、ステップＳ２０４における条件「ｉ＝ｎ」が満たされるまで、ステップＳ２０４〜Ｓ２０８における処理手順を繰り返し行う。そして、条件「ｉ＝ｎ」を満たした場合、入替部１４４は、変数ｎをデクリメントする（ステップＳ２１０）。そして、入替部１４４は、ステップＳ２０２における条件「ｎ≦１」が満たされるまで、ステップＳ２０２〜Ｓ２１１における処理手順を繰り返し行う。

［入替処理手順］
次に、図１６を用いて、図１５のステップＳ２０５に示した入替判定処理の手順について説明する。図１６は、入替部１４４による入替判定処理手順を示すフローチャートである。なお、図１６では、図１５に示した例と同様に、配列Ｚ（ｉ）には、図１４に示した処理手順が実行された後の業務モデルが代入されているものとする。

入替部１４４は、入替判定処理を行う場合、まず、Ｚ（ｉ）の業務モデルにおいて参照または更新されるテーブルの名称を変数ＺＴ（ｉ）に代入する（ステップＳ３０１）。また、入替部１４４は、Ｚ（ｉ＋１）の業務モデルにおいて参照または更新されるテーブルの名称を変数ＺＴ（ｉ＋１）に代入する（ステップＳ３０１）。

続いて、入替部１４４は、Ｚ（ｉ）の業務モデルが「更新系」である場合（ステップＳ３０２肯定）、「入替処理を行わない」と判定する（ステップＳ３０３）。具体的には、入替部１４４は、Ｚ（ｉ）とＺ（ｉ＋１）とを入れ替える処理を行わないと判定する。これは、図９に示した条件のうち、「現在の業務モデルの属性」が「更新系」である場合を示している。

一方、Ｚ（ｉ）の業務モデルが「更新系」でない場合（ステップＳ３０２否定）、入替部１４４は、ＺＴ（ｉ）とＺＴ（ｉ＋１）とが等しいか否かを判定する（ステップＳ３０４）。そして、ＺＴ（ｉ）とＺＴ（ｉ＋１）とが等しい場合（ステップＳ３０４肯定）、入替部１４４は、「入替処理を行わない」と判定する（ステップＳ３０５）。これは、図９に示した条件のうち、「現在の業務モデルの属性」が「参照系（共有）」または「参照系（ロックなし）」であり、かつ、「参照先／更新先テーブル」が「同一」である場合を示している。

一方、ＺＴ（ｉ）とＺＴ（ｉ＋１）とが異なる場合（ステップＳ３０４否定）、入替部１４４は、「入替処理を行う」と判定する（ステップＳ３０６）。これは、図９に示した条件のうち、「現在の業務モデルの属性」が「参照系（共有）」または「参照系（ロックなし）」であり、かつ、「参照先／更新先テーブル」が「相違」である場合を示している。

上記例を用いて説明すると、「ｉ＝１」である場合、Ｚ（ｉ）＝Ｚ（１）の業務モデルは、業務モデルＭ１３であり、Ｚ（ｉ＋１）＝Ｚ（２）の業務モデルは、業務モデルＭ２２である。図１０に示すように、業務モデルＭ１３の属性は、参照系（共有）である（ステップＳ３０２否定）。また、図１０に示すように、業務モデルＭ１３と業務モデルＭ２２の「参照先／更新先テーブル」は、テーブルＢであるので、「同一」である（ステップＳ３０４肯定）。したがって、「ｉ＝１」である場合、入替部１４４は、業務モデルＭ１３と業務モデルＭ２２とを入れ替える処理を行わないと判定する。

［多重化処理手順］
次に、図１７および図１８−１〜図１８−４を用いて、図１３のステップＳ１６に示した多重化処理の手順について説明する。図１７は、多重化部１４５による多重化処理手順を示すフローチャートである。図１８−１〜図１８−４は、多重化部１４５による多重化処理の一例を説明するための図である。

図１８−１には、多重化処理対象の業務モデルＭ１０１〜Ｍ１２１を示す。図１８−１に例示した業務モデルＭ１０１〜Ｍ１２１は、入替部１４４によって入替処理が行われており、それぞれＺ（１）〜Ｚ（２１）に代入されている。

また、図１８−２には、多重化部１４５によって多重化処理が行われる場合に用いられる配列Ｙ（ｊ、ｋ）を示す。多重化部１４５は、配列Ｚ（ｉ）に代入されている業務モデルを、配列Ｙ（ｊ、ｋ）に代入することにより多重化処理を行う。ここで、配列Ｙ（ｊ、ｋ）のうち、同一の行（ｊ）に代入された業務モデルは、並行して実行されることを示す。

また、図１８−３には、配列Ｘ（ｊ）を示す。かかる配列Ｘ（ｊ）は、配列Ｙ（ｊ、ｋ）のうち、行（ｊ）に格納されている業務モデルの数を示す。また、図１８−４には、配列Ｗ（ｊ）を示す。かかる配列Ｗ（ｊ）は、配列Ｙ（ｊ、ｋ）のうち、行（ｊ）において同期処理を行うか否かを示す。

なお、図１８−２に示した配列Ｙ（ｊ、ｋ）、図１８−３に示した配列Ｘ（ｊ）、図１８−４に示した配列Ｗ（ｊ）は、多重化部１４５によって多重化処理が行われた後の状態を示している。

以下に、図１８−１〜図１８−４に示した例を用いながら、図１７に示した処理手順について説明する。なお、初期状態において、配列Ｙ（ｊ、ｋ）には、空であるものとする。

まず、図１７に示すように、多重化部１４５は、初期化処理を行う（ステップＳ４０１）。具体的には、多重化部１４５は、配列Ｘ（ｊ）および配列Ｗ（ｊ）に「０」を代入する。なお、多重化部１４５による初期化処理については、図１９を用いて後述する。

続いて、多重化部１４５は、変数ｎに要素数を代入し、変数ｉに「１」を代入する（ステップＳ４０２）。図１８−１に示した例では、業務モデルの数は「２１」であるので、多重化部１４５は、ｎに「２１」を代入する。

続いて、多重化部１４５は、条件「ｎ≦１」が満たされるまで、ステップＳ４０３〜Ｓ４１７における処理手順を繰り返し行う。ここでは、「ｎ＝２１」であるので、条件「ｎ≦１」を満たしていない。したがって、多重化部１４５は、変数ｊにｉを代入する（ステップＳ４０４）。ここでは、「ｉ＝１」であるので、多重化部１４５は、変数ｊに「１」を代入する。

続いて、多重化部１４５は、条件「ｊ＜１」が満たされるまで、ステップＳ４０５〜Ｓ４１３における処理手順を繰り返し行う。ここでは、「ｊ＝１」であるので、条件「ｊ＜１」を満たしていない。したがって、多重化部１４５は、変数ｋにＸ（ｊ）を代入する（ステップＳ４０６）。ここでは、「ｊ＝１」であり、「Ｘ（１）＝０」であるので、多重化部１４５は、変数ｋに「０」を代入する。

続いて、多重化部１４５は、条件「ｋ＜１」が満たされるまで、ステップＳ４０７〜Ｓ４１１における処理手順を繰り返し行う。ここでは、「ｋ＝０」であるので、条件「ｋ＜１」を満たしている。したがって、多重化部１４５は、変数ｊをデクリメントする（ステップＳ４１２）。ここでは、「ｊ＝１」であるので、多重化部１４５は、変数ｊを、「１」から「１」を減算した値「０」に更新する。

続いて、多重化部１４５は、ステップＳ４０５における条件「ｊ＜１」を満たしているか否かを判定する。ここでは、「ｊ＝０」であるので、条件「ｊ＜１」を満たしている。したがって、多重化部１４５は、ステップＳ４１４における処理手順を行う。

具体的には、多重化部１４５は、変数ｊを「０」から「１」に更新する。また、多重化部１４５は、Ｘ（ｊ）に「Ｘ（ｊ）＋１」を代入する。ここでは、「ｊ＝１」であり、「Ｘ（１）＝０」であるので、Ｘ（１）に「０＋１」を代入する。また、多重化部１４５は、変数ｋにＸ（ｊ）を代入する。ここでは、「Ｘ（１）＝１」であるので、多重化部１４５は、変数ｋに「１」を代入する。また、多重化部１４５は、Ｙ（ｊ、ｋ）にＺ（ｉ）を代入する。ここでは、「ｉ＝１」であり、「ｊ＝１」であり、「ｋ＝１」であり、Ｚ（１）には、業務モデルＭ１０１が代入されているので、多重化部１４５は、図１８−２に示したように、Ｙ（１、１）に業務モデルＭ１０１を代入する。

続いて、多重化部１４５は、同期設定処理を行う（ステップＳ４１５）。なお、多重化部１４５による同期設定処理については、図２１を用いて後述する。続いて、多重化部１４５は、変数ｎをデクリメントし、変数ｉをインクリメントする。ここでは、多重化部１４５は、変数ｎを「２１」から「２０」に更新し、変数ｉを「１」から「２」に更新する。

続いて、多重化部１４５は、ステップＳ４０３における条件「ｎ≦１」を満たしているか否かを判定する。ここでは、「ｎ＝２０」であるので、条件「ｎ≦１」を満たしていない。したがって、多重化部１４５は、変数ｊにｉを代入する（ステップＳ４０４）。ここでは、「ｉ＝２」であるので、多重化部１４５は、変数ｊに「２」を代入する。

続いて、多重化部１４５は、ステップＳ４０５における条件「ｊ＜１」を満たしているか否かを判定する。ここでは、「ｊ＝２」であるので、条件「ｊ＜１」を満たしていない。したがって、多重化部１４５は、変数ｋにＸ（ｊ）を代入する（ステップＳ４０６）。ここでは、「ｊ＝２」であり、「Ｘ（２）＝０」であるので、多重化部１４５は、変数ｋに「０」を代入する。

続いて、多重化部１４５は、ステップＳ４０７における条件「ｋ＜１」を満たしているか否かを判定する。ここでは、「ｋ＝０」であるので、条件「ｋ＜１」を満たしている。したがって、多重化部１４５は、変数ｊを、「２」から「１」に更新する（ステップＳ４１２）。

続いて、多重化部１４５は、ステップＳ４０５における条件「ｊ＜１」を満たしているか否かを判定する。ここでは、「ｊ＝１」であるので、条件「ｊ＜１」を満たしていない。したがって、多重化部１４５は、変数ｋにＸ（ｊ）を代入する（ステップＳ４０６）。ここでは、「ｊ＝１」であり、「Ｘ（１）＝１」であるので、多重化部１４５は、変数ｋに「１」を代入する。

続いて、多重化部１４５は、ステップＳ４０７における条件「ｋ＜１」を満たしているか否かを判定する。ここでは、「ｋ＝１」であるので、条件「ｋ＜１」を満たしていない。したがって、多重化部１４５は、多重化判定処理を行う（ステップＳ４０８）。なお、多重化部１４５により多重化判定処理については、図２０を用いて後述する。

多重化判定処理の結果、多重化を行うことを決定した場合、多重化部１４５は、変数ｋをデクリメントする（ステップＳ４１０）。一方、多重化を行わないことを決定した場合、多重化部１４５は、ステップＳ４１４における処理手順を行う。

なお、ここでは、多重化部１４５は、多重化を行わないことを決定するので、ステップＳ４１４における処理手順を行う。具体的には、多重化部１４５は、変数ｊを「１」から「２」に更新する。また、多重化部１４５は、Ｘ（ｊ）に「Ｘ（ｊ）＋１」を代入する。ここでは、「ｊ＝２」であり、「Ｘ（２）＝０」であるので、Ｘ（２）に「０＋１」を代入する。また、多重化部１４５は、変数ｋにＸ（ｊ）を代入する。ここでは、「Ｘ（２）＝１」であるので、多重化部１４５は、変数ｋに「１」を代入する。また、多重化部１４５は、Ｙ（ｊ、ｋ）にＺ（ｉ）を代入する。ここでは、「ｉ＝２」であり、「ｊ＝２」であり、「ｋ＝１」であり、Ｚ（２）には、業務モデルＭ１０２が代入されているので、多重化部１４５は、図１８−２に示したように、Ｙ（２、１）に業務モデルＭ１０２を代入する。

このようにして、多重化部１４５は、ステップＳ４０３における条件「ｎ≦１」を満たすまで、上述した処理手順を行う。これにより、図１８−１に示した配列Ｚ（ｉ）に代入されている業務モデルＭ１０１〜Ｍ１２１は、図１８−２に示したように、配列Ｙ（ｊ、ｋ）に代入される。図１８−２に示した例では、同一の行（ｊ）に代入されている業務モデルが多重化されていることを示している。例えば、業務モデルＭ１０１およびＭ１０３が多重化されていることを示している。そして、図１８−２に示した例では、業務モデルＭ１０１およびＭ１０３が並行して実行された後に、業務モデルＭ１０２、Ｍ１０５、Ｍ１０７が並行して実行されることを示している。そして、最後に、図１８−２に示した例では、業務モデルＭ１１８およびＭ１２０が実行されることを示している。

［初期化処理手順］
次に、図１９を用いて、図１７のステップＳ４０１に示した初期化処理の手順について説明する。図１９は、多重化部１４５による初期化処理手順を示すフローチャートである。

図１９に示すように、多重化部１４５は、まず、変数ｎに要素数を代入する（ステップＳ５０１）。続いて、多重化部１４５は、条件「ｎ≦１」が満たされるまで、ステップＳ５０２〜Ｓ５０５における処理手順を繰り返し行う。

具体的には、多重化部１４５は、配列Ｘ（ｎ）および配列Ｗ（ｎ）に「０」を代入する（ステップＳ５０３）。続いて、多重化部１４５は、変数ｎをデクリメントする（ステップＳ５０４）。すなわち、多重化部１４５は、配列Ｘ（ｎ）の要素（１）〜Ｘ（ｎ）と、配列Ｗ（ｎ）の要素Ｗ（１）〜Ｗ（ｎ）に、「０」を代入する。

［多重化判定処理手順］
次に、図２０を用いて、図１７のステップＳ４０８に示した多重化判定処理の手順について説明する。図２０は、多重化部１４５による多重化判定処理手順を示すフローチャートである。

多重化部１４５は、多重化判定処理を行う場合、まず、Ｚ（ｉ）の業務モデルにおいて参照または更新されるテーブルの名称を変数ＺＴ（ｉ）に代入する（ステップＳ６０１）。また、多重化部１４５は、Ｙ（ｊ、ｋ）の業務モデルにおいて参照または更新されるテーブルの名称を変数ＹＴ（ｊ、ｋ）に代入する（ステップＳ６０１）。

続いて、多重化部１４５は、Ｚ（ｉ）の業務モデルが「更新系」であり（ステップＳ６０２肯定）、かつ、ＺＴ（ｉ）とＹＴ（ｊ、ｋ）とが等しい場合（ステップＳ６０３肯定）、「多重化処理を行わない」と判定する（ステップＳ６０４）。

一方、多重化部１４５は、Ｚ（ｉ）に代入されている業務モデルが「更新系」であり（ステップＳ６０２肯定）、かつ、ＺＴ（ｉ）とＹＴ（ｊ、ｋ）とが異なる場合（ステップＳ６０３否定）、「多重化処理を行う」と判定する（ステップＳ６０５）。

また、多重化部１４５は、Ｚ（ｉ）に代入されている業務モデルが「更新系」でない場合（ステップＳ６０２否定）、Ｙ（ｊ、ｋ）に代入されている業務モデルが「更新系」であるか否かを判定する（ステップＳ６０６）。

そして、多重化部１４５は、Ｙ（ｊ、ｋ）に代入されている業務モデルが「更新系」であり（ステップＳ６０６肯定）、かつ、ＺＴ（ｉ）とＹＴ（ｊ、ｋ）とが等しい場合（ステップＳ６０７肯定）、「多重化処理を行わない」と判定する（ステップＳ６０８）。

一方、Ｙ（ｊ、ｋ）に代入されている業務モデルが「更新系」であり（ステップＳ６０６肯定）、かつ、ＺＴ（ｉ）とＹＴ（ｊ、ｋ）とが異なる場合（ステップＳ６０７否定）、多重化部１４５は、「多重化処理を行う」と判定する（ステップＳ６０９）。

また、多重化部１４５は、Ｙ（ｊ、ｋ）に代入されている業務モデルが「更新系」でない（ステップＳ６０６否定）、「多重化処理を行う」と判定する（ステップＳ６１０）。このように、多重化部１４５は、図１１に示した条件に従って、多重化処理を行うか否かを決定する。

［同期設定処理手順］
次に、図２１を用いて、図１７のステップＳ４１５に示した同期設定処理の手順について説明する。図２１は、多重化部１４５による同期設定処理手順を示すフローチャートである。

図２１に示すように、多重化部１４５は、同期設定処理を行う場合、まず、変数ｊをデクリメントする（ステップＳ７０１）。続いて、多重化部１４５は、変数ｊが「１」よりも小さいか否かを判定する（ステップＳ７０２）。

そして、多重化部１４５は、変数ｊが「１」よりも小さい場合、処理を終了する。一方、多重化部１４５は、変数ｊが「１」以上である場合、Ｘ（ｊ）の値を変数ｋに代入する（ステップＳ７０３）。

続いて、多重化部１４５は、条件「ｋ≦１」が満たされるまで、ステップＳ７０４〜Ｓ７０８における処理手順を繰り返し行う。具体的には、多重化部１４５は、Ｚ（ｉ）とＹ（ｊ、ｋ）とを比較し、Ｚ（ｉ）が更新系、かつ、Ｙ（ｊ、ｋ）が参照系である場合、同期設定は不要であると判定する（ステップＳ７０５）。そして、多重化部１４５は、変数ｋをデクリメントする（ステップＳ７０６）。

一方、多重化部１４５は、Ｚ（ｉ）が更新系でないか、または、Ｙ（ｊ、ｋ）が参照系でない場合、同期設定が必要であると判定する（ステップＳ７０５）。そして、多重化部１４５は、変数ｊをインクリメントするとともに、Ｗ（ｊ）に「１」を代入する（ステップＳ７０７）。

例えば、多重化部１４５は、図１８−１に示した業務モデルＭ１０１〜Ｍ１２１に対して多重化処理を行った場合、配列Ｗ（ｊ）に図１８−４に示した値を代入する。これは、配列Ｙ（ｊ、ｋ）のうち、「ｊ＝３〜６」の行において、同期情報を付与していることを示す。

［実施例１の効果］
上述してきたように、実施例１に係るシナリオ作成装置１００は、各サーバ間で送受されるメッセージを収集し、同一のトランザクション内に送受されたメッセージを関連付けて業務モデルを生成する。そして、シナリオ作成装置１００は、生成した業務モデルを、ＤＢサーバ１５へのアクセスを開始した時刻の昇順にソートすることによりシナリオを作成する。これにより、シナリオ作成装置１００は、テストの合否判定を正しく行うことができるシナリオを作成することができる。

また、実施例１に係るシナリオ作成装置１００は、ＤＢサーバ１５へのアクセスを開始した時刻の昇順にソートした業務モデルを多重化するので、テストの実行時間が短いシナリオを作成することができる。

さらに、シナリオ作成装置１００によって生成されたシナリオは、多重化されているので、負荷テストに用いることもできる。また、シナリオ作成装置１００によって生成されたシナリオは、各サーバ間で送受されたメッセージを保持しているので、テストの検証結果がＮＧになった場合に、どのサーバ間でエラーが発生したかを特定することができる。これにより、シナリオ作成装置１００によって生成されたシナリオを用いると、容易かつ短時間でエラー箇所を特定することができる。

ところで、本願の開示するシナリオ作成装置等は、上述した実施例以外にも、種々の異なる形態にて実施されてよい。そこで、実施例２では、本願の開示するシナリオ作成装置等の他の実施例について説明する。

［業務モデルの属性］
上記実施例１では、図９や図１１に示したように、隣接する２個の業務モデルについて、「参照先／更新先テーブル」が同一であるか否かを判定する例を示した。ここで、１個の業務モデルによって複数のテーブルに参照処理や更新処理が行われることも考えられる。かかる場合、入替部１４４や多重化部１４５は、比較対象の２個の業務モデルによって参照処理や更新処理が行われるテーブルが１個でも重複する場合に、「参照先／更新先テーブル」が「同一」であると判定する。言い換えれば、入替部１４４や多重化部１４５は、比較対象の２個の業務モデルによって参照処理や更新処理が行われるテーブルが全て異なる場合に、「参照先／更新先テーブル」が「相違」であると判定する。

例えば、現在の業務モデルがテーブルＡ、Ｂ、Ｃに対して更新処理を行い、直前の業務モデルがテーブルＣ、Ｄ、Ｅに対して参照処理を行う場合、入替部１４４や多重化部１４５は、現在の業務モデルと、直前の業務モデルとの「参照先／更新先テーブル」が「同一」であると判定する。これは、双方の業務モデルがテーブルＣに対して参照処理または更新処理を行うからである。

また、例えば、現在の業務モデルがテーブルＡ、Ｂ、Ｃに対して更新処理を行い、直前の業務モデルがテーブルＤ、Ｅに対して参照処理を行う場合、入替部１４４や多重化部１４５は、現在の業務モデルと、直前の業務モデルとの「参照先／更新先テーブル」が「相違」であると判定する。これは、双方の業務モデルが全て異なるテーブルに対して参照処理または更新処理を行うからである。

［プログラム］
上記実施例１で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図２２を用いて、上記の実施例１におけるシナリオ作成装置１００と同様の機能を有するシナリオ作成プログラムを実行するコンピュータの一例を説明する。

図２２は、シナリオ作成プログラムを実行するコンピュータを示す図である。図２２に示すように、コンピュータ１０００は、ＲＡＭ（Random Access Memory）１０１０と、キャッシュ１０２０と、ＨＤＤ１０３０と、ＲＯＭ（Read Only Memory）１０４０と、ＣＰＵ（Central Processing Unit）１０５０とを有する。ＲＡＭ１０１０、キャッシュ１０２０、ＨＤＤ１０３０、ＲＯＭ１０４０、ＣＰＵ１０５０は、バス１０６０によって接続されている。

ＲＯＭ１０４０には、上記の実施例１におけるシナリオ作成装置１００と同様の機能を発揮するシナリオ作成プログラムが予め記憶されている。具体的には、ＲＯＭ１０４０には、収集プログラム１０４１と、関連付けプログラム１０４２と、ソートプログラム１０４３と、入替プログラム１０４４と、多重化プログラム１０４５と、シナリオ作成プログラム１０４６とが記憶されている。

そして、ＣＰＵ１０５０は、これらの収集プログラム１０４１と、関連付けプログラム１０４２と、ソートプログラム１０４３と、入替プログラム１０４４と、多重化プログラム１０４５と、シナリオ作成プログラム１０４６とを読み出して実行する。これにより、図２２に示すように、収集プログラム１０４１は、収集プロセス１０５１になり、関連付けプログラム１０４２は、関連付けプロセス１０５２になり、ソートプログラム１０４３は、ソートプロセス１０５３になる。また、入替プログラム１０４４は、入替プロセス１０５４になり、多重化プログラム１０４５は、多重化プロセス１０５５になり、シナリオ作成プログラム１０４６は、シナリオ作成プロセス１０５６になる。

なお、収集プロセス１０５１は、図２に示した収集部１４１に対応し、関連付けプロセス１０５２は、図２に示した関連付け部１４２に対応し、ソートプロセス１０５３は、図２に示したソート部１４３に対応する。また、入替プロセス１０５４は、図２に示した入替部１４４に対応し、多重化プロセス１０５５は、図２に示した多重化部１４５に対応し、シナリオ作成プロセス１０５６は、図２に示したシナリオ作成部１４６に対応する。

また、ＨＤＤ１０３０には、図２２に示すように、シナリオ作成関連データ１０３１が設けられる。かかるシナリオ作成関連データ１０３１は、図２に示した業務モデル記憶部１５１やシナリオ記憶部１５２に対応する。

なお、上記した各プログラム１０４１〜１０４６については、必ずしもＲＯＭ１０４０に記憶させなくてもよい。例えば、コンピュータ１０００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」にプログラム１０４１〜１０４６を記憶させてもよい。または、コンピュータ１０００の内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用の物理媒体」にプログラム１０４１〜１０４６を記憶させてもよい。または、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１０００に接続される「他のコンピュータ（またはサーバ）」にプログラム１０４１〜１０４６を記憶させてもよい。そして、コンピュータ１０００は、上述したフレキシブルディスク等から各プログラムを読み出して実行するようにしてもよい。

１ 情報処理システム
９ 情報処理システム
１１ テスト端末
１２ 負荷分散装置
１３ Ｗｅｂサーバ
１４ ＡＰサーバ
１５ ＤＢサーバ
２１〜２６ ルータ
３１ ネットワーク
３２ ファイアーウォール
１００ シナリオ作成装置
１１０ ＩＦ部
１２０ 入力部
１３０ 出力部
１４０ 制御部
１４１ 収集部
１４２ 関連付け部
１４３ ソート部
１４４ 入替部
１４５ 多重化部
１４６ シナリオ作成部
１５１ 業務モデル記憶部
１５２ シナリオ記憶部
１０００ コンピュータ
１０１０ ＲＡＭ
１０２０ キャッシュ
１０３０ ＨＤＤ
１０３１ シナリオ作成関連データ
１０４０ ＲＯＭ
１０４１ 収集プログラム
１０４２ 関連付けプログラム
１０４３ ソートプログラム
１０４４ 入替プログラム
１０４５ 多重化プログラム
１０４６ シナリオ作成プログラム
１０５０ ＣＰＵ
１０５１ 収集プロセス
１０５２ 関連付けプロセス
１０５３ ソートプロセス
１０５４ 入替プロセス
１０５５ 多重化プロセス
１０５６ シナリオ作成プロセス
１０６０ バス

Claims (8)

1. データベースサーバを含む複数のサーバが接続された情報処理システムの動作を検証するためのシナリオを作成するシナリオ作成プログラムであって、
   動作検証を行う端末装置によって前記情報処理システムの動作検証が行われている場合に、前記複数のサーバ間で送受されるメッセージを収集する収集手順と、
   前記収集手順によって収集されたメッセージを関連付ける関連付け手順と、
   前記関連付け手順によって関連付けられたメッセージ群である業務モデルを、前記データベースサーバにアクセスした時刻の昇順にソートするソート手順と、
   前記ソート手順によってソートされた業務モデルに基づいてシナリオを作成するシナリオ作成手順と
   をコンピュータに実行させることを特徴とするシナリオ作成プログラム。
2. 前記ソート手順によってソートされた業務モデルのうち、隣接する業務モデルによってアクセスされる前記データベースサーバのテーブルが異なる場合に、該隣接する業務モデルを並列に並び替える多重化手順をさらにコンピュータに実行させ、
   前記シナリオ作成手順は、前記多重化手順によって並び替えられた業務モデルに基づいてシナリオを作成することを特徴とする請求項１に記載のシナリオ作成プログラム。
3. 前記多重化手順は、前記ソート手順によってソートされた業務モデルのうち、隣接する業務モデルの双方が前記データベースサーバへ参照処理だけを行う場合に、該隣接する業務モデルを並列に並び替えることを特徴とする請求項２に記載のシナリオ作成プログラム。
4. 前記データベースサーバに対して更新処理を行う業務モデルである更新系の業務モデル同士が隣接し、かつ、前記データベースサーバに対して参照処理を行う業務モデル同士が隣接するように、前記ソート手順によってソートされた業務モデルの順序を入れ替える入替手順をさらにコンピュータに実行させ、
   前記多重化手順は、前記入替手順によって入れ替えられた業務モデルを並列に並び替えることを特徴とする請求項２または３に記載のシナリオ作成プログラム。
5. 前記入替手順は、更新系の業務モデルの後に、参照系の業務モデルが配置されており、かつ、該更新系の業務モデルと該参照系の業務モデルによってアクセスされるテーブルが同一である場合には、該参照系の業務モデルと該更新系の業務モデルとの順序を維持し、更新系の業務モデルの後に、参照系の業務モデルが配置されており、かつ、該更新系の業務モデルと該参照系の業務モデルによってアクセスされるテーブルが異なる場合には、該参照系の業務モデルと該更新系の業務モデルとの順序を入れ替えることを特徴とする請求項４に記載のシナリオ作成プログラム。
6. 前記入替手順は、参照系の業務モデルの後に、参照系の業務モデルが配置されており、かつ、双方の業務モデルによってアクセスされるテーブルが異なる場合には、双方の業務モデルの順序を入れ替えることを特徴とする請求項４または５に記載のシナリオ作成プログラム。
7. データベースサーバを含む複数のサーバが接続された情報処理システムの動作を検証するためのシナリオを作成するシナリオ作成装置であって、
   動作検証を行う端末装置によって前記情報処理システムの動作検証が行われている場合に、前記複数のサーバ間で送受されるメッセージを収集する収集部と、
   前記収集部によって収集されたメッセージを関連付ける関連付け部と、
   前記関連付け部によって関連付けられたメッセージ群である業務モデルを、前記データベースサーバにアクセスした時刻の昇順にソートするソート部と、
   前記ソート部によってソートされた業務モデルに基づいてシナリオを作成するシナリオ作成部と
   を備えたことを特徴とするシナリオ作成装置。
8. データベースサーバを含む複数のサーバが接続された情報処理システムの動作を検証するためのシナリオを作成するシナリオ作成装置によるシナリオ作成方法であって、
   前記シナリオ作成装置が、
   動作検証を行う端末装置によって前記情報処理システムの動作検証が行われている場合に、前記複数のサーバ間で送受されるメッセージを収集する収集ステップと、
   前記収集ステップによって収集されたメッセージを関連付ける関連付けステップと、
   前記関連付けステップによって関連付けられたメッセージ群である業務モデルを、前記データベースサーバにアクセスした時刻の昇順にソートするソートステップと、
   前記ソートステップによってソートされた業務モデルに基づいてシナリオを作成するシナリオ作成ステップと
   を含んだことを特徴とするシナリオ作成方法。

Images