JP6224194B1 - テスト工程管理システム、テスト工程管理方法及びテスト工程管理プログラム - Google Patents

Abstract

【課題】テスト対象システムにおいて、効率的にテストを行なうためのテスト工程管理システム、テスト工程管理方法及びテスト工程管理プログラムを提供する。【解決手段】クライアントツールは、取引サービスを構成する商品サービスのフローを定義するＦＤＬ生成ツールにおいてフローパスパターン生成Ｓ１−１されたフローパスパターンを取得し、フローパスパターンに含まれるすべての商品サービスを並べた商品サービス列を生成する。フローパスパターン毎に、商品サービス列において、フローパスパターンに含まれる商品サービスの有無を表示したフローパスパターン表シートを生成Ｓ１−２する。フローパスパターン表シートにおいて、テストが必要なフローパスパターンを取得Ｓ１−３して、フローパスパターン毎にテストケースを生成Ｓ１−４し、各テストケースで用いる電文を出力Ｓ１−５する。【選択図】図３

Description

本発明は、テスト対象システムにおいて、テストを行なうためのテスト工程管理システム、テスト工程管理方法及びテスト工程管理プログラムに関する。

システムを構築する場合、様々なテストが行なわれる。これらのテストには、例えば、各モジュールをテストする単体テストや、各モジュールを結合させた状態でテストを実施する統合テスト、ユーザによる受け入れテストや本番環境でのテストを実施する運用テスト等がある。

そして、複数のモジュールから構成されたシステムにおいて、テスト実施時の負担を軽減することにより、効率的に結合テストを行なうための結合テストシステムが検討されている（例えば、特許文献１を参照。）。この文献記載の技術においては、アプリケーション実行環境上で必要な共通制御処理を行なう共通制御モジュールを加工して生成された汎用ドライバは、共通制御処理の実行後、外部インターフェイスから取得したモジュール名の検証モジュールをコールする。この検証モジュールは、データベース（ＤＢ）初期設定後にテスト対象の個別業務モジュールをコールする。個別業務モジュールは、アプリケーション実行環境と同一のテスト環境において、テストデータ及びＤＢ設定値を用いて個別業務処理を実行する。個別業務モジュールからの出力値を取得した検証モジュールは、出力結果を検証する。

また、一つの取引サービスにおいて、複数の個別処理（商品サービス）を組み合わせて行なうこともある。例えば、口座残高を利用して証券購入を行なう取引サービスにおいては、口座残高管理及び証券販売の商品サービスを利用することになる。そこで、複数の処理を連携して実行する場合に、一部の処理で発生したエラーに対する対応を支援するための連携処理管理システムが検討されている（例えば、特許文献２を参照。）。この文献記載の技術においては、取引共通システムの制御部は、取引端末から受信した取引電文に基づいて生成した処理依頼電文をサービス管理サーバに送信し、処理結果電文を受信する。この処理結果電文においてエラーと判定した場合、エラーを登録するとともに、迂回設定を行ない、再度、処理依頼電文を送信することにより、すべての個別処理を終了するまで取引処理を続行する。すべての個別処理を終了した場合、エラーが登録されている場合には、実行済み処理を取り消す。そして、取引処理において発生するすべてのエラーをまとめて取引端末において出力して、承認端末において承認処理を行なう。

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

複数の個別処理を組み合わせて行なわれる連携処理においては、取引サービスの各種条件に応じて、必要な個別処理が異なる。従って、連携処理に関するテストにおいては、各種条件に基づいて必要な個別処理を行なうための連携処理（フローパスパターン）についての検証を行なう必要がある。しかしながら、各種条件の組み合わせは多様であり、これらを考慮して、テストに用いる電文を作成する場合には手間がかかる。特に、複数の個別処理を連携する場合には、個別処理毎の電文レイアウトを考慮する必要がある。

