JP6382610B2 - シミュレータシステム、ゲートウェイシステムテスト装置及びゲートウェイシステムテスト方法 - Google Patents

Description

本発明は、シミュレータシステム、ゲートウェイシステムテスト装置及びゲートウェイシステムテスト方法に係り、特に、ゲートウェイシステムの単独保守テストを可能とするシミュレータシステム、ゲートウェイシステムテスト装置及びゲートウェイシステムテスト方法に関する。

近年、業務システムの複雑化に伴い、業務システム間のインタフェースの調整は困難になっている。そこで業務システム間の仲介処理を行うゲートウェイシステムが増加している。例えば通信キャリアが全国に展開するショップにおいて顧客のサービス申込受付や契約照会などをフロントエンドのショップ端末に入力し、バックエンドの契約管理システムへ問い合わせする処理においても、ショップ端末と契約管理システムとの間にはゲートウェイシステムが稼動することで両システムのインタフェースを取り持つケースが多い。このようなフロントエンドシステムとバックエンドシステムの仲介処理を果たす業務系のゲートウェイシステムにおいて、回帰テストなどの保守テストが行われる場合がある。

特許文献１では、回帰テスト実行システムが開示されている。この回帰テスト実行システムは、概略、回帰テスト自動実行装置からのリクエストデータをアプリケーションに送信し、受信したレスポンスデータを回帰テスト自動実行装置内にある期待値と比較することで実行結果の正当性確認を可能としている。これにより保守テストにおいてテスト項目とテスト自動実行ツールを連携することにより、アプリケーションテストにおけるテストシナリオの再利用性を高めることを実現し、アプリケーション改修によるデグレードの検出などを効率化している。

特開２０１０−１６５２６７号公報

しかしながら、特許文献１はフロントエンドシステム及びバックエンドシステムとの連携を前提としたゲートウェイシステムのアプリケーションを想定しておらず、フロントエンドシステム及びバックエンドシステムが切り離された、ゲートウェイシステムが単独で動作する保守テスト環境においてはゲートウェイシステムの動作を再現することが困難である。また、ゲートウェイシステムの動作を再現するためにはフロントエンド側装置とバックエンド側装置に、それぞれテストデータを保持させることが考えられるが、フロントエンド側で設定しているテストデータ、もしくはバックエンド側で設定しているテストデータが不正（不適切）な場合、ゲートウェイシステムのデグレードによるエラーかテストデータ不正によるエラーか切り分け調査が必要となりテスト効率は悪い。さらにバックエンド側のテストデータを参照し、フロントエンド側で設定したテストデータをゲートウェイシステムが処理する場合、フロントエンド側のテストデータとバックエンド側のテストデータは相互に整合性が取れている必要がある。例えばバックエンド側に設定されている契約サービスデータに追加でフロントエンド側からサービスを申込むというテストを実行する場合、バックエンド側の契約サービステストデータとフロントエンド側の申込サービステストデータが、サービス同士の従属性や排他性などの観点で正しく設定されている必要がある。

以上の現状に鑑み、本発明は、フロントエンドシステムとバックエンドシステムの仲介処理を行うゲートウェイシステムに対し、フロントエンドシステムとバックエンドシステムを切り離して保守テストを行うシミュレータシステム、ゲートウェイシステムテスト装置及びゲートウェイシステムテスト方法を提供することを目的とする。

本発明は、フロントエンドシステムとバックエンドシステムの仲介処理を果たす業務系のゲートウェイシステムにおいて、回帰テストなどの保守テストで使用するシミュレータ方式に関するものである。

本発明の第１の解決手段によると、
フロントエンドシステムとバックエンドシステムの仲介処理を行うゲートウェイシステムをテストするシミュレータシステムであって、
前記ゲートウェイシステムと接続されるフロントエンドシミュレータ装置と、
前記ゲートウェイシステムと接続されるバックエンドシミュレータ装置と、
前記フロントエンドシミュレータ装置とバックエンドシミュレータ装置に前記テストのためのデータを設定するシミュレータデータ出力装置と
を備え、
前記シミュレータデータ出力装置は、
前記フロントエンドシミュレータ装置が前記ゲートウェイシステムに送信する第１リクエストデータに含める第１情報と、前記ゲートウェイシステムが正常な場合に該第１リクエストデータに対して該ゲートウェイシステムから受信する第１レスポンスデータの予測情報とを前記フロントエンドシミュレータ装置に設定し、
第１リクエストデータに応じて前記ゲートウェイシステムから送信される第２リクエストデータに対して前記バックエンドシミュレータ装置が返信する第２レスポンスデータに含める第２情報を、前記バックエンドシミュレータ装置に設定し、
前記フロントエンドシミュレータ装置は、前記ゲートウェイシステムに送信した第１情報を含む第１リクエストデータに応答して返信される、前記ゲートウェイシステムからの第１レスポンスデータと、設定された前記予測情報とを比較して、前記ゲートウェイシステムの正常及び異常を判定する前記シミュレータシステムが提供される。

本発明の第２の解決手段によると、
フロントエンドシステムとバックエンドシステムの仲介処理を行うゲートウェイシステムをテストするゲートウェイシステムテスト装置であって、
前記ゲートウェイシステムと接続されるフロントエンドシミュレーション部と、
前記ゲートウェイシステムと接続されるバックエンドシミュレーション部と、
前記フロントエンドシミュレーション部とバックエンドシミュレーション部に前記テストのためのデータを設定するシミュレータデータ出力部と
を備え、
前記シミュレータデータ出力部は、
前記フロントエンドシミュレーション部が前記ゲートウェイシステムに送信する第１リクエストデータに含める第１情報と、前記ゲートウェイシステムが正常な場合に該第１リクエストデータに対して該ゲートウェイシステムから受信する第１レスポンスデータの予測情報とを前記フロントエンドシミュレーション部に設定し、
第１リクエストデータに応じて前記ゲートウェイシステムから送信される第２リクエストデータに対して前記バックエンドシミュレータ部が返信する第２レスポンスデータに含める第２情報を、前記バックエンドシミュレータ部に設定し、
前記フロントエンドシミュレーション部は、前記ゲートウェイシステムに送信した第１情報を含む第１リクエストデータに応答して返信される、前記ゲートウェイシステムからの第１レスポンスデータと、設定された前記予測情報とを比較して、前記ゲートウェイシステムの正常及び異常を判定する前記ゲートウェイシステムテスト装置が提供される。

本発明の第３の解決手段によると、
フロントエンドシステムとバックエンドシステムの仲介処理を行うゲートウェイシステムをテストするゲートウェイシステムテスト方法であって、
フロントエンドシミュレータ装置とバックエンドシミュレータ装置に前記テストのためのデータを設定するシミュレータデータ出力装置は、
フロントエンドシミュレータ装置がゲートウェイシステムに送信する第１リクエストデータに含める第１情報と、ゲートウェイシステムが正常な場合に該第１リクエストデータに対して該ゲートウェイシステムから受信する第１レスポンスデータの予測情報とをフロントエンドシミュレータ装置に設定し、
第１リクエストデータに応じてゲートウェイシステムから送信される第２リクエストデータに対してバックエンドシミュレータ装置が返信する第２レスポンスデータに含める第２情報を、バックエンドシミュレータ装置に設定し、
フロントエンドシミュレータ装置は、ゲートウェイシステムに送信した第１情報を含む第１リクエストデータに応答して返信される、ゲートウェイシステムからの第１レスポンスデータと、設定された予測情報とを比較して、ゲートウェイシステムの正常及び異常を判定するゲートウェイシステムテスト方法が提供される。

