(57)【要約】【課題】効率的に有効なテストケースの組合せを決定する。【解決手段】順序が予め定まっている複数のテストケース仕様書に含まれるテストケースを正常ケースと異常ケースの２種類に分類する。そして、順序と分類されたテストケースの種類と、に基づいて特定されるテストケースの組合せの中から、選択済条件節集合Ｃselectedに含まれていない条件節を含み、その数が最も多いテストケースの組合せを取得する処理（Ｓ１４、Ｓ１６）と、取得したテストケースの組合せが充足可能な組合せかをＳＡＴソルバにより判定する処理（Ｓ２０）と、取得したテストケースの組合せに含まれる条件節を選択済条件節集合Ｃselectedに追加する処理（Ｓ２６）を、選択済条件節集合Ｃselectedに含まれる条件節と全条件節集合Ｃallに含まれる条件節とが一致するまで繰り返し（Ｓ２８）、充足可能と判定されたテストケースの組合せを出力する（Ｓ３２）。【選択図】図６
2016110327.tif 000002
【特許請求の範囲】
【請求項１】
順序が予め定まっている複数のテストケース仕様書を結合するテストケース仕様書結合プログラムであって、
前記複数のテストケース仕様書に含まれるテストケースを正常と異常の２種類に分類し、
前記順序と、分類された前記テストケースの種類と、に基づいて特定されるテストケースの組合せの中から、取得済みの条件節を格納する格納部に格納されていない条件節を含み、該格納部に格納されていない条件節の数が最も多いテストケースの組合せを取得する処理と、取得した前記テストケースの組合せが充足可能な組合せかを判定する処理と、取得した前記テストケースの組合せに含まれる条件節を前記格納部に格納する処理とを、所定のタイミングまで繰り返し、
充足可能な組合せと判定された前記テストケースの組合せを出力する、処理をコンピュータに実行させ、
前記所定のタイミングは、前記格納部に格納された条件節が、前記複数のテストケース仕様書に含まれる全ての条件節と一致したタイミングである、ことを特徴とするテストケース仕様書結合プログラム。
【請求項２】
前記出力する処理では、更に、前記順序が最初のテストケース仕様書に含まれる異常に分類されたテストケースを出力する、ことを特徴とする請求項１に記載のテストケース仕様書結合プログラム。
【請求項３】
前記繰り返す処理において、前記テストケースの組合せを特定する際に、正常に分類されたテストケースを優先し、異常に分類されたテストケースと前記順序が該異常に分類されたテストケースの後方のテストケースとは組み合わせない、ことを特徴とする請求項１又は２に記載のテストケース仕様書結合プログラム。
【請求項４】
順序が予め定まっている複数のテストケース仕様書を結合するテストケース仕様書結合方法であって、
前記複数のテストケース仕様書に含まれるテストケースを正常と異常の２種類に分類し、
前記順序と、分類された前記テストケースの種類と、に基づいて特定されるテストケースの組合せの中から、取得済みの条件節を格納する格納部に格納されていない条件節を含み、該格納部に格納されていない条件節の数が最も多いテストケースの組合せを取得する処理と、取得した前記テストケースの組合せが充足可能な組合せかを判定する処理と、取得した前記テストケースの組合せに含まれる条件節を前記格納部に格納する処理とを、所定のタイミングまで繰り返し、
充足可能な組合せと判定された前記テストケースの組合せを出力する、処理をコンピュータが実行し、
前記所定のタイミングは、前記格納部に格納された条件節が、前記複数のテストケース仕様書に含まれる全ての条件節と一致したタイミングである、ことを特徴とするテストケース仕様書結合方法。
【請求項５】
順序が予め定まっている複数のテストケース仕様書を結合するテストケース仕様書結合装置であって、
前記複数のテストケース仕様書に含まれるテストケースを正常と異常の２種類に分類する分類部と、
前記順序と、分類された前記テストケースの種類と、に基づいて特定されるテストケースの組合せの中から、取得済みの条件節を格納する格納部に格納されていない条件節を含み、該格納部に格納されていない条件節の数が最も多いテストケースの組合せを取得する処理と、取得した前記テストケースの組合せが充足可能な組合せかを判定する処理と、取得した前記テストケースの組合せに含まれる条件節を前記格納部に格納する処理とを、所定のタイミングまで繰り返す処理部と、
充足可能な組合せと判定された前記テストケースの組合せを出力する出力部と、を備え、
前記所定のタイミングは、前記格納部に格納された条件節が、前記複数のテストケース仕様書に含まれる全ての条件節と一致したタイミングである、ことを特徴とするテストケース仕様書結合装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、テストケース仕様書結合プログラム、方法及び装置に関する。
【背景技術】
【０００２】
従来、統合テストにおいて、複数のシステム仕様書それぞれからテストケース仕様書を生成し、これらのテストケース仕様書を結合して１つの統合テスト仕様書を生成する技術が知られている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１２−１８５６４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
テストケース仕様書の結合においては、通常、網羅性向上のため、全てのテストケース仕様書に含まれるテストケースの全組合せの充足可能性を確認する。このため、仕様書が多い場合や、仕様書が多くのテストケースを含む場合には、組合せの数が膨大になり（爆発し）、処理に長時間を要する又は処理に失敗するおそれがある。
【０００５】
また、システム仕様書が正常又は異常に分類されるテストケースを含む場合（例えば、チェック系仕様書）には、実際には無効となるはずのテストケースの組合せが統合テスト仕様書に含まれる可能性がある。
【０００６】
１つの側面では、本発明は、効率的に有効なテストケースの組合せを決定することが可能なテストケース仕様書結合プログラム、方法及び装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
一つの態様では、テストケース仕様書結合プログラムは、順序が予め定まっている複数のテストケース仕様書を結合するテストケース仕様書結合プログラムであって、前記複数のテストケース仕様書に含まれるテストケースを正常と異常の２種類に分類し、前記順序と、分類された前記テストケースの種類と、に基づいて特定されるテストケースの組合せの中から、取得済みの条件節を格納する格納部に格納されていない条件節を含み、該格納部に格納されていない条件節の数が最も多いテストケースの組合せを取得する処理と、取得した前記テストケースの組合せが充足可能な組合せかを判定する処理と、取得した前記テストケースの組合せに含まれる条件節を前記格納部に格納する処理とを、所定のタイミングまで繰り返し、充足可能な組合せと判定された前記テストケースの組合せを出力する、処理をコンピュータに実行させ、前記所定のタイミングは、前記格納部に格納された条件節が、前記複数のテストケース仕様書に含まれる全ての条件節と一致したタイミングである、テストケース仕様書結合プログラムである。
【発明の効果】
【０００８】
効率的に有効なテストケースの組合せを決定することができる。
【図面の簡単な説明】
【０００９】
【図１】一実施形態に係る統合テスト装置のハードウェア構成を示鈴である。
【図２】統合テスト装置の機能ブロック図である。
【図３】ＡＴＭの利用シナリオの統合テスト内容を示す図である。
【図４】図３の統合テストを実行するためのテストケース仕様書の例を示す図である。
【図５】図２のテストケース仕様書結合部の詳細な機能ブロック図である。
【図６】テストケース仕様書結合部の処理を示すフローチャートである。
【図７】図７（ａ）〜図７（ｃ）は、図６の説明に用いるテストケース仕様書を説明するための図である。
【図８】前処理部の処理を説明するための図である。
【図９】図６のステップＳ１０を説明するための図である。
【図１０】図１０（ａ）は、テストケースの組合せを取得する方法について説明するための図であり、図１０（ｂ）は、図１０（ａ）の優先順をまとめたテーブルである。
【図１１】図６のステップＳ１２〜Ｓ３２の処理を説明するための図（その１）である。
【図１２】図６のステップＳ１２〜Ｓ３２の処理を説明するための図（その２）である。
【図１３】比較例の処理概要を示す図である。
【図１４】比較例において生成されるテストケース組合せを示す図（その１）である。
【図１５】比較例において生成されるテストケース組合せを示す図（その２）である。
【図１６】比較例においてＳＡＴソルバ後に抽出される組合せと、該組合せから作成される全条件節集合を示す図である。
【図１７】比較例におけるテストケース組合せのチェックについて説明するための図である。
【図１８】図１８（ａ）は、比較例における出力を示す図であり、図１８（ｂ）は、比較例と実施形態とを比較した表である。
【図１９】比較例の出力に無効な組合せが含まれることを示す図である。
【発明を実施するための形態】
【００１０】
以下、統合テスト装置の一実施形態について、図１〜図１２に基づいて詳細に説明する。本実施形態の統合テスト装置１０は、金融システム向けに、複数のシステム（ＳＳ：System Specification）仕様書から、統合テスト（ＩＴ：Integration Test）仕様書を自動生成する装置である。
【００１１】
図１には、一実施形態に係るテストケース仕様書結合装置としての統合テスト装置１０のハードウェア構成が示されている。図１に示すように、統合テスト装置１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、表示部９３、入力部９５、及び可搬型記憶媒体用ドライブ９９等を備えている。これら統合テスト装置１０の構成各部は、バス９８に接続されている。統合テスト装置１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（テストケース仕様書結合プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（テストケース仕様書結合プログラムを含む）をＣＰＵ９０が実行することにより、図２に示す機能が実現される。
【００１２】
図２には、統合テスト装置１０の機能ブロック図が示されている。統合テスト装置１０では、ＣＰＵ９０がプログラムを実行することで、プログラム変換部１２、テストケース仕様書生成部１４、テストケース仕様書結合部１６、ＩＴ仕様書変換部１８としての機能が実現されている。
【００１３】
プログラム変換部１２は、ＳＳ仕様書（例えばEXCELデータ）をそれぞれJava（登録商標）プログラムに変換する。
【００１４】
テストケース仕様書生成部１４は、シンボリック実行技術を用いてJava（登録商標）プログラムを解析し、テストケース仕様書（XMLデータ）を生成する。
【００１５】
テストケース仕様書結合部１６は、全てのテストケース仕様書に含まれるテストケースの組合せのうち充足可能な組合せを抽出し、結合したテストケース仕様書として出力する。なお、テストケース仕様書結合部１６の詳細については、後述する。
【００１６】
ＩＴ仕様書変換部１８は、結合したテストケース仕様書（XMLデータ）を、人間が理解可能なＩＴ仕様書（例えばEXCELデータ）に変換する。
【００１７】
ここで、本実施形態におけるテストケース仕様書の一例について、図３、図４に基づいて説明する。
【００１８】
図３は、ＡＴＭ（Automated Teller Machine）の利用シナリオの統合テスト内容を示し、図４は、図３の統合テストを実行するためのテストケース仕様書の例を示している。図３に示すように、統合テストのチェック項目は６種類（通帳、カード、取引、暗証番号、金額、エラー）あり、各チェック項目に対してあり得るチェック内容が定まっている。本例では、図４に示すように、テストケース仕様書は３つ（Ｘ，Ｙ，Ｚ）となり、ＸとＹはチェック系の仕様書で、Ｚは更新系の仕様書である。ここで、チェック系仕様書とは、システム状態やユーザ入力の様々な条件をチェックし、チェック結果によって正常ケースと異常ケースに分割するものである。一方、更新系仕様書は、システム状態やユーザ入力の様々な条件をチェックし、チェック結果によってシステム状態やユーザ入力値を更新する物である。また、各テストケース仕様書には順序が予め決められており、本例では、Ｘ→Ｙ→Ｚとなっている。更に、テストケース仕様書Ｘは９件のテストケースを有し、テストケース仕様書Ｙは４件のテストケースを有し、テストケース仕様書Ｚは４件のテストケースを有する。
【００１９】
例えば、テストケース仕様書Ｘの場合、ＩＤ＝Ｘ０１，Ｘ０２では、通帳記帳において、カードの有無を問わず、通帳が挿入されていなければエラーになることが示されている。また、ＩＤ＝Ｘ０３〜Ｘ０６では、預入れにおいて、カード及び通帳のいずれか、又は両方でも預入れが可能だが、カード及び通帳の両方がなければエラーになることが示されている。また、ＩＤ＝Ｘ０７〜Ｘ０９では、引き出しの場合、通帳の有無を問わず、カードが挿入されていなければエラーとなり、暗証番号が正しくない場合にもエラーとなることが示されている。
【００２０】
また、テストケース仕様書Ｙの場合、ＩＤ＝Ｙ０１，Ｙ０２では、引き出しの場合に、金額が５０万円を超えるとエラーになることが示されている。また、ＩＤ＝Ｙ０３，Ｙ０４では、預入れの場合に、１００万円を超えるとエラーになることが示されている。
【００２１】
また、テストケース仕様書Ｚの場合、ＩＤ＝Ｚ０１〜Ｚ０４では、条件によって更新処理が異なることが示されている。
【００２２】
図５には、図２のテストケース仕様書結合部１６の具体的な機能ブロック図が示されている。図５に示すように、テストケース仕様書結合部１６は、分類部としての前処理部２０、テストケース組合せ取得部２２、充足可能性判定部２４、出力部としての後処理部２６を有する。なお、テストケース組合せ取得部２２及び充足可能性判定部２４を含んで処理部の機能が実現されている。
【００２３】
前処理部２０は、テストケース仕様書生成部１４から出力されたテストケース仕様書（XMLデータ）を読み込み、条件を解析する。また、前処理部２０は、テストケース仕様書に含まれる各テストケースを正常ケースと異常ケースに分割する。また、前処理部２０は、全てのテストケースに含まれる条件節の集合（全条件節集合Ｃall）を作成する。
【００２４】
テストケース組合せ取得部２２は、テストケースの組合せを１組ずつ作成し、その組合せが所定条件を満たす場合に、充足可能性判定を行う組合せとして取得する。
【００２５】
充足可能性判定部２４は、テストケース組合せ取得部２２が取得したテストケースの組合せをＳＡＴソルバ（Satisfiability Solver）実行用数式コードに変換する。また、充足可能性判定部２４は、ＳＡＴソルバ実行用数式コードを入力とし、ＳＡＴソルバを実行して、充足可能（ＳＡＴ）となった組合せを抽出する。ここで、ＳＡＴソルバは、Yicesなどであり、与えられた条件や式を解析して充足可能性を判定する。この場合、ＳＡＴソルバは、与えられた条件や式を満たす解釈やモデル、値セットが１つでも見つかった場合に充足可能（ＳＡＴ）を出力し、見つからなかった場合に充足不可能（ＵＮＳＡＴ）を出力する。
【００２６】
後処理部２６は、テストケースのＩＤを整理するなどして、充足可能なテストケースの組合せを正規化し、正規化したテストケースの組合せをXMLデータに変換して、ＩＴ仕様書変換部１８に出力する。
【００２７】
次に、本実施形態のテストケース仕様書結合部１６が実行する処理について、図６のフローチャートに沿って詳細に説明する。図６の処理の前提として、図７（ａ）に示すようなテストケース仕様書がテストケース仕様書生成部１４から入力されるものとする。具体的には、テストケース仕様書は、Ｘ，Ｙ，Ｚの３種類があり、Ｘ，Ｙがチェック系仕様書で、Ｚが更新系仕様書となっている。また、テストケース使用書の順序は、Ｘ→Ｙ→Ｚの順となっており、生成されたテストケース件数（テストケース仕様書が含むテストケースの数）は、Ｘが４、Ｙが４、Ｚが３となっている。
【００２８】
また、テストケース仕様書の各テストケースの条件（前処理部２０によるXML解析後のテストケースのＩＤと条件式）は、図７（ｂ）のようになっているものとする。なお、条件式は、実際には、図４に示すような式となる場合が多いが、本実施形態では、図７（ｂ）に示すように、条件式を分かり易く表現するために変数（Ａ，Ｂ…）を用いることとしている。図７（ｂ）の各条件に含まれる変数は、図７（ｃ）の変数のタイプ・値一覧に示すようになっている。なお、図７（ｂ）の例では、error=0が正常を意味し、error=1が異常を意味している。また、テストケース仕様書Ｚは更新系仕様書であるため、正常ケース、異常ケースを分割するためのerror節は存在しない。
【００２９】
また、前処理部２０は、図６の処理の前に、テストケース仕様書に含まれる各テストケースを正常ケースと異常ケースに分割する。この場合、前処理部２０は、各テストケースに含まれるerror節に基づいて、図８（ａ）に示すテストケースを、図８（ｂ）に示すように正常ケース（上段）と、異常ケース（下段）とに分割する。なお、テストケース仕様書Ｚは、更新系仕様書であるので、全てのテストケースが正常ケースとなる。また、各テストケースのerror節は、分割後に各条件から削除される。なお、図６の処理が開始される時点では、選択済条件節集合Ｃselectedを空にしておく（図１１の最上段参照）。なお、選択済条件節集合Ｃselectedには、テストケース組合せ取得部２２が取得したテストケースの組合せに含まれる条件節が随時格納される。なお、予め正常ケースと異常ケースに分割されている場合には、上記処理は不要となる。
【００３０】
図６の処理では、まず、ステップＳ１０において、前処理部２０が、全条件節の和集合を全条件節集合Ｃallとする。具体的には、図９において(1)〜(6)を付して示すように、各テストケースに含まれる条件節を取り出し、その和集合を全条件節集合Ｃallとする。
【００３１】
次いで、ステップＳ１２では、テストケース組合せ取得部２２が、次の組合せを取得する。ここで、テストケース組合せ取得部２２は、以下の条件の下、次の組合せを取得する。
（Ａ）正常ケースを多く含むテストケースの組合せを優先する。
（Ｂ）テストケース組合せに含まれる条件節のうち、選択済条件節集合Ｃselectedに含まれない条件節が多い組合せを優先して選択する。
（Ｃ）空の異常ケースを含む組合せは空とする、という条件の下、次の組合せを取得する。
【００３２】
上記（Ａ）の条件を適用すると、図１０（ａ）の（１）に示すように、「Ｘ＿正常→Ｙ＿正常→Ｚ＿正常」が最優先となる。また、次に優先されるのは、「Ｘ＿正常→Ｙ＿正常→Ｚ＿異常」だが、Ｚ＿異常は空であるので、（Ｃ）の条件より、組合せが空となる。また、次に優先されるのは、「Ｘ＿正常→Ｙ＿異常」であり、その次に優先されるのは、「Ｘ＿異常」である。なお、図１０（ｂ）は、（Ａ）、（Ｃ）の条件を適用した場合の優先順をまとめたテーブルである。
【００３３】
したがって、ステップＳ１２では、テストケース組合せ取得部２２は、最も優先される「Ｘ＿正常→Ｙ＿正常→Ｚ＿正常」の組合せの１つ（ここでは、Ｘ０１→Ｙ０１→Ｚ０１を取得する（図１１の符号（Ｓ１２−１）参照）。なお、以下においては、テストケースの組合せを「Ｘ０１Ｙ０１Ｚ０１」のように表記する。
【００３４】
次いで、ステップＳ１４では、テストケース組合せ取得部２２が、条件節の和集合Ｃcombを取得する。この場合、テストケースの組合せＸ０１Ｙ０１Ｚ０１においては、Ｃcombとして、「A=1 & B<100 & C!="p" & C!="q" & B>0 & D=true」が取得される（図１１の符号（Ｓ１４−１）参照）。
【００３５】
次いで、ステップＳ１６では、テストケース組合せ取得部２２が、Ｃcomb⊂Ｃselectedであるか否かを判断する。すなわち、テストケース組合せに含まれる全ての条件節が選択済条件節集合Ｃselectedに含まれる条件節に含まれているか否かを判断する。ここでは、Ｃselectedは、空であるので、判断は否定され、ステップＳ１８に移行する。なお、ステップＳ１６の判断が肯定された場合には、ステップＳ１２に移行する。
【００３６】
ステップＳ１８に移行すると、テストケース組合せ取得部２２は、条件を組み合わせる。次いで、ステップＳ２０では、充足可能性判定部２４は、組み合わせた条件の充足可能性判定をＳＡＴソルバにより実行する。なお、ここでは、図１１の符号（Ｓ２０−１）に示すように、ＳＡＴソルバの結果、ＳＡＴであったとする。
【００３７】
次いで、ステップＳ２２では、充足可能性判定部２４が、ＳＡＴソルバの結果、ＳＡＴであったか否かを判断する。ここでの判断が否定された場合には、ステップＳ１２に移行するが、肯定された場合には、ステップＳ２４に移行する。
【００３８】
ステップＳ２４に移行すると、充足可能性判定部２４は、テストケースの組合せを出力のテストケース組合せに追加する（図１１の符号（Ｓ２４−１）参照）。次いで、ステップＳ２６では、充足可能性判定部２４が、テストケースの組合せに含まれる条件節のうち選択済条件節集合Ｃselectedに既存しない条件節をＣselectedに追加する。この場合、ステップＳ１４で取得した条件節の和集合Ｃcombの全てが選択済条件節集合Ｃselectedに追加される（図１１の符号（Ｓ２６−１）参照）。
【００３９】
次いで、ステップＳ２８では、充足可能性判定部２４が、Ｃselected＝Ｃallであるか否かを判断する。なお、本処理においては、全てのテストケースの全ての条件節が、少なくとも１回、出力のテストケース組合せに出現していればよいという概念に基づいて、ステップＳ２８の判断は行われる。ここでは、図９の全条件節集合Ｃallと、選択済条件節集合Ｃselectedとは一致しないので、判断は否定され、ステップＳ１２に戻る。
【００４０】
ステップＳ１２に戻ると、上述した処理を繰り返す。すなわち、ステップＳ１２では、テストケース組合せ取得部２２は、最も優先される「Ｘ＿正常→Ｙ＿正常→Ｚ＿正常」の組合せのうち、上述した（Ｂ）の条件（テストケース組合せに含まれる条件節のうち、選択済条件節集合Ｃselectedに含まれない条件節が多い組合せを優先して選択する）に基づいて、テストケースの組合せを取得する。ここでは、最も優先されるＸ＿正常→Ｙ＿正常→Ｚ＿正常の組合せのうち（Ｂ）の条件を満たす組合せ「Ｘ０３Ｙ０４Ｚ０２」が取得される（図１１の符号（Ｓ１２−２）参照）。
【００４１】
次いで、ステップＳ１４では、テストケース組合せ取得部２２が、組合せ「Ｘ０３Ｙ０４Ｚ０２」の条件節の和集合Ｃcombとして「A=2 & B≧200 & A!=3 & C="s" & B>300 & D=false」を取得する（図１１の符号（Ｓ１４−２）参照）。その後、ステップＳ１６の判断が否定されると、ステップＳ１８において、条件が組み合わされ、ステップＳ２０において、充足可能性判定部２４は、組み合わせた条件の充足可能性判定をＳＡＴソルバにより実行する。なお、ここでは、図１１の符号（Ｓ２０−２）に示すように、ＳＡＴソルバの結果、ＳＡＴであったとする。従って、ステップＳ２２の判断は肯定され、ステップＳ２４において、充足可能性判定部２４は、テストケースの組合せを出力のテストケース組合せに追加する（図１１の符号（Ｓ２４−２）参照）。次いで、ステップＳ２６では、充足可能性判定部２４が、テストケースの組合せに含まれる条件節のうち選択済条件節集合Ｃselectedに既存しない条件節（図１１の符号（Ｓ１４−２）において下線を付した全ての条件節）をＣselectedに追加する（図１１の符号（Ｓ２６−２）参照）。その後は、ステップＳ２８において、充足可能性判定部２４が、Ｃselected＝Ｃallであるか否かを判断する。ここでは、図９の全条件節集合Ｃallと、選択済条件節集合Ｃselectedとは一致しないので、ステップＳ２８の判断は否定され、ステップＳ１２に戻る。
【００４２】
ステップＳ１２に戻ると、テストケース組合せ取得部２２は、上記と同様、最も優先される「Ｘ＿正常→Ｙ＿正常→Ｚ＿正常」の組合せから次の組合せを取得しようとする。ただし、選択済条件節集合Ｃselectedに含まれない条件節を有するテストケースの組合せが存在していない（Ｓ１６：肯定）。したがって、テストケース組合せ取得部２２は、次に優先される「Ｘ＿正常→Ｙ＿異常」の組合せ（図１０（ａ）、図１０（ｂ）の（３）の組合せ）の中から次の組合せを取得する。この場合、テストケース組合せ取得部２２は、図１２に示すように、（Ｂ）の条件に基づいて、テストケースの組合せ「Ｘ０１Ｙ０２」を取得する（符号（Ｓ１２−３）参照）。
【００４３】
次いで、ステップＳ１４では、テストケース組合せ取得部２２が、組合せ「Ｘ０１Ｙ０２」の条件節の和集合Ｃcombとして「A=1 & B<100 & A!=2 & C!="p"」を取得する（図１２の符号（Ｓ１４−３）参照）。その後、ステップＳ１６の判断が否定されると、ステップＳ１８において、条件が組み合わされ、ステップＳ２０において、充足可能性判定部２４は、組み合わせた条件の充足可能性判定をＳＡＴソルバにより実行する。なお、ここでは、図１２の符号（Ｓ２０−３）に示すように、ＳＡＴソルバの結果、ＳＡＴであったとする。従って、ステップＳ２２の判断は肯定され、ステップＳ２４において、充足可能性判定部２４は、テストケースの組合せを出力のテストケース組合せに追加する（図１２の符号（Ｓ２４−３）参照）。次いで、ステップＳ２６では、充足可能性判定部２４が、テストケースの組合せに含まれる条件節のうち選択済条件節集合Ｃselectedに既存しない条件節（図１２の符号（Ｓ１４−３）において下線を付した条件節）をＣselectedに追加する（図１２の符号（Ｓ２６−３）参照）。その後は、ステップＳ２８において、充足可能性判定部２４が、Ｃselected＝Ｃallであるか否かを判断する。ここでは、図９の全条件節集合Ｃallと、選択済条件節集合Ｃselectedとは一致しないので、ステップＳ２８の判断は否定され、ステップＳ１２に戻る。
【００４４】
ステップＳ１２に戻ると、テストケース組合せ取得部２２は、上記と同様、「Ｘ＿正常→Ｙ＿異常」の組合せの中から次の組合せを取得する。この場合、テストケース組合せ取得部２２は、図１２に示すように、（Ｂ）の条件に基づいて、テストケースの組合せ「Ｘ０３Ｙ０３」を取得する（符号（Ｓ１２−４）参照）。
【００４５】
次いで、ステップＳ１４では、テストケース組合せ取得部２２が、組合せ「Ｘ０３Ｙ０３」の条件節の和集合Ｃcombとして「A=2 & B≧200 & A!=3 & C="p"」を取得する（図１２の符号（Ｓ１４−４）参照）。その後、ステップＳ１６の判断が否定されると、ステップＳ１８において、条件が組み合わされ、ステップＳ２０において、充足可能性判定部２４は、組み合わせた条件の充足可能性判定をＳＡＴソルバにより実行する。なお、ここでは、図１２の符号（Ｓ２０−４）に示すように、ＳＡＴソルバの結果、ＳＡＴであったとする。従って、ステップＳ２２の判断は肯定され、ステップＳ２４において、充足可能性判定部２４は、テストケースの組合せを出力のテストケース組合せに追加する（図１２の符号（Ｓ２４−４）参照）。次いで、ステップＳ２６では、充足可能性判定部２４が、テストケースの組合せに含まれる条件節のうち選択済条件節集合Ｃselectedに既存しない条件節（図１２の符号（Ｓ１４−４）において下線を付した条件節）をＣselectedに追加する（図１２の符号（Ｓ２６−４）参照）。その後は、ステップＳ２８において、充足可能性判定部２４が、Ｃselected＝Ｃallであるか否かを判断する。ここでは、図９の全条件節集合Ｃallと、選択済条件節集合Ｃselectedとは一致するので、ステップＳ２８の判断は肯定され、ステップＳ３０に移行する。
【００４６】
ステップＳ３０に移行すると、充足可能性判定部２４は、最初の仕様書が異常の組合せがあれば、出力のテストケース組合せにそのまま追加する。本実施形態では、「Ｘ＿異常」である「Ｘ０２」と「Ｘ０４」が、出力のテストケース組合せに追加される（図１２の符号（Ｓ３０−１）、（Ｓ３０−２）参照）。ステップＳ３０の後は、ステップＳ３２に移行し、後処理部２６は、出力のテストケース組合せをＸＭＬデータに変換して、ＩＴ仕様書変換部１８に出力する。その後は、図６の全処理が終了する。
【００４７】
ここで、本実施形態では、図６の処理を実行することにより、ＳＡＴソルバを網羅的に実行する場合と比べて、実行回数を減少することができる。本例ではＳＡＴソルバの実行回数は４回で済む。また、出力のテストケース組合せは、全て有効なものとなる。
【００４８】
（比較例）
次に、比較例について、図１３〜図１９に基づいて説明する。
【００４９】
図１３には、比較例の手順の概要が示されている。図１３に示すように、比較例においては、（１）テストケース仕様書から、テストケースの全組合せを網羅的に生成し、（２）ＳＡＴソルバによる充足可能性判定により充足可能な組合せを抽出し、（３）条件網羅によりテストケース組合せを絞り込む処理を実行する。なお、条件網羅による絞込みについては、上記実施形態と同様、全てのテストケースの全ての条件節が、少なくとも１回、出力のテストケース組合せに出現していればよいという概念に基づいている。以下、比較例における処理の主体は、「テストケース仕様書結合部１６’」であるものとして、説明する。
【００５０】
この比較例の手順を実現するため、まず、（１）テストケース仕様書結合部１６’は、Ｘ，Ｙ、Ｚの全組合せを網羅的な順番に取得し、図１４、図１５に示すように、４×４×３＝４８件のテストケース組合せを生成する。なお、error節は比較例では用いないので、図１４、図１５では削除している。また、条件節が重複する組合せは、１つを残し、その他を削除する。例えば、図１４のＮｏ．１３と、Ｎｏ．１５が重複し、Ｎｏ．１６とＮｏ．１８が重複するので、Ｎｏ．１３とＮｏ．１６を残し、Ｎｏ．１５とＮｏ．１８を削除する。
【００５１】
次いで、（２）テストケース仕様書結合部１６’は、各テストケースの組合せの充足可能性判定をＳＡＴソルバにより実行し、ＳＡＴな組合せのみを抽出する。なお、図１４、図１５の条件節のうち、下線が付された条件節は、ＵＮＳＡＴの原因となった競合する条件節を意味する。この場合、図１４、図１５に示すような充足可能性の判定結果から、図１６の上段に示すような２６組の組合せが抽出されることになる。
【００５２】
次いで、（３−１）テストケース仕様書結合部１６’は、全てのテストケースの組合せの条件節の和集合を求め、全条件節集合Ｃallを作成する（図１６の下段参照）。次いで、（３−２）テストケース仕様書結合部１６’は、選択済条件節集合Ｃselectedを空にし、（３−３）テストケース組合せを１つずつ取得し、チェックを行う。
【００５３】
（３−３）のチェックにおいては、テストケース仕様書結合部１６’は、取得したテストケースの組合せの条件節の全てが、選択済条件節集合Ｃselectedに既存するか否かをチェックし、既存している場合には、そのテストケースの組合せを消去する。一方、取得したテストケースの組合せの条件節の少なくとも１つが選択済条件節集合Ｃselectedに既存していない場合には、取得したテストケースの組合せを消去せずに、既存していない条件節を選択済条件節集合Ｃselectedに含める。そして、選択済条件節集合Ｃselectedが全条件節集合Ｃallと一致した場合に、チェックを終了する。
【００５４】
具体的には、テストケース仕様書結合部１６’は、図１７に示すように、Ｎｏ．１、Ｎｏ．２…の順にテストケースの組合せを取得して、チェックを行う。すなわち、Ｎｏ．１のテストケースの組合せが取得されると、条件節の全てが選択済条件節集合Ｃselectedに含まれていないので、組合せは消去されずに、条件節の全てが選択済条件節集合Ｃselectedに含められる（図１７の実線矢印）。次いで、Ｎｏ．２の組合せが取得されると、条件節の全てが選択済条件節集合Ｃselectedに含まれているので、組合せは消去される。この場合、選択済み条件節集合Ｃselectedには何も含められない（図１７の破線矢印）。また、Ｎｏ．３の組合せが取得されると、条件節の一部が選択済条件節集合Ｃselectedに含まれていないので、組合せは消去されずに、選択済条件節集合Ｃselectedに含まれていない条件節が選択済条件節集合Ｃselectedに含められる。次いで、Ｎｏ．４の組合せが取得されると、条件節の全てが選択済条件節集合Ｃselectedに含まれているので、組合せは消去される。以降、Ｎｏ．１７の組合せまで同様の処理を実行すると、選択済条件節集合Ｃselectedが全条件節集合Ｃallと一致するので、チェックを終了する（Ｎｏ．１８〜２６のチェックは行わない）。
【００５５】
以上の処理により、比較例では、図１８（ａ）に示すような６つのテストケースの組合せを出力することになる。図１８（ｂ）には、比較例と本実施形態におけるＳＡＴソルバの実行回数及び絞込みでの条件チェック回数を対比した表が示されている。比較例においては、ＳＡＴソルバの実行回数が４８回となり、絞込みでの条件チェック回数（図１７のチェック回数）が１７回となった。一方、本実施形態では、前述のように、ＳＡＴソルバの回数が４回、絞込みでの条件チェック回数も４回となっている。この結果から、本実施形態では、ＳＡＴソルバの実行回数、絞込みでの条件チェック回数を減少させることができたことがわかる。
【００５６】
また、比較例においては、図１９に示すように、無効となる組合せが４つ存在する。例えば、組合せ「Ｘ０１Ｙ０２Ｚ０１」は、Ｙ０２が異常ケースであり、Ｚ０１と組み合わせても無駄であり、実際には無効になる組合せである。また、組合せ「Ｘ０１Ｙ０３Ｚ０３」も、Ｙ０３が異常ケースであるので、Ｚ０３と組み合わせても無駄であり、実際には無効になる組合せである。また、「Ｘ０２Ｙ０１Ｚ０２」は、Ｘ０２が異常ケースであるため、Ｙ０１，Ｚ０２と組み合わせても無駄であり、実際には無効になる組合せである。更に、「Ｘ０３Ｙ０３Ｚ０２」は、Ｙ０３が異常ケースであるため、Ｚ０２と組み合わせても無駄であり、実際には無効になる組合せである。これに対し、本実施形態では、予めテストケースを正常ケースと、異常ケースとに分けてテストケースを組合せているため、無効な組合せは出力されないという利点がある。
【００５７】
以上、詳細に説明したように、本実施形態によると、前処理部２０が、順序が予め定まっている複数のテストケース仕様書に含まれるテストケースを正常ケースと異常ケースの２種類に分類する。そして、テストケース組合せ取得部２２が実行する、順序と、分類されたテストケースの種類（正常ケース又は異常ケース）と、に基づいて特定されるテストケースの組合せの中から、選択済条件節集合Ｃselectedに含まれていない条件節を含み、その数が最も多いテストケースの組合せを取得する処理（Ｓ１４、Ｓ１６）と、充足可能性判定部２４が実行する、取得したテストケースの組合せが充足可能な組合せかをＳＡＴソルバにより判定する処理（Ｓ２０）と、取得したテストケースの組合せに含まれる条件節を選択済条件節集合Ｃselectedに追加する処理（Ｓ２６）を、選択済条件節集合Ｃselectedに含まれる条件節と全条件節集合Ｃallに含まれる条件節とが一致するまで繰り返し（Ｓ２８）、後処理部２６が、充足可能（ＳＡＴ）と判定されたテストケースの組合せを出力する（Ｓ３２）。これにより、テストケースを正常ケースと異常ケースに分割し、分割した結果に基づいてテストケースの組合せを特定するので、無効なテストケースの組合せが出力されるのを抑制することができる。特に、本実施形態では、テストケース組合せ取得部２２は、テストケースの組合せを取得する際に、正常ケースを優先し、異常ケースの後に他のテストケースを組み合わせないこととしているので、無効なテストケースの組合せが出力されるのを防止することができる。また、上記のように正常ケースと異常ケースに分類して処理することで、テストケース仕様書が多い場合でも組合せが爆発する可能性が低くなり、処理の効率化を図ることが可能となる。また、選択済条件節集合Ｃselectedに含まれていない条件節を最も多く含むテストケースの組合せからＳＡＴソルバを実行し、当該テストケースの組合せに含まれる条件節を選択済条件節集合Ｃselectedに追加するので、網羅的にテストケースを特定する場合と比較して、選択済条件節集合Ｃselectedに含まれる条件節と全条件節集合Ｃallに含まれる条件節とが一致するまでの時間を短くすることができるとともに、ＳＡＴソルバの回数を低減することができる。更に、選択済条件節集合Ｃselectedに含まれていない条件節を含むテストケースの組合せについてのみ、充足可能な組合せかをＳＡＴソルバにより判定する（Ｓ２０）ので、比較例のようにＳＡＴソルバによる判定の後に選択済条件節集合Ｃselectedに含まれていない条件節を含むか否かを判断する場合と比べ、ＳＡＴソルバの回数を低減することができる。以上のように、本実施形態によれば、効率的に有効なテストケースの組合せを決定することができる。
【００５８】
また、本実施形態では、後処理部２６は、順序が最初のテストケース仕様書（Ｘ）に含まれる異常ケースをＩＴ仕様書変換部１８に出力する。これにより、他のテストケースと組み合わせることがないが、独立して充足可能なテストケースを漏れなく出力することが可能となる。
【００５９】
なお、上記実施形態では、金融システム向けのテスト仕様書に関する処理について説明したが、これに限らず、その他のチェック系仕様書を含む複数のテストケース仕様書を結合する処理において、上記実施形態を適用することも可能である。
【００６０】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体（ただし、搬送波は除く）に記録しておくことができる。
【００６１】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【００６２】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【００６３】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【００６４】
なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
(付記１）  順序が予め定まっている複数のテストケース仕様書を結合するテストケース仕様書結合プログラムであって、
前記複数のテストケース仕様書に含まれるテストケースを正常と異常の２種類に分類し、
前記順序と、分類された前記テストケースの種類と、に基づいて特定されるテストケースの組合せの中から、取得済みの条件節を格納する格納部に格納されていない条件節を含み、該格納部に格納されていない条件節の数が最も多いテストケースの組合せを取得する処理と、取得した前記テストケースの組合せが充足可能な組合せかを判定する処理と、取得した前記テストケースの組合せに含まれる条件節を前記格納部に格納する処理とを、所定のタイミングまで繰り返し、
充足可能な組合せと判定された前記テストケースの組合せを出力する、処理をコンピュータに実行させ、
前記所定のタイミングは、前記格納部に格納された条件節が、前記複数のテストケース仕様書に含まれる全ての条件節と一致したタイミングである、ことを特徴とするテストケース仕様書結合プログラム。
(付記２）  前記出力する処理では、更に、前記順序が最初のテストケース仕様書に含まれる異常に分類されたテストケースを出力する、ことを特徴とする付記１に記載のテストケース仕様書結合プログラム。
(付記３）  前記繰り返す処理において、前記テストケースの組合せを特定する際に、正常に分類されたテストケースを優先し、異常に分類されたテストケースと前記順序が該異常に分類されたテストケースの後方のテストケースとは組み合わせない、ことを特徴とする付記１又は２に記載のテストケース仕様書結合プログラム。
(付記４）  順序が予め定まっている複数のテストケース仕様書を結合するテストケース仕様書結合方法であって、
前記複数のテストケース仕様書に含まれるテストケースを正常と異常の２種類に分類し、
前記順序と、分類された前記テストケースの種類と、に基づいて特定されるテストケースの組合せの中から、取得済みの条件節を格納する格納部に格納されていない条件節を含み、該格納部に格納されていない条件節の数が最も多いテストケースの組合せを取得する処理と、取得した前記テストケースの組合せが充足可能な組合せかを判定する処理と、取得した前記テストケースの組合せに含まれる条件節を前記格納部に格納する処理とを、所定のタイミングまで繰り返し、
充足可能な組合せと判定された前記テストケースの組合せを出力する、処理をコンピュータが実行し、
前記所定のタイミングは、前記格納部に格納された条件節が、前記複数のテストケース仕様書に含まれる全ての条件節と一致したタイミングである、ことを特徴とするテストケース仕様書結合方法。
(付記５）  前記出力する処理では、更に、前記順序が最初のテストケース仕様書に含まれる異常に分類されたテストケースを出力する、ことを特徴とする付記４に記載のテストケース仕様書結合方法。
(付記６）  前記繰り返す処理において、前記テストケースの組合せを特定する際に、正常に分類されたテストケースを優先し、異常に分類されたテストケースと前記順序が該異常に分類されたテストケースの後方のテストケースとは組み合わせない、ことを特徴とする付記４又は５に記載のテストケース仕様書結合方法。
（付記７）  順序が予め定まっている複数のテストケース仕様書を結合するテストケース仕様書結合装置であって、
前記複数のテストケース仕様書に含まれるテストケースを正常と異常の２種類に分類する分類部と、
前記順序と、分類された前記テストケースの種類と、に基づいて特定されるテストケースの組合せの中から、取得済みの条件節を格納する格納部に格納されていない条件節を含み、該格納部に格納されていない条件節の数が最も多いテストケースの組合せを取得する処理と、取得した前記テストケースの組合せが充足可能な組合せかを判定する処理と、取得した前記テストケースの組合せに含まれる条件節を前記格納部に格納する処理とを、所定のタイミングまで繰り返す処理部と、
充足可能な組合せと判定された前記テストケースの組合せを出力する出力部と、を備え、
前記所定のタイミングは、前記格納部に格納された条件節が、前記複数のテストケース仕様書に含まれる全ての条件節と一致したタイミングである、ことを特徴とするテストケース仕様書結合装置。
(付記８）  前記出力部は、前記順序が最初のテストケース仕様書に含まれる異常に分類されたテストケースを更に出力する、ことを特徴とする付記７に記載のテストケース仕様書結合装置。
(付記９）  前記処理部は、前記テストケースの組合せを特定する際に、正常に分類されたテストケースを優先し、異常に分類されたテストケースと前記順序が該異常に分類されたテストケースの後方のテストケースとは組み合わせない、ことを特徴とする付記７又は８に記載のテストケース仕様書結合装置。
【符号の説明】
【００６５】
１０  統合テスト装置（テストケース仕様書結合装置）
２０  前処理部（分類部）
２２  テストケース組合せ取得部（処理部の一部）
２４  充足可能性判定部（処理部の一部）
２６  後処理部（出力部）
【図１】
2016110327.tif 000003
【図２】
2016110327.tif 000004
【図３】
2016110327.tif 000005
【図４】
2016110327.tif 000006
【図５】
2016110327.tif 000007
【図６】
2016110327.tif 000008
【図７】
2016110327.tif 000009
【図８】
2016110327.tif 000010
【図９】
2016110327.tif 000011
【図１０】
2016110327.tif 000012
【図１１】
2016110327.tif 000013
【図１２】
2016110327.tif 000014
【図１３】
2016110327.tif 000015
【図１４】
2016110327.tif 000016
【図１５】
2016110327.tif 000017
【図１６】
2016110327.tif 000018
【図１７】
2016110327.tif 000019
【図１８】
2016110327.tif 000020
【図１９】
2016110327.tif 000021