本発明は、上記課題を解決するためになされたものであり、テスト対象システムにおいて、効率的にテストを行なうためのテスト工程管理システム、テスト工程管理方法及びテスト工程管理プログラムを提供することにある。

・上記課題を解決するテスト工程管理システムでは、テスト対象システムにおけるテスト工程を管理する制御部を備える。そして、前記制御部が、取引サービスを構成する商品サービスのフローを定義するフロー定義生成ツールにおいて生成されたフローパスパターンを取得し、前記フローパスパターンに含まれるすべての商品サービスを並べた商品サービス列を生成し、フローパスパターン毎に、前記商品サービス列において、フローパスパターンに含まれる商品サービスの有無を表示したフローパスパターン一覧リストを生成し、前記フローパスパターン一覧リストにおいて、テストが必要なフローパスパターンを取得して、フローパスパターン毎にテストケースを生成し、前記各テストケースで用いる電文を出力する。これにより、テスト対象のフローパスパターンで用いる電文を、効率的に作成することができる。

・上記テスト工程管理システムにおいて、前記制御部が、前記各テストケースで用いる各電文の各項目の設定値及び期待値を取得し、前記各電文を用いてテストを実行することにより、取得した応答電文の項目値を取得し、前記期待値との比較結果を前記各テストケース毎にテストケース記述書に出力することが好ましい。これにより、効率的に検証を行なうことができる。

・上記テスト工程管理システムにおいて、前記フローパスパターン一覧リストにおいて、商品サービスで用いる条件に基づいて、使用可能なフローパスパターンと使用不可のフローパスパターンとを区別して出力することが好ましい。商品サービスで用いる各種条件の組み合わせにおいては、実際に発生しないフローパスパターンが生成される場合もあるが、使用可能なフローパスパターンを用いて、テスト対象を効率的に特定することができる。

本発明によれば、テスト対象システムにおいて、効率的にテストを行なうことができる。

本実施形態のシステム概略図。 本実施形態のＦＤＬ検証におけるシステム概略図。 本実施形態のＦＤＬ検証フローの説明図。 本実施形態のＦＤＬ検証における各シートの説明図。 本実施形態のＦＤＬ検証におけるフローパスパターン表シートの説明図。 本実施形態のＦＤＬ検証における電文データ仕様書の説明図。 本実施形態のＦＤＬ検証における電文設定シートの説明図。

以下、本発明を具体化した実施形態を図１〜図７に従って説明する。ここでは、顧客との取引を管理する取引システムのテストを行なう場合、商品サービス検証、ＦＤＬ検証、取引サービス検証を行なう。本実施形態では、ＦＤＬ検証を説明する。取引を実現するための取引サービスにおいて、一つ以上の商品サービスを利用することがある。この場合、これらの商品サービスを利用するために、電文の呼出（データ移送）・送受信や、応答結果による取引応答電文の編集等をＦＤＬ（FlowMark Definition Language）で記述されたフロー定義をテストすることをＦＤＬ検証と呼ぶ。

（取引システムの概要）
図１を用いて、テストに用いる取引システムの概要を説明する。テスト対象の取引システムは、チャネル１０、メインＨＵＢ２０，４０、取引共通システム３０、プロダクト層５０から構成される。このメインＨＵＢ２０，４０は、電文を中継するコンピュータシステムであり、それぞれ第１階層、第２階層によって構成される。本実施形態では、取引共通システム３０、メインＨＵＢ４０、プロダクト層５０がテスト対象である。

チャネル１０は、店舗端末や店頭端末、現金自動預払機（ＡＴＭ）、インターネットバンキングサーバ等、顧客との取引を受け付けるシステムである。
メインＨＵＢ２０は、チャネル１０から取得した要求電文を取引共通システム３０に中継するとともに、取引共通システム３０から取得した応答電文をチャネル１０に返信するコンピュータシステム（フロント接続システム）である。