本発明によれば、フロントエンドシステムとバックエンドシステムの仲介処理を行うゲートウェイシステムに対し、フロントエンドシステムとバックエンドシステムを切り離して保守テストを行うシミュレータシステム、ゲートウェイシステムテスト装置及びゲートウェイシステムテスト方法を提供することができる。

ゲートウェイシステムテストシステムの構成と、ゲートウェイシステムの通常運用時の構成を示すシステム構成図。 保守テスト実行全体フロー図。 テストシナリオ作成フロー図。 サービス内容整合性チェックフロー図。 サービス内容相互整合性チェックフロー図。 テスト実行フロー図。 サービス内容整合性チェック時のデータ関連図。 サービス内容相互整合性チェック時のデータ関連図。 シミュレーションデータ出力装置の設定画面例。 シミュレーションデータ出力装置のテスト実行結果画面例。

以下、実施例を、図面を用いて説明する。
図１は、ゲートウェイシステムテストシステムの構成と、ゲートウェイシステムの通常運用時の構成を示すシステム構成図である。ゲートウェイシステムの通常運用時と本実施例を適用した保守テスト時を示す。

本実施例のシステム構成を説明する前提として、まずゲートウェイシステムの通常運用時のシステム構成を説明する。通常運用時はオペレータが端末を含むフロントエンドシステム３１を操作し、各業務処理を行う。フロントエンドシステム３１は申込受付処理や契約照会処理などの業務処理を受け付け、ゲートウェイシステム２０へ業務処理に関するリクエストデータを送信する。さらにゲートウェイシステム２０は、バックエンドシステム３３へリクエストデータを送信し、バックエンドシステム３２からのレスポンスデータを処理することで、フロントエンドシステム３１へゲートウェイシステム２０のレスポンスデータを送信する。オペレータは一連の業務処理を実行することで予め定められた業務フローを成立させている。

保守テスト時に使用されるゲートウェイシステムテストシステム１３１は、シミュレータデータ出力装置１４１と、フロントエンドシミュレータ装置１４２と、バックエンドシミュレータ装置１４３とを備え、テスト対象のゲートウェイシステム２０に、フロントエンドシミュレータ装置１４２とバックエンドシミュレータ装置１４３を接続している。

フロントエンドシミュレータ装置１４２は、ゲートウェイシステム２０とのデータ送受信を行うＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）送受信部１５３と、ＡＰＩ設定情報１１５を入力しリクエストデータの生成とプロトコル情報の設定及びＡＰＩ送受信部１５３へリクエストデータの送信命令を出すＡＰＩ操作部１５２と、業務処理の順番が設定されている業務フロー情報１１４を入力し順番にＡＰＩ操作部１５２に処理命令を出す試験自動実行部１５１と、ゲートウェイシステムから受信したレスポンスデータが正常な値であるかをチェックするための期待値（予測情報）が設定された比較元情報１１６を入力しアサーション処理（正常／異常判定処理）を行う比較処理部１５４とを有する。

バックエンドシミュレータ装置１４３は、ゲートウェイシステム２０とのデータ送受信及びバックエンドシステム３２と同等のインタフェースを有する処理受付部１６１と、テストシナリオで設定しているキー情報に紐づく処理結果データを処理結果ＤＢ１２３より抽出する処理結果選択部１６２とを有する。

シミュレータデータ出力装置１４１は、業務フロー雛形１１１を入力して業務フロー情報１１４を出力する業務フロー情報作成部１０１と、ＡＰＩ雛形１１２を入力してＡＰＩ設定情報１１５を出力するＡＰＩ設定情報作成部１０２と、処理結果雛形１１３を入力して処理結果ＤＢ１２３にデータを出力する処理結果情報作成部１０３と、画面入出力装置１０５と、サービス従属ＤＢ１２１とサービス排他ＤＢ１２２の各情報を入力し、画面入出力装置１０５から入力したテストデータに含まれるサービス情報の整合性が取れているかチェックするデータチェック部１０４とを有する。

画面入出力装置１０５は、例えば表示部と入力部を備える。表示部は、テストシナリオ及びシミュレーションデータ等を設定するための設定画面、テスト実行結果画面等を表示する。入力部は、マウス、キーボード及びタッチパネルのいずれか又は複数で構成されることができる。
なお、図１に示す各雛形及び各情報は、適宜の記憶部に記憶されることができる。

図２は一実施形態として、保守テスト方式を実行する際の全体フローチャートを示している。

ステップ２０１では、ゲートウェイシステム２０が、ゲートウェイシステム２０の参照先をバックエンドシステム３２からバックエンドシミュレータ装置１４３に変更する。例えば、障害の発生が検知されたときに自動的に切り替わってもよいし、ゲートウェイシステムテストシステム１３１から切替指示を送信し、ゲートウェイシステム２０が切替指示に応じて参照先を切り替えてもよい。フロントエンドシミュレータ装置１４２に関しては、フロントエンドシステムと同じゲートウェイシステムの接続先に接続できる場合、保守テスト開始前から接続しておいてもよい。

ステップ２０２では、例えばシミュレータデータ出力装置１４１が、保守テストで使用するテストシナリオが存在するか確認する。例えば、テストシナリオが所定の記憶部に記憶されているか確認する。既にテストシナリオが存在する（記憶されている）場合、ステップ２０４に遷移し既存のテストシナリオを実行する。テストシナリオが未作成の場合（記憶されていない場合）、ステップ２０３のテストシナリオ作成を実施する。

ステップ２０３では、例えばシミュレータデータ出力装置１４１が、保守テストで実施したいテストシナリオを作成する。テストシナリオ作成のフローチャートを図３に示す。

ステップ２０４では、ゲートウェイシステムテストシステム１３１が、作成したテストシナリオを実行する。テスト実行のフローチャートを図６に示す。なお、テストシナリオの作成及び実行の詳細は後述する。

ステップ２０５では、例えばフロントエンドシミュレータ装置１４２が、ステップ２０４において実行される比較元情報１１６とレスポンスデータとのアサーション処理が全て正常に完了していることを確認する。アサーション処理でエラーになっている場合、ステップ２０７で原因調査及びアプリケーションの改修を行い、ステップ２０４に遷移し再びテストを実行する。一方、アサーション処理が全て正常に完了している場合はステップ２０６に遷移する。

ステップ２０６では、全ての保守テストが完了したら、ゲートウェイシステム２０がゲートウェイシステムの参照先をバックエンドシミュレータ装置１４３からバックエンドシステム３２に切り替え、通常運用時のシステム構成に戻す。

図３は一実施形態として、テストシナリオを作成する際のフローチャートを示している。ここでテストシナリオの例として、「フロントエンドシステムから申込受付処理と契約照会処理と追加申込処理を行う。なお契約照会処理と追加申込処理はバックエンドシステムの契約サービスデータを参照する。また追加申込処理は契約サービスデータに対し追加でサービスを申込む処理である」との内容を設定する。なお、テストシナリオの作成の際に、画面入出力装置１０５に設定画面（図９）を表示してもよい。

ステップ３０１では、シミュレータデータ出力装置１４１（例えばデータチェック部１０４、又は図示しないシナリオ作成部。以下同様）は、テストシナリオで使用するキー情報を指定する。例えばキー情報として、契約照会処理のリクエストデータに含める契約ＩＤを画面入出力装置１０５から入力する。契約ＩＤは、顧客氏名（ｃｕｓｔｏｍｅｒ ｎａｍｅ）でもよいし、適宜の識別子でもよいし、これらを組み合わせたものでもよい。

