(57)【要約】【課題】複数のプラットフォームにより構成されたテスト対象システムにおいて、効率的にテストを行なうためのテスト工程管理システム、テスト工程管理方法及びテスト工程管理プログラムを提供する。【解決手段】クライアントツールＴ１１は、テストケース毎にテスト記述を設定するテストシナリオシート、テスト対象システムにおける電文項目に関連付けて投入電文を設定する投入電文シート、データベースの事前設定値を設定するＤＢ事前設定シート、期待値を設定するＤＢ期待値シートを設定する。そして、テスト対象システムのプラットフォームに応じた操作に変換してデータベースに設定し、投入電文シートの電文を投入し、データベースから照会結果を取得し、期待値との比較結果を出力する。【選択図】図１
2018055189.tif 000002
【特許請求の範囲】
【請求項１】
複数のプラットフォームからなるテスト対象システムにおけるテスト工程を管理する制御部を備えたテスト工程管理システムであって、
前記制御部が、
テストケース毎にテスト記述を設定するテストシナリオシートと、
前記テスト対象システムにおいて用いる電文項目を特定し、前記テストケース毎に、電文項目に関連付けて投入電文を設定する投入電文シートと、
前記テスト対象システムにおいて用いるデータベースのレイアウト情報を取得し、前記レイアウト情報に対応させて、前記データベースの事前設定値を設定するＤＢ事前設定シートと、前記テストケースに対応する期待値を設定するＤＢ期待値シートとを含むテストケース設定部から、各シートの設定値を取得し、
前記ＤＢ事前設定シートの事前設定値を、前記テスト対象システムの前記データベースに設定し、
前記テストシナリオシートのテストケースについて、前記投入電文シートの電文を前記テスト対象システムに投入し、
前記テスト対象システムの前記データベースから照会結果を取得し、前記ＤＢ期待値シートに記録された期待値との比較結果を出力する検証部を備えることを特徴とするテスト工程管理システム。
【請求項２】
前記テストケース設定部には、更に、前記投入電文に対応する応答電文期待値を設定する電文期待値シートが含まれており、
前記検証部が、更に、前記投入電文シートの電文を前記テスト対象システムに投入し、前記テスト対象システムにおいて応答電文を取得し、前記電文期待値シートに記録された期待値との比較結果を出力することを特徴とする請求項１に記載のテスト工程管理システム。
【請求項３】
前記テストケース設定部から、前記データベースの構成情報を取得し、
前記構成情報に基づいたコマンドを用いて、前記ＤＢ事前設定シートに記録された事前設定値を前記データベースに設定し、
前記検証部は、前記構成情報に基づいたコマンドを用いて、前記データベースから照会結果を取得することを特徴とする請求項１又は２に記載のテスト工程管理システム。
【請求項４】
複数のプラットフォームからなるテスト対象システムにおけるテスト工程を管理する制御部を備えたテスト工程管理システムを用いて、テスト工程を管理する方法であって、
前記制御部が、
テストケース毎にテスト記述を設定するテストシナリオシートと、
前記テスト対象システムにおいて用いる電文項目を特定し、前記テストケース毎に、電文項目に関連付けて投入電文を設定する投入電文シートと、
前記テスト対象システムにおいて用いるデータベースのレイアウト情報を取得し、前記レイアウト情報に対応させて、前記データベースの事前設定値を設定するＤＢ事前設定シートと、前記テストケースに対応する期待値を設定するＤＢ期待値シートとを含むテストケース設定部から、各シートの設定値を取得し、
前記ＤＢ事前設定シートの事前設定値を、前記テスト対象システムの前記データベースに設定し、
前記テストシナリオシートのテストケースについて、前記投入電文シートの電文を前記テスト対象システムに投入し、
前記テスト対象システムの前記データベースから照会結果を取得し、前記ＤＢ期待値シートに記録された期待値との比較結果を出力する検証処理を実行することを特徴とするテスト工程管理方法。
【請求項５】
複数のプラットフォームからなるテスト対象システムにおけるテスト工程を管理する制御部を備えたテスト工程管理システムを用いて、テスト工程を管理するプログラムであって、
前記制御部を、
テストケース毎にテスト記述を設定するテストシナリオシートと、
前記テスト対象システムにおいて用いる電文項目を特定し、前記テストケース毎に、電文項目に関連付けて投入電文を設定する投入電文シートと、
前記テスト対象システムにおいて用いるデータベースのレイアウト情報を取得し、前記レイアウト情報に対応させて、前記データベースの事前設定値を設定するＤＢ事前設定シートと、前記テストケースに対応する期待値を設定するＤＢ期待値シートとを含むテストケース設定部から、各シートの設定値を取得し、
前記ＤＢ事前設定シートの事前設定値を、前記テスト対象システムの前記データベースに設定し、
前記テストシナリオシートのテストケースについて、前記投入電文シートの電文を前記テスト対象システムに投入し、
前記テスト対象システムの前記データベースから照会結果を取得し、前記ＤＢ期待値シートに記録された期待値との比較結果を出力する検証部として機能させることを特徴とするテスト工程管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のプラットフォームにより構成されたテスト対象システムにおいて、テストを行なうためのテスト工程管理システム、テスト工程管理方法及びテスト工程管理プログラムに関する。
【背景技術】
【０００２】
システムを構築する場合、様々なテストが行なわれる。これらテストには、例えば、各モジュールをテストする単体テストや、各モジュールを結合させた状態でテストを実施する統合テスト、ユーザによる受け入れテストや本番環境でのテストを実施する運用テスト等がある。
【０００３】
そして、複数のモジュールから構成されたシステムにおいて、テスト実施時の負担を軽減することにより、効率的に結合テストを行なうための結合テストシステムが検討されている（例えば、特許文献１を参照。）。この文献記載の技術においては、アプリケーション実行環境上で必要な共通制御処理を行なう共通制御モジュールを加工して生成された汎用ドライバは、共通制御処理の実行後、外部インターフェイスから取得したモジュール名の検証モジュールをコールする。この検証モジュールは、データベース（ＤＢ）初期設定後にテスト対象の個別業務モジュールをコールする。個別業務モジュールは、アプリケーション実行環境と同一のテスト環境において、テストデータ及びＤＢ設定値を用いて個別業務処理を実行する。個別業務モジュールからの出力値を取得した検証モジュールは、出力結果を検証する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−１８６７９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、テスト対象システムが、複数のプラットフォームから構成されている場合がある。更に、テスト対象システムにおいて複数のデータベースが用いられることもあり、データベースによってレイアウトが異なることもある。このように構成されたテスト対象システムにおいて、個別にテストケースを設定していたのでは、環境による制約の影響が大きく、テストに時間や労力がかかり、効率的なテストを実現することが困難である。
【０００６】
本発明は、上記問題点を解決するためになされたものであり、複数のプラットフォームにより構成されたテスト対象システムにおいて、効率的にテストを行なうためのテスト工程管理システム、テスト工程管理方法及びテスト工程管理プログラムを提供することにある。
【課題を解決するための手段】
【０００７】
・上記課題を解決するテスト工程管理システムでは、複数のプラットフォームからなるテスト対象システムにおけるテスト工程を管理する制御部を備える。そして、前記制御部が、テストケース毎にテスト記述を設定するテストシナリオシートと、前記テスト対象システムにおいて用いる電文項目を特定し、前記テストケース毎に、電文項目に関連付けて投入電文を設定する投入電文シートと、前記テスト対象システムにおいて用いるデータベースのレイアウト情報を取得し、前記レイアウト情報に対応させて、前記データベースの事前設定値を設定するＤＢ事前設定シートと、前記テストケースに対応する期待値を設定するＤＢ期待値シートとを含むテストケース設定部から、各シートの設定値を取得し、前記ＤＢ事前設定シートの事前設定値を、前記テスト対象システムの前記データベースに設定し、前記テストシナリオシートのテストケースについて、前記投入電文シートの電文を前記テスト対象システムに投入し、前記テスト対象システムの前記データベースから照会結果を取得し、前記ＤＢ期待値シートに記録された期待値との比較結果を出力する検証部を備える。これにより、複数のプラットフォームからなる環境においても、各シートにより統一されたインターフェイスで、テストを実行し、データベースの検証を行なうことができる。
【０００８】
・上記テスト工程管理システムにおいて、前記テストケース設定部には、更に、前記投入電文に対応する応答電文期待値を設定する電文期待値シートが含まれており、前記検証部が、更に、前記投入電文シートの電文を前記テスト対象システムに投入し、前記テスト対象システムにおいて応答電文を取得し、前記電文期待値シートに記録された期待値との比較結果を出力することが好ましい。これにより、複数のプラットフォームからなる環境においても、各シートにより統一されたインターフェイスで、テストを実行し、応答電文の検証を行なうことができる。
【０００９】
・上記テスト工程管理システムにおいて、前記テストケース設定部から、前記データベースの構成情報を取得し、前記構成情報に基づいたコマンドを用いて、前記ＤＢ事前設定シートに記録された事前設定値を前記データベースに設定し、前記検証部は、前記構成情報に基づいたコマンドを用いて、前記データベースから照会結果を取得することが好ましい。これにより、データベースの構成情報を用いて、所望のコマンド操作を行なうことができる。
【発明の効果】
【００１０】
本発明によれば、複数のプラットフォームにより構成されたテスト対象システムにおいて、効率的にテストを行なうことができる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態のシステム概略図。
【図２】本実施形態の商品サービス検証におけるシステム概略図。
【図３】本実施形態の商品サービス検証におけるＤＢアクセスの説明図。
【図４】本実施形態の商品サービス検証におけるクライアントツール（テスト実行前）の説明図。
【図５】本実施形態の商品サービス検証におけるクライアントツール（テスト実行後）の説明図。
【図６】本実施形態の商品サービス検証におけるフローの説明図。
【図７】本実施形態の商品サービス検証におけるテストシナリオシートの説明図。
【図８】本実施形態の商品サービス検証におけるクライアントツールの説明図であって、（ａ）は投入電文シート、（ｂ）は応答電文期待値シート、（ｃ）はＤＢ事前設定シート、（ｄ）はＤＢ期待値シート、（ｅ）は実行結果＿電文シート、（ｆ）は実行結果＿ＤＢシートの説明図。
【図９】本実施形態の商品サービス検証における結果表示の説明図。
【図１０】本実施形態の取引サービス検証におけるシステム概略図。
【図１１】本実施形態の取引サービス検証におけるＤＢアクセスの説明図。
【図１２】本実施形態の取引サービス検証におけるクライアントツール（テスト実行前）の説明図。
【図１３】本実施形態の取引サービス検証におけるクライアントツール（テスト実行後）の説明図。
【図１４】本実施形態の取引サービス検証におけるフローの説明図。
【図１５】本実施形態の取引サービス検証におけるテストシナリオシートの説明図。
【図１６】本実施形態の取引サービス検証におけるクライアントツールの説明図であって、（ａ）は電文データ仕様書シート、（ｂ）は投入電文シート、（ｃ）は応答電文期待値シート、（ｄ）はＤＢ期待値シートの説明図。
【図１７】本実施形態の取引サービス検証における結果表示の説明図。
【発明を実施するための形態】
【００１２】
以下、本発明を具体化した実施形態を図１〜図１７に従って説明する。ここでは、顧客との取引を管理する取引システムのテストを行なう場合、商品サービス検証、ＦＤＬ検証、取引サービス検証を行なう。本実施形態では、商品サービス検証、取引サービス検証を説明する。
【００１３】
（取引システムの概要）
図１を用いて、テストに用いる取引システムの概要を説明する。取引システムは、チャネル１０、メインＨＵＢ２０，４０、取引共通システム３０、プロダクト層５０から構成される。このメインＨＵＢ２０，４０は、電文を中継するコンピュータシステムであり、それぞれ第１階層、第２階層によって構成される。本実施形態では、取引共通システム３０、メインＨＵＢ４０、プロダクト層５０がテスト対象である。
【００１４】
チャネル１０は、店舗端末、現金自動預払機（ＡＴＭ）、インターネットバンキングサーバ等、顧客との取引を受け付けるシステムである。
メインＨＵＢ２０は、チャネル１０から取得した要求電文を取引共通システム３０に中継するとともに、取引共通システム３０から取得した応答電文をチャネル１０に返信するコンピュータシステム（フロント接続システム）である。
【００１５】
取引共通システム３０は、顧客との取引において共通的に行なわれる処理（共通業務）を管理するコンピュータシステムである。この取引共通システムは、メインフレーム（第１のプラットフォーム）により構成され、共通業務としては、例えば、取引メイン、行内勘定、流動性預金、内国為替、ＣＩＦ（顧客番号）、手数料等の管理を行なう。
【００１６】
メインＨＵＢ４０は、取引共通システム３０から取得した要求電文をプロダクト層５０に中継するとともに、プロダクト層５０から取得した応答電文を取引共通システム３０に返信するコンピュータシステム（バックエンド接続システム）である。
【００１７】
プロダクト層５０は、金融機関が提供する各商品を管理するコンピュータシステムである。このプロダクト層５０は、異なるシステムプロバイダから提供された複数のオープン環境システムにより構成される。例えば、第２のプラットフォームであるオープン環境システム５０ａにおいては、融資、外国、為替、信託等で用いられる商品サービスを管理する。また、第３のプラットフォームであるオープン環境システム５０ｂにおいては、定期性預金で用いられる商品サービスを管理する。
【００１８】
本実施形態では、テストのために、クライアント端末Ｔ１、テスト管理サーバＴ２を用いる。
クライアント端末Ｔ１は、テスト担当者が使用するコンピュータ端末であり、制御部、キーボードやポインティングデバイス等からなる入力部や、ディスプレイ等からなる出力部を備えている。
【００１９】
更に、このクライアント端末Ｔ１は、制御部において、クライアントツールＴ１１を起動する。このクライアントツールＴ１１は、後述するように、表計算ファイルによって構成される。そして、このクライアントツールＴ１１は、テスト工程管理システムを利用するためのユーザインターフェースであり、テスト担当者によってテスト内容に関する情報が設定される。更に、クライアントツールＴ１１には、各テストの検証結果が記録される。
【００２０】
テスト管理サーバＴ２は、クライアントツールＴ１１によって設定されたテストケースをコントロールするコンピュータシステムである。このテスト管理サーバＴ２は、シナリオ制御シェルＴ２１、キャプチャ開始シェルＴ２２、キャプチャ停止シェルＴ２３、リポジトリＴ２４等を備えている。更に、テスト管理サーバＴ２は、取引サービス検証時のテスト結果を、テストケースを特定する情報（テストケースＩＤ）に関連付けて保存するテスト結果記憶部（図示せず）を備えている。
【００２１】
シナリオ制御シェルＴ２１は、検証部として機能し、クライアント端末Ｔ１のクライアントツールＴ１１で作成されたテストケースに従って、商品サービス検証、取引サービス検証等の実施を制御する。テストケースには、後述するように、ＤＢデータ準備、エビデンス取得（ＤＢの事前事後照会、電文、取引ログ等の取得、取得データの整形等）の検証に付随する処理についても実行する。
【００２２】
キャプチャ開始シェルＴ２２は、クライアントツールＴ１１からの電文キャプチャ取得要求に基づいて、取引共通システム３０に対して、電文キャプチャのセットアップを依頼する。このセットアップにより、取引共通システム３０内の機能に基づいて、所定の電文がキャプチャされる。このキャプチャ開始シェルＴ２２は、初回テスト時に打鍵により発生した電文をキャプチャする場合に用いる。そして、キャプチャされた電文は、後述するリポジトリＴ２４に保存され、再テスト時に用いる電文を作成する場合に再利用される。具体的には、キャプチャされた電文における電文項目毎の項目値を設定した電文データ仕様書の作成に利用する。
【００２３】
キャプチャ停止シェルＴ２３は、クライアントツールＴ１１からの電文キャプチャ停止要求に基づいて、取引共通システム３０に対して、取得電文の後処理を依頼する。
リポジトリＴ２４は、店舗端末、現金自動預払機（ＡＴＭ）等での打鍵により発生した電文をキャプチャした場合に一時的に保存する記憶部である。
【００２４】
制御シェルＴ３は、取引共通システム３０のテスト管理サーバＴ２に対するインターフェイス機能部である。この制御シェルＴ３は、テスト管理サーバＴ２から取引共通システム３０へのリクエストを中継する。そして、制御シェルＴ３は、テスト管理サーバＴ２からのリクエストに応じて、キャプチャの開始、停止、テストケースの実行、スタックテーブルのリダイレクト等のサブ機能を実現する。
更に、プロダクト層５０には、ローカルシェルＴ６（シェルスクリプト）を設ける。制御シェルＴ３は、後述するように、ローカルシェルＴ６を介して、ＤＢにアクセスする。
【００２５】
また、商品サービス検証や取引サービス検証においては、取引共通システム３０内に各種ドライバやスタブを設ける。本実施形態では、クライアントツールＴ１１、各種シェル、各種ドライバ、各種スタブ等、テストに必要な機能部をまとめてテスト工程管理システムと呼ぶ。なお、各種ドライバ、各種スタブの詳細については、各検証において説明する。
【００２６】
（商品サービス検証）
次に、図２を用いて、商品サービス検証を説明する。この場合、取引共通システム３０におけるＨＵＢコネクト３１、業務コンポーネント３５を用いる。この商品サービス検証においては、取引共通システム３０の業務コンポーネント３５からの応答電文、業務コンポーネント３５の業務ＤＢが検証対象である。
【００２７】
ＨＵＢコネクト３１は、取引共通システム３０において、メインＨＵＢ２０に接続されて、電文の転送を管理する機能部である。
業務コンポーネント３５は、共通業務を管理する機能部である。
更に、テストのために、ＭＱドライバ６１、商品サービスドライバ６２を用いる。
ＭＱドライバ６１は、チャネル１０、メインＨＵＢ２０の動作のシミュレーションを行ない、要求電文をＨＵＢコネクト３１に送信したり、応答電文を受信したりするメッセージキュー方式のドライバ（テスト用の仮の上位階層モジュール）である。
【００２８】
商品サービスドライバ６２は、ＨＵＢコネクト３１から取得した電文を、商品サービス検証用リージョンの業務コンポーネント３５に投入するドライバである。
商品サービス検証時には、ＭＱドライバ６１を、ＨＵＢコネクト３１に接続する。そして、ＭＱドライバ６１から、商品サービスドライバ６２を経由して、商品サービス要求電文を、テスト対象の業務コンポーネント３５に投入する。
【００２９】
この場合、テスト対象の業務コンポーネント３５が応答する商品サービス応答電文のキャプチャを行なう。更に、業務コンポーネント３５における業務ＤＢのＤＢ値のキャプチャを行なう。
【００３０】
キャプチャした応答電文及びＤＢ値について、期待値と比較検証し、検証結果をクライアント端末Ｔ１のディスプレイに表示する。検証結果が期待値と一致していることを確認できた場合には、テストを終了する。一方、検証結果が期待値と相違がある場合には、テスト担当者は相違した値を目視で確認する。
【００３１】
（商品サービス検証におけるＤＢアクセス方式）
次に、図３を用いて、商品サービス検証におけるＤＢアクセス方式を説明する。
商品サービス検証では、テスト工程管理システムにおいて、クライアントツールＴ１１、シナリオ制御シェルＴ２１、制御シェルＴ３、変換部Ｔ５を用いる。本実施形態では、取引共通システム３０には、リレーショナルＤＢ、階層型ＤＢが設けられている。階層型ＤＢとしては、例えばＩＭＳ−ＤＢ（商品名）がある。
【００３２】
クライアントツールＴ１１には、商品サービス検証に必要なテストケースを設定する。そして、クライアントツールＴ１１において設定されたテストケースに基づいて、シナリオ制御シェルＴ２１、制御シェルＴ３を制御する。
【００３３】
制御シェルＴ３は、リレーショナルＤＢに、直接的にアクセスする。また、制御シェルＴ３は、変換部Ｔ５を介して、階層型ＤＢにアクセスする。
変換部Ｔ５は、メインフレームのデータを他の環境のシステムで利用可能なデータに変換する処理を実行する。例えば、変換部Ｔ５として、ＩＢＭ社のクラシック・フェデレーション（商品名）を用いることにより、階層型ＤＢに応じたコマンドにより操作を行なうことができる。
【００３４】
（商品サービス検証で用いるクライアントツール）
次に、図４、図５を用いて、商品サービス検証におけるクライアントツールＴ１１を説明する。
【００３５】
図４に示すように、テスト実行前においては、クライアントツールＴ１１には、表紙シート８００、テストシナリオシート８０１と、投入電文シート８０２、応答電文期待値シート８０３、ＤＢ事前設定シート８０４、ＤＢ期待値シート８０５を含んで構成される。ここでは、テストシナリオシート８０１〜ＤＢ期待値シート８０５がテストケース設定部として機能する。
【００３６】
表紙シート８００には、テストシナリオ、投入電文、応答電文期待値、ＤＢ事前設定、ＤＢ期待値の各シートへのリンクが設定されている。更に、表紙シート８００において、取引ログの取得の要否、モジュールトレースの取得の要否を設定する。
【００３７】
図５に示すように、テスト実行後においては、クライアントツールＴ１１には、表紙シート８００〜ＤＢ期待値シート８０５の他に、実行結果＿電文シート８０６、実行結果＿ＤＢシート８０７を含んで構成される。そして、表紙シート８００には、テストシナリオシート８０１〜実行結果＿ＤＢシート８０７へのリンクが設定されている。
【００３８】
（商品サービス検証におけるフロー）
次に、図６を用いて、商品サービス検証におけるフローを説明する。
テスト工程管理システムは、テストシナリオの作成処理を実行する（ステップＳ１−１）。ここでは、クライアントツールＴ１１を用いて、テストシナリオシート８０１を設定する。
【００３９】
図７に示すように、テストシナリオシート８０１には、テストシナリオが表形式で記載される。このテストシナリオには、テストケースＩＤ（テストケースを特定する情報）に関連付けて、テストケース定義、テストケースの内容を設定する。
テストケース定義においては、シナリオのステップ毎に実行する内容が記載され、「ステップＩＤ」、「テスト記述」、「実行」、「結果（応答電文、ＤＢ）」が記録されるコラムが設けられている。「ステップＩＤ」においては、各テストケースの実行順番が記録される。「テスト記述」においては、テスト担当者が任意の記述を行なうことができる。「実行」においては、テスト実行時に実行対象のステップを選択することができる。「結果」においては、応答電文、ＤＢ値の検証結果が表示される。
【００４０】
次に、テスト工程管理システムは、投入電文設定・ＤＢ事前設定処理を実行する（ステップＳ１−２）。ここでは、クライアントツールＴ１１を用いて、表紙シート８００において、投入電文やＤＢ事前の設定指示が入力された場合、投入電文シート８０２、ＤＢ事前設定シート８０４を、クライアント端末Ｔ１のディスプレイに表示する。
【００４１】
図８（ａ）に示すように、投入電文シート８０２には、表形式で、商品サービス要求電文の電文レイアウト情報が予め設定されており、各テストステップの投入電文についての電文項目（フィールド）単位に項目値を設定する。
【００４２】
図８（ｃ）に示すように、ＤＢ事前設定シート８０４には、表形式で、テスト対象のテーブルのＤＢレイアウト情報が予め設定されており、各フィールドに対して、キー（照会キー）、事前設定の設定値（初期値）を設定する。
【００４３】
次に、テスト工程管理システムは、応答電文期待値設定・ＤＢ期待値設定処理を実行する（ステップＳ１−３）。ここでは、クライアントツールＴ１１を用いて、表紙シート８００において、応答電文やＤＢの期待値設定指示が入力された場合、応答電文期待値シート８０３、ＤＢ期待値シート８０５を、クライアント端末Ｔ１のディスプレイに表示する。
【００４４】
図８（ｂ）に示すように、応答電文期待値シート８０３には、表形式で、商品サービス要求電文の電文レイアウト情報が予め設定されており、各テストステップの応答電文についての電文項目（フィールド）単位に、検証タイプ、期待値を設定する。
【００４５】
図８（ｄ）に示すように、ＤＢ期待値シート８０５には、表形式で、テスト対象のテーブルのＤＢレイアウト情報が予め設定されている。そして、ＤＢレイアウトの各フィールドに対して、各テストステップで商品サービス電文を投入する際の前後の照会を実施するためのキー（照会キー）と、実行後の期待値を設定する。
【００４６】
次に、テスト工程管理システムは、テスト実行処理を実行する（ステップＳ１−４）。ここでは、クライアントツールＴ１１において、テストケースの実行指示が入力された場合、シナリオ制御シェルＴ２１は、テストシナリオシート８０１に基づいて、制御シェルＴ３を用いて、各ＤＢにＤＢ事前設定シート８０４に記録されたＤＢ値を、ＤＢの種類（構成情報）に応じたコマンドにより設定する。そして、シナリオ制御シェルＴ２１は、テストシナリオシート８０１に基づいて、制御シェルＴ３を介して、ＭＱドライバ６１から商品サービス電文を投入し、テストを実行する。この場合、応答電文期待値シート８０３、ＤＢ期待値シート８０５に設定されている応答電文やＤＢ値をキャプチャし、テストケースＩＤに関連付けて、テスト結果記憶部に記録する。
【００４７】
次に、テスト工程管理システムは、応答電文検証・ＤＢ検証処理を実行する（ステップＳ１−５）。ここでは、テスト結果記憶部に記録された応答電文の項目値やＤＢ値と、応答電文期待値シート８０３、ＤＢ期待値シート８０５に設定されている期待値とを比較する。そして、検証結果を記録した実行結果＿電文シート８０６、実行結果＿ＤＢシート８０７を生成し、クライアントツールＴ１１に記録する。
【００４８】
図８（ｅ）に示すように、実行結果＿電文シート８０６には、表形式で、商品サービス要求電文の電文レイアウト情報が設定されており、各テストステップの投入電文についての電文項目（フィールド）単位に項目値を記録する。そして、電文レイアウトの各フィールドに対して、検証タイプ、テストステップの期待値、結果が記録される。結果には、キャプチャデータと判定結果（一致又は不一致）を記録する。
【００４９】
図８（ｆ）に示すように、実行結果＿ＤＢシート８０７には、表形式で、テスト対象のテーブルのＤＢレイアウト情報が設定されている。そして、ＤＢレイアウトの各フィールドに対して、キー、テストステップの期待値、結果を記録する。結果には、事後照会結果と判定結果（一致又は不一致）が記録される。
【００５０】
更に、テスト工程管理システムは、取引共通システム３０に記録されたＪＯＢＬＯＧ、ＳＹＳＬＯＧ、取引ログ、モジュールトレースを取得する。そして、クライアントツールＴ１１において、実行ステータス照会の選択ボタンを出力する。この選択ボタンが選択された場合、クライアントツールＴ１１は、クライアント端末Ｔ１のディスプレイに検証結果を表示する。
【００５１】
図９に示すように、商品サービス検証の結果表示においては、実行ステータス照会に対して、応答電文期待値との比較結果、ＤＢの比較結果、ＪＯＢＬＯＧ、ＳＹＳＬＯＧ、取引ログ、モジュールトレースが記録される。応答電文期待値との比較結果には、全体の検証結果、データ項目単位の検証結果が含まれる。また、ＤＢの比較結果には、全体の検証結果、データ項目単位の検証結果が含まれる。
【００５２】
（取引サービス検証）
次に、図１０を用いて、取引サービス検証を説明する。この場合、取引共通システム３０におけるＨＵＢコネクト３１、営業店端末固有３２、取引メイン３３、ＭＤＦ３４、業務コンポーネント３５、ＨＵＢコネクト３６を用いる。更に、メインＨＵＢ４０、プロダクト層５０、ＡＭＬＣ６０を用いる。この取引サービス検証においては、取引共通システム３０のＭＤＦ３４において送受信される要求電文、応答電文、業務コンポーネント３５における業務ＤＢ、プロダクト層５０における業務ＤＢが検証対象である。
【００５３】
ここで、営業店端末固有３２は、チャネル１０における営業店端末から要求電文を受信した場合に、この営業店端末独自の共通業務処理を実行する。
取引メイン３３は、共通業務において処理が必要な業務コンポーネント３５を特定し、各業務コンポーネント３５に対する要求電文を送信するとともに、業務コンポーネント３５からの応答電文を取得する。
【００５４】
ＨＵＢコネクト３６は、取引共通システム３０において、メインＨＵＢ４０に接続されて、電文の転送を管理する機能部である。
ＭＤＦ３４は、複数のシステムを統合したときに必要となる要求電文のデータ移送、配信、複数システム間の連携、メッセージの変換を行なう機能部である。
【００５５】
ＡＭＬＣ６０は、アンチマネーロンダリングを管理する階層型ＤＢである。
更に、テストのために、ＭＱドライバ６１、商品サービススタブ７２、ＭＱスタブ７３、ＩＣＡＬスタブ７４を用いる。
【００５６】
ＭＱドライバ６１は、チャネル１０、メインＨＵＢ２０の動作のシミュレーションを行ない、ＨＵＢコネクト３１との間で要求電文、応答電文の送受信を行なうドライバである。
【００５７】
商品サービススタブ７２は、取引サービス検証において、取引共通システム３０内の業務コンポーネント３５のスタブ（テスト用の仮の下位階層モジュール）である。商品サービススタブ７２は、ＭＤＦ３４から要求電文を受信し、応答電文を返信する。
【００５８】
ＭＱスタブ７３は、メインＨＵＢ４０、プロダクト層５０の動作のシミュレーションを行ない、ＨＵＢコネクト３６との間で要求電文、応答電文の送受信を行なうスタブである。
ＩＣＡＬスタブ７４は、ＭＤＦ３４から、階層型ＤＢであるＩＭＳ（登録商標）を呼び出すスタブである。
【００５９】
取引サービス検証では、再テスト時およびリグレッションテスト時に自動実行・自動検証を実現するため、キャプチャ開始シェルＴ２２、キャプチャ停止シェルＴ２３を用いて、初回テスト時は再テスト時に備え電文をキャプチャする。
【００６０】
初回テスト時においては、キャプチャ開始シェルＴ２２を起動し、各チャネル１０の端末から打鍵し、電文をキャプチャし、キャプチャ停止シェルＴ２３を起動する。キャプチャされた電文は、リポジトリＴ２４に保存され、再テスト時の電文として再利用される。
再テスト時には、ＭＱドライバ６１から取引サービス要求電文を投入する。テスト対象のＭＤＦ３４から取引サービスについての要求電文、プロダクト層５０からの応答電文をキャプチャする。更に、プロダクト層５０の業務ＤＢのＤＢ値についてもキャプチャする。
【００６１】
キャプチャした応答電文及び業務ＤＢのＤＢ値について、期待値と比較検証し、検証結果をクライアント端末Ｔ１のディスプレイに表示する。検証結果が期待値と一致していることを確認できた場合には、テストを終了する。一方、検証結果が期待値と相違がある場合には、テスト担当者は相違した値を目視で確認する。
【００６２】
（取引サービス検証におけるＤＢアクセス）
次に、図１１を用いて、取引サービス検証におけるＤＢアクセスを説明する。
取引サービス検証では、テスト工程管理システムにおいて、クライアントツールＴ１１、シナリオ制御シェルＴ２１、制御シェルＴ３、変換部Ｔ５、ローカルシェルＴ６を用いる。前述したように、取引共通システム３０には、プラットフォームに応じて、リレーショナルＤＢ、階層型ＤＢが設けられている。また、プロダクト層５０には、リレーショナルＤＢが設けられている。
【００６３】
クライアントツールＴ１１には、取引サービス検証に必要なテストケースが記録されている。そして、クライアントツールＴ１１において設定されたテストケースに基づいて、シナリオ制御シェルＴ２１、制御シェルＴ３を制御する。
【００６４】
制御シェルＴ３は、リレーショナルＤＢに、直接的にアクセスする。また、制御シェルＴ３は、変換部Ｔ５を介して、階層型ＤＢにアクセスする。また、制御シェルＴ３は、ローカルシェルＴ６を介して、プロダクト層５０のリレーショナルＤＢにアクセスする。
【００６５】
（取引サービス検証で用いるクライアントツール）
次に、図１２、図１３を用いて、取引サービス検証におけるクライアントツールＴ１１を説明する。
【００６６】
図１２に示すように、テスト実行前においては、テストシナリオシート９００、取引サービス呼出シート９０１、ＤＢ操作シート９０２、ＤＢ照会シート９０３を含んで構成される。
【００６７】
テストシナリオシート９００には、取引サービス呼出シート９０１〜ＤＢ照会シート９０３の各シートへのリンクが設定されている。更に、テストシナリオシート９００において、キャプチャレベル（キャプチャする電文の取得箇所）、取引ログの取得の要否、フローダンプの取得の要否を設定する。
【００６８】
取引サービス呼出シート９０１には、電文データ仕様書シート９０４へのリンクが設定されている。更に、電文データ仕様書シート９０４には、投入電文シート９０５、応答電文期待値シート９０６へのリンクが設けられている。
【００６９】
ＤＢ操作シート９０２には、ＤＢ事前設定情報が記録されている。
ＤＢ照会シート９０３には、ＤＢ期待値シート９０７へのリンクが設けられている。
ここでは、ＤＢ操作シート９０２、電文データ仕様書シート９０４がテストケース設定部として機能する。
【００７０】
図１３に示すように、テスト実行後には、テストシナリオシート９００、取引サービス呼出シート９０１、ＤＢ照会シート９０３、電文データ仕様書シート９０４、応答電文期待値シート９０６、ＤＢ期待値シート９０７には、取引サービス検証における実行結果が記録される。
【００７１】
（取引サービス検証におけるフロー）
次に、図１４を用いて、取引サービス検証におけるフローを説明する。
まず、テスト工程管理システムは、テストシナリオの作成処理を実行する（ステップＳ２−１）。ここでは、クライアントツールＴ１１において、テストシナリオシート９００を設定する。
【００７２】
図１５に示すように、テストシナリオシート９００には、表形式で、ステップＩＤ、種別、取引サービス、データベース、テスト記述、結果に関するデータが記録される。種別には、取引サービス呼出、ＤＢ操作、ＤＢ照会、プログラム呼出の処理種別を設定する。
【００７３】
取引サービスのコラムには、取引識別コード、チャネル識別／取引処理Ｎｏに関するデータが含まれる。ここでは、テスト対象の取引サービスの取引識別コードを指定する。
【００７４】
データベースに関するコラムには、テーブル名、セグメント名に関するデータが含まれる。「ＤＢ操作」においては、リレーショナルＤＢ（テーブル名）や階層型ＤＢ（セグメント名）を設定する。「ＤＢ照会」において、ＤＢの照会を行なう。リレーショナルＤＢにおいてはパラメータの指定は不要であるが、階層型ＤＢにおいてはセグメント表名を指定する。「プログラム呼出」においては、任意のプログラムの実行を指定することができる。
【００７５】
そして、テストシナリオシート９００において、テストケースＩＤ（テストケースを特定する情報）に関連付けて、電文データ仕様作成指示を入力する。この場合、このテストケースに対して、テストケース記述書兼報告書が作成される。更に、取引サービス呼出シート９０１、ＤＢ操作シート９０２、ＤＢ照会シート９０３が生成される。このテストケース記述書兼報告書には、各シート（９０１〜９０３）へのリンクが設定されている。
【００７６】
次に、テスト工程管理システムは、取引サービス呼出処理を実行する（ステップＳ２−２）。具体的には、テストシナリオシート９００のテストケース記述書兼報告書において、種別「取引サービス呼出」を選択する。
【００７７】
この場合、テスト工程管理システムは、投入電文設定・応答電文期待値設定処理を実行する（ステップＳ２−３）。種別「取引サービス呼出」の選択に応じて、電文データ仕様書シート９０４を、クライアント端末Ｔ１のディスプレイに表示する。
【００７８】
図１６（ａ）に示すように、電文データ仕様書シート９０４には、電文明細として、「Ｎｏ」、「サービスコード」、「固有ＩＤ」、「サービス名称」、「Ｆｒｏｍ」、「Ｔｏ」、「用途」、「結果」の項目値が記録される。この電文データ仕様書シート９０４の項目値としては、初回テスト時に、打鍵に応じた電文をキャプチャし、この電文の項目値が初期設定される。そして、テスト担当者は、初期設定された項目値を、テストの目的に応じて所望の値に変更する。
【００７９】
図１６（ｂ）に示すように、投入電文シート９０５には、表形式で電文レイアウトが記録されており、フィールドに対して、項目値が記録される。
そして、テスト担当者は各項目に必要事項を入力する。この場合、テスト工程管理システムは、入力された項目内容を電文データ仕様書シート９０４に設定する。
【００８０】
また、テスト工程管理システムは、ＤＢ操作処理を実行する（ステップＳ２−４）。具体的には、テストシナリオシート９００のテストケース記述書兼報告書において、種別「ＤＢ操作」を選択する。
この場合、テスト工程管理システムは、ＤＢ操作設定処理を実行する（ステップＳ２−５）。ここでは、種別「ＤＢ操作」の選択に応じて、ＤＢ操作シート９０２を、クライアント端末Ｔ１のディスプレイに表示する。そして、テスト担当者は各項目に必要事項を入力する。この場合、テスト工程管理システムは、入力された項目内容をＤＢ操作シート９０２に設定する。
【００８１】
また、テスト工程管理システムは、ＤＢ照会処理を実行する（ステップＳ２−６）。具体的には、テストシナリオシート９００のテストケース記述書兼報告書において、種別「ＤＢ照会」を選択する。
【００８２】
この場合、テスト工程管理システムは、ＤＢ期待値設定処理を実行する（ステップＳ２−７）。ここでは、ＤＢ照会シート９０３を、クライアント端末Ｔ１のディスプレイに表示する。そして、テスト担当者は各項目に期待値を入力する。この場合、テスト工程管理システムは、入力された項目内容をＤＢ照会シート９０３に設定する。
【００８３】
次に、テスト工程管理システムは、テスト実行処理を実行する（ステップＳ２−８）。ここでは、テストケースの実行指示が入力された場合、シナリオ制御シェルＴ２１は、テストシナリオシート９００に基づいて、制御シェルＴ３を用いて、各ＤＢにＤＢ操作シート９０２に記録されたＤＢ事前設定値を設定する。そして、シナリオ制御シェルＴ２１は、テストシナリオシート９００に基づいて、制御シェルＴ３を用いて、ＭＱドライバ６１から取引サービス電文を投入し、テストを実行する。この場合、電文データ仕様書シート９０４、ＤＢ照会シート９０３に設定されている応答電文やＤＢ値をキャプチャし、テストケースＩＤに関連付けて、テスト結果記憶部に記録する。
【００８４】
次に、テスト工程管理システムは、応答電文検証・ＤＢ検証処理を実行する（ステップＳ２−９）。ここでは、テスト結果記憶部に記録された応答電文の項目値やＤＢ値と、応答電文期待値シート９０６、ＤＢ期待値シート９０７に設定されている期待値とを比較する。そして、テストシナリオシート９００、応答電文期待値シート９０６、ＤＢ期待値シート９０７に、検証結果を記録する。
【００８５】
テストシナリオシート９００には、表形式で、テストシナリオ毎にテスト結果が記録される。
図１６（ｃ）に示すように、応答電文期待値シート９０６には、表形式で、電文レイアウトのフィールドに対して、検証タイプ、期待値、結果が記録される。
図１６（ｄ）に示すように、ＤＢ期待値シート９０７には、表形式で、ＤＢレイアウトのフィールドに対して、キー、期待値、結果が記録される。
【００８６】
更に、テスト工程管理システムは、取引共通システム３０に記録されたＪＯＢＬＯＧ、ＳＹＳＬＯＧ、取引ログ、モジュールトレースを取得する。そして、クライアントツールＴ１１において、実行ステータス照会の選択ボタンを出力する。この選択ボタンが選択された場合、クライアントツールＴ１１は、クライアント端末Ｔ１のディスプレイに検証結果を表示する。
【００８７】
図１７に示すように、取引サービス検証の結果表示においては、実行ステータス照会に対して、応答電文期待値との比較結果、ＤＢの比較結果、ＪＯＢＬＯＧ、ＳＹＳＬＯＧ、取引ログ、モジュールトレースが記録される。応答電文期待値との比較結果には、全体の検証結果、データ項目単位の検証結果が含まれる。また、ＤＢの比較結果には、全体の検証結果、データ項目単位の検証結果が含まれる。
【００８８】
以上、本実施形態によれば、以下に示す効果を得ることができる。
（１）上記実施形態では、クライアントツールＴ１１には、要求電文のレイアウト情報が設定されている。これにより、テストに用いる要求電文を効率的に設定するとともに、応答電文を取得することができる。特に、テスト対象システムが、複数のプラットフォームで構成されている場合、プラットフォーム毎にレイアウト情報を保持させることにより、統一されたユーザインターフェースで、テスト準備から検証までを実現することができる。
【００８９】
（２）上記実施形態では、クライアントツールＴ１１には、ＤＢのレイアウト情報が設定されている。これにより、テスト対象システムのＤＢ値を効率的に事前設定することができるとともに、テスト後のＤＢ値を取得することができる。
【００９０】
（３）上記実施形態では、クライアントツールＴ１１には、複数のプラットフォーム毎にレイアウト情報を保持している。これにより、複数のプラットフォームで、全体のシステム構成されているテスト対象システムにおいて、統一されたユーザインターフェースで、テスト準備から検証までを実現することができる。
【００９１】
（４）上記実施形態では、クライアントツールＴ１１には、応答電文やＤＢ値の期待値を設定する。これにより、キャプチャした値と期待値との比較に基づいて、効率的に検証を行なうことができる。
【００９２】
（５）上記実施形態では、クライアントツールＴ１１を用いて、商品サービス検証、取引サービス検証を行なう。これにより、商品サービスにおける単体テストと取引サービスにおける結合テストとを、統一されたユーザインターフェースで実施することができる。
【００９３】
なお、上記実施形態は、以下の態様に変更してもよい。
・上記実施形態では、本発明を、商品サービス検証、取引サービス検証に適用した。適用対象のテストは、これらに限定されるものではない。何れか一方のテストや、他のテストとの組み合わせに適用することも可能である。
【００９４】
・上記実施形態では、取引共通システム３０〜プロダクト層５０によって構成されたテスト対象システムにおいて、テスト工程を管理する。テスト対象システムはこれに限定されるものではなく、複数のプラットフォームにより構成されたシステムに適用することができる。
【００９５】
・上記実施形態では、リレーショナルＤＢ、階層型ＤＢにおいてＤＢ操作や照会を行なう。データベースの種類は、これらに限定されるものではない。一種類のデータベースを用いる場合には、変換部を用いる必要はない。他の種類のデータベースを用いる場合には、データベースの種類毎に変換部を設ける。これにより、統一したユーザインターフェースにより、ＤＢ操作や照会を行なうことができる。
【００９６】
・上記実施形態では、リポジトリＴ２４に、キャプチャした電文を一時的に保存する。ここで、キャプチャレベル（キャプチャする電文の取得箇所）の値のみを保存したり、キャプチャした電文の中で、検証対象箇所のみを保存したりするようにしてもよい。この場合には、クライアントツールＴ１１において、キャプチャレベルを指定しておく。
【符号の説明】
【００９７】
１０…チャネル、２０，４０…メインＨＵＢ、３０…取引共通システム、３１，３６…ＨＵＢコネクト、３２…営業店端末固有、３３…取引メイン、３４…ＭＤＦ、３５…業務コンポーネント、５０…プロダクト層、６０…ＡＭＬＣ、６１…ＭＱドライバ、６２…商品サービスドライバ、７２…商品サービススタブ、７３…ＭＱスタブ、７４…ＩＣＡＬスタブ、Ｔ１…クライアント端末、Ｔ１１…クライアントツール、Ｔ２…テスト管理サーバ、Ｔ２１…シナリオ制御シェル、Ｔ２２…キャプチャ開始シェル、Ｔ２３…キャプチャ停止シェル、Ｔ２４…リポジトリ、Ｔ３…制御シェル、Ｔ５…変換部、Ｔ６…ローカルシェル。
【図１】
2018055189.tif 000003
【図２】
2018055189.tif 000004
【図３】
2018055189.tif 000005
【図４】
2018055189.tif 000006
【図５】
2018055189.tif 000007
【図６】
2018055189.tif 000008
【図７】
2018055189.tif 000009
【図８】
2018055189.tif 000010
【図９】
2018055189.tif 000011
【図１０】
2018055189.tif 000012
【図１１】
2018055189.tif 000013
【図１２】
2018055189.tif 000014
【図１３】
2018055189.tif 000015
【図１４】
2018055189.tif 000016
【図１５】
2018055189.tif 000017
【図１６】
2018055189.tif 000018
【図１７】
2018055189.tif 000019