取引共通システム３０は、顧客との取引において共通的に行なわれる処理（共通業務）を管理するコンピュータシステムである。この取引共通システムは、メインフレーム（第１のプラットフォーム）により構成され、共通業務としては、例えば、取引メイン、行内勘定、流動性預金、内国為替、ＣＩＦ（顧客番号）、手数料等の管理を行なう。

メインＨＵＢ４０は、取引共通システム３０から取得した要求電文をプロダクト層５０に中継するとともに、プロダクト層５０から取得した応答電文を取引共通システム３０に返信するコンピュータシステム（バックエンド接続システム）である。

プロダクト層５０は、金融機関が提供する各商品を管理するコンピュータシステムである。このプロダクト層５０は、異なるシステムプロバイダから提供された複数のオープン環境システムにより構成される。例えば、第２のプラットフォームであるオープン環境システム５０ａにおいては、融資、外国為替、信託等で用いられる商品サービスを管理する。また、第３のプラットフォームであるオープン環境システム５０ｂにおいては、定期性預金等で用いられる商品サービスを管理する。

本実施形態では、テストのために、クライアント端末Ｔ１、テスト管理サーバＴ２を用いる。
クライアント端末Ｔ１は、テスト担当者が使用するコンピュータ端末であり、制御部、キーボードやポインティングデバイス等からなる入力部や、ディスプレイ等からなる出力部を備えている。

更に、このクライアント端末Ｔ１は、制御部において、クライアントツールＴ１１を起動する。このクライアントツールＴ１１は、テスト工程管理システムを利用するためのユーザインターフェースであり、テスト担当者によってテスト内容に関する情報が設定される。このため、クライアントツールＴ１１は、投入電文の電文レイアウト情報を保持している。この電文レイアウト情報には、投入電文、要求電文、応答電文に設定される項目が設定されている。そして、クライアントツールＴ１１は、各テストの検証結果を取得し出力する。

クライアントツールＴ１１において、ＦＤＬ検証に必要なテストケースを設定する。そして、クライアントツールＴ１１は、テスト対象として設定されたテストケースに基づいて、後述するシナリオ制御シェルＴ２１、制御シェルＴ３を制御する。また、プロダクト層５０のデータベースを操作する場合には、ローカルシェルＴ６を用いる。

テスト管理サーバＴ２は、クライアントツールＴ１１によって設定されたテストケースをコントロールするコンピュータシステムである。このテスト管理サーバＴ２は、シナリオ制御シェルＴ２１、リポジトリＴ２４等を備えている。更に、テスト管理サーバＴ２は、取引サービス検証時のテスト結果は、テストケースを特定する情報（テストケースＩＤ）に関連付けて保存するテスト結果記憶部（図示せず）を備えている。

更に、クライアントツールＴ１１は、ＦＤＬサーバＴ４に接続される。このＦＤＬサーバＴ４は、ＦＤＬ生成ツールＴ４０を備える。ＦＤＬ生成ツールＴ４０は、フローパスパターンを生成する機能部（フロー定義生成ツール）である。このＦＤＬ生成ツールＴ４０は、フロー定義及びマッピング定義、サービスインターフェース情報を用いて、フローパスパターンを生成する。ここで、フロー定義は、取引サービス毎に、利用する商品サービスのフロー（順番）を定めた情報である。マッピング定義は、取引サービスの要求電文の項目値を商品サービスの要求電文の項目への移送、商品サービスの応答電文の項目値を他の商品サービスの要求電文の項目への移送等を行なうための定義（項目の対応付け）である。

シナリオ制御シェルＴ２１は、検証部として機能し、クライアント端末Ｔ１のクライアントツールＴ１１で作成されたテストケースに従って、ＦＤＬ検証等の実施を制御する。テストケースには、後述するように、ＤＢデータ準備、エビデンス取得（ＤＢの事前事後照会、電文、取引ログ等の取得、取得データの整形等）の検証に付随する処理についても実行する。