ステップ３０２では、シミュレータデータ出力装置１４１（例えばデータチェック部１０４）は、テストシナリオで使用する業務フローの内容と順序を画面入出力装置１０５から入力する。業務フローとは申込受付処理や契約照会処理などの業務処理の組み合わせである。今回の例では「（１）申込受付処理、（２）契約照会処理、（３）追加申込処理」という３つの業務処理を組み合わせた業務フローを入力する。

ステップ３０３では、シミュレータデータ出力装置１４１（例えばデータチェック部１０４）は、ステップ３０２で定義した業務フローに申込受付処理が含まれているかチェックする。申込受付処理が含まれている場合、申込サービス内容の定義（ステップ３０４）に遷移し、申込受付処理が含まれていない場合はステップ３０６に遷移する。

ステップ３０４では、シミュレータデータ出力装置１４１（例えばデータチェック部１０４）は、申込サービス内容を画面入出力装置１０５から入力する。申込サービス内容とは、フロントエンドシステム３１が送信するリクエストデータに含まれる、顧客が申し込むサービスの内容を示すデータであり、例えば「サービスＡ、サービスＢ、サービスＣ…を申込む」というように設定される。例えば、予め定められたサービス内容を画面入出力装置１０５に表示し、選択されたサービス内容をシミュレータデータ出力装置１４１が入力するようにしてもよい。

ステップ３０５では、シミュレータデータ出力装置１４１（例えばデータチェック部１０４）は、ステップ３０４で定義した申込サービス内容の整合性をチェックする。サービス内容整合性チェックフローを図４に示す。詳細は後述する。

ステップ３０６では、シミュレータデータ出力装置１４１（例えばデータチェック部１０４）は、ステップ３０２で定義した業務フローに契約照会処理が含まれているかチェックする。契約照会処理が含まれている場合、契約サービス内容の定義（ステップ３０７）に遷移し、契約照会処理が含まれていない場合はステップ３０９に遷移する。

ステップ３０７では、シミュレータデータ出力装置１４１（例えばデータチェック部１０４）は、照会する契約サービス内容を画面入出力装置１０５から入力する。契約サービス内容とは、バックエンドシステム３２が保持する顧客が契約しているサービスの内容を示すデータであり、例えば「サービスＡ、サービスＢ、サービスＣ…を契約している」というように設定される。

ステップ３０８では、ステップ３０７で定義した契約サービス内容の整合性をチェックする。サービス内容整合性チェックフローについては、図４を参照して後述する。

ステップ３０９では、シミュレータデータ出力装置１４１（例えばデータチェック部１０４）は、ステップ３０２で定義した業務フローに追加申込処理が含まれるかチェックする。追加申込処理が含まれている場合、追加申込サービス内容の定義（ステップ３１０）に遷移し、追加申込処理が含まれていない場合はステップ３１２に遷移する。

ステップ３１０では、シミュレータデータ出力装置１４１（例えばデータチェック部１０４）は、追加申込サービス内容を画面入出力装置１０５から入力する。追加申込サービスとはバックエンドシステム３２内に保持している契約サービス内容に対し、フロントエンドシステムから追加で申込むサービス内容であり、「サービスＸ、サービスＹ、サービスＺ…の契約にサービスＡ、サービスＢ、サービスＣ…を追加申込する」というように、契約サービス内容と申込サービス内容が設定される。なお、契約サービス内容は契約ＩＤなどの契約識別情報に対応して契約内容データベース（図示せず）に記憶し、追加申込サービス内容は、契約ＩＤと、追加申し込みするサービスの識別情報（例えばサービスＡ、サービスＢ、サービスＣ）を設定してもよい。この場合、契約サービス内容を用いる場合は、契約ＩＤに基づき契約内容データベースを参照すればよい。

ステップ３１１では、ステップ３１０で定義した追加申込サービス内容が、フロントエンド側の申込サービス内容とバックエンド側の契約サービス内容で相互に整合性が取れていることをチェックする。サービス内容相互整合性チェックフローを図５に示す。詳細は後述する。

ステップ３１２では、ステップ３０２で定義した業務フローを、業務フロー情報作成部１０１が業務フロー情報１１４としてフロントエンドシミュレータ装置１４２に出力する。このとき業務フロー雛形１１１を参照し、ステップ３０２で定義した業務フローが業務フロー雛形１１１に登録されていない場合、業務フロー情報作成部１０１は不正な業務フローと判定しエラーを画面入出力装置１０５に出力する。

ステップ３１３では、ＡＰＩ設定情報作成部１０２がリクエストデータとプロトコル情報を設定したＡＰＩ設定情報（第１情報）１１５をフロントエンドシミュレータ装置１４２に出力する。このときＡＰＩ設定情報作成部１０２は、リクエストデータのデータ構造やインタフェースのプロトコル情報が設定されたＡＰＩ雛形１１２を入力して、ステップ３０１で設定したキー情報及び、ステップ３０４とステップ３１０で設定した申込サービス内容をＡＰＩ雛形１１２に埋め込むようにしてリクエストデータを設定する。例えばＡＰＩのプロトコルとしてＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）による通信があるが、この場合リクエストデータで使用するＸＭＬのデータ構造をＡＰＩ雛形１１２に定義することで、ゲートウェイシステムが受信できるリクエストデータを作成する。

ステップ３１４では、処理結果情報作成部１０３が、バックエンド側からのレスポンスデータを設定した処理結果情報（第２情報）を、バックエンドシミュレータ装置１４３の処理結果ＤＢ１２３に出力する。このとき処理結果情報作成部１０３は、レスポンスデータのデータ構造が設定された処理結果雛形１１３を入力して、ステップ３０１で設定したキー情報及び、ステップ３０７とステップ３１０で設定した契約サービス内容を処理結果雛形１１３に埋め込むようにして処理結果データを作成する。

ステップ３１５では、シミュレータデータ出力装置１４１（例えば図示しない比較元情報作成部）が、ゲートウェイシステムから送信されるレスポンスデータの期待値を比較元情報１１６として定義し、フロントエンドシミュレータ装置１４２に設定する。比較元情報はレスポンスデータ全体である必要はなく、「処理結果コードが正常」などレスポンスデータの一部を期待値として設定してもよい。
フロントエンドシミュレータ装置１４２に設定される、レスポンスデータの期待値と、バックエンドシミュレータ装置１４３から送信されるレスポンスデータとは異なってもよい。ゲートウェイシステム２０は、バックエンドシミュレータ装置１４３からのレスポンスデータに対して予め定められた処理を実行して他のレスポンスデータを作成し、フロントエンドシミュレータ装置１４２へ送信する。フロントエンドシミュレータ装置１４２に設定される比較元情報は、バックエンドシミュレータ装置１４３に設定される処理結果情報に基づくレスポンスデータに対して、ゲートウェイシステム２０での処理を実行して得られる予測情報である。

図４は一実施形態として、サービス内容整合性チェックフロー図を示す。図４には、図３の申込サービス内容を定義する処理（ステップ３０４）、もしくは契約サービス内容を定義する処理（ステップ３０７）で定義した各サービス内容に対し、データチェック部１０４がサービス内容整合性チェックを実行する際のフローチャートを示している。例として少なくとも一部のサービス同士には従属関係と排他関係があるとし、設定したサービス内容の整合性が取れているかチェックする。サービスの従属関係とは子サービスとして定義されているサービスは前提である親サービスがなければサービスの提供ができないものとする。また親サービスはサービス内容に必須で、かつひとつ設定できるものとする。なお、本実施例では、設定できる親サービスの数はひとつとして説明するが、複数の親サービスが設定できるようにしてもよい。さらに、サービスの排他関係とはあるサービスを設定している場合は別のあるサービスは提供できないものとする。

