(57)【特許請求の範囲】
【請求項１】
ソフトウェア仕様としてＩＦ−ＴＨＥＮ形式で記述したルールのテスト装置であって、
前記ルールが成立するための条件を格納する条件部と当該条件が成立した場合の結果を格納する結果部とを含む前記ルールの１以上の集まりであるルールセットを受け付けるルール作成・修正部と、
論理式で記述されたテストの対象とする入力値の条件を格納する入力条件部と当該入力値の条件を満たす入力に対して期待する結果を格納する期待出力条件部とを含む１以上の論理テストケースを受け付けるテストケース修正・作成部と、
１以上の前記ルールセットと１つの前記論理テストケースから、当該ルールセットの入出力のうち、当該論理テストケースの入力条件を満たしかつ当該論理テストケースの期待出力条件を満たさないケースを表す不合格ケース生成式を生成し、当該不合格ケース生成式の充足可能性を判定することで前記論理テストケースの入力条件を満たす全入力に対する結果が前記期待出力条件を満たすか否かの合否を判定するテスト実行部と、
前記テスト実行部が判定したテスト結果を出力するテスト結果出力部と
を備えるルールテスト装置。
【請求項２】
請求項１に記載のルールテスト装置であって、
前記テスト実行部は、前記論理テストケースごとの前記合否、前記論理テストケースの入力条件を満たしかつ当該論理テストケースの前記期待出力条件を満たさない時に適用される１以上の前記ルールを含む不合格ケース、および、前記論理テストケースの入力条件を満たしかつ当該論理テストケースの前記期待出力条件を満たすときに適用される１以上の前記ルールを含む合格ケース、を一部または全て取得および記録し、
前記テスト結果出力部は、前記テスト実行部が判定したテスト結果として前記テスト実行部が記録した前記合否、前記不合格ケースおよび前記合格ケースを表示する
ことを特徴とするルールテスト装置。
【請求項３】
請求項１または２に記載のルールテスト装置であって、
前記テストの対象が同じである前記論理テストケースを１以上含むテストケースセットごとに、テストしていない前記ルールセットの入力の存在を漏れとして検知するテストケース漏れ検査部と、
前記漏れおよび前記ルールセットを用いて、当該漏れに相当する前記ルールセットの入力の範囲をテストするための補完テストケースを１以上生成する補完テストケース生成部と
をさらに備えるルールテスト装置。
【請求項４】
請求項２または請求項２を引用する請求項３に記載のルールテスト装置であって、
前記論理テストケースごとの前記合否、前記不合格ケースおよび前記合格ケースを分析し、前記不合格ケースに偏って含まれる前記ルールおよび前記不合格ケースに共通する前記ルールを特定する不具合箇所分析部をさらに備えるルールテスト装置。
【請求項５】
請求項２または３に記載のルールテスト装置であって、
前記ルールの編集内容および前記テスト実行部が判定したテスト結果を用いて、当該ルールの編集により前記テスト実行部が判定する前記合否が変わる可能性のある前記論理テストケースを特定する影響範囲分析部をさらに備えるルールテスト装置。
【請求項６】
ソフトウェア仕様としてＩＦ−ＴＨＥＮ形式で記述したルールのテスト方法であって、
前記ルールが成立するための条件を格納する条件部と当該条件が成立した場合の結果を格納する結果部とを含む前記ルールの１以上の集まりであるルールセットを受け付ける第１のステップと、
論理式で記述されたテストの対象とする入力値の条件を格納する入力条件部と当該入力値の条件を満たす入力に対して期待する結果を格納する期待出力条件部とを含む１以上の論理テストケースを受け付ける第２のステップと、
１以上の前記ルールセットと１つの前記論理テストケースから、当該ルールセットの入出力のうち、当該論理テストケースの入力条件を満たしかつ当該論理テストケースの期待出力条件を満たさないケースを表す不合格ケース生成式を生成し、当該不合格ケース生成式の充足可能性を判定することで前記論理テストケースの入力条件を満たす全入力に対する結果が前記期待出力条件を満たすか否かの合否を判定する第３のステップと、
前記第３のステップで判定したテスト結果を出力する第４のステップと
を有するルールテスト方法。
【請求項７】
請求項６に記載のルールテスト方法であって、
前記第３のステップは、前記論理テストケースごとの前記合否、前記論理テストケースの入力条件を満たしかつ当該論理テストケースの前記期待出力条件を満たさない時に適用される１以上の前記ルールを含む不合格ケース、および、前記論理テストケースの入力条件を満たしかつ当該論理テストケースの前記期待出力条件を満たすときに適用される１以上の前記ルールを含む合格ケース、を一部または全て取得および記録することを含み、
前記第４のステップは、前記第３のステップで判定したテスト結果として記録した前記合否、前記不合格ケースおよび前記合格ケースを表示することを含む
ことを特徴とするルールテスト方法。
【請求項８】
請求項６または７に記載のルールテスト方法であって、
前記テストの対象が同じである前記論理テストケースを１以上含むテストケースセットごとに、テストしていない前記ルールセットの入力の存在を漏れとして検知するテストケース漏れ検査ステップと、
前記漏れおよび前記ルールセットを用いて、当該漏れに相当する前記ルールセットの入力の範囲をテストするための補完テストケースを１以上生成する補完テストケース生成ステップと
をさらに有するルールテスト方法。
【請求項９】
請求項７または請求項７を引用する請求項８に記載のルールテスト方法であって、
前記論理テストケースごとの前記合否、前記不合格ケースおよび前記合格ケースを分析し、前記不合格ケースに偏って含まれる前記ルールおよび前記不合格ケースに共通する前記ルールを特定する不具合箇所分析ステップをさらに有するルールテスト方法。
【請求項１０】
請求項７または８に記載のルールテスト方法であって、
前記ルールの編集内容および前記第３のステップで判定したテスト結果を用いて、当該ルールの編集により前記第３のステップで判定する前記合否が変わる可能性のある前記論理テストケースを特定する影響範囲分析ステップをさらに有するルールテスト方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ルールの不具合を検出するためのルールテスト装置およびルールテスト方法に関する。
【背景技術】
【０００２】
流通や金融などの業務を支援するソフトウェアは、商品、サービス等の業務に関する法的な規制、業務上の規則および基準等（以下、「業務規則」という）に従って仕様が決定され設計される。
そのようなソフトウェアでは、ＩＦ−ＴＨＥＮ形式でその仕様を整理する場合がある。ＩＦ−ＴＨＥＮ形式の仕様（以下、ＩＦ節を「条件部」、ＴＨＥＮ節を「結果部」という）は、ビジネスルール、システムルールおよびチェックルールなどのように、適用するフェーズに応じて様々な呼び名がある（以下、これらを「ルール」という）。ルールは、「もし〜ならば〜である」のような自然文による記述、「ＩＦ  Ａ＝１  ＡＮＤ  Ｂ＝２  ＴＨＥＮ  Ｒ＝１」のようなコンピュータにより解釈可能な所定の規則に従った記述および条件と結果の対応関係を表形式で定義した決定表による記述など、さまざまな形態で表現される。
【０００３】
ルールは、業務規則に従って決定されるため、業務規則と整合している必要がある。整合性しているかどうかは、例えば、有識者によるレビューによって確認できる。しかし、例えば法的な規制を例にとると、膨大な数のルールがあり、また、ルール間の依存関係などにより複雑である。そのため、レビューでは、ルールと業務規則の整合性を確認することは非常に困難である。
ルールが、規則と整合しているかを確認する別の方法として、ルールに対して具体的な入力値を与え、期待する結果が得られるかを確認する方法（以下、「テスト」という）が、例えば、特許文献１に開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願公開第２００９／０１１２６５４号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に開示されている技術により、具体的な入力値を使って、テストした範囲内で、ルールと業務規則の整合性を保証できるが、テストしていない範囲については、ルールと業務規則の整合性を保証できない。ルールと業務規則の整合性を保証するには、起こり得る全ての入力値の組合せを使ってテストする必要がある。しかし、起こり得る入力値の組合せ数が膨大になると、実用時間でテストを完了させることは、困難になる。
【課題を解決するための手段】
【０００６】
本発明に係るルールテスト装置は、ソフトウェア仕様としてＩＦ−ＴＨＥＮ形式で記述したルールのテスト装置であって、前記ルールが成立するための条件を格納する条件部と当該条件が成立した場合の結果を格納する結果部とを含むルールの１以上の集まりであるルールセットを受け付けるルール作成・修正部と、論理式で記述されたテストの対象とする入力値の条件を格納する入力条件部と当該入力値の条件を満たす入力に対して期待する結果を格納する期待出力条件部とを含む１以上の論理テストケースを受け付けるテストケース修正・作成部と、１以上の前記ルールセットと１つの前記論理テストケースから、当該ルールセットの入出力のうち、当該論理テストケースの入力条件を満たしかつ当該論理テストケースの期待出力条件を満たさないケースを表す不合格ケース生成式を生成し、当該不合格ケース生成式の充足可能性を判定することで前記論理テストケースの入力条件を満たす全入力に対する結果が前記期待出力条件を満たすか否かの合否を判定するテスト実行部と、テスト実行部が判定したテスト結果を出力するテスト結果出力部とを備える。
【発明の効果】
【０００７】
本発明に係るルールテスト装置によれば、１つのテストケースで複数の入力に対してテストが実施でき、また、テストしていないルールへの入力を検知でき、ルールの網羅的なテストが実用時間で実施可能になる。
【図面の簡単な説明】
【０００８】
【図１】図１は、本発明に係るルールテスト装置の構成の例を示す図である。
【図２】図２は、ルールテストの例を示す図である。
【図３】図３は、ルール記録部のデータ構造の例を示す図である。
【図４】図４は、テストケース記録部のデータ構造の例を示す図である。
【図５】図５は、テストケースセットの記述例を示す図である。
【図６】図６は、テスト結果記録部のデータ構造の例を示す図である。
【図７】図７は、ルールの作成・編集画面の例を示す図である。
【図８】図８は、テストケースセットの作成・編集画面の例を示す図である。
【図９】図９は、テスト結果表示画面の例を示す図である。
【図１０】図１０は、適用ケース表示画面の例を示す図である。
【図１１】図１１は、適用ケースの分析結果画面の例を示す図である。
【図１２】図１２は、補完テストケースの表示・編集画面の例を示す図である。
【図１３】図１３は、テストケース漏れ検査部が実行する処理のフローチャートを示す図である。
【図１４】図１４は、漏れ検査式および関連する論理式の例を示す図である。
【図１５】図１５は、テスト実行部が実行する処理のフローチャートを示す図である。
【図１６】図１６は、テスト実行部の処理フローで生成する論理式の例を示す図である。
【図１７】図１７は、補完テストケース生成部が実行する処理のフローチャートを示す図である。
【図１８】図１８は、補完テストケース生成部の処理フローで生成する論理式の例を示す図である。
【図１９】図１９は、不具合箇所分析部が実行する処理のフローチャートを示す図である。
【図２０】図２０は、影響範囲分析部が実行する処理のフローチャートを示す図である。
【図２１】図２１は、合否の変わる可能性のある論理テストケースを取得するために影響範囲分析部が実行する処理のフローチャートを示す図である。
【発明を実施するための形態】
【０００９】
以下、本発明に係る実施形態を、実施例として、図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明する諸要素およびその組み合わせの全てが発明の解決手段に必須であるとは限らない。
【実施例】
【００１０】
本実施形態では、装置利用者がルールの不具合を検出するルールテスト装置を実施例として説明する。
図１は、本発明の実施例に係るルールテスト装置１００の構成の例を示す図である。ルールテスト装置１００は、少なくとも、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）等のプロセッサ１３１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）等のメモリ１３２、補助記憶装置１２０、および、キーボード、表示モニタ等の入出力装置１３３を備えたコンピュータである。
【００１１】
また、ルールテスト装置１００は、ルール作成・修正部１０１、テストケース作成・修正部１０２、テストケース漏れ検査部１０３、テスト実行部１０４、テスト結果出力部１０５、補完テストケース生成部１０６、不具合箇所分析部１０７および影響範囲分析部１０８の機能ロジックを備える。これらの機能ロジックは、コンピュータプログラムとして実現され、メモリ１３２上でプロセッサ１３１により実行される。
さらに、ルールテスト装置１００は、テストケース記録部１２１、ルール記録部１２２およびテスト結果記録部１２３などのデータを補助記憶装置１２０に保管している。これらのデータは、プロセッサ１３１が前述した機能ロジックを実行する際に補助記憶装置１２０から読み出して使用される。
【００１２】
図２は、２つのルールセット（ＲＳ１およびＲＳ２）と１つのテストケースを使用したルールテストの例を示す図である。ルールセットについては後述する。条件部と結果部を有するルールは、ＩＤ（識別子）が付されている。例えば、条件部が「２００１  ＜＝  加入年」で、結果部が「加入期間  ＝  適用年  −  加入年」であるルールは、そのＩＤとしてＲ１が付され、「ＩＦ  ２００１  ＜＝加入年  ＴＨＥＮ  加入期間  ＝  適用年  −  加入年」を意味する。
【００１３】
ルールを適用するときに、値が付与される変数を「入力項目」と呼び、ルールを適用した結果、値が付与される変数を「出力項目」と呼ぶ。
加入期間計算（ＲＳ２）のＲ１およびＲ２のルールでは、「適用年」および「加入年」が入力項目であり、「加入期間」が出力項目である。そして、入力項目の値を「入力値」、出力項目の値を「出力値」と呼ぶ。例えば、Ｒ１のルールでは、「適用年」および「加入年」として付与される値「２０１５」および「１９９５」が入力値であり、「加入期間」として付与される「２０」（＝２０１５−１９９５）が出力値である。
【００１４】
また、会員特典付与判定（ＲＳ１）のＲ１〜Ｒ８のルールでは、「特典付与」が出力項目であり、「しない」が出力値である。図２から明らかなように、入力値および出力値は必ずしも数値ではなく、文字列などの場合もある（以下、入力とは、入力値の集まりのことである）。
【００１５】
このようなルールの集まりを「ルールセット」と呼ぶ。図２では、会員特典付与判定と加入期間計算の２つのルールセット（ＲＳ１とＲＳ２）を表している。ルールセットは１以上のルールの集まりであるところ、各ルールの出力項目は同一である。また、ルールが複数であれば、入力は、ルールセットに含まれるルールのいずれか１つのルールの条件部を真とする（成立させる）。例えば、加入期間計算のルールセット（ＲＳ２）においては、各ルールの出力項目は同一の「加入期間」である。「適用年」と「加入年」へ入力値を割当てると、Ｒ１〜Ｒ２のルールのいずれか１つの条件部を真とする。
【００１６】
図２では、加入期間計算のルールセット（ＲＳ２）の出力項目は、会員特典付与判定のルールセット（ＲＳ１）の入力項目の１つとして用いられる（以下、ルールセットの出力項目が別のルールセットの入力項目になっている場合、これら２つのルールセット間の関係を「依存関係」という）。また、図２から明らかなように、入力項目には、他のルールセットの出力項目になっている入力項目と、他のルールセットの出力項目になっていない入力項目が存在する（以下、他のルールセットの出力項目になっている入力項目を、「依存入力項目」といい、他のルールセットの出力項目になっていない入力項目を、「非依存入力項目」という）。
【００１７】
会員特典付与判定のルールセット（ＲＳ１）の入力項目では、ルールセットおよびルールの入力項目は１つとは限らず、個々の入力項目の条件式は演算子で結合されている。会員特典付与判定のルールセット（ＲＳ１）では、ＡＮＤの論理演算子を用いている。
なお、ルールセットの各ルールの出力項目は同一であるとしたが、複数種の出力項目に共通する（共用できる）ルールがある場合、１つのルールセットに複数種の出力項目を持たせることも可能である。しかし、ルールセットに複数種の出力項目があると、業務規則の変更に応じて、そのルールセットのルールの変更が複雑になる。そこで、ルールセットの意味の分かり易さおよびルールの変更の容易さの観点からいえば、複数種の出力項目に対しては、それぞれ１つの出力項目を有する複数のルールセットを設けることが望ましい。
【００１８】
これらのルールセット（１つの場合もある）単位で、業務規則と整合しているかを確認するため、まず、業務規則を人が解釈し、入力と期待する結果を作成する（以下、「テストケース」という）。次に、当該入力をルールセットに与え、得られる結果が期待を満たすか確認する。このとき、ルールセット間の依存関係を考慮せずにテストを実施する場合は、依存入力項目と非依存入力項目の両方に対する入力値を入力とする。また、ルールセット間の依存関係を考慮してテストを実施する場合は、非依存入力項目に対する入力値を入力とする。
【００１９】
図２の例では、「会員特典付与判定」と「加入期間計算」に対して、入力として、「適用年：２０１５、加入年：１９９５、年齢：４０」を与えた結果、会員特典付与判定（ＲＳ１）のルールＲ５と加入期間計算（ＲＳ２）のルールＲ２が適用され、期待する結果としての「特典付与：しない」を満たす結果である「特典付与：しない」が得られる。よって、テストに合格していることが判明する。
【００２０】
以降では、入力に対して適用されるルールの集合を「適用ケース」という。なお、適用ケースにおいて、各ルールが含まれるルールセットはすべて異なっている。
本発明に係るルールテスト装置が実現するルールテストでは、テストケースとして具体的な入力値ではなく、論理式で記述されたテストを行う入力の条件（以下、「入力条件」という）と期待する結果の条件（以下、「期待出力条件」という）を使用する。
【００２１】
図１に示すルールテスト装置１００の各処理部の説明として、論理式で記述されたテストケースを用いたルールのテストの概要を含めて説明する（以下、論理式で記述されたテストケースを「論理テストケース」という。）。
ルール作成・修正部１０１は、装置利用者が追加、変更または削除した入力項目、出力項目およびルールに関する情報を受け付け、ルール記録部１２２に登録する。
テストケース作成・修正部１０２は、装置利用者が追加、変更または削除した論理テストケースに関する情報を受け付け、テストケース記録部１２１に登録する。
【００２２】
テストケース漏れ検査部１０３は、テストの対象とするルールセットが同一である１つ以上のテストケースの集まり（以下、「テストケースセット」という。）ごとに、テスト対象とするルールセットに起こり得る入力のうち、当該テストケースセットでは、テストしていない入力（以下、「入力の漏れ」という）が存在するかどうかを判定する。テストケース漏れ検査部１０３の処理については後述する。
【００２３】
テスト実行部１０４は、ルール記録部１２２に登録されているルールが、テストケース記録部１２１に登録されている各論理テストケースの入力条件を満たす全入力において、ルールの適用結果が期待出力条件を満たすかどうか判定する。この論理テストケースの入力条件を満たす全入力において、ルールの適用結果が期待出力条件を満たす場合は、テスト合格とみなし、ルールの適用結果が期待出力条件を満たさないケースがひとつでも存在する場合は、テスト不合格とみなす。
【００２４】
次に、テスト実行部１０４は、論理テストケースの入力条件を満たす入力において、結果が期待出力条件を満たすケースでの適用ケース（以下、「合格ケース」という）と、結果が期待出力条件を満たさないケースでの適用ケース（以下、「不合格ケース」という）をすべて取得する。図２では、入力として、「適用年：２０１５、加入年：１９９５、年齢：４０」が与えられると、加入期間計算（ＲＳ２）のルールＲ２と、会員特典付与判定（ＲＳ１）のルールＲ５の条件部が真となり、これらのルールがそれぞれ適用される。その結果は「特典付与：しない」である。これは、期待する結果を満たす結果であるから、「加入期間計算（ＲＳ２）のルールＲ２および会員特典付与判定（ＲＳ１）のルールＲ５」は、合格ケースとなる。テスト実行部１０４の処理については後述する。次に、テスト実行部１０４は、テストの結果として、各論理テストケースの合否、合格ケースおよび不合格ケース（以下、「テスト結果」という）をテスト結果記録部１２３に記録する。
【００２５】
テスト結果出力部１０５は、テスト結果記録部１２３に登録されたテスト結果を装置利用者等に対して表示する。
補完テストケース生成部１０６は、テストケース漏れ検査部１０３で検出した入力の漏れを対象とする論理テストケースを生成する。補完テストケース生成部１０６の処理については後述する。また、補完テストケース生成部１０６は、生成した論理テストケースをテストケース記録部１２１に記録する。
【００２６】
不具合箇所分析部１０７は、テスト結果記録部１２３に記録されたテスト結果を用いて、不合格ケースに偏って含まれるルールや不合格ケースに共通するルールを特定する。不具合箇所分析部１０７の処理については後述する。
影響範囲分析部１０８は、ルールの編集を検知し、当該ルールの編集内容とテスト結果記録部１２３に登録されたテスト結果を用いて、テスト結果記録部１２３に記録された論理テストケースのうち、当該ルールの編集の結果、テスト結果の合否が変わる可能性のある論理テストケースを特定する。影響範囲分析部１０８の処理については後述する。
【００２７】
図３は、ルール記録部１２２のデータ構造の例を示す図である。ルール記録部１２２は、ルールセット情報３１０、エンティティ情報３２０、ルール情報３３０、入力情報３４０、出力情報３５０および属性情報３６０の各テーブルを有する。図３の各テーブルの表記については、２つの四角形により構成され、上の四角形内にテーブル名を表し、下の四角形内に当該テーブルのカラム名を表している。また、テーブル間の関連については、ひし形と実線を結んで表し、ひし形側のテーブルと実線側のテーブルは、１対多の関係にあることを表す。以下に示す他のデータ構造の図についても、同様の表記を用いている。
【００２８】
図３に示すルールセット情報３１０は、ルールセットに関する情報として、ルールセットＩＤおよびルールセット名を有する。ルールセットＩＤは、ルールセット間でユニークな識別子である。図２では、ルールセットＩＤとして、会員特典付与判定のＲＳ１と加入期間計算のＲＳ２がある。ルールセット名は、ルールセットＩＤが示すルールセットの名称であることから、図２では、ルールセットの名称は、「会員特典付与判定」と「加入期間計算」である。
【００２９】
エンティティ情報３２０は、当該ルールセットの入力値のエンティティの情報として、エンティティ名を有する。エンティティ名は、当該エンティティの名称である。
ルール情報３３０は、ルールセットに含まれるルールに関する情報として、ルールＩＤ、条件部論理式および結果部論理式を有する。ルールＩＤは、ルールセットにおいて、各ルールに付したユニークな識別子である。図２の例では、ルールセット「会員特典付与判定」に含まれるＲ１〜Ｒ８がルールＩＤである。条件部論理式は、ルールの条件部を表す論理式であり、入力項目、比較演算子（等式演算子を含む）、四則演算子および論理演算子などの組合せで表現される。結果部論理式は、ルールの結果部を表す論理式であり、入力項目、入力項目が取り得る値、出力項目、出力項目が取り得る値、等式演算子および四則演算子などの組合せで表現される。
【００３０】
入力情報３４０は、当該ルールセットの入力項目に関する情報として、入力項目名、参照種別および参照式を有する。入力項目名は、入力項目の名称である。参照種別は、当該入力項目に代入する値の参照先の種別であり、実施例では、「Ｅｎｔｉｔｙ」および「ＲｕｌｅＳｅｔ」のいずれかである。参照種別が「Ｅｎｔｉｔｙ」の場合、参照先はエンティティ情報３２０であり、「ＲｕｌｅＳｅｔ」の場合、参照先はルールセット情報３１０である。参照式は、当該入力項目に代入する値の参照先である。参照種別が「Ｅｎｔｉｔｙ」の場合、参照式は「エンティティ名．属性名」となり、参照種別が「ＲｕｌｅＳｅｔ」の場合、参照式は「ルールセット名．出力項目名」となる。入力情報３４０の参照種別が「ＲｕｌｅＳｅｔ」であるとき、他のルールセットの出力項目に依存していることを表すので、ルールセット間の依存関係を表現していることになる。
【００３１】
入力情報３４０の例を、図２の会員特典付与判定（ＲＳ１）を用いて説明する。会員特典付与判定のルールセット（ＲＳ１）の入力項目名は、「年齢」と「加入期間」である。「年齢」の参照種別は「Ｅｎｔｉｔｙ」であり、「エンティティ名．属性名」の参照式を用いて、後述するエンティティ情報３２０を参照し、エンティティ情報３２０の定義に従った値を、会員特典付与判定のルールセット（ＲＳ１）の「年齢」の入力値とする。「加入期間」の参照種別は「ＲｕｌｅＳｅｔ」であり、「ルールセット名．出力項目名」の参照式として「加入期間計算．加入期間」を用いて、加入期間計算（ＲＳ２）の出力項目「加入期間」の出力値を、会員特典付与判定のルールセット（ＲＳ１）の「加入期間」の入力値とする。
【００３２】
出力情報３５０は、当該ルールセットの出力項目に関する情報として、出力項目名および出力項目型を有する。出力項目名は、出力項目の名称である。出力項目型は、Ｉｎｔｅｇｅｒ型（整数型）、Ｂｏｏｌ型、Ｄａｔｅ型およびユーザ定義の列挙型のような出力項目のデータ型である。
属性情報３６０は、エンティティ情報３２０が有する属性に関する情報として、属性名および属性型を有する。属性名は、当該属性の名称である。属性型は、Ｉｎｔｅｇｅｒ型（整数型）、Ｂｏｏｌ型、Ｄａｔｅ型およびユーザ定義の列挙型のような当該属性のデータ型である。
【００３３】
図４は、テストケース記録部１２１のデータ構造の例を示す図である。テストケース記録部１２１は、テストケースセット情報４１０および論理テストケース情報４２０のテーブルを有する。
【００３４】
テストケースセット情報４１０は、テストケースセットの情報として、テスト種別、テストケースセットＩＤ、テストケースセット名およびルールセットＩＤを有する。テスト種別は、テストケースセットを用いて実施するテストの種類であり、実施例では、「単体」または「結合」のいずれかである。テスト種別が「単体」の場合、テストを実施する際、ルールセットＩＤに対応するルールセット（以下、「テスト対象ルールセット」という）のみを使用する。テスト種別が「結合」の場合、テスト対象ルールセットと当該ルールセットの入力項目が直接的または間接的に依存しているルールセット（以下、「依存ルールセット」という）の全て（「依存ルールセット」の集合）を使用する。なお、以下では、テスト種別が「単体」となっているテストケースセットを用いたテストを「単体テスト」、テスト種別が「結合」となっているテストケースセットを用いたテストを「結合テスト」という。
【００３５】
図２では、ルールセット会員特典付与判定（ＲＳ１）のテストにおいて、テストケースセットのテスト種別が「結合」となっている場合、ルールセット会員特典付与判定（ＲＳ１）の入力項目「加入期間」は、加入期間計算（ＲＳ２）に依存しているため、ルールセット会員特典付与判定（ＲＳ１）と加入期間計算（ＲＳ２）を使用して、結合テストを実施する。さらに、加入期間計算（ＲＳ２）の入力項目「加入年」が別のルールセットに依存している場合、当該ルールセットも使用してテストを実施する。
【００３６】
図４に戻り、テストケースセットＩＤは、テストケースセット間でユニークな識別子である。テストケースセット名は、テストケースセットＩＤに対するテストケースセットの名称である。ルールセットＩＤは、テストの対象とするルールセットのＩＤであり、ルールセット情報３１０のいずれかである。
【００３７】
論理テストケース情報４２０は、テストケースセットに含まれる論理テストケースに関する情報として、テストケースＩＤ、入力条件および期待出力条件を有する。テストケースＩＤは、テストケースセットにおいて、論理テストケース間でユニークな識別子である。入力条件は、当該論理テストケースで対象とする入力の条件論理式であり、入力項目、入力項目が取り得る値、比較演算子（等式演算子を含む）、四則演算子および論理演算子などの組合せで表現される。単体テストを実施する場合、テスト対象ルールセットの入力項目は、当該論理テストケースの入力条件で使用可能である。結合テストを実施する場合、テスト対象ルールセットの非依存入力項目と当該テスト対象ルールセットの依存ルールセットの集合に含まれるルールセットの非依存入力項目を、当該論理テストケースの入力条件に使用できる。期待出力条件は、当該論理テストケースで対象とする入力から得られる結果が満たして欲しい条件の論理式であり、入力項目、テスト対象ルールセットの出力項目、当該出力項目が取り得る値、比較演算子（等式演算子を含む）、四則演算子および論理演算子などの組合せで表現される。
【００３８】
論理テストケースの例を、図５に示す、会員特典付与判定（ＲＳ１）へ結合テストを実施するテストケースセットの例を用いて説明する。
会員特典付与判定（ＲＳ１）の非依存項目は「年齢」であり、依存入力項目は「加入期間」であり、当該「加入期間」の入力値は加入期間計算（ＲＳ２）に依存している。加入期間計算（ＲＳ２）の非依存入力項目は、「加入年」および「適用年」であり、依存入力項目を持たない。当該テストケースセットのテスト種別は「結合」であり、入力条件に使用可能な入力項目は「年齢」、「加入年」および「適用年」である。当該テストケースセットの論理テストケース（Ｔ１）の入力条件は「１００＜＝年齢」であり、期待出力条件は「特典付与＝しない」であり、「年齢が１００以上の入力」において、結果が「特典付与：しない」になることを期待している。
【００３９】
図６は、テスト結果記録部１２３のデータ構造の例を示す図である。テスト結果記録部１２３は、テスト結果情報６１０、適用ケース情報６２０およびルールパス情報６３０の各テーブルを有する。
テスト結果情報６１０は、テストの結果に関する情報として、テストケースセットＩＤ、テストケースＩＤおよびテスト合否を有する。テストケースセットＩＤは、テスト結果情報６１０が対応する論理テストケースが含まれるテストケースセットを識別する情報であり、テストケースセット情報４１０のいずれかである。テストケースＩＤは、テスト結果情報６１０が対応する論理テストケースを識別する情報であり、論理テストケース情報４２０のいずれかである。テスト合否は、当該論理テストケースの合否である。
【００４０】
適用ケース情報６２０は、テスト結果の合格ケースおよび不合格ケースに関する情報として、適用ケースＩＤおよび合否を有する。適用ケースＩＤは、テスト結果内での一意の識別子である。合否は、適用ケースの種類であり、実施例では、「合格」または「不合格」のいずれかであり、合格ケースの場合、合否は「合格」となり、不合格ケースの場合、合否は「不合格」となる。
【００４１】
ルールパス情報６３０は、適用ケースに含まれるルールに関する情報として、ルールセットＩＤおよびルールＩＤを有する。ルールセットＩＤは、適用ケースに含まれるルールが含まれるルールセットを識別する情報であり、ルールセット情報３１０のいずれかである。ルールＩＤは、適用ケースに含まれるルールを識別する情報であり、ルール情報３３０のいずれかである。
【００４２】
図７は、ルールの作成・編集画面の例を示す図である。
ルール作成・編集画面７００は、ルール作成・修正部１０１が、装置利用者からのルールの編集入力を受け付けるために、入出力装置１３３に表示される画面である。
ルール作成・編集画面７００は、ルールセット基本情報表示エリア７１０、入力項目編集エリア７２０、出力項目編集エリア７３０、ルール編集エリア７４０およびテストケースセット表示エリア７５０を含む。
【００４３】
ルールセット基本情報表示エリア７１０は、編集対象のルールセットに関する基本情報を表示する領域で、ルールセットＩＤおよびルールセット名を表示する。ルール作成・修正部１０１が「ルールセットＩＤ」および「ルールセット名」のタイトル（項目名）を表示し、装置利用者によるルールセットＩＤおよびルールセット名を入力する。図７では、ルールセットＩＤとして「ＲＳ１」、ルールセット名として「会員特典付与判定」が入力された例を示している。
【００４４】
入力項目編集エリア７２０は、ルールセットの入力項目を編集（追加、変更および削除）する領域であり、入力項目名、種別および参照式の項目を表示する。ルール作成・修正部１０１は、入力項目の数に応じて入力項目編集エリア７２０の行数を追加または削除する。また、ルール作成・修正部１０１は、装置利用者による入力項目の編集（追加、変更および削除）の結果を、ルール記録部１２２に反映する。したがって、編集後の各項目の内容は、それぞれルール記録部１２２の入力情報３４０の入力項目名、参照種別および参照式に対応する。
【００４５】
出力項目編集エリア７３０は、ルールセットの出力項目を編集（追加、変更および削除）する領域であり、出力項目名および型の項目を表示する。装置利用者による編集後の各項目の内容は、入力項目編集エリア７２０と同様に、ルール作成・修正部１０１によってルール記録部１２２に反映され、それぞれルール記録部１２２の出力情報３５０の出力項目名および出力項目型に対応する。
【００４６】
ルール編集エリア７４０は、ルールセットのルールを編集（追加、変更および削除）する領域であり、ルールＩＤ、条件部論理式および結果部論理式を表示する。ルール作成・修正部１０１は、装置利用者が編集するルールを選択した際、編集前のルールＩＤ、条件部および結果部をメモリ１３２に保持する。装置利用者による条件部論理式または結果部論理式の編集後、ルール作成・修正部１０１は、編集後の当該ルールと編集前の当該ルールを、影響範囲分析部１０８に通知する。
【００４７】
影響範囲分析部１０８は、当該ルールの編集によって、合否が変わる可能性のある論理テストケースを用いてテストを実施し、当該ルール編集前後での論理テストケースの合否の変化を、ルール作成・修正部１０１に通知する。ルール作成・修正部１０１は、影響範囲分析部１０８から通知された当該論理テストケースの合否の変化を装置利用者に提示し、編集内容をルール記録部１２２に反映させるかを確認する。装置利用者が反映させることを選択した場合、ルール作成・修正部１０１は、メモリ１３２に記録した編集前のルールを削除し、編集内容をルール記録部１２２に反映する。編集後のルール編集エリア７４０の各項目の内容は、それぞれルール記録部１２２のルール情報３３０のルールＩＤ、条件部論理式および結果部論理式に対応する。
【００４８】
テストケースセット表示エリア７５０は、対象が当該ルールセットになっているテストケースセットを表示する領域であり、テストケースセットＩＤおよびテストケースセット名を表示する。
【００４９】
図８は、テストケースセットの作成・編集画面の例を示す図である。
テストケースセット作成・編集画面８００は、テストケース作成・修正部１０２が、装置利用者からの論理テストケースの編集入力を受け付けるために、入出力装置１３３に表示される画面である。
テストケースセット作成・編集画面８００は、テストケースセット基本情報表示エリア８１０、入力項目表示エリア８２０、出力項目表示エリア８３０、テストケース編集エリア８４０、漏れチェックボタン８５０およびテスト実行ボタン８６０を含む。
【００５０】
テストケースセット基本情報表示エリア８１０は、編集対象のテストケースセットに関する基本情報を表示する領域であり、テスト種別、テストケースセットＩＤ、テストケースセット名およびテスト対象ルールセットＩＤを表示する。テストケース作成・修正部１０２が「テスト種別」、「テストケースセットＩＤ」、「テストケースセット名」および「テスト対象ルールセットＩＤ」のタイトル（項目名）を表示し、装置利用者によるテストケースセットＩＤ、テストケースセット名およびテスト対象ルールセットＩＤを入力する。図８では、種別として「結合」、テストケースセットＩＤとして「ＴＳ１」、テストケースセット名として「会員特典付与判定の結合テスト」およびテスト対象ルールセットＩＤとして「ＲＳ１」が入力された例を示している。
【００５１】
入力項目表示エリア８２０は、テストケースセットの論理テストケースの入力条件および期待出力条件で使用可能な入力項目を表示するための領域であり、図７の入力項目編集エリア７２０と同様に、入力項目名、種別および参照式を表示する。入力項目表示エリア８２０の構成要素は、図５のテストケースセットの例で示したように、「年齢」、「加入年」および「適用年」である。
【００５２】
出力項目表示エリア８３０は、テストケースセットの論理テストケースの期待出力条件に使用可能な出力項目を表示するための領域であり、出力項目名および型を表示する。出力項目表示エリア８３０の構成要素は、図７の出力項目編集エリア７３０と同一である（当該構成要素の説明は省略）。
【００５３】
テストケース編集エリア８４０は、テストケースセットの論理テストケースを編集（追加、変更および削除）する領域であり、テストケースＩＤ、入力条件および期待出力条件を表示する。テストケース作成・修正部１０２は、論理テストケースの数に応じてテストケース編集エリア８４０の行数を追加または削除する。また、テストケース作成・修正部１０２は、装置利用者による論理テストケースの編集（追加、変更および削除）の結果を、テストケース記録部１２１に反映する。したがって、編集後の各項目の内容は、それぞれテストケース記録部１２１の論理テストケース情報４２０のテストケースＩＤ、入力条件および期待出力条件に対応する。
【００５４】
漏れチェックボタン８５０は、テストケース漏れ検査部１０３によるテストケースセットの漏れの検査を実施するための操作ボタンである。テストケース作成・修正部１０２は、装置利用者が当該ボタンを押下した後、テストケース漏れ検査部１０３による漏れの検査を実施し、テストケース漏れ検査部１０３は、当該検査の結果を後述する補完テストケース表示・編集画面１２００に表示する。
【００５５】
テスト実行ボタン８６０は、テスト実行部１０４によるテストを実施するための操作ボタンである。テストケース作成・修正部１０２は、装置利用者が当該ボタンを押下した後、テスト実行部１０４によるテストを実施し、テスト実行部１０４は、当該テストの結果を後述するテスト結果表示画面９００に表示する。
【００５６】
図９は、テスト結果表示画面の例を示す図である。
テスト結果表示画面９００は、テスト実行部１０４が、テストの実行結果を表示するために、入出力装置１３３に表示される画面である。
テスト結果表示画面９００は、テストケースセット基本情報表示エリア９１０およびテスト結果表示エリア９２０を含む。
【００５７】
テストケースセット基本情報表示エリア９１０の構成要素は、図８のテストケースセット基本情報表示エリア８１０と同一である（当該構成要素の説明を省略）。
テスト結果表示エリア９２０は、テストの結果を表示するための領域であり、テストケースＩＤ、テスト合否、合格ケースおよび不合格ケースを表示する。各構成要素は、テスト結果情報６１０、適用ケース情報６２０またはルールパス情報６３０のいずれかを表示させる。テスト実行部１０４は、テスト結果表示エリア９２０の合格ケースおよび不合格ケースに表示される適用ケースのうち、１つ以上を装置利用者が選択すると、後述する適用ケース表示画面１０００に当該適用ケースを図示する。
なお、テスト結果表示エリア９２０に、合格もしくは不合格となる場合の具体的な入力値の組合せを表示するようにしてもよい。
【００５８】
図１０は、適用ケース表示画面の一例を示す図である。
適用ケース表示画面１０００は、テスト実行部１０４が、装置利用者が選択した適用ケースを表示するために、入出力装置１３３に表示する画面である。
適用ケース表示画面１０００は、適用ケース表示エリア１０１０を含む。適用ケース表示エリア１０１０は、装置利用者が選択した適用ケースを図示する領域である。
【００５９】
図１０では、図９において、装置利用者が、テストケースＩＤが「Ｔ３」および「Ｔ５」の論理テストケースの適用ケースを選択した場合を示す図である。
適用ケース表示エリア１０１０に示される四角は、当該適用ケースに出現するルールを表し、楕円は、当該ルールが含まれるルールセットを表している。ルール間の線は、ルールが同一の適用ケース中に含まれていることを表し、実線は、当該適用ケースが合格ケースであること、点線は、当該適用ケースが不合格ケースであること、をそれぞれ表している。
【００６０】
図１１は、適用ケースの分析結果表示画面の一例を示す図である。
適用ケース分析結果表示画面１１００は、不具合箇所分析部１０７が、装置利用者が選択した適用ケースに対するテストを実行し不具合箇所の分析結果を表示するために、入出力装置１３３に表示される画面である。
適用ケース分析結果表示画面１１００は、適用ケース分析結果表示エリア１１１０を含む。
【００６１】
適用ケース分析結果表示エリア１１１０は、不具合箇所の分析として、適用ケースを分析した結果をルールごとに表示する領域であり、ルール名、合格率および出現率（不合格）を含む。ルール名は、ルールのＩＤおよびそのルールを含むルールセットのＩＤであり、「当該ルールセットのＩＤ．ルールのＩＤ」の形で表示させる。
【００６２】
合格率は、当該ルールが含まれる適用ケースのうち合格ケースの割合であり、「（当該ルールが含まれる合格ケース数／合格ケース数）／（（当該ルールが含まれる合格ケース数／合格ケース数）＋（当該ルールが含まれる不合格ケース数／不合格ケース数））」の式で算出する。
出現率（不合格）は、不合格ケースのうち当該ルールが含まれる不合格ケースの割合であり、「（当該ルールが含まれる不合格ケース数）／不合格ケース数」の式で算出する。
【００６３】
また、不具合箇所分析部１０７は、装置利用者による操作指示に応じて、適用ケース分析結果表示エリア１１１０に表示するデータの並べ替えを可能にする。合格率の列に設けた三角形１１１１対して、三角形１１１１が下向きの状態で三角形１１１１を押下した場合は、合格率が低い順に並べ替え、三角形１１１１が上向きの状態で三角形１１１１を押下した場合は、合格率が高い順に並べ替える。同様に、出現率（不合格）の列に設けた三角形１１１２に対して、三角形１１１２が下向きの状態で三角形１１１２を押下した場合は、出現率（不合格）が低い順に並べ替え、三角形１１１２が上向きの状態で三角形１１０２を押下した場合は、出現率（不合格）が高い順に並べ替える。
なお、適用ケース分析結果表示エリア１１１０に、合格ケース数、不合格ケース数、当該ルールが含まれる合格ケース数および当該ルールが含まれる不合格ケース数を表示するようにしてもよい。
【００６４】
図１２は、漏れ検査の結果および補完テストケース生成部１０６が生成したテストケース（以下、「補完テストケース」という）を表示および編集する画面の例を示す図である。
補完テストケース表示・編集画面１２００は、テストケース漏れ検査部１０３が検査した漏れ検査の結果および補完テストケース生成部１０６が生成した論理テストケースを表示するためと装置利用者からの補完テストケースの編集入力を受け付けるために、入出力装置１３３に表示される画面である。
【００６５】
補完テストケース表示・編集画面１２００は、テストケースセット基本情報表示エリア
１２１０、漏れ検査結果表示エリア１２２０、補完テストケース編集エリア１２３０、漏れチェックボタン１２４０および終了ボタン１２５０を含む。
テストケースセット基本情報表示エリア１２１０の構成要素は、図８のテストケースセット基本情報表示エリア８１０と同一である（当該構成要素の説明を省略）。
【００６６】
漏れ検査結果表示エリア１２２０は、漏れ検査の結果を表示するための領域であり、「漏れアリ」または「漏れナシ」のいずれかである。テストケース漏れ検査部１０３は、漏れ検査の結果、入力の漏れを検出した場合には「漏れアリ」を表示し、入力の漏れが存在しない場合には「漏れナシ」と表示する。なお、漏れ検査結果表示エリア１２２０は、この領域だけを独立した画面としてもよい。
【００６７】
補完テストケース編集エリア１２３０は、テストケースセット作成・編集画面８００で装置利用者が作成した論理テストケースを表示すると共に、補完テストケース生成部１０６が生成した補完テストケースを編集（追加、変更および削除）するための領域であり、採否１２３１、入力条件および期待出力条件を表示する。
採否１２３１は、補完テストケースを採用するかどうかを装置利用者が入力するためのチェックボックスであり、補完テストケースのみに表示される。
【００６８】
漏れチェックボタン１２４０は、補完テストケース編集エリア１２３０の論理テストケースおよび採否１２３１がチェックされている補完テストケースに対して、テストケース漏れ検査部１０３による入力の漏れの検査を実施するためのボタンである。装置利用者が漏れチェックボタン１２４０を押下すると、テストケース漏れ検査部１０３は、補完テストケース編集エリア１２３０の論理テストケースおよび採否１２３１が、チェックされている補完テストケースの入力の漏れが存在するかを検査する。そして、当該入力の漏れを検知した場合は、漏れ検査結果表示エリア１２２０に、「漏れアリ」と表示し、補完テストケース部１０６を用いて、当該入力の漏れの補完テストケースを生成し、補完テストケース編集エリア１２３０に追加して、当該領域で採否１２３１がチェックされていない補完テストケースを削除する。漏れが存在しない場合は、当該領域で、採否１２３１がチェックされていない補完テストケースを削除する。なお、補完テストケースが生成できなった場合、テストケース漏れ検査部１０３はメッセージを表示する。これは、図８の漏れチェックボタン８５０を押下した場合も同様である。
【００６９】
終了ボタン１２５０は、補完テストケース編集エリア１２３０の採否１２３１がチェックされている補完テストケースを論理テストケースとして、テストケース記録部１２１に反映させるための操作ボタンである。装置利用者が終了ボタン１２５０を押下すると、テストケース漏れ検査部１０３は、補完テストケース編集エリア１２３０の採否１２３１がチェックされている補完テストケースに、テストケースＩＤを付与して論理テストケースとして、テストケース記録部１２１に追加する。したがって、補完テストケース編集エリア１２３０の入力条件および期待出力条件は、それぞれ論理テストケース情報４２０の入力条件および期待出力条件に対応する。
【００７０】
図１３は、テストケース漏れ検査部１０３が実行する処理のフローチャートを示す図である。
ステップ１３００（Ｓ１３００）で、テストケース漏れ検査部１０３は、装置利用者が、図８の漏れチェックボタン８５０または図１２の漏れチェックボタン１２４０を押下した場合に、処理を開始する。
【００７１】
ステップ１３０１（Ｓ１３０１）で、テストケース漏れ検査部１０３は、テストケース記録部１２１を参照し、入力の漏れ検査対象のテストケースセットに含まれる論理テストケースの入力条件を全て取得する。
ステップ１３０２（Ｓ１３０２）で、テストケース漏れ検査部１０３は、ルール記録部１２２を参照し、当該テストケースのテスト対象ルールセットを取得する。
【００７２】
ステップ１３０３（Ｓ１３０３）で、テストケース漏れ検査部１０３は、入力の漏れ検査対象のテストケースセットの種別を確認する。テストケース漏れ検査部１０３は、当該種別が「単体」の場合、ステップ１３０５（Ｓ１３０５）に進み、当該種別が「結合」の場合、ステップ１３０４（Ｓ１３０４）に進む。
【００７３】
ステップ１３０４（Ｓ１３０４）で、テストケース漏れ検査部１０３は、テスト対象ルールセットの入力項目の依存関係を辿って依存ルールセットの集合を取得する。
ステップ１３０５（Ｓ１３０５）で、テストケース漏れ検査部１０３は、テストケースセットに漏れが存在するかどうかを判定するために、後述する漏れ検査式１４００を生成する。
【００７４】
図１４は、漏れ検査式１４００および関連する論理式の例を示す図である。
漏れ検査式１４００は、単体テストの場合、非テスト入力値式１４１０と対象ルールセット入力値式１４２０との論理積で結合した式であり、結合テストの場合、単体テストの論理積に依存関係制約式１４３０を加えて論理積で結合した式である。
【００７５】
非テスト入力値式１４１０は、テストケースセットに含まれるすべての論理テストケースの入力条件を論理和で結合し、全体を否定した論理式である。
対象ルールセット入力値式１４２０は、テスト対象ルールセットに含まれるすべてのルールの条件部を論理和で結合した論理式である。
【００７６】
依存関係制約式１４３０は、依存ルールセットの集合に含まれる各ルールセットに含まれる各ルールの条件部と結果部を論理包含で結合した論理式を論理積で結合した式を、依存ルールセットの集合において論理積で結合した論理式である。
なお、図１４において、ＴＳはテストケースセット、ｔｃは当該テストケースセットに含まれる論理テストケース、ｔｃ．ｃｏｎは当該論理テストケースの入力条件、ＲＳ＿ＳＥＴは依存ルールセットの集合、ＤｅｐｅｎｄＲＳは当該依存ルールセットの集合に含まれるルールセット、ＴａｒｇｅｔＲＳはテスト対象ルールセット、ｒｕｌｅは当該テスト対象ルールセットに含まれるルール、ｒｕｌｅ．ｃｏｎは当該ルールの条件部、ｒｕｌｅ．ｒｅｓは当該ルールの結果部を表す。
【００７７】
図１３に戻り、ステップ１３０６（Ｓ１３０６）で、テストケース漏れ検査部１０３は、当該漏れ検査式１４００の充足可能性を判定し、充足可能の場合には漏れがあると判断し、充足不能の場合には漏れが無いと判断し、ステップ１３０７（Ｓ１３０７）で処理を終了する。
充足可能性とは、与えられた論理式を真（ＴＲＵＥ）にする変数の値の組合せが存在するか否かを表す性質である。漏れ検査式１４００が充足可能とは、漏れ検査式１４００が真になること、すなわち、テスト対象のルールセットに起こり得る入力のうち、テストケースセットでテストする入力に含まれない入力が存在することを意味している。
【００７８】
充足可能性は、単純には、すべての変数の値の組合せをチェックすることで判定可能である。また、ＤＰＬＬ（Ｄａｖｉｓ−Ｐｕｔｎａｍ−Ｌｏｇｅｍａｎｎ−Ｌｏｖｅｌａｎｄ）アルゴリズムなど、変数の値の組合せではなく、論理式の構造に着目して効率的に充足可能性を判定するツールがある。例えば、ＳＭＴ（Ｓａｔｉｓｆｉａｂｉｌｉｔｙ  Ｍｏｄｕｌｏ  Ｔｈｅｏｒｉｅｓ）ソルバは、充足可能性を判定するツールの一種であり、漏れ検査式１４００の充足可能性を判定できる。
【００７９】
図１５は、テスト実行部１０４が実行する処理のフローチャートを示す図である。
ステップ１５００（Ｓ１５００）で、テスト実行部１０４は、装置利用者が図８のテスト実行ボタン８６０を押下した場合、または、図２０を用いて後述する影響範囲分析部１０８により合否の変化する可能性のある論理テストケースを通知された場合に、テストを実施する論理テストケースごとに処理を開始する（Ｓ１５００）。
【００８０】
ステップ１５０１（Ｓ１５０１）で、テスト実行部１０４は、テストケース記録部１２１から論理テストケースを取得する。
ステップ１５０２（Ｓ１５０２）で、テスト実行部１０４は、必要なルールセットを取得する。当該論理テストケースで実施するテストが、結合テストの場合には、テスト対象ルールセットと依存ルールセットの集合を取得し、単体テストの場合には、テスト対象ルールセットのみを取得する。
【００８１】
ステップ１５０３（Ｓ１５０３）で、テスト実行部１０４は、テスト対象ルールセットおよび依存ルールセットの集合内の各ルールセットにおいて、入力に対して条件部が真となるルール間で、出力値が整合していることを表すルール間の整合性を検査する。このとき、別の論理テストケースによるテスト実行において、既に当該ステップ１５０３（Ｓ１５０３）の処理を実行済みのルールセットに対しては、当該処理を省略する。また、ルール間の整合性の判定方法については、例えば、特開２０１２−１９０２０３号公報に開示される、充足可能性判定を用いた方法を使用することができる。
【００８２】
ステップ１５０３（Ｓ１５０３）の整合性の検査結果が「整合していない」の場合、テスト実行部１０４は、ステップ１５１３（Ｓ１５１３）で処理を終了する。
ステップ１５０３（Ｓ１５０３）の整合性の検査結果が「整合している」の場合、テスト実行部１０４は、ステップ１５０４（Ｓ１５０４）に進む。
ステップ１５０４（Ｓ１５０４）で、テスト実行部１０４は、合格ケースを生成するために、後述する合格ケース生成式１６００を生成する。
【００８３】
図１６は、テスト実行部１０４の処理フローチャート中で生成する論理式の一例を示す図である。合格ケース生成式１６００は、単体テストの場合、期待充足式１６１０とルールセット入出力式１６２０との論理積で結合した式であり、結合テストの場合、当該単体テストの論理積に依存関係制約式１４３０を論理積で結合した式である。
ここで、期待充足式１６１０は、論理テストケースの入力条件と期待出力条件とを論理積で結合した式である。ルールセット入出力式１６２０は、ルールセットに含まれるルールの条件部と結果部を論理包含で結合した式を、論理積で結合した式である。
【００８４】
図１６において、ｔｃ．ｃｏｎは当該論理テストケースの入力条件、ｔｃ．ｅｘｒｅｓは当該論理テストケースの期待出力条件、ＲＳはテスト対象ルールセット、ｒｕｌｅは当該テスト対象ルールセットに含まれるルール、ｒｕｌｅ．ｃｏｎは当該ルールの条件部、ｒｕｌｅ．ｒｅｓは当該ルールの結果部およびＣａｓｅは適用ケースを表す。
【００８５】
図１５に戻り、ステップ１５０５（Ｓ１５０５）で、テスト実行部１０４は、当該合格ケース生成式１６００の充足可能性を判定する。合格ケース生成式１６００が充足可能とは、合格ケース生成式１６００が真になること、すなわち、論理テストケースの入力条件を満たすテスト対象ルールセットの入力値において、当該論理テストケースの期待出力条件を満たす結果が得られるケースが存在することを意味している。
【００８６】
ステップ１５０５（Ｓ１５０５）で合格ケース生成式１６００が「充足不能」と判定された場合、テスト実行部１０４は、ステップ１５０８（Ｓ１５０８）に進む。
ステップ１５０５（Ｓ１５０５）で合格ケース生成式１６００が「充足可能」と判定された場合、テスト実行部１０４は、ステップ１５０６（Ｓ１５０６）に進む。
【００８７】
ステップ１５０６（Ｓ１５０６）で、テスト実行部１０４は、合格ケース生成式１６００を真とするテスト対象のルールセットおよび依存ルールセットの集合内のルールセットへの入力（以下、「モデル」という）を取得して、そのモデルにおいて条件部が真となる、テスト対象ルールセットおよび依存ルールセットの集合のルールを取得し、当該ルールの集合を合格ケースとする。これは、ルールの条件部に入力としてモデルを実際に与えることで確認できる。なお、モデルにおいて、同一のルールセット内のルールで真となるルールが２つ以上の場合は、それぞれ別の合格ケースとする。
【００８８】
ステップ１５０７（Ｓ１５０７）で、テスト実行部１０４は、当該合格ケースから、合格ケースに含まれるルールの条件部を論理積で結合して全体を否定した重複禁止制約式１６３０を生成する。そして、当該重複禁止制約式１６３０を合格ケース生成式１６００と論理積で結合し、ステップ１５０５（Ｓ１５０５）に進む。なお、ステップ１５０６（Ｓ１５０６）で複数個の合格トレースを取得した場合は、すべての合格トレースから重複禁止制約１６３０を生成し、合格ケース生成式１６００と論理積で結合する。
【００８９】
ステップ１５０５（Ｓ１５０５）で、前述した合格ケース生成式１６００の充足可能性が判定されるところ、ステップ１５０７（Ｓ１５０７）で同じものが出てこないように制約が追加されることになるから、最終的には「充足不能」となり、ステップ１５０８（Ｓ１５０８）に進むことになる。
ステップ１５０８（Ｓ１５０８）で、テスト実行部１０４は、不合格ケースを生成するために、後述する不合格ケース生成式１６４０を生成する。
【００９０】
図１６に示す不合格ケース生成式１６４０は、単体テストの場合、ルールセット入出力式１６２０と期待非充足式１６５０との論理積で結合した式であり、結合テストの場合、当該単体テストの論理積に依存関係制約式１４３０を加えて論理積で結合した式である。ここで、期待非充足式１６５０は、論理テストケースの入力条件と期待出力条件の否定を論理積で結合した式である。
【００９１】
図１５に戻り、ステップ１５０９（Ｓ１５０９）で、テスト実行部１０４は、不合格ケース生成式１６４０の充足可能性を判定する。不合格ケース生成式１６４０が充足可能とは、不合格ケース生成式１６４０が真になること、すなわち、論理テストケースの入力条件を満たすテスト対象のルールセットの入力値において、当該論理テストケースの期待出力条件を満たさない結果が得られるケースが存在することを意味している。
【００９２】
ステップ１５０９（Ｓ１５０９）で不合格ケース生成式１６４０が「充足不能」と判定された場合、テスト実行部１０４は、ステップ１５１２（Ｓ１５１２）に進む。
ステップ１５０９（Ｓ１５０９）で不合格ケース生成式１６４０が「充足可能」と判定された場合、テスト実行部１０４は、ステップ１５１０（Ｓ１５１０）に進む。
【００９３】
ステップ１５１０（Ｓ１５１０）で、テスト実行部１０４は、不合格ケース生成式１６４０のモデルを取得し、そのモデルにおいて条件部が真となる、テスト対象のルールセットおよび依存ルールセットの集合のルールを取得し、当該ルールの集合を不合格ケースとする。これは、ルールの条件部に入力としてモデルを実際に与えることで確認できる。なお、モデルにおいて、同一のルールセット内のルールで真となるルールが２つ以上の場合は、それぞれ別の不合格ケースとする。
【００９４】
ステップ１５１１（Ｓ１５１１）で、テスト実行部１０４は、当該不合格ケースから、重複禁止制約式１６３０を生成する。そして、当該重複禁止制約式１６３０を不合格ケース生成式１６４０と論理積で結合し、ステップ１５０９（Ｓ１５０９）に進む。なお、ステップ１５１１（Ｓ１５１１）で複数個の不合格ケースを取得した場合は、すべての不合格ケースから重複禁止制約１６３０を生成し、不合格ケース生成式１６４０と論理積で結合する。
【００９５】
ステップ１５１２（Ｓ１５１２）で、テスト実行部１０４は、生成された不合格ケースが１つ以上存在する場合、テスト不合格と判定し、１つも存在しない場合、テスト合格と判定する。そして、ステップ１５１３（Ｓ１５１３）で、テスト実行部１０４は処理を終了する。
【００９６】
なお、実施例では、すべての合格トレースおよび不合格トレースを取得しているところ、所定の個数だけを取得するようにしてもよい。これは、例えば、ステップ１５０５（Ｓ１５０５）からステップ１５０７（Ｓ１５０７）の繰り返し処理、および、ステップ１５０９（Ｓ１５０９）からステップ１５１２（Ｓ１５１２）の繰り返し処理のループ回数を制限することで実現する。これにより、合格トレースおよび不合格トレースの数が膨大になる場合の処理時間を短縮できる。
【００９７】
また、合格ケースを取得せず（ステップ１５０３（Ｓ１５０３）からステップ１５０７（Ｓ１５０７）の処理を省略）、ステップ１５０９（Ｓ１５０９）の処理を残し、不合格ケースを取得しない（ステップ１５１０（Ｓ１５１０）からステップ１５１１（Ｓ１５１１）を省略）ようにしてもよい。この場合には、テストの合否のみを取得でき、テストの合否のみを知りたい場合に有効である。
【００９８】
図１７は、補完テストケース生成部１０６が実行する処理のフローチャートを示す図である。
ステップ１７００（Ｓ１７００）で、補完テストケース生成部１０６は、テストケース漏れ検査部１０３により入力の漏れが発見された場合に処理を開始する。
ステップ１７０１（Ｓ１７０１）で、補完テストケース生成部１０６は、入力の漏れが存在するテストケースセット（以下、「漏れテストケースセット」という）のテスト対象ルールセットおよびテスト対象ルールセットの依存ルールセットの集合において、各ルールセットが完全であるかをその完全性を検査して確認する。
【００９９】
ルールセットが完全とは、すべての入力に対して、ルールセット内のいずれかのルールの条件部が真になることである。例えば、ルールセット内に「ＩＦ  Ａ＜１  ＴＨＥＮ  Ｒ＝１」と「ＩＦ  Ａ＞１  ＴＨＥＮ  Ｒ＝２」という２つのルールを想定する。入力がＡ＝１の場合、いずれのルールの条件部も真とならないため、当該ルールセットは完全ではない。ルールセットの完全であるか否かの判定は、例えば、ルールセット内の条件部の論理和の否定の充足可能性を判定することにより行う。このとき、充足可能な場合は、当該ルールセットは完全ではなく、充足不能な場合は、当該ルールセットは完全である。
【０１００】
ステップ１７０１（Ｓ１７０１）で、ルールセットが完全であると判定された場合、補完テストケース生成部１０６は、ステップ１７０２（Ｓ１７０２）で、漏れテストケースセットから、後述するルール適用式１８００を生成する。
【０１０１】
図１８は、補完テストケース生成部１０６の処理フローの中で生成する論理式の例を示す図である。
ルール適用式１８００は、実施するテストが、単体テストの場合、ルールセット入出力式１６２０、非テスト入力値式１４１０および対象ルールセット入力値式１４２０の論理積であり、結合テストの場合、ルールセット入出力式１６２０、非テスト入力値式１４１０、対象ルールセット入力値式１４２０および依存関係制約式１４３０の論理積である。
【０１０２】
図１８において、Ｃａｓｅは適用ケースを、ｒｕｌｅは当該適用ケース中のルール、ｒｕｌｅ．ｃｏｎは当該ルールの条件部を表している。また、ｒｕｌｅ．ｒｅｐｌａｃｅｄ＿ｃｏｎは、当該ルールの条件部において、依存入力項目を、当該適用ケース中のルールのうち、当該依存入力項目が参照しているルールセットに含まれるルールの結果部に置き換えることで、全ての依存入力項目を除去した論理式である（以下、「置換済み条件部」という）。
例えば、図２において、適用ケース｛会員特典付与判定（ＲＳ１）．Ｒ５、加入期間計算（ＲＳ２）．Ｒ１｝の場合、会員特典付与判定（ＲＳ１）．Ｒ５の置換済み条件部は、「年齢  ＜  ６０  ａｎｄ  ２５  ＜＝  適用日―加入日」となる。」
【０１０３】
図１７に戻って、ステップ１７０３（Ｓ１７０３）で、補完テストケース生成部１０６は、ルール適用式１８００の充足可能性を判定する。ルール適用式１８００が充足可能とは、ルール適用式が真になること、すなわち、入力の漏れにおいてルールが適用されるケースが存在することを表している。
ステップ１７０３（Ｓ１７０３）で、ルール適用式１８００が「充足不能」と判定された場合、補完テストケース生成部１０６は、ステップ１７０６（Ｓ１７０６）に進む。
ステップ１７０３（Ｓ１７０３）で、ルール適用式１８００が「充足可能」と判定された場合、補完テストケース生成部１０６は、ステップ１７０４（Ｓ１７０４）に進む。
【０１０４】
ステップ１７０４（Ｓ１７０４）で、補完テストケース生成部１０６は、ルール適用式１８００のモデルから、テスト対象のルールセットの出力値と条件部が真となるテスト対象のルールセットおよびテスト対象のルールセットの依存ルールセットの集合のルールを特定し、当該特定したルールの集合を適用ケースとする。これは、ルールの条件部に入力としてモデルを実際に与えることで確認できる（以下、取得した出力値と適用ケースを「適用結果ペア」という。）なお、モデルにおいて、同一のルールセット内のルールで真となるルールが２つの場合は、それぞれ別の適用ケースとする。
【０１０５】
ステップ１７０５（Ｓ１７０５）で、補完テストケース生成部１０６は、適用結果ペアの適用ケースから重複禁止制約式１６３０を生成し、当該重複禁止制約式１６３０をルール適用式１８００と論理積を用いて結合し、ステップ１７０３（Ｓ１７０３）に進む。なお、ステップ１７０４（Ｓ１７０４）で複数個の適用ケースを取得した場合は、すべての適用ケースから重複禁止制約１６３０を生成し、ルール適用式１８００と論理積で結合する。
ステップ１７０６（Ｓ１７０６）で、補完テストケース生成部１０６は、適用結果ペアごとに、適用ケースから後述する同値クラス式１８１０を生成する。
【０１０６】
図１８において、同値クラス式１８１０は、漏れテストケースセットで実施するテストが、単体テストの場合、図１４の非テスト入力値式１４１０と適用ケースに含まれる全ルールの条件部を論理積で結合した式とを論理積で結合した式であり、結合テストの場合、非テスト入力値式１４１０と適用ケースに含まれる全ルールの置換済み条件部とを論理積で結合した式をさらに論理積で結合した式である。
【０１０７】
図１７に戻り、ステップ１７０７（Ｓ１７０７）で、補完テストケース生成部１０６は、全適用結果ペアに対して、適用結果ペアの同値クラス式１８１０を入力条件とし、出力値を「出力項目  ＝  項目値」形式で記述した論理式を期待出力条件として、補完テストケースを生成する。そして、ステップ１７０８（Ｓ１７０８）で、補完テストケース生成部１０６は処理を終了する。
【０１０８】
ここで、補完テストケース生成部１０６は、補完テストケース生成時に、同値クラス式１８１０をより短い論理式に変換してもよい。
例えば、論理式の真偽に影響を与えない部分（以下、「ドントケア」という）を削除することで、同値クラス式１８１０を短くすることが可能である。論理式中の一部がドントケアかどうかは、以下の判定を行う。漏れテストケースセットで実施するテストが単体テストならば、同値クラス式１８１０および一部を削除した同値クラス式（以下、「削除後同値クラス式」という）を用いて、「同値クラス式１８１０→削除後同値クラス式」と「削除後同値クラス式→同値クラス式１８１０」の論理積を否定したドントケア判定式１８２０の充足可能性を判定する。漏れテストケースセットで実施するテストが結合テストならば、当該単体テストの判定式に加えて、図１４の依存関係制約式１４３０を論理積で結合したドントケア判定式１８２０の充足可能性を判定する。
【０１０９】
ドントケア判定式１８２０が充足可能ならば、削除した部分はドントケアではない。ドントケア判定式１８２０が充足可能ならば、削除した部分はドントケアである。なお、同値クラス式１８１０の理解容易性を向上させるため、ド・モルガンの法則等を用いて、同値クラス式１８１０に存在する否定演算子「ｎｏｔ」を、「入力項目  比較演算子  計算式」、「入力項目  比較演算子  項目値」などの比較式の直前に移動し、式中の括弧の数を減らすことも可能である。さらに、比較式中の比較演算子を当該演算子の否定に対応する比較演算子に変更することで、比較式直前の否定演算子を除去できる。
例えば、「ｎｏｔ（（加入年  ＞２００１）  ｏｒ  （加入年  ＜  ２００１））」という同値クラス式１８１０の場合、「ｎｏｔ（加入年  ＞２００１）  ａｎｄ  ｎｏｔ（加入年  ＜  ２００１）」に変換し、さらに、「（加入年  ＜＝  ２００１）  ａｎｄ  （加入年  ＞＝  ２００１）」に変換することも可能である。
【０１１０】
図１９は、不具合箇所分析部１０７が実行する処理のフローチャートを示す図である。
ステップ１９００（Ｓ１９００）で、不具合箇所分析部１０７は、１つ以上の論理テストケースに対してテストを実施した結果、不合格した論理テストケースが見つかった場合に処理を開始する。なお、図１９のステップ１９０３（Ｓ１９０３）〜ステップ１９０６（Ｓ１９０６）は、テスト結果記録部１２３に記録されたテスト結果中の適用ケース（以下、「分析対象適用ケースの集合」という）に含まれるルール（以下、「分析対象ルール」という）ごとに処理を実行する。
【０１１１】
ステップ１９０１（Ｓ１９０１）で、不具合箇所分析部１０７は、分析対象適用ケースの集合から合格ケース数をカウントする。
ステップ１９０２（Ｓ１９０２）で、不具合箇所分析部１０７は、分析対象適用ケースの集合から、不合格ケース数をカウントする。
ステップ１９０３（Ｓ１９０３）で、不具合箇所分析部１０７は、分析対象適用ケースの集合に含まれる分析対象ルールを取得する。
【０１１２】
ステップ１９０４（Ｓ１９０４）で、不具合箇所分析部１０７は、分析対象適用ケースの集合のうち、分析対象ルールが含まれる不合格ケース数をカウントして不合格の出現率を算出する。
ステップ１９０５（Ｓ１９０５）で、不具合箇所分析部１０７は、分析対象適用ケースの集合のうち、分析対象ルールが含まれる合格ケース数をカウントして合格の出現率を算出する。
【０１１３】
ステップ１９０６（Ｓ１９０６）で、不具合箇所分析部１０７は、先に求めた出現率（不合格）と出現率（合格）とから合格率を算出する。この算出した結果から、不合格ケースに偏って含まれるルールや不合格ケースに共通するルールを特定することが可能となる。
不具合箇所分析部１０７は、すべての分析対象ルールに対して、ステップ１９０３（Ｓ１９０３）〜ステップ１９０６（Ｓ１９０６）の処理を実行した後、ステップ１９０７（Ｓ１９０７）で処理を終了する。
【０１１４】
図２０は、影響範囲分析部１０８が実行する処理のフローチャートを示す図である。
ステップ２０００（Ｓ２０００）で、影響範囲分析部１０８は、図７のルール作成・編集画面７００において、装置利用者によるルールの編集を検知した場合に、処理を開始する（以下、装置利用者によって編集されたルールを「編集済みルール」という）。
【０１１５】
ステップ２００１（Ｓ２００１）で、影響範囲分析部１０８は、編集前の当該ルールをメモリ１３２から、また、編集後の当該ルールを図７のルール編集エリア７４０から、それぞれ取得する。
ステップ２００２（Ｓ２００２）で、影響範囲分析部１０８は、編集内容を特定する。
例えば、ルールの追加・削除に関しては、編集前のルールが存在するか、または編集後のルールが存在するかによって特定できる。また、ルールＩＤおよび結果部の変更に関しては、文字列一致で変更されたかどうかを特定できる。さらに、条件部に関しては、入力値増加式「¬（編集後のルールの条件部→編集前のルールの条件部）」、および、入力値減少式「¬（編集前のルールの条件部→編集後のルールの条件部）」が充足可能かを判定することで、編集済みルールの条件部を真とする入力値の増加または減少を特定できる。
【０１１６】
入力増加式が充足可能であるとは、入力値増加の検査式が真になること、すなわち、編集後のルールの条件部を真とする入力のうち、編集前のルールの条件部が真にならない入力が存在することを意味している。
また、入力減少式が充足可能であるとは、入力値減少の検査式が真になること、すなわち、編集前ルールの条件部を真とする入力のうち、編集後のルールの条件部が真にならない入力が存在することを意味している。
【０１１７】
ステップ２００３（Ｓ２００３）で、影響範囲分析部１０８は、編集によって合否の変わる可能性のある論理テストケースをテストケース記録部１２１から取得する。編集内容に対して、合否の変わる可能性のある論理テストケースは、例えば、図２１に示す処理フローによって取得できる。
【０１１８】
図２１は、影響範囲分析部１０８が、合否の変わる可能性のある論理テストケースを取得する処理のフローチャートを示す図である。
ステップ２１００（Ｓ２１００）で、影響範囲分析部１０８は、図２０のステップ２００３（Ｓ２００３）において、図２１のフローチャートの処理を開始する。
【０１１９】
ステップ２１０１（Ｓ２１０１）で、影響範囲分析部１０８は、編集内容を確認する。
編集内容が「ルールの追加」の場合、影響範囲分析部１０８は、ステップ２１０２（Ｓ２１０２）に進む。
編集内容が「ルールの削除」の場合、影響範囲分析部１０８は、ステップ２１０４（Ｓ２１０４）に進む。
編集内容が「ルールの変更」の場合、影響範囲分析部１０８は、ステップ２１０６（Ｓ２１０６）に進む。
【０１２０】
編集内容が「ルールの追加」の場合には、ステップ２１０２（Ｓ２１０２）で、影響範囲分析部１０８は、合否の変わる可能性のある論理テストケースとして、編集済みルールを含むルールセットをテスト対象ルールセットとするテストケースセットに含まれる論理テストケース（以下、「候補テストケース」という）を全て取得し、ステップ２１０３（Ｓ２１０３）で処理を終了する。
【０１２１】
編集内容が「ルールの削除」の場合には、ステップ２１０４（Ｓ２１０４）で、影響範囲分析部１０８は、候補テストケースのうち、編集済みルールを含む適用ケースを持つ論理テストケースを取得し、ステップ２１０５（Ｓ２１０５）で処理を終了する。
【０１２２】
編集内容が「ルールの変更」の場合には、ステップ２１０６（Ｓ２１０６）で、影響範囲分析部１０８は、変更の対象を確認する。
変更対象が「ルールＩＤ」の場合、影響範囲分析部１０８は、ステップ２１０７（Ｓ２１０７）で処理を終了する。
変更対象が「結果部」の場合、影響範囲分析部１０８は、ステップ２１０８（Ｓ２１０８）に進む。
変更対象が「条件部」の場合、影響範囲分析部１０８は、ステップ２１１０（Ｓ２１１０）に進む。
【０１２３】
変更対象が「結果部」の場合には、ステップ２１０８（Ｓ２１０８）で、影響範囲分析部１０８は、候補テストケースのうち、編集済みルールを含む適用ケースを持つ論理テストケースを取得し、ステップ２１０９（Ｓ２１０９）で処理を終了する。
変更対象が「条件部」の場合には、ステップ２１１０（Ｓ２１１０）で、影響範囲分析部１０８は、入力増加式の充足可能性を確認する。
【０１２４】
入力増加式が「充足可能」な場合、影響範囲分析部１０８は、ステップ２１１１（Ｓ２１１１）に進む。ステップ２１１１（Ｓ２１１１）で、影響範囲分析部１０８は、候補テストケースを全て取得し、ステップ２１１４（Ｓ２１１４）で処理を終了する。
入力増加式が「充足不能」な場合、影響範囲分析部１０８は、ステップ２１１２（Ｓ２１１２）に進む。ステップ２１１２（Ｓ２１１２）で、影響範囲分析部１０８は、入力減少式の充足可能性を確認する。
【０１２５】
入力減少式が「充足可能」な場合、影響範囲分析部１０８は、ステップ２１１３（Ｓ２１１３）に進む。ステップ２１１３（Ｓ２１１３）で、影響範囲分析部１０８は、候補テストケースのうち、編集済みルールを含む適用ケースを持つ論理テストケースを取得し、ステップ２１１４（Ｓ２１１４）で処理を終了する。
入力減少式が「充足不能」な場合、すなわち、入力増加式および入力減少式共に充足不能とは等価であり変更がないことを意味し、影響範囲分析部１０８は、ステップ２１１４（Ｓ２１１４）で処理を終了する。
【０１２６】
図２０に戻り、ステップ２００４（Ｓ２００４）で、影響範囲分析部１０８は、影響を受ける論理テストケースに対してテストを実行し、ステップ２００５（Ｓ２００５）で処理を終了する。
【符号の説明】
【０１２７】
１００…ルールテスト装置、１０１…ルール作成・修正部、１０２…テストケース作成・修正部、１０３…テストケース漏れ検査部、１０４…テスト実行部、１０５…テスト結果出力部、１０６…補完テストケース生成部、１０７…不具合箇所分析部、１０８…影響範囲分析部、１２０…補助記憶装置、１２１…テストケース記録部、１２２…ルール記録部、１２３…テスト結果記録部、１３１…プロセッサ、１３２…メモリ、１３３…入出力装置
【図１】
0006604892.tif 000002
【図２】
0006604892.tif 000003
【図３】
0006604892.tif 000004
【図４】
0006604892.tif 000005
【図５】
0006604892.tif 000006
【図６】
0006604892.tif 000007
【図７】
0006604892.tif 000008
【図８】
0006604892.tif 000009
【図９】
0006604892.tif 000010
【図１０】
0006604892.tif 000011
【図１１】
0006604892.tif 000012
【図１２】
0006604892.tif 000013
【図１３】
0006604892.tif 000014
【図１４】
0006604892.tif 000015
【図１５】
0006604892.tif 000016
【図１６】
0006604892.tif 000017
【図１７】
0006604892.tif 000018
【図１８】
0006604892.tif 000019
【図１９】
0006604892.tif 000020
【図２０】
0006604892.tif 000021
【図２１】
0006604892.tif 000022