リポジトリＴ２４は、店舗端末、現金自動預払機（ＡＴＭ）等での打鍵により発生した電文をキャプチャした場合に一時的に保存する記憶部である。

制御シェルＴ３は、取引共通システム３０のテスト管理サーバＴ２に対するインターフェイス機能部である。この制御シェルＴ３は、テスト管理サーバＴ２から取引共通システム３０へのリクエストを中継する。そして、制御シェルＴ３は、テスト管理サーバＴ２からのリクエストに応じて、テストケース実行、スタックテーブルのリダイレクト等のサブ機能を実現する。

また、ＦＤＬ検証においては、取引共通システム３０内に各種ドライバやスタブを設ける。本実施形態では、クライアントツールＴ１１、各種シェル、各種ドライバ、各種スタブ等、テストに必要な機能部をまとめてテスト工程管理システムと呼ぶ。なお、各種ドライバ、各種スタブの詳細については後述する。

（ＦＤＬ検証）
次に、図２を用いて、ＦＤＬ検証を説明する。この場合、取引共通システム３０におけるＨＵＢコネクト３１、取引メイン３３、ＭＤＦ３４、ＨＵＢコネクト３６を用いる。ＦＤＬ検証においては、取引共通システム３０のＭＤＦ３４において送受信される要求電文、応答電文が検証対象である。

ＨＵＢコネクト３１は、取引共通システム３０において、メインＨＵＢ２０に接続されて、電文の転送を管理する機能部である。
取引メイン３３は、共通業務において処理が必要な業務コンポーネント３５を特定し、各業務コンポーネント３５に対する要求電文を送信するとともに、業務コンポーネント３５からの応答電文を取得する。

ＨＵＢコネクト３６は、取引共通システム３０において、メインＨＵＢ４０に接続されて、電文の転送を管理する機能部である。
ＭＤＦ３４は、商品サービスに対応する複数のシステムを統合したときに必要となるメッセージ配信、複数システム間の連携、メッセージの変換を行なう機能部である。

取引共通システム３０においては、各取引に対応した取引サービス毎に、取引を実現するための一つ以上の商品サービスを利用する。このため、このＭＤＦ３４には、商品サービス要求電文の呼出（データ移送）・送受信や、応答結果による取引応答電文の編集を予めフロー定義（ＦＤＬ）として取引毎に事前に登録される。

更に、テストのために、ＭＱドライバ６０、ＡＦＥシミュレータ６１、商品サービススタブ６２、ＭＱスタブ６３、ＩＣＡＬスタブ６４を用いる。
ＭＱドライバ６０は、チャネル１０、メインＨＵＢ２０の動作のシミュレーションを行ない、要求電文をＨＵＢコネクト３１に送信したり、応答電文を受信したりするメッセージキュー方式のドライバ（テスト用の仮の上位階層モジュール）である。

ＡＦＥシミュレータ６１は、ＨＵＢコネクト３１からの要求電文を、取引メイン３３に転送し、取引メイン３３からの応答電文を、ＨＵＢコネクト３１に転送する処理を実行する。

商品サービススタブ６２は、ＦＤＬ検証において、取引共通システム３０内の業務コンポーネント３５のスタブ（テスト用の仮の下位階層モジュール）である。商品サービススタブ６２は、ＭＤＦ３４から要求電文を受信し、応答電文を返信する。

ＭＱスタブ６３は、メインＨＵＢ４０、プロダクト層５０の動作のシミュレーションを行ない、ＨＵＢコネクト３６との間で要求電文、応答電文の送受信を行なうスタブである。
ＩＣＡＬスタブ６４は、ＭＤＦ３４から、階層型ＤＢであるＩＭＳ（登録商標）を呼び出すスタブである。