ステップ４１１では、データチェック部１０４が、定義したサービス数分ステップ４１１のループ処理を繰り返す。例えばサービス内容が「サービスＡ、サービスＢ」と定義されている場合、サービス数は２である。また、例えばサービスＡを１番目のサービス、サービスＢを２番目のサービスとしてカウントし、ループ中は「ｉ（ｉは０＜ｉの整数）」を使用しｉ番目のサービスとしてカウントする。

ステップ４１２では、データチェック部１０４が、ｉ番目のサービスが親サービスであるかチェックする。ｉ番目のサービスが親サービスであるかチェックするために、データチェック部１０４は、サービス従属ＤＢ１２１を参照する。サービス従属ＤＢ１２１は、例えば図７（ａ）に示すように、各サービスの親サービスが記憶されている。本実施例では、親サービス自身の親サービスのフィールドはＮＵＬＬである。従って、データチェック部１０４は、サービス従属ＤＢ１２１を参照し、ｉ番目のサービスの親サービスがＮＵＬＬであれば、ｉ番目のサービスの親サービスは存在しないとし、ｉ番目のサービス自身が親サービスであると判定できる。データチェック部１０４は、ｉ番目のサービスが親サービスであった場合、ステップ４１３に遷移し、一方、ｉ番目のサービスが親サービスでない場合、ステップ４１１に遷移しｉ＋１番目のサービスについて処理をする。

ステップ４１３では、データチェック部１０４は、ステップ４１２で親サービスであると判定したサービスを親サービス情報として定義する。また、ステップ４１１に遷移しｉ＋１番目のサービスについて処理をする。

ステップ４１４では、データチェック部１０４は、ステップ４１１のループ処理後、親サービス情報が定義されているかチェックする。親サービス情報が定義されていない、もしくは親サービス情報が２つ以上定義されている場合、サービス内容不正エラー処理（ステップ４１９）に進む。親サービス情報がひとつ定義されている場合、ステップ４１５に進む。

ステップ４１５では、データチェック部１０４は、定義したサービス数分ステップ４１５のループ処理を繰り返す。上述と同様、ループ中は「ｉ（ｉは０＜ｉの整数）」を使用しｉ番目のサービスとしてカウントする。

ステップ４１６では、データチェック部１０４は、ｉ番目のサービスがステップ４１４で定義した親サービスに従属する子サービスか判定する。ｉ番目のサービスが親サービスに従属する子サービスであるかチェックするために、データチェック部１０４は、サービス従属ＤＢ１２１を参照する。ｉ番目のサービスの親サービスがステップ４１３で定義した親サービスと同一ならば、親サービスに従属する子サービスと判定してステップ４１７に遷移し、一方、ｉ番目のサービスの親サービスがステップ４１３で定義した親サービスと異なる場合、サービス内容不正エラー処理（ステップ４１９）に遷移する。

ステップ４１７では、データチェック部１０４は、ｉ番目のサービスがステップ４１８で定義した子サービス情報と排他関係にあるサービスかチェックする。ｉ番目のサービスと子サービス情報が排他関係にあるかチェックするために、データチェック部１０４は、サービス排他ＤＢ１２２を参照する。サービス排他ＤＢ１２２には、例えば図７（ｂ）に示すように、各サービスと排他関係にあるサービスが予め定義され記憶されている。データチェック部１０４は、ｉ番目のサービスに対応する排他サービスの少なくともひとつがステップ４１８で定義された子サービスと合致する場合、サービス内容不正エラー処理（ステップ４１９）に遷移する。また、子サービスがｊ（ｊは０＜ｊの整数）個定義されている場合、定義されているｊ個の子サービスとの排他関係をそれぞれチェックする。例えばｉ番目のサービスがサービスＡで、１番目の子サービス情報にサービスＢ、２番目の子サービス情報にサービスＣが定義されている場合、サービスＡとサービスＢの排他関係のチェック、サービスＡとサービスＣの排他関係のチェック、というように子サービスが２つ定義されている場合は排他関係のチェックを２回行う。

ステップ４１８では、データチェック部１０４は、ｉ番目のサービスを子サービスとして定義する。この際、ｉ番目のサービスと親サービス情報が同一の場合、ｉ番目のサービスは子サービス情報として定義しない。また既にｊ個の子サービスが定義されている場合、ｊ＋１番目の子サービスとして定義する。さらにステップ４１５に遷移し、ｉ＋１番目のサービスについて処理を実行する。

ステップ４１９では、データチェック部１０４は、サービス内容が不正であることを例えば画面入出力装置１０５に表示する。この際、どのチェック（処理）で不正と判断されたかを画面入出力装置１０５に表示する。例としてステップ４１４のチェックで不正と判定された場合、例えば「親サービス情報が定義されていない」等のエラーメッセージを表示し、ステップ４１６のチェックで不正と判定された場合、例えば「子サービスの前提サービスが定義されていない」等のエラーメッセージを表示し、ステップ４１７のチェックで不正と判定された場合、例えば「排他関係にあるサービスを定義している」等のエラーメッセージを表示する。

例として図７に「子サービスの前提サービスが定義されていない」ときのチェックと、「排他関係にあるサービスを定義している」ときのチェック時のデータ関連図を示す。この例では、サービス内容としてサービスＡ、Ｂ、Ｃが設定されている。サービス従属ＤＢ１２１を参照すると、サービスＢに対応する親サービスはＮＵＬＬであり、データチェック部１０４は、サービスＢを親サービスとして定義できる（ステップ４１２、４１３に相当）。また、サービスＡについて、サービス従属ＤＢ１２１を参照すると、対応する親サービスにサービスＢが設定されており、既に定義した親サービスと一致するため、サービスＡは子サービスとして定義できる（ステップ４１６、４１８に相当）。一方、サービスＣについては、サービス従属ＤＢ１２１を参照すると、対応する親サービスにサービスＸが設定されており、既に定義した親サービスと一致しないため、サービス内容不正エラー処理にてエラーメッセージが表示される（ステップ４１６、４１９に相当）。

また、この例では、サービス排他ＤＢ１２２には図７（ｂ）に示す情報が記憶されているものとする。初期の状態では、子サービスがまだ定義されていない。サービスＡについて、サービス排他ＤＢ１２２を参照すると、対応する排他サービスと一致する子サービスはないため、サービスＡは子サービスとして定義できる（ステップ４１７、４１８に相当）。サービスＢについては、親サービスのため子サービスとして定義しない。サービスＣについて、サービス排他ＤＢ１２２を参照すると、対応する排他サービスＡと既に定義した子サービスが一致するため、サービス内容不正エラー処理にてエラーメッセージが表示される（ステップ４１７、４１９に相当）。

図５は、サービス内容相互整合性チェックフロー図である。一実施形態として、図３の追加申込サービス内容を定義する処理（ステップ３１０）で定義したサービス内容に対し、データチェック部１０４がサービス内容の相互整合性チェックを実行する際のフローチャートを示している。サービス内容の相互整合性の例として、追加申込サービス内容に含まれる申込サービス内容と契約サービス内容の各親サービス情報は一致している必要があり、契約サービス内容の親サービス情報に従属する子サービスのみが追加可能で、かつ契約サービス内容と申込サービス内容に排他関係のサービスがないこととする。また申込サービス数のカウンタには「ｉ（ｉは、０＜ｉの整数）」を使用し説明する。

ステップ５０１では、データチェック部１０４は、上述のステップ３１０で入力した追加申込サービス内容のうち、申込サービス内容の整合性が取れているかチェックする。

ステップ５０２では、データチェック部１０４は、追加申込サービス内容のうち、契約サービス内容の整合性が取れているかチェックする。ステップ５０１及び５０２のサービス内容整合性チェックの処理は、図４のフローと同様である。

ステップ５０３では、データチェック部１０４は、追加申込サービス内容に定義されている申込サービス内容の親サービス情報と、契約サービス内容の親サービス情報が一致するかチェックする。申込サービス内容の親サービス情報は、ステップ５０１のサービス内容整合性チェックの処理で定義した親サービス情報を使用し、契約サービス内容の親サービス情報は、ステップ５０２のサービス内容整合性チェックの処理で定義した親サービス情報を使用する。申込サービス内容の親サービス情報と契約サービス内容の親サービス情報が不一致の場合、相互整合性不正エラー処理（ステップ５０７）へ遷移する。

ステップ５０４では、データチェック部１０４は、追加申込サービス内容のうち、申込サービス数分ステップ５０４のループ処理を繰り返す。

ステップ５０５では、データチェック部１０４は、ｉ番目の申込サービスが契約サービス内容に追加可能なサービスであるかチェックする。データチェック部１０４は、ｉ番目の申込サービスと契約サービス内容の親サービス情報として定義されているサービスとの従属関係をチェックするためにサービス従属ＤＢ１２１を参照する。ｉ番目の申込サービスの親サービスが契約サービス内容の親サービスと異なる場合、相互整合性不正エラー処理（ステップ５０７）に遷移する。

ステップ５０６では、データチェック部１０４は、ｉ番目の申込サービスと契約サービス内容の排他関係をチェックする。契約サービス内容にｊ（ｊは、０＜ｊの整数）個のサービスが定義されている場合、「ｉ番目の申込サービスと１番目の契約サービスの排他関係、ｉ番目の申込サービスと２番目の契約サービスの排他関係…」というようにｉ番目の申込サービスとｊ個全ての契約サービスとの排他関係をチェックする。データチェック部１０４は、申込サービスと契約サービスの排他関係をチェックするためにサービス排他ＤＢ１２２を参照する。ｉ番目の申込サービスが契約サービスと排他関係にある場合、相互整合性不正エラー処理（ステップ５０７）に遷移する。

ステップ５０７では、データチェック部１０４は、追加申込サービス内容が不正であることを示すエラーメッセージを表示する。この際、どのチェック（処理）で不正と判断されたかを画面入出力装置１０５に表示する。例えば、ステップ５０３のチェックで不正と判定された場合「親サービス情報が不一致」等のエラーメッセージを表示し、ステップ５０５のチェックで不正と判定された場合「契約サービスと従属関係のない申込サービスが定義されている」等のエラーメッセージを表示し、ステップ５０６のチェックで不正と判定された場合「契約サービスと排他関係にある申込サービスを定義している」等のエラーメッセージを表示する。

例として図８に「親サービス情報が不一致」のチェックと、「契約サービスと排他関係にある申込サービスを定義している」のチェック時のデータ関連図を示す。この例では、申込サービス内容として、サービスＡ、Ｂ、Ｃが設定され、そのうちサービスＢが親サービスであり、サービスＡ、Ｃが子サービスである。図８（ａ）の例では、契約サービス内容としてサービスＸ、Ｙ、Ｚが予め登録され、そのうちサービスＸが親サービスである。この場合、申込サービス内容と契約サービス内容の各親サービスが異なるため、エラーとなる（ステップ５０３、５０７に相当）。

図８（ｂ）の例は、契約サービス内容としてサービスＢ、Ｙ、Ｚが登録され、そのうちサービスＢが親サービスであり、サービスＹ、Ｚが子サービスである。この場合、各親サービスは一致している（ステップ５０３に相当）。一方、図８（ｂ）に例示するサービス排他ＤＢ１２２を参照すると、サービスＡと排他関係にある契約サービスはないものの、サービスＣと契約サービスＺが排他関係にあり、エラーとなる（ステップ５０６、５０７に相当）。

図６は、テスト実行のフローチャートである。図６は、一実施形態として、ゲートウェイシステム２０がフロントエンドシミュレータ装置１４２とバックエンドシミュレータ装置１４３と接続し、テストを実行する際のフローチャートを示している。テストは、ゲートウェイシステムテストシステム１３１の操作者の操作を契機に開始されてもよいし、ゲートウェイシステム２０の障害の発生が検知されたときに自動的に実行されるなど適宜の契機でもよい。なお、図６のフローチャートは、処理の順序をわかり易く説明するため、各装置での処理をまとめて図示している。

ステップ６０１〜６０６は、フロントエンドシミュレータ装置１４２の処理である。ステップ６０１では、試験自動実行部１５１は業務フロー情報１１４に定義されている業務処理の数分ステップ６０１のループ処理を行う。業務処理の数分とは、例えば業務フローに「申込受付処理、契約照会処理、追加申込処理」と業務処理が定義されている場合、申込処理を１番目の業務処理、契約照会処理を２番目の業務処理、追加申込処理を３番目の業務処理とカウントする。また業務処理数のカウンタには「ｉ（０＜ｉの整数）」を使用しｉ番目の業務処理としてカウントする。試験自動実行部１５１はＡＰＩ操作部１５２へｉ番目の業務処理を実行するよう処理命令を出す。

ステップ６０２では、ＡＰＩ操作部１５２はｉ番目の業務処理用のＡＰＩ設定情報１１５を入力し、ゲートウェイシステム２０への所定のフォームのリクエストデータ及びプロトコル情報を設定する。

ステップ６０３では、ＡＰＩ操作部１５２はＡＰＩ設定情報１１５に、業務処理間のパラメタ引継ぎ設定があるかチェックする。業務処理間のパラメタとは、例えばｘ番目の業務処理が申込受付処理であり、ｉ番目の業務処理が契約照会処理である場合、ｘ番目（ｘは、例えばｘ＜ｉの整数）の申込受付処理で取得したゲートウェイシステム２０からのレスポンスデータに含まれる申込ＩＤ等をｉ番目の契約照会処理のリクエストで使用したい場合、ｘ番目の申込受付処理のレスポンスデータに含まれる申込ＩＤを業務処理間のパラメタとして、ｉ番目の契約照会処理に渡すものである。業務処理間のパラメタ引継ぎ設定にはどの業務処理から何のデータを引き継ぎ、どのように使用するかを予め設定する。業務処理間のパラメタ引継ぎ設定がある場合、ステップ６０４に遷移し、設定がなければステップ６０５に遷移する。

ステップ６０４では、ＡＰＩ操作部１５２はパラメタ引継ぎとして設定されているｘ番目のリクエストデータから予め設定された種別のパラメタを抽出し、ｉ番目のリクエストデータの該当する埋め込み部分に抽出したパラメタを設定してリクエストデータを生成する。
ステップ６０５では、ＡＰＩ操作部１５２はＡＰＩ送受信部１５３に対し、ゲートウェイシステム２０へのリクエストデータの送信命令を出す。
ステップ６０６では、ＡＰＩ送受信部１５３はゲートウェイシステム２０へリクエストデータを送信する。

ステップ６０７〜６０８は、ゲートウェイシステム２０の処理である。ステップ６０７では、ＡＰＩ送受信部１５３からのリクエストデータを受信したゲートウェイシステム２０は、バックエンド側のデータを参照する必要がある場合はステップ６０８へ遷移し、必要がない場合はステップ６１１に遷移する。例えば契約照会処理や追加申込処理でバックエンド側の契約サービス内容を参照する場合はステップ６０８へ遷移する。