ＦＤＬ検証時には、ＭＱドライバ６０を、ＨＵＢコネクト３１に接続する。そして、ＭＱドライバ６０から、取引サービス要求電文を、ＨＵＢコネクト３１に投入する。この取引サービス要求電文は、ＡＦＥシミュレータ６１、取引メイン３３を介して、テスト対象のＭＤＦ３４に送信される。

この場合、ＭＤＦ３４は、フロー定義に基づいて、商品サービス要求電文を呼び出し、商品サービススタブ６２、ＨＵＢコネクト３６を介してＭＱスタブ６３、ＩＣＡＬスタブ６４に送信する。そして、ＭＤＦ３４は、商品サービススタブ６２、ＨＵＢコネクト３６を介してＭＱスタブ６３、ＩＣＡＬスタブ６４からの商品サービス応答電文を受信する。更に、ＭＤＦ３４は、各商品サービスを終了した場合には、取引サービス応答電文を、取引メイン３３、ＡＦＥシミュレータ６１、ＨＵＢコネクト３１を介して、ＭＱドライバ６０に返信する。この場合、取引共通システム３０は、投入された取引サービス要求電文に対する各商品サービス要求電文、商品サービス応答電文、取引サービス応答電文をキャプチャし、テスト結果記憶部に格納する。

クライアントツールＴ１１は、キャプチャした応答電文について、期待値と比較検証し、検証結果をクライアント端末Ｔ１のディスプレイに表示する。検証結果が期待値と一致していることを確認できた場合には、テストを終了する。一方、検証結果が期待値と相違がある場合には、テスト担当者は相違した値を目視で確認する。

（ＦＤＬ検証におけるフロー）
次に、図３を用いて、ＦＤＬ検証におけるフローを説明する。
まず、ＦＤＬ生成ツールＴ４０を用いて、フローパスパターンの生成処理を実行する（ステップＳ１−１）。具体的には、テスト管理サーバＴ２において、フロー定義及びマッピング定義、サービスインターフェース情報を準備する。そして、ＦＤＬ生成ツールＴ４０は、フロー定義及びマッピング定義、サービスインターフェース情報を用いて、フローパスパターン（商品サービス列）を生成する。ここでは、取引サービスフローにおいて、すべての分岐を網羅したフローパスパターンを生成する。

更に、ＦＤＬ生成ツールＴ４０は、生成したフローパスパターンには、実際には通らないフローパスパターンが含まれるため、不要なフローパスパターンを区分する。
具体的には、分岐条件を所定の順番で並び替え、その順番で入れ子構造にすることにより、有意義なフローパスパターンを区分する。例えば、「電文項目ａ＞１０」、「電文項目ａ＞９」、「電文項目ａ＞８」、「電文項目ａ＞７」、「電文項目ａ≦７」を判断する分岐がある場合を想定する。すべての分岐（判断子）を組み合わせると、１６個のフローパスパターンが生成される。そこで、項目値が小さい順番に並べ替えて、「電文項目ａ≦７」、「電文項目ａ＞７」、「電文項目ａ＞８」、「電文項目ａ＞９」、「電文項目ａ＞１０」の分岐（判断子）を連続的に判定することにより、５個のフローパスパターンに絞り込むことができる。

また、複数分岐条件を用いることにより、有意義なフローパスパターンを区分する。例えば、「電文項目ｂ＝１０」、「電文項目ｂ＝９」、「電文項目ｂ＝８」、「電文項目ｂ＝７」、「電文項目ｂ≠７，８，９，１０」を判断する分岐がある場合を想定する。この場合も、すべての分岐（判断子）を組み合わせると、１６個のフローパスパターンが生成される。そこで、項目値を用いた単一の複数分岐「電文項目ｂ＝７」、「電文項目ｂ＝８」、「電文項目ｂ＝９」、「電文項目ｂ＝１０」、「電文項目ｂ≠７，８，９，１０」の判断子を用いることにより、５個のフローパスパターンに絞り込むことができる。