ステップ６０８では、ゲートウェイシステム２０は、バックエンド側のデータを参照するためにバックエンドシミュレータ装置１４３の処理受付部１６１へリクエストデータを送信する。例えば、ゲートウェイシステム２０は、フロントエンドシミュレータ装置１４２から受信したリクエストデータをバックエンドシミュレータ装置１４３へ転送してもよいし、所望のリスエストデータを作成してバックエンドシミュレータ装置１４３へ送信してもよい。

ステップ６０９〜６１０は、バックエンドシミュレータ装置１４３の処理である。ステップ６０９では、リクエストデータを受信した処理結果受付部１６１はリクエストデータに含まれるキー情報を処理結果選択部１６２に引数として渡す。処理結果選択部１６２はキー情報を使用し、対応する処理結果情報を処理結果ＤＢ１２３から抽出する。
ステップ６１０では、処理結果受付部１６１は、処理結果選択部１６２が抽出した処理結果情報を含むレスポンスデータをゲートウェイシステム２０へ送信する。

ステップ６１１では、ゲートウェイシステム２０は、予め定められた業務処理を実行し、フロントエンドシミュレータ装置１４２のＡＰＩ送受信部１６１へレスポンスデータを送信する。ゲートウェイシステム２０から送信されるレスポンスデータは、バックエンドシミュレータ装置１４３からのレスポンスデータが処理されたデータを含む場合があり、ゲートウェイシステム２０から送信されるレスポンスデータと、バックエンドシミュレータ装置１４３から送信されるレスポンスデータは必ずしも同一ではない。

ステップ６１２では、比較処理部１５４はＡＰＩ送受信部１５３が受信したゲートウェイシステム２０からのレスポンスデータを、比較元情報１１６と比較する。このとき、ゲートウェイシステムからのレスポンスデータが、期待値として予め設定された比較元情報１１６と異なる場合は、例えば画面入出力装置１０５にエラーを表示する。一方、レスポンスデータと比較元情報１１６が一致する場合、例えば正常である旨表示する。

ステップ６１３では、ＡＰＩ操作部１５２はＡＰＩ送受信部１５３が受信したゲートウェイシステムからのレスポンスデータを、ｉ＋１番目の業務処理へ引き継ぐ。この引き継がれたレスポンスデータは後続の業務処理のステップ６０３でパラメタ引継ぎ設定がされていた場合使用される。また、ステップ６０１に遷移しｉ＋１番目の業務処理を実行する。

図９は、シミュレーションデータ出力装置の設定画面例である。図１０は、シミュレーションデータ出力装置のテスト実行結果画面例である。
図９（ａ）に、画面入出力装置１０５に表示されるテストシナリオ設定画面の例を示す。テストシナリオ設定画面９０１は、例えば、シナリオ名設定フィールド９０１ａと、業務フロー設定フィールド９０１ｂと、キー情報設定フィールド９０１ｃと、設定完了ボタンとを含む。シナリオ名設定フィールド９０１ａには、例えば所望のシナリオ名が入力される。業務フロー設定フィールド９０１ｂは、業務フローの処理順に、申込受付処理、契約照会処理及び追加申込処理等の業務処理を設定するフィールドであり、例えば、プルダウンメニューからこれらの業務処理を選択できる。キー情報設定フィールド９０１ｃは、キー情報の種別を示すパラメタ名と、キー情報の値が入力される。このような設定画面を画面入出力装置１０５に表示することで、ゲートウェイシステムテストシステム１３１又はシミュレータデータ出力装置１４１の操作者に各情報の設定を促す。

図９（ｂ）に、画面入出力装置１０５に表示されるシミュレーションデータ設定画面の例を示す。ここでは、申込受付処理に対するシミュレーションデータの設定画面を例示する。申込受付処理に対するシミュレーションデータの設定画面９０２は、例えば、申込サービス内容（識別情報）の設定フィールド９０２ａと、申込サービス内容以外の設定フィールド９０２ｂと、パラメタ引継設定フィールド９０２ｃと、比較元情報設定フィールド９０２ｄと、設定完了ボタンとを含む。申込サービス内容の設定フィールド９０２ａは、新規に申し込むサービスが設定される。申込サービス内容以外の設定フィールド９０２ｂは、例えば、申込顧客氏名等の適宜の情報を設定するフィールドである。パラメタ引継設定フィールド９０２ｃは、他の業務処理から引き継ぐパラメタを設定するためのフィールドであり、例えば、引き継ぎ元の業務処理の識別情報と、パラメタ名が設定される。比較元情報設定フィールド９０２ｄは、例えば比較元情報を設定するフィールドであり、パラメタ名と値が設定される。

なお、契約照会処理及び追加申込処理についても、入力するデータに応じたフィールドを有する設定画面を作成して画面入出力装置１０５に表示することができる。

図１０にシミュレーションデータ出力装置のテスト実行結果画面例を示す。テスト実行結果画面１００１は、テストシナリオ設定情報フィールドと、テスト実行結果フィールドを含む。テストシナリオ設定情報フィールドには、テストに用いた業務フロー情報、キー情報等が表示される。テスト実行結果フィールドは、各業務処理に対して、比較処理結果１００１ｄの他、例えばフロントエンドシミュレータ装置１４２から送信したリクエストデータ１００１ｂ及びフロントエンドシミュレータ装置１４２が受信したレスポンスデータ１００１ｃを表示してもよい。さらに、バックエンドシミュレータ装置１４３が送信したレスポンスデータを表示してもよい。これにより、どのようなデータがやりとりされて、テストの結果が導かれたのかを操作者に提示できる。なお、上述の各画面は一例であり、他の適宜の形態でもよい。

上述の例では、ゲートウェイシステムテストシステム１３１が、シミュレータデータ出力装置１４１、フロントエンドシミュレータ装置１４２及びバックエンドシミュレータ装置１４３の別々の装置で構成されたが、ゲートウェイシステムテストシステム１３１を物理的にひとつのゲートウェイシステムテスト装置として構成してもよい。この場合、ゲートウェイシステムテスト装置は、シミュレータデータ出力装置１４１に相当するシミュレータデータ出力部と、フロントエンドシミュレータ装置１４２に相当するフロントエンドシミュレーション部と、バックエンドシミュレータ装置１４３に相当するバックエンドシミュレーション部とを備える。各部の処理は上述の実施例と同様である。

本実施例によれば、ゲートウェイシステムがフロントエンドシステムとバックエンドシステムと切り離されて単独で動作する保守テスト環境において、ゲートウェイシステムの動作を再現するためのシステム及び装置を提供でき、かつテストデータの不正を防止することでゲートウェイシステムの保守テストの効率が向上する。

以上の説明では、業務システムで使用されるゲートウェイシステムの保守テストを例にとり説明したが、各種業務システムへ適用することができる。例えば通信キャリアにおいては全国に展開するフロントエンドのショップシステムとバックエンドの契約管理システムの仲介処理を果たすゲートウェイシステムに適用でき、また金融機関においては、入金処理を行うフロントエンドシステムと顧客情報を管理するバックエンドシステムがあり、両システムの仲介処理を果たすゲートウェイシステムが存在する場合、同様のシミュレータ方式を適用することが可能である。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。さらに各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録媒体、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

（構成例）
上述の実施例は、例えば、以下のように構成することもできるが、これに限定されるものではない。