そして、解析により、有意義なフローパスパターンを区分して、リポジトリＴ２４に格納する。
次に、クライアント端末Ｔ１は、フローパスパターン一覧表示処理を実行する（ステップＳ１−２）。具体的には、クライアント端末Ｔ１のクライアントツールＴ１１において、フローパスパターン表の生成指示を入力する。この場合、クライアントツールＴ１１は、リポジトリＴ２４に格納されたフローパスパターンを呼び出す。そして、クライアント端末Ｔ１のディスプレイに、フローパスパターンフォームを出力する。

図４に示すように、フローパスパターンフォーム９００は、表計算ファイルにより構成されている。そして、フローパスパターンフォーム９００は、フローパスパターン表シート９０１、複合条件シート９０２、ＦＤＬ条件直接記述シート９０３、単純条件シート９０４、繰返し条件シート９０５から構成されている。

フローパスパターン表シート９０１は、対象ＦＤＬについて、条件分岐によるフローの全てのパターンごとに、呼び出される商品サービスおよび使用される条件と、その条件に対する真偽とを示す。

図５に示すように、フローパスパターン表シート９０１には、テスト実施対象、フローパスパターン、取引サービス、複数の商品サービス、条件の各欄が設けられている。
テスト実施対象欄は、初期値としてブランクになっており、テスト対象を選択する場合に用いられる。テストを実施する場合には、テスト実施対象欄に「○」を入力し、テストケース記述書を作成する。一方、テストを実施しない場合には、テスト実施対象欄に「×」を入力する。なお、ブランク（初期値）の場合もテスト実施対象外とする。そして、ＦＤＬ生成ツールＴ４０において、実際には通らないと判定されたフローパスパターンは、予め機械的に除外されている。

フローパスパターン欄には、各フローパスパターンを特定するための識別子に関する情報が記録される。
取引サービス欄には、このフローパスパターンを用いる取引サービスに関する情報が記録される。

商品サービス欄には、この取引サービスに利用する商品サービスに関する情報が記録される。
条件欄には、後述する複合条件、ＦＤＬ条件直接記述、単純条件、繰返し条件における選択の有無が表示される。

複合条件シート９０２は、フローで使用される条件のうち、単純条件に記載された条件を組み合わせた複合条件を設定するための参考情報が記録される。
ＦＤＬ条件直接記述シート９０３は、ＦＤＬの条件記述時に条件の設定を直接記述するための参考情報が記録される。

単純条件シート９０４は、フローで使用される条件のうち、単一条件を設定するための参考情報が記録される。
繰返し条件シート９０５は、フローにおいて、繰返し条件が使用されている場合、ブレーク条件になるまでの最大反復回数を設定するための参考情報が記録される。

次に、クライアント端末Ｔ１は、テスト対象の選定処理を実行する（ステップＳ１−３）。具体的には、担当者は、フローパスパターン表シート９０１のテスト実施対象欄を用いて、テスト対象のフローパスパターンを選択する。この場合、クライアント端末Ｔ１のクライアントツールＴ１１は、「○」が入力されたフローパスパターンを、テストケースとして仮記憶する。

そして、クライアントツールＴ１１において、実行入力が行なわれた場合、テストケースとして特定されたフローパスパターン毎に以下の処理を繰り返す。
ここでは、クライアント端末Ｔ１は、テストケースの生成処理を実行する（ステップＳ１−４）。具体的には、クライアント端末Ｔ１のクライアントツールＴ１１において、テスト対象のフローパスパターンについて、テストケース記述書を作成する。

図４に示すように、テストケース記述書９１０は、フローパスパターンフォーム９００に基づいて生成される。このテストケース記述書９１０のヘッダシートには、テストケースのステップＩＤに対して、種別「取引サービス呼出」に対して、各商品サービスにおけるパラメータが設定される。

次に、クライアント端末Ｔ１は、電文データ仕様書の作成処理を実行する（ステップＳ１−５）。具体的には、クライアント端末Ｔ１のクライアントツールＴ１１において、テストケース記述書９１０において設定されたテストケースで用いる電文定義シートを生成する。

図４に示すように、電文定義シート９２０は、フローパスパターンフォーム９００に基づいて生成される。この電文定義シート９２０には、電文データ仕様書、電文設定シートが含まれる。

図６に示すように、電文データ仕様書９２１には、サービスコード、サービス名称、Ｆｒｏｍ、Ｔｏ、用途、結果（期待値、キャプチャ値、判定結果）の各欄が含まれる。
ここで、用途欄には、投入用、検証用、スタブ応答用、検証用の電文の目的が設定される。
図７に示すように、電文設定シート９２２には、電文データ仕様書９２１において用いる各電文（投入用、検証用）の電文レイアウトの各項目について項目値が設定される。投入用の電文設定シート９２２には、各項目、仕様について投入電文の設定値を記録し、検証用の電文設定シート９２２には、期待値を設定値欄に記録する。そして、テスト後に、検証用の電文設定シート９２２には、各項目、仕様について取得したキャプチャ値及び検証結果が記録される。
そして、テスト対象のすべてのフローパスパターンについて以上の処理を繰り返す。

次に、クライアント端末Ｔ１は、テストケース記述書の出力処理を実行する（ステップＳ１−６）。具体的には、クライアントツールＴ１１は、クライアント端末Ｔ１のディスプレイに、テストケース記述書を出力する。

そして、テストケース記述書を確認できた場合、クライアントツールＴ１１においてテスト実行入力を行なう。
この場合、テスト管理サーバＴ２は、テスト実行処理を実行する（ステップＳ１−７）。具体的には、テスト管理サーバＴ２は、シナリオ制御シェルＴ２１、制御シェルＴ３により、投入用の電文設定シート９２２に設定された電文を、ＭＱドライバ６０から投入する。そして、検証対象の電文を取得し、テスト結果記憶部、検証用の電文設定シート９２２のキャプチャ欄に記録する。そして、検証用の電文設定シート９２２の設定値欄に記録されている値と比較し、この比較による比較結果を電文設定シート９２２の結果欄に記録する。

以上、本実施形態によれば、以下に示す効果を得ることができる。
（１）本実施形態では、ＦＤＬ生成ツールＴ４０は、フローパスパターンの生成処理を実行する（ステップＳ１−１）。この場合、不要なフローパスパターンを区分する。これにより、電文が通らないフローパスパターンを排除して、有意義なフローパスパターンを、効率的に特定することができる。

（２）本実施形態では、クライアント端末Ｔ１は、フローパスパターン一覧表示処理（ステップＳ１−２）、テスト対象の選定処理（ステップＳ１−３）を実行する。これにより、所望のテスト対象のフローパスパターンを選択することができる。

（３）本実施形態では、テスト対象として特定されたフローパスパターン毎に、クライアント端末Ｔ１は、テストケースの生成処理（ステップＳ１−４）、電文データ仕様書の作成処理（ステップＳ１−５）を実行する。これにより、効率的に、テスト対象のフローパスパターンに対応した電文を生成して、テスト対象システムに投入し、ＦＤＬ検証を行なうことができる。

なお、上記実施形態は、以下の態様に変更してもよい。
・上記実施形態では、ＦＤＬ検証に適用したが、適用対象のテストは、これに限定されるものではなく、他のテストとの組み合わせに適用することも可能である。

・上記実施形態では、取引共通システム３０〜プロダクト層５０によって構成されたテスト対象システムにおいて、テスト工程を管理する。テスト対象システムはこれに限定されるものではなく、複数の個別処理を連携して行なうフローに適用することができる。

・上記実施形態では、ＦＤＬ生成ツールＴ４０を用いてフローパスパターンを生成する。フローパスパターンの生成方法は、これに限定されるものではない。例えば、クライアントツールＴ１１において、ＦＤＬ生成ツールＴ４０の機能を設けるようにしてもよい。