ゲートウェイシステムとのデータ送受信を実行するＡＰＩ送受信部１５３とリクエストデータを生成しＡＰＩ送受信部１５３に送信命令を出すＡＰＩ操作部１５２と業務フロー情報１１４を入力しＡＰＩ操作部１５２に処理命令を出す試験自動実行部１５１に加え、比較元情報１１６を入力しレスポンスデータのアサーション処理を実行する比較処理部１５４が連携することでテストを自動実行するフロントエンドシミュレータ装置１４２と、ゲートウェイシステムとのデータ送受信を行う処理受付部１６１と処理結果ＤＢ１２３からテストデータを抽出する処理結果選択部１６２が連携することでバックエンドシステムへの参照処理を再現するバックエンドシミュレータ装置１４３と、画面入出力装置１０５からテストデータを入力しデータチェック部１０４でテストデータの整合性をチェックしフロントエンドシミュレータ装置１４２とバックエンドシミュレータ装置１４３が入力するシミュレータデータを業務フロー情報作成部１０１とＡＰＩ設定情報作成部１０２と処理結果情報作成部１０３を使用して出力するシミュレータデータ出力装置１４１を、保守テスト時の環境に備える。

［構成例１］
フロントエンドシステムとバックエンドシステムの仲介処理を果たすゲートウェイシステムにおいて、フロントエンドシステムの代わりとなるフロントエンドシミュレータ装置（１４２）と、バックエンドシステムの代わりとなるバックエンドシミュレータ装置（１４３）と、フロントエンドシミュレータ装置（１４２）とバックエンドシミュレータ装置（１４３）が入力するデータを生成するシミュレータデータ出力装置（１４１）を使用したゲートウェイシステムの保守テストにおけるシミュレータ方式。

［構成例２］
構成例１において、フロントエンドシミュレータ装置（１４２）は業務処理の順番が設定されている業務フロー情報（１１４）と試験自動実行部（１５１）とリクエストデータとプロトコル情報が設定されたＡＰＩ設定情報（１１５）とＡＰＩ操作部（１５２）とＡＰＩ送受信部（１５３）をさらに有し、試験自動実行部（１５１）が業務フロー情報（１１４）を入力し、順番にＡＰＩ操作部（１５２）にＡＰＩ操作の処理命令を行い、ＡＰＩ操作部（１５２）はＡＰＩ設定情報（１１５）を入力し設定されているリクエストデータの送信命令をＡＰＩ送受信部（１５３）に出すことで、フロントエンドシミュレータ装置（１４２）がゲートウェイシステムとフロントエンドシステムの連携を再現するシミュレータ方式。

［構成例３］
構成例２において、フロントエンドシミュレータ装置（１４２）は比較元情報（１１６）と比較処理部（１５４）をさらに有し、期待したテスト結果であるかチェックするために、ＡＰＩ送受信部（１５３）がゲートウェイシステムから受信したレスポンスデータと期待値を設定した比較元情報（１１６）とを比較処理部（１５４）がアサーション処理することでゲートウェイシステムのデグレードを検出するシミュレータ方式。

［構成例４］
構成例１において、バックエンドシミュレータ装置（１４３）は処理受付部（１６１）と処理結果選択部（１６２）と処理結果ＤＢ（１２３）をさらに有し、ゲートウェイシステムからのリクエストデータを受信した処理受付部（１６１）は処理結果選択部（１６２）にテストシナリオで使用するキー情報を引数として渡し、処理結果選択部（１６２）は処理結果ＤＢ（１２３）からキー情報に紐づくテストデータを抽出し、処理結果受付部（１６１）がゲートウェイシステムへテストデータをレスポンスデータとして送信することでバックエンドシミュレータ装置（１４３）がゲートウェイシステムとバックエンドシステムの連携を再現するシミュレータ方式。

［構成例５］
構成例１において、シミュレータデータ出力装置（１４１）は業務フロー雛形（１１１）と業務フロー情報作成部（１０１）と画面入出力装置（１０５）を有し、業務フロー情報作成部（１０１）は、画面入出力装置（１０５）から入力した業務処理の組み合わせが業務フロー雛形（１１１）に定義されている正しい業務フローかチェックした上で、業務フロー情報（１１４）を自動生成し、フロントエンドシミュレータ装置（１４２）に出力するシミュレータ方式。

［構成例６］
構成例１において、シミュレータデータ出力装置（１４１）はＡＰＩ設定情報作成部（１０２）とＡＰＩ雛形（１１２）をさらに有し、ＡＰＩ設定情報作成部（１０２）はＡＰＩ雛形（１１２）に定義されているリクエストデータのデータ構造とプロトコルの設定情報を入力して、画面入出力装置（１０５）から入力したサービス情報とテストシナリオで使用するキー情報をゲートウェイシステムが処理できるリクエストデータの形式に変換してＡＰＩ設定情報（１１５）を生成し、フロントシミュレータ装置（１４２）に出力するシミュレータ方式。

［構成例７］
構成例１において、シミュレータデータ出力装置（１４１）は処理結果雛形（１１３）と処理結果情報作成部（１０３）をさらに有し、ゲートウェイシステムがバックエンドシステムへ参照リクエストを出した際に返却するレスポンスデータを、画面入出力装置（１０５）から入力したサービス情報とテストシナリオで使用するキー情報を、処理結果情報作成部（１０３）が処理結果雛形（１１３）のデータ構造に合わせ生成し、処理結果データとして処理結果ＤＢ（１２３）に設定するシミュレータ方式。

［構成例８］
構成例６、７において、シミュレータデータ出力装置（１４１）はデータチェック部（１０４）とサービス従属ＤＢ（１２１）とサービス排他ＤＢ（１２２）をさらに有し、フロントエンドシミュレータ装置（１４２）から送信するリクエストデータと、バックエンドシミュレータ装置（１４３）が返却するレスポンスデータの整合性、もしくはリクエストデータとレスポンスデータの相互の整合性について、データチェック部（１０４）はサービス従属ＤＢ（１２１）とサービス排他ＤＢ（１２２）を参照し、リクエストデータに含まれるサービス内容と処理結果データに含まれるサービス内容の従属関係のチェックと排他関係のチェックを実行することで、フロントエンドシミュレータ装置（１４２）とバックエンドシミュレータ装置（１４３）が有するテストデータの整合性、及び相互の整合性を確保するシミュレータ方式。

２０ ゲートウェイシステム
１３１ ゲートウェイシステムテストシステム
１４１ シミュレータデータ出力装置
１４２ フロントエンドシミュレータ装置
１４３ バックエンドシミュレータ装置
１０１ 業務フロー情報作成部
１０２ ＡＰＩ設定情報作成部
１０３ 処理結果情報作成部
１０４ データチェック部
１０５ 画面入出力装置
１５１ 試験自動実行部
１５２ ＡＰＩ操作部
１５３ ＡＰＩ送受信部
１５４ 比較処理部
１６１ 処理受付部
１６２ 処理結果選択部
１１１ 業務フロー雛形
１１２ ＡＰＩ雛形
１１３ 処理結果雛形
１１４ 業務フロー情報
１１５ ＡＰＩ設定情報
１１６ 比較元情報
１２１ サービス従属ＤＢ
１２２ サービス排他ＤＢ
１２３ 処理結果ＤＢ

Claims (11)

1. フロントエンドシステムとバックエンドシステムの仲介処理を行うゲートウェイシステムをテストするシミュレータシステムであって、
   前記ゲートウェイシステムと接続されるフロントエンドシミュレータ装置と、
   前記ゲートウェイシステムと接続されるバックエンドシミュレータ装置と、
   前記フロントエンドシミュレータ装置とバックエンドシミュレータ装置に前記テストのためのデータを設定するシミュレータデータ出力装置とを備え、
   前記シミュレータデータ出力装置は、
   前記フロントエンドシミュレータ装置が前記ゲートウェイシステムに送信する第１リクエストデータに含める第１情報と、前記ゲートウェイシステムが正常な場合に該第１リクエストデータに対して該ゲートウェイシステムから受信する第１レスポンスデータの予測情報とを前記フロントエンドシミュレータ装置に設定し、
   第１リクエストデータに応じて前記ゲートウェイシステムから送信される第２リクエストデータに対して前記バックエンドシミュレータ装置が返信する第２レスポンスデータに含める第２情報を、前記バックエンドシミュレータ装置に設定し、
   前記フロントエンドシミュレータ装置は、前記ゲートウェイシステムに送信した第１情報を含む第１リクエストデータに応答して返信される、前記ゲートウェイシステムからの第１レスポンスデータと、設定された前記予測情報とを比較して、前記ゲートウェイシステムの正常及び異常を判定する前記シミュレータシステム。
2. 前記フロントエンドシミュレータ装置に設定される、前記第１レスポンスデータの予測情報と、前記バックエンドシミュレータ装置から送信される、前記第２情報に基づく前記第２レスポンスデータとは異なる請求項１に記載のシミュレータシステム。
3. 前記ゲートウェイシステムは、前記バックエンドシミュレータ装置からの前記第２レスポンスデータに対して予め定められた処理を実行して前記第１レスポンスデータを作成し、前記フロントエンドシミュレータ装置へ送信し、
   前記フロントエンドシミュレータ装置に設定される前記予測情報は、前記バックエンドシミュレータ装置に設定される前記第２情報に基づく前記第２レスポンスデータに対して、前記ゲートウェイシステムでの前記処理を実行して得られる予測情報である請求項２に記載のシミュレータシステム。
4. 前記ゲートウェイシステムは、前記フロントエンドシミュレータ装置からの前記第１リクエストデータを受信すると、前記バックエンドシミュレータ装置へ前記第１リクエストデータに基づく前記第２リクエストデータを送信し、前記第２リクエストデータに対する前記第２レスポンスデータを前記バックエンドシミュレータ装置から受信し、前記第２レスポンスデータに対して予め定められた処理を実行して前記第１レスポンスデータを作成して前記フロントエンドシミュレータ装置に送信する請求項３に記載のシミュレータシステム。
5. 前記第１リクエストデータは、複数のサービス識別情報を含むサービスの新規申込、サービスの契約照会、又は、サービスの追加申込のリクエストデータであり、
   前記シミュレータデータ出力装置は、
   所定のサービス識別情報に対して、該サービスとともに申し込むことができない排他関係にあるサービス識別情報が予め記憶されたサービス排他データベースと、
   前記第１情報に含まれる複数のサービス識別情報に基づき前記サービス排他データベースを参照し、排他関係にあるサービス情報が前記第１情報に含まれる場合はエラーを通知するデータチェック部とを有する請求項１に記載のシミュレータシステム。
6. 前記第１リクエストデータは、複数のサービス識別情報を含むサービスの新規申込、サービスの契約照会、又は、サービスの追加申込のリクエストデータであり、
   前記シミュレータデータ出力装置は、
   親サービスの識別情報と、サービスを申し込むために親サービスが必要な子サービスのサービス識別情報に対して、該親サービスのサービス識別情報とが予め記憶されたサービス従属データベースと、
   前記第１情報に含まれる複数のサービス識別情報に基づき前記サービス従属データベースを参照して親サービスを特定し、前記第１情報に含まれる親サービス以外のサービス識別情報に基づき前記サービス従属データベースを参照して各サービス識別情報の親サービスを特定し、各親サービスが一致していない場合はエラーを通知するデータチェック部とを有する請求項１に記載のシミュレータシステム。
7. 前記第１リクエストデータは、ひとつ又は複数のサービス識別情報を含むサービスの追加申込のリクエストデータであり、
   前記シミュレータデータ出力装置は、
   所定のサービス識別情報に対して、該サービスとともに申し込むことができない排他関係にあるサービス識別情報が予め記憶されたサービス排他データベースと、
   前記第１情報に含まれるサービス識別情報に基づき前記サービス排他データベースを参照し、該サービス識別情報と排他関係にあるサービス識別情報が既に契約しているサービス識別情報に含まれる場合はエラーを通知するデータチェック部とを有する請求項１に記載のシミュレータシステム。
8. 前記第１リクエストデータは、ひとつ又は複数のサービス識別情報を含むサービスの追加申込のリクエストデータであり、
   前記シミュレータデータ出力装置は、
   親サービスの識別情報と、サービスを申し込むために親サービスが必要な子サービスのサービス識別情報に対して、該親サービスのサービス識別情報とが予め記憶されたサービス従属データベースと、
   前記第１情報に含まれる複数のサービス識別情報に基づき前記サービス従属データベースを参照して親サービスを特定し、既に契約している親サービスのサービス識別情報と一致していない場合はエラーを通知するデータチェック部とを有する請求項１に記載のシミュレータシステム。
9. 前記データチェック部は、既に契約しているサービスのサービス識別情報に基づき前記サービス従属データベースを参照して、既に契約している親サービスのサービス識別情報を特定する請求項８に記載のシミュレータシステム。
10. フロントエンドシステムとバックエンドシステムの仲介処理を行うゲートウェイシステムをテストするゲートウェイシステムテスト装置であって、
    前記ゲートウェイシステムと接続されるフロントエンドシミュレーション部と、
    前記ゲートウェイシステムと接続されるバックエンドシミュレーション部と、
    前記フロントエンドシミュレーション部とバックエンドシミュレーション部に前記テストのためのデータを設定するシミュレータデータ出力部とを備え、
    前記シミュレータデータ出力部は、
    前記フロントエンドシミュレーション部が前記ゲートウェイシステムに送信する第１リクエストデータに含める第１情報と、前記ゲートウェイシステムが正常な場合に該第１リクエストデータに対して該ゲートウェイシステムから受信する第１レスポンスデータの予測情報とを前記フロントエンドシミュレーション部に設定し、
    第１リクエストデータに応じて前記ゲートウェイシステムから送信される第２リクエストデータに対して前記バックエンドシミュレーション部が返信する第２レスポンスデータに含める第２情報を、前記バックエンドシミュレーション部に設定し、
    前記フロントエンドシミュレーション部は、前記ゲートウェイシステムに送信した第１情報を含む第１リクエストデータに応答して返信される、前記ゲートウェイシステムからの第１レスポンスデータと、設定された前記予測情報とを比較して、前記ゲートウェイシステムの正常及び異常を判定するゲートウェイシステムテスト装置。
11. フロントエンドシステムとバックエンドシステムの仲介処理を行うゲートウェイシステムをテストするゲートウェイシステムテスト方法であって、
    フロントエンドシミュレータ装置とバックエンドシミュレータ装置に前記テストのためのデータを設定するシミュレータデータ出力装置は、
    フロントエンドシミュレータ装置がゲートウェイシステムに送信する第１リクエストデータに含める第１情報と、ゲートウェイシステムが正常な場合に該第１リクエストデータに対して該ゲートウェイシステムから受信する第１レスポンスデータの予測情報とをフロントエンドシミュレータ装置に設定し、
    第１リクエストデータに応じてゲートウェイシステムから送信される第２リクエストデータに対してバックエンドシミュレータ装置が返信する第２レスポンスデータに含める第２情報を、バックエンドシミュレータ装置に設定し、
    フロントエンドシミュレータ装置は、ゲートウェイシステムに送信した第１情報を含む第１リクエストデータに応答して返信される、ゲートウェイシステムからの第１レスポンスデータと、設定された予測情報とを比較して、ゲートウェイシステムの正常及び異常を判定するゲートウェイシステムテスト方法。

Images