１０…チャネル、２０，４０…メインＨＵＢ、３０…取引共通システム、３１，３６…ＨＵＢコネクト、３３…取引メイン、３４…ＭＤＦ、３５…業務コンポーネント、５０…プロダクト層、６０…ＭＱドライバ、６１…ＡＦＥシミュレータ、６２…商品サービススタブ、６３…ＭＱスタブ、６４…ＩＣＡＬスタブ、Ｔ１…クライアント端末、Ｔ１１…クライアントツール、Ｔ２…テスト管理サーバ、Ｔ４…ＦＤＬサーバ、Ｔ４０…ＦＤＬ生成ツール、Ｔ２１…シナリオ制御シェル、Ｔ２４…リポジトリ、Ｔ３…制御シェル、Ｔ６…ローカルシェル。

Claims (5)

1. テスト対象システムにおけるテスト工程を管理する制御部を備えたテスト工程管理システムであって、
   前記制御部が、
   取引サービスを構成する商品サービスのフローを定義するフロー定義生成ツールにおいて生成されたフローパスパターンを取得し、
   前記フローパスパターンに含まれるすべての商品サービスを並べた商品サービス列を生成し、
   フローパスパターン毎に、前記商品サービス列において、フローパスパターンに含まれる商品サービスの有無を表示したフローパスパターン一覧リストを生成し、
   前記フローパスパターン一覧リストにおいて、テストが必要なフローパスパターンを取得して、フローパスパターン毎にテストケースを生成し、
   前記各テストケースで用いる電文を出力することを特徴とするテスト工程管理システム。
2. 前記制御部が、前記各テストケースで用いる各電文の各項目の設定値及び期待値を取得し、
   前記各電文を用いてテストを実行することにより、取得した応答電文の項目値を取得し、前記期待値との比較結果を前記各テストケース毎にテストケース記述書に出力することを特徴とする請求項１に記載のテスト工程管理システム。
3. 前記フローパスパターン一覧リストにおいて、商品サービスで用いる条件に基づいて、使用可能なフローパスパターンと使用不可のフローパスパターンとを区別して出力することを特徴とする請求項１又は２に記載のテスト工程管理システム。
4. テスト対象システムにおけるテスト工程を管理する制御部を備えたテスト工程管理システムを用いて、テスト工程を管理する方法であって、
   前記制御部が、
   取引サービスを構成する商品サービスのフローを定義するフロー定義生成ツールにおいて生成されたフローパスパターンを取得し、
   前記フローパスパターンに含まれるすべての商品サービスを並べた商品サービス列を生成し、
   フローパスパターン毎に、前記商品サービス列において、フローパスパターンに含まれる商品サービスの有無を表示したフローパスパターン一覧リストを生成し、
   前記フローパスパターン一覧リストにおいて、テストが必要なフローパスパターンを取得して、フローパスパターン毎にテストケースを生成し、
   前記各テストケースで用いる電文を出力することを特徴とするテスト工程管理方法。
5. テスト対象システムにおけるテスト工程を管理する制御部を備えたテスト工程管理システムを用いて、テスト工程を管理するプログラムであって、
   前記制御部を、
   取引サービスを構成する商品サービスのフローを定義するフロー定義生成ツールにおいて生成されたフローパスパターンを取得し、
   前記フローパスパターンに含まれるすべての商品サービスを並べた商品サービス列を生成し、
   フローパスパターン毎に、前記商品サービス列において、フローパスパターンに含まれる商品サービスの有無を表示したフローパスパターン一覧リストを生成し、
   前記フローパスパターン一覧リストにおいて、テストが必要なフローパスパターンを取得して、フローパスパターン毎にテストケースを生成し、
   前記各テストケースで用いる電文を出力する手段として機能させることを特徴とするテスト工程管理プログラム。

Images