JP2018092374A - テストケース生成装置、及びテストケース生成方法 - Google Patents

Abstract

【課題】業務ソフトウェアのテストを効率よく行う。【解決手段】テストケース生成装置は、ルール仕様と、テストケースを生成する範囲に関する情報である範囲条件、及びテストケースの生成の方式を指定する情報である生成方式を含む、一つ以上のテストケース生成条件と、を記憶する情報記憶部と、ルール仕様を表す論理式であるルール仕様論理式を生成するルール仕様論理式生成部と、テストケース生成条件ごとに、テストケースを生成する範囲を表す論理式である範囲条件論理式を生成する範囲条件論理式生成部と、ルール仕様論理式と範囲条件論理式とを論理積によって結合した論理式であるテストケース生成用論理式を生成するテストケース生成用論理式生成部と、テストケース生成用論理式に基づきテストケースを生成するテストケース生成部とを備える。【選択図】図２

Description

本発明は、テストケース生成装置、及びテストケース生成方法に関する。

特許文献１には、「ルール群ネットワークがルートノード、１つ又は複数の中間ノード、及び１つ又は複数の端末ノードを含み、各ノードについて局所的な制限が個別に設定される。生成装置は、ルール群ネットワークを走査して、祖先ノードの局所的な制限と自分の局所的な制限とを組み合わせることで各ノードの大域的な制限を算出する走査部と、端末ノードの大域的な制限に基づいて、テストケースを生成するための事実情報を取得する事実情報取得部と、テストケースに含まれる必要がある事実群と各事実属性の値範囲とを含む事実情報に基づいてテストケースを生成するテストケース生成部とを含む。これにより、ビジネスルール管理システム（ＢＲＭＳ）においてテストケースを自動的に生成できる。」と記載されている。

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

業務（金融、保険、製造、流通、通信、教育、医療等）を支援するソフトウェア（以下、業務ソフトウェアと称する。）は、業務ルール（業務に係る商品やサービス等に関する法的な規制、業務上の規則、基準等。ビジネスルール、システムルール、チェックルール等とも称される。）に従ってその仕様が決定され設計がなされる。上記仕様はＩＦ−ＴＨＥＮ形式で記述される情報（以下、ルールと称する。）の集まりであるルール仕様によって整理される。業務ソフトウェアの開発や保守に際しては、上記ルール仕様を基にプログラムが作成され、またルール仕様を基に作成したテストケースをプログラムに与えることによりプログラムがルール仕様通りに作成されていることのテスト（検証）が行われる。

特許文献１では、ルール仕様に基づき一律にテストケースを生成している。しかし業務ソフトウェアの開発や保守の現場では、テストケースの生成に関し、例えば、ルール仕様の変更前と変更後の差分や過去に不具合が発生しているパターン等、プログラムの特定の記述部分や論理についてテストケースの数を増やして重点的にテストを行いたい、プログラムのルール仕様を変更していない記述部分や論理についてはテストケースの数を減らしたい、といった多様なニーズが存在し、こうした要求に効率よく対応する必要がある。

本発明はこうした背景に鑑みてなされたもので、テストケースの生成に関する多様なニーズに柔軟に対応することが可能な、テストケース生成装置、及びテストケース生成方法を提供することを目的とする。

本発明の一つは、業務ルールの仕様を記述したルール仕様に基づき生成されるプログラムのテストに用いるテストケースを生成するテストケース生成装置であって、前記ルール仕様と、テストケースを生成する範囲に関する情報である範囲条件、及びテストケースの生成の方式を指定する情報である生成方式を含む、一つ以上のテストケース生成条件と、を記憶する情報記憶部と、前記ルール仕様を表す論理式であるルール仕様論理式を生成するルール仕様論理式生成部と、前記テストケース生成条件ごとに、テストケースを生成す
る範囲を表す論理式である範囲条件論理式を生成する、範囲条件論理式生成部と、前記ルール仕様論理式と前記範囲条件論理式とを論理積によって結合した論理式であるテストケース生成用論理式を生成するテストケース生成用論理式生成部と、前記テストケース生成用論理式に基づきテストケースを生成するテストケース生成部と、を備える

その他、本願が開示する課題、及びその解決方法は、発明を実施するための形態の欄、及び図面により明らかにされる。

本発明の実施形態によれば、テストケースの生成に関する多様なニーズに柔軟に対応することができる。

テストケース生成装置のハードウェア構成例を示す図である。 テストケース生成装置が備える機能及びテストケース生成装置が記憶するデータを示す図である。 ルール仕様の一例を示す図である。 ルール仕様が変更される場合の一例を示す図である。 テストケース生成条件情報の一例を示す図である。 テストケースの一例を示す図である。 メイン処理を説明するフローチャートである。 生成方式として「条件網羅」が設定されているテストケース生成条件に基づくテストケース生成処理を説明するフローチャートである。 生成方式として「パス網羅」が設定されているテストケース生成条件に基づくテストケース生成処理を説明するフローチャートである。

以下、図面を参照しつつ実施形態について説明する。尚、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではない。また実施形態において説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１に、一実施形態として示すテストケース生成装置１０のハードウェア構成を、図２に、テストケース生成装置１０が備える機能及びテストケース生成装置１０が記憶するデータを、夫々示している。

テストケース生成装置１０は、業務（金融、保険、製造、流通、通信、教育、医療等）を支援するソフトウェア（以下、業務ソフトウェアと称する。）の開発や保守等に利用される情報処理装置（コンピュータ）である。テストケース生成装置１０は、クラウドシステムにより提供されるクラウドサーバ等のように仮想的に実現されるものであってもよい。

業務ソフトウェアは、業務ルール（業務に係る商品やサービス等に関する法的な規制、業務上の規則、基準等。ビジネスルール、システムルール、チェックルール等とも称される。）に従ってその仕様が決定され設計がなされる。上記仕様は、いわゆるＩＦ−ＴＨＥＮ形式で記述される情報（以下、ルールと称する。）の集まりであるルール仕様によって整理される。上記のルールは、例えば、「もし〜ならば〜である」といった自然文による記述、「ＩＦ Ａ＝１ ＡＮＤ Ｂ＝２ ＴＨＥＮ Ｒ＝１」というようにコンピュータにより解釈可能な所定の規則に従った記述、条件と結果の対応関係を表形式で定義した決定表による記述等、様々な形態で表現され得る。

業務ソフトウェアの開発や保守に際しては、上記ルール仕様を基に情報処理装置に実行させるプログラムが作成される。そしてルール仕様を基に作成したテストケースをプログラムに与えることにより、プログラムがルール仕様通りに作成されていることのテスト（検証）が行われる。

テストケース生成装置１０は、ルール仕様に基づき生成されるプログラムをテスト（検査）するためのテストケースを生成する。テストケースは、入力条件と、当該入力条件に対して業務ソフトウェアを実行した際に期待される結果（以下、期待結果と称する。）と、を含む。

テストケース生成装置１０は、テストケースを生成する範囲に関する条件である範囲条件と当該範囲条件の下で適用するテストケースの生成の方式とを含む情報であるテストケース生成条件をユーザ等から受け付け、ルール仕様と上記テストケース生成条件とに基づき、テストケース生成条件ごとに、テストケースを生成する範囲を表す論理式である範囲条件論理式を生成する。

テストケース生成条件は、当該テストケース生成条件の範囲条件論理式と他のテストケース生成条件の範囲条件論理式との間に重複が有る場合に何れのテストケース生成条件を優先させるかを示す情報（後述する優先度）を含む。テストケース生成装置１０は、複数のテストケース生成条件の間の範囲条件論理式の重複の有無を調べ、重複が有る場合は重複が無くなるように範囲条件論理式を修正する。

テストケースの生成に際し、テストケース生成装置１０は、ルール仕様を表す論理式であるルール仕様論理式を生成し、生成したルール仕様論理式と範囲条件論理式とを論理積で結合したテストケース生成用論理式を生成する。そしてテストケース生成装置１０は、生成したテストケース生成用論理式の充足可能性を判定し、テストケース生成用論理式が充足可能と判定される場合、充足可能となるルール仕様の入力項目の値の組み合せと出力項目の値とを含むデータをテストケースとして生成する。尚、充足可能性の詳細については後述する。

図１に示すように、テストケース生成装置１０は、プロセッサ１１、主記憶装置１２、補助記憶装置１３、入力装置１４、出力装置１５、及び通信装置１６を備える。これらは図示しないバス等の通信手段を介して互いに通信可能に接続されている。

プロセッサ１１は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）を用いて構成されている。プロセッサ１１が、主記憶装置１２に格納されているプログラムを読み出して実行することにより、テストケース生成装置１０の様々な機能が実現される。主記憶装置１２は、プログラムやデータを記憶する装置であり、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、不揮発性半導体メモリ（ＮＶＲＡＭ（Non Volatile RAM））等である。

補助記憶装置１３は、例えば、ハードディスクドライブ、ＳＳＤ（Solid State Drive
）、光学式記憶装置（ＣＤ（Compact Disc）、ＤＶＤ(Digital Versatile Disc)等）、ストレージシステム、ＩＣカード、ＳＤメモリカードや光学式記録媒体等の記録媒体の読取／書込装置、クラウドサーバの記憶領域等である。補助記憶装置１３に格納されているプログラムやデータは主記憶装置１２に随時ロードされる。

入力装置１４は、例えば、キーボード、マウス、タッチパネル、カードリーダ、音声入力装置等である。出力装置１５は、ユーザに処理経過や処理結果等の各種情報を提供するユーザインタフェースであり、例えば、画面表示装置（液晶モニタ、ＬＣＤ（Liquid Cry
stal Display）、グラフィックカード等）、音声出力装置（スピーカ等）、印字装置等である。尚、例えば、テストケース生成装置１０が通信装置１６を介して他の装置との間で情報の入力や出力を行う構成としてもよい。

通信装置１６は、ＬＡＮやインターネット等の通信手段を介した他の装置との間の通信を実現する有線方式又は無線方式の通信インタフェースであり、例示すれば、ＮＩＣ（Network Interface Card）、無線通信モジュール、ＵＳＢ（Universal Serial Interface）モジュール、シリアル通信モジュール等である。

図２に示すように、テストケース生成装置１０は、テストケース設定編集部１１０、ルール仕様論理式生成部１１１、範囲条件論理式生成部１１２、テストケース生成用論理式生成部１１３、テストケース生成部１１４、及び情報記憶部１５０の各機能（処理部、機能部）を備える。これらの機能は、例えば、プロセッサ１１が、主記憶装置１２や補助記憶装置１３に格納されているプログラムを読み出して実行することにより実現される。またこれらの機能は、例えば、テストケース生成装置１０が備えるハードウェア（ＡＳＩＣ（Application Specific Integrated Circuit）等）によって実現される。

情報記憶部１５０は、ルール仕様１５１、テストケース生成条件情報１５２、及びテストケース１５３を、補助記憶装置１３に記憶する。これらの情報の詳細については後述する。情報記憶部１５０は、これらの情報以外にも、テストケース設定編集部１１０やテストケース生成部１１４が適宜参照もしくは生成する情報等を記憶する。情報記憶部１５０は、補助記憶装置１３に記憶する情報を、例えば、ファイルシステムやＤＢＭＳ（DataBase Management System）によって管理する。

テストケース設定編集部１１０は、ユーザが入力装置１４及び出力装置１５を介してテストケース生成条件情報１５２等の各種設定（登録、変更、削除）を行う際のユーザインタフェースを提供する。

ルール仕様論理式生成部１１１は、ルール仕様１５１を表す論理式であるルール仕様論理式を生成する。

範囲条件論理式生成部１１２は、テストケース生成条件ごとに、テストケースを生成する範囲を表す論理式である範囲条件論理式を生成する。

テストケース生成用論理式生成部１１３は、ルール仕様論理式と範囲条件論理式とを論理積によって結合した論理式であるテストケース生成用論理式を生成する。

テストケース生成部１１４は、テストケース生成用論理式に基づきテストケースを生成する。尚、テストケース生成部１１４が生成したテストケースは情報記憶部１５０がテストケース１５３として補助記憶装置１３に記憶する。

図３に情報記憶部１５０が記憶するルール仕様１５１の一例を示している。同図に示すように、例示するルール仕様１５１は、識別子（以下、ＩＤと表記することがある。）として、「ＲＳ１」が付与されたルール群（名称：ランク判定）と、識別子として「ＲＳ２」が付与されたルール群（名称：割引率判定）とを含む。以下、上記ルール群のことをルールセットと称する。また各ルールセットは、ルールセットＲＳ１、ルールセットＲＳ２等と表記して区別する。同図に示すように、ルールセットＲＳ１は、夫々Ｒ１〜Ｒ３の識別子が付された３つのルールを含む。ルールセットＲＳ２は、夫々Ｒ１〜Ｒ５の識別子が付された５つのルール（以下、各ルールをルールＲ１、ルールＲ２、・・・と表記する。）を含む。

各ルールは、ＩＦ−ＴＨＥＮ形式における記述のＩＦ節に相当する条件部と、ＩＦ−ＴＨＥＮ形式の記述におけるＴＨＥＮ節に相当する結果部とを含む。例えば、ルールセットＲＳ１のルールＲ１は「ＩＦ Ａｍｏｕｎｔ＜２００００ ＴＨＥＮ Ｒａｎｋ＝Ｒｅｇｕｌａｒ」との内容であり、条件部は「Ａｍｏｕｎｔ＜２００００」、結果部は「Ｒａｎｋ＝Ｒｅｇｕｌａｒ」である。

以下の説明において、ルールの条件部に記述されている変数のことを入力項目と称し、結果部に記述されている変数のことを出力項目と称する。また入力項目に設定される具体的な値のことを入力値と称し、出力項目に設定される具体的な値のことを出力値と称する。図３の例の場合、ルールセットＲＳ１のルールＲ１には入力項目として「Ａｍｏｕｎｔ」が、出力項目として「Ｒａｎｋ」が記述されている。またルールセットＲＳ１のルールＲ１の場合、入力項目「Ａｍｏｕｎｔ」に設定される値が入力値であり、出力項目「Ｒａｎｋ」に設定される値である「Ｒｅｇｕｌａｒ」が出力値である。入力値や出力値は必ずしも数値であるとは限らず、文字や文字列等の数値以外で表されるものであってもよい。

図３の例では、ルールセットＲＳ１の出力項目である「Ｒａｎｋ」は、ルールセットＲＳ２の入力項目の一つとして用いられている。またルールセットＲＳ２の入力項目のように、ルールセット及びルールの入力項目は一つとは限らない。入力項目が複数である場合、個々の入力項目の条件式は、論理演算子（ＡＮＤ、ＯＲ等）で結合される。例えば、図３のルールセットＲＳ２では論理演算子「ＡＮＤ」で条件式が結合されている。

複数種の出力項目に共通する（共用できる）ルールがある場合、一つのルールセットに複数種の出力項目をもたせることも可能である。しかしルールセットに複数種の出力項目をもたせると、例えば、業務規則等が変更された際のルールの変更が煩雑になる。そこでルールセットの意味の分かり易さやルールの変更の容易さ等の観点から、本実施形態では同じルールセットに含まれる各ルールの出力項目を同一としている。例えば、ルールセットＲＳ１の各ルールの出力項目は同じ「Ｒａｎｋ」としている。

同じルールセットに含まれるルールの入力項目に設定される入力値は、いずれか一つのルールの条件部を真とする（成立させる）。例えば、ルールセットＲＳ１の入力項目「Ａｍｏｕｎｔ」に設定される入力値は、ルールＲ１〜Ｒ３のいずれか一つの条件部を真とする。

ルール仕様１５１は、業務ソフトウェアの開発や保守に際し適宜変更され得る。テストケース生成装置１０は、ルール仕様１５１をバージョン別に管理している。テストケース生成装置１０が記憶する各ルール仕様１５１には夫々のバージョンを示す情報（以下、バージョン情報と称する。）が付帯する。

図４に、バージョン情報が「Ｖ１」のルール仕様１５１（以下、ルール仕様Ｖ１とも称する。）、及びルール仕様Ｖ１を更新したバージョン情報が「Ｖ２」のルール仕様１５１（以下、ルール仕様Ｖ２とも称する。）の組を例示している。同図においてルール仕様Ｖ２に下線を付して示した部分がルール仕様Ｖ１とルール仕様Ｖ２の差分である。

本例では、ルール仕様Ｖ２に下線で示しているように、ルールセットＲＳ１のルールＲ３の入力項目「Ａｍｏｕｎｔ」に上限が追加され、ルールセットＲＳ１の出力値に「Ｐｌａｔｉｎｕｍ」を出力する内容のルールＲ４が追加されている。またルールセットＲＳ２のルールＲ１の条件部が変更され、ルールＲ４がルールセットＲＳ２の入力項目として「Ｐｌａｔｉｎｕｍ」を用いる内容に変更され、「Ｒａｎｋ」に「Ｐｌａｔｉｎｕｍ」を設定するルールＲ６が追加されている。

図５は、情報記憶部１５０が記憶するテストケース生成条件情報１５２の一例である。同図に示すように、テストケース生成条件情報１５２は、テスト対象１５２１、テスト種別１５２２、条件ＩＤ１５２３、範囲条件１５２４（範囲種別１５２４１、テスト範囲１５２４２を含む。）、生成方式１５２５、境界値ケース要否１５２６、及び優先度１５２７の各項目を有する。

テスト対象１５２１には、テスト対象となるルールセットの識別子が設定される。例えば、ルール仕様１５１が図３に示す内容である場合、テスト対象１５２１には「ＲＳ１」や「ＲＳ２」が設定される。図５の例ではテスト対象１５２１に「ＲＳ２」が設定されており、従って当該テストケース生成条件情報１５２は識別子が「ＲＳ２」のルールセットに関するものということになる。

テスト種別１５２２には「単体」又は「結合」のいずれかが設定される。テスト種別１５２２に「単体」が設定されている場合、テストケース生成装置１０は、当該テストケース生成条件情報１５２に基づき、ルールセットごとに独立したテストケースを生成する。例えば、図３の例では、ルールセットＲＳ２の入力項目の１つにルールセットＲＳ１の出力項目「Ｒａｎｋ」が含まれているが、テストケース生成装置１０は、テストケースの生成に際しルールセットＲＳ１を考慮せず、従ってこの場合、入力条件に含まれる入力項目は「Ａｇｅ」と「Ｒａｎｋ」となる。

一方、テスト種別１５２２に「結合」が設定されている場合、テストケース生成装置１０は、同じルール仕様１５１に属する複数のルールセットの関連を考慮したテストケースを生成する。例えば、図３の例では、ルールセットＲＳ２の入力項目「Ｒａｎｋ」の値は、ルールセットＲＳ１の入力項目である「Ａｍｏｕｎｔ」によって一意に定まる。そのため、テストケースの生成に際し、テストケース生成装置１０は、入力条件から「Ｒａｎｋ」を除外し、入力条件を「Ａｍｏｕｎｔ」及び「Ａｇｅ」とする。

図５に戻り、条件ＩＤ１５２３、範囲条件１５２４（範囲種別１５２４１、テスト範囲１５２４２を含む。）、生成方式１５２５、境界値ケース要否１５２６、及び優先度１５２７の項目からなる各行は、夫々、前述したテストケース生成条件に相当する。

上記項目のうち条件ＩＤ１５２３には各テストケース生成条件の識別子が設定される。

範囲条件１５２４には、前述した範囲条件を指定する情報が設定される。範囲条件１５２４の範囲種別１５２４１には、テストケース生成条件の種別を指定する情報が設定される。本例では、「仕様差分」、「入力条件」、「出力条件」、及び「Ｄｅｆａｕｌｔ」のいずれかが設定される。範囲条件１５２４のテスト範囲１５２４２には、範囲条件に関するより具体的な内容が設定される。このテスト範囲１５２４２に設定可能な内容は、範囲種別１５２４１の設定内容によって異なる。以下具体例を示す。

例えば、範囲種別１５２４１に「仕様差分」が設定されている場合、テスト範囲１５２４２には「変更有」、「変更無」のいずれかを設定することができる。ここで「仕様差分」とは、ルール仕様１５１の変更前と変更後の差分を意味する。テスト範囲１５２４２に「変更有」が設定されている場合、テストケース生成装置１０は、例えば、ルール仕様１５１の変更によってルール仕様１５１に対する入力と出力の関係が変化した範囲に関する入力項目の値の組み合わせをテストケースとして生成する。またテスト範囲１５２４２に「変更無」が設定されている場合、テストケース生成装置１０は、例えば、入力と出力の関係が変化していない範囲に関する入力項目の値の組み合わせをテストケースとして生成する。尚、本例では、変更前のルール仕様１５１をルール仕様Ｖ２の１つ前のバージョン
のルール仕様Ｖ１としているが、変更後のルール仕様と比較する変更前のルール仕様のバージョンをユーザ等が任意に指定できるようにしてもよい。

範囲種別１５２４１に「入力条件」が設定されている場合、テスト範囲１５２４２には入力項目の値に関する条件を示す論理式を設定することができる。この場合、テストケース生成装置１０は、入力項目の値がテスト範囲１５２４２に設定されている論理式を満たすようなテストケースを生成する。

範囲種別１５２４１に「出力条件」が設定されている場合、テスト範囲１５２４２には出力項目の値に関する条件を示す論理式を設定することができる。この場合、テストケース生成装置１０は、出力項目の値がテスト範囲１５２４２に設定された論理式を満たすようなテストケースを生成する。

範囲種別１５２４１に「Ｄｅｆａｕｌｔ」が設定されている場合、テスト範囲１５２４２には「−」が設定される。この場合、テストケース生成装置１０は、当該テストケース生成条件情報１５２における他のテストケース生成条件のいずれの条件も満たさない入力項目の値の組み合わせをテストケースとして生成する。

その他、範囲種別１５２４１及びテスト範囲１５２４２として、例えば、ソースコードの差分、入力項目と出力項目の両方を使った条件等を設定可能としてもよい。その場合、ソースコードの差分は、例えば、記号実行を使うことにより特定することができる。

生成方式１５２５には、テストケースの生成方式を指定する情報（以下、生成方式とも称する。）が設定される。本実施形態では、「条件網羅」、「パス網羅」、「ルール網羅」、「ＡｌｌＰａｉｒｓ／２因子」、「ＡｌｌＰａｉｒｓ／３因子」のいずれかが設定されるものとする。

生成方式１５２５に「条件網羅」が設定されている場合、テストケース生成装置１０は、ルールの条件部の最小構成要素である条件項（例えば図３における「Ａｍｏｕｎｔ＜２００００」、「Ａｇｅ＜＝３５」等）のＴｒｕｅ（真）／Ｆａｌｓｅ（偽）の組み合わせを網羅するようにテストケースを生成する。

「パス網羅」は、テスト種別１５２２に「結合」が設定されているときにのみ生成方式１５２５に設定することができる。生成方式１５２５に「パス網羅」が設定されている場合、テストケース生成装置１０は、ルール仕様１５１の各ルールセット間のルールの組み合わせを網羅するようにテストケースを生成する。例えば、図３の例では、テストケース生成装置１０は、ルールセットＲＳ１のルールＲ１とルールセットＲＳ２のルールＲ１（以下、｛ＲＳ１．Ｒ１、ＲＳ２．Ｒ１｝のように表記する。）、｛ＲＳ１．Ｒ１、ＲＳ２．Ｒ２｝、｛ＲＳ１．Ｒ１、ＲＳ２．Ｒ３｝等の組み合わせを網羅するようにテストケースを生成する。

尚、例えば、図４のルール仕様Ｖ２の例では、ルールセットＲＳ１に含まれるルールの数が４つ、ルールセットＲＳ２に含まれるルールの数が６つであり、この場合、テストケース生成装置１０は、最大で４×６＝２４個のテストケースを生成する。但し実際には実行不能なパスが存在するので、組み合わせの数は上記のような単純計算によって求められる値よりも少なくなる。

生成方式１５２５に「ルール網羅」が設定されている場合、テストケース生成装置１０は、テスト対象のルールセットに含まれているルールが少なくとも１回以上実行されるようにテストケースを生成する。

生成方式１５２５に「ＡｌｌＰａｉｒｓ／２因子」が設定されている場合、テストケース生成装置１０は、ＡｌｌＰａｉｒｓ法を用いて２因子網羅となるようにテストケースを生成する。

生成方式１５２５に「ＡｌｌＰａｉｒｓ／３因子」が設定されている場合、テストケース生成装置１０は、ＡｌｌＰａｉｒｓ法を用いて３因子網羅となるようにテストケースを生成する。

境界値ケース要否１５２６には、テストケース生成装置１０がテストケースを生成する際に境界値に関するテストケースを生成するか否かを表すフラグ（「要」、「不要」、「−」）が設定される。本例では、生成方式１５２５に、「条件網羅」、「ＡｌｌＰａｉｒｓ／２因子」、「ＡｌｌＰａｉｒｓ／３因子」が設定されている場合にのみ、境界値ケース要否１５２６に「要」又は「不要」を設定可能であり、それ以外の場合は「−」が設定される。境界値に関するテストケースの具体例については後述する。

優先度１５２７には、複数のテストケース生成条件の夫々に基づく範囲条件論理式の間に重複が有る場合、即ち、あるテストケース生成条件の範囲種別１５２４１とテスト範囲１５２４２とによって定まる入力値の範囲（以下、入力空間とも称する。）が他のテストケース生成条件の入力空間と重複する場合、いずれのテストケース生成条件を優先するかを決定するための値（以下、優先度と称する。）が設定される。尚、本例では、優先度が大きいテストケース生成条件の生成方式１５２５が優先されるものとする。また複数のテストケース生成条件の優先度１５２７に同じ優先度が設定されている場合、例えば、重複する部分について、双方のテストケース生成条件の生成方式１５２５に設定されている生成方式によってテストケースを生成する。

図６に、テストケース生成装置１０が図４に示すルール仕様１５１、及び図５に示すテストケース生成条件情報１５２に基づき生成したテストケースの例を示す。同図における各行は、夫々、テストケース生成装置１０が生成する一つのテストケースに相当する。同図に示すように、テストケース１５３は、テストケースＩＤ１５３１、条件ＩＤ１５３２、入力条件１５３３、及び期待結果１５３４の各項目を有する。テストケースＩＤ１５３１には、テストケース１５３の識別子が設定される。

条件ＩＤ１５３２には、当該テストケース１５３が、テストケース生成条件情報１５２のいずれのテストケース生成条件に基づき生成したテストケースであるかを識別する識別子が設定される。本例では、テストケース生成条件情報１５２の条件ＩＤ１５２３に設定される識別子が設定されている。

入力条件１５３３には、ルール仕様１５１の入力項目の入力値が設定される。図５のテストケース生成条件情報１５２では、テスト対象１５２１に「ＲＳ２」が設定されており、テスト種別１５２２に「結合」が設定されているので、テストケース生成装置１０は、入力項目「Ａｇｅ」及び「Ａｍｏｕｎｔ」の夫々の入力値を生成して入力条件１５３３に設定する。

期待結果１５３４には、ルール仕様１５１が入力条件を満たす場合のルールセットの出力項目の出力値が設定される。本例では、出力項目は「Ｄｉｓｃｏｕｎｔ」であり、テストケース生成装置１０は、入力条件１５３３の「Ａｇｅ」、「Ａｍｏｕｎｔ」の夫々に設定した入力値に基づき「Ｄｉｓｃｏｕｎｔ」の出力値を求めて期待結果１５３４に設定する。

図７は、テストケースの生成に際してテストケース生成装置１０が行う処理（以下、メイン処理Ｓ７００と称する。）を説明するフローチャートである。以下、同図とともにメイン処理Ｓ７００について説明する。尚、テストケース生成部１１４は、例えば、ユーザからの指示を契機としてメイン処理Ｓ７００を開始する。またテストケース生成部１１４は、例えば、バッチ処理等により自動的に処理を実行する。

同図に示すように、まずテストケース生成装置１０は、情報記憶部１５０が記憶しているテストケース生成条件情報１５２を読み込む（Ｓ７１１）。またテストケース生成装置１０は、テストケース生成に必要なルール仕様１５１を読み込む（Ｓ７１２）。例えば、テストケース生成条件情報１５２が図５の内容である場合、テスト対象１５２１がルールセットＲＳ２であり、テスト種別１５２２に「結合」が設定されているので、テストケース生成装置１０は、図４の最新バージョンのルール仕様１５１であるルール仕様Ｖ２の内容（ルールセットＲＳ１及びルールセットＲＳ２）を読み込む。また図５のテストケース生成条件情報１５２では、範囲種別１５２４１に「仕様差分」が設定されているので、テストケース生成装置１０は、変更前のバージョンのルール仕様１５１であるルール仕様Ｖ２の内容（ルールセットＲＳ１及びルールセットＲＳ２）も読み込む。

続いて、テストケース生成装置１０は、Ｓ７１１で読み込んだテストケース生成条件情報１５２、及びＳ７１２で読み込んだルール仕様１５１に基づき、テストケース生成条件情報１５２の各テストケース生成条件について前述した範囲条件論理式を生成する（Ｓ７１３）。

例えば、図５のテストケース生成条件情報１５２における条件ＩＤ１５２３が「Ｃ１」のテストケース生成条件の場合、範囲種別１５２４１に「仕様差分」が設定され、テスト範囲１５２４２に「変更有」が設定されているので、テストケース生成装置１０は「ＤｉｓｃｏｕｎｔＶ１≠ＤｉｓｃｏｕｎｔＶ２」という範囲条件論理式を生成する。ここで「ＤｉｓｃｏｕｎｔＶ１」は、ルール仕様Ｖ１のルールセットＲＳ２の出力項目、「ＤｉｓｃｏｕｎｔＶ２」は、ルール仕様Ｖ２のルールセットＲＳ２の出力項目である。上記の範囲条件論理式「ＤｉｓｃｏｕｎｔＶ１≠ＤｉｓｃｏｕｎｔＶ２」は、ルール仕様１５１のルール仕様１５１の変更前と変更後とで出力値が異なることを表す。尚、同じテストケース生成条件でテスト範囲１５２４２に「変更無」が設定されている場合、範囲条件論理式は「ＤｉｓｃｏｕｎｔＶ１＝ＤｉｓｃｏｕｎｔＶ２」となる。

また例えば、図５のテストケース生成条件情報１５２における条件ＩＤ１５２３が「Ｃ２」のテストケース生成条件の場合、範囲種別１５２４１に「入力条件」が設定され、テスト範囲１５２４２に「Ａｇｅ＞６０」が設定されているので、テストケース生成装置１０は、「Ａｇｅ＞６０」という範囲条件論理式を生成する。

また例えば、図５のテストケース生成条件情報１５２における条件ＩＤ１５２３が「Ｃ３」のテストケース生成条件の場合、範囲種別１５２４１に「Ｄｅｆａｕｌｔ」が設定されているので、テストケース生成装置１０は、条件ＩＤ１５２３が「Ｃ１」のテストケース生成条件の範囲条件論理式と、条件ＩＤ１５２３が「Ｃ２」のテストケース生成条件の範囲条件論理式とを除いた範囲に相当する範囲条件論理式「¬（範囲条件論理式Ｃ１∨範囲条件論理式Ｃ２）」を生成する。尚、「∨」は論理和を表し、「¬」は論理否定を表す。

図７に戻り、続いてテストケース生成装置１０は、Ｓ７１３で生成した複数の範囲条件論理式の間に重複が有るか否か（重複する入力空間が存在するか否か）を判定する（Ｓ７１４）。ここでテストケース生成装置１０は、複数の範囲条件論理式の間に重複が有るか否かを、例えば、テストケース生成条件のうち範囲種別が「Ｄｅｆａｕｌｔ」であるテス
トケース生成条件を除く任意の２つのテストケース生成条件について生成した範囲条件論理式の論理積の充足可能性を判定することにより行う。具体的には、テストケース生成装置１０は、上記判定により充足可能と判定した場合は重複が有ると判定し、上記判定により充足不能と判定した場合は重複が無いと判定する。例えば、図５のテストケース生成条件情報１５２の場合、テストケース生成装置１０は、条件ＩＤ１５２３が「Ｃ１」のテストケース生成条件の範囲条件論理式と、条件ＩＤ１５２３が「Ｃ２」のテストケース生成条件の範囲条件論理式の論理積の充足可能性を判定する。

ここで充足可能性とは、与えられた論理式をＴＲＵＥ（真）にする変数の値の組み合わせが存在するか否かを表す性質をいう。充足可能性は、単純には、全ての変数の値の組み合わせをチェックすることにより判定することができる。またＤＰＬＬ（Davis-Putnam-Logemann-Loveland）アルゴリズム等、変数の値の組み合わせではなく論理式の構造に着目して効率よく充足可能性を判定するツールを用いて充足可能性を判定することもできる。例えば、ＳＭＴ（Satisfiability Modulo Theories）ソルバを用いて充足可能性を判定することができる。

Ｓ７１４において範囲条件論理式に重複が有ると判定した場合（Ｓ７１４：ＹＥＳ）、テストケース生成装置１０は、テストケース生成条件の夫々の優先度１５２７に基づき、重複が無くなるように少なくともいずれかの範囲条件論理式を修正する（Ｓ７１５）。例えば、図５のテストケース生成条件情報１５２の場合、条件ＩＤ１５２３が「Ｃ１」のテストケース生成条件の範囲条件論理式と、条件ＩＤ１５２３が「Ｃ２」のテストケース生成条件の範囲条件論理式との間に重複が有り、条件ＩＤ１５２３が「Ｃ１」のテストケース生成条件の優先度が条件ＩＤ１５２３が「Ｃ２」のテストケース生成条件の優先度よりも高い。この場合、テストケース生成装置１０は、条件ＩＤ１５２３が「Ｃ１」のテストケース生成条件の範囲条件論理式はそのままとし、条件ＩＤ１５２３が「Ｃ２」のテストケース生成条件の範囲条件論理式を「範囲条件論理式Ｃ２∧¬範囲条件論理式Ｃ１」と修正する。このように「¬範囲条件論理式Ｃ１」を論理積で結合することで、範囲条件論理式間で重複が無いようにすることができる。また優先度によっていずれのテストケース生成条件を優先するかを選択可能にしたことで、優先すべきテストケース生成条件に対応するテストケースの生成を優先させることができる。

Ｓ７１４においてテストケース生成装置１０が範囲条件論理式に重複が無いと判定した場合（Ｓ７１４：ＮＯ）、処理はＳ７１６に進む。

図７に戻り、Ｓ７１６では、テストケース生成装置１０は、Ｓ７１２で読み込んだルール仕様１５１を表す論理式（以下、ルール仕様論理式と称する。）を生成する。具体的には、テストケース生成装置１０は、テスト対象のルールセットと、テスト対象のルールセットの入力になっている全てのルールセットの各論理式を論理積（「∧」）で結合することにより、ルール仕様論理式を生成する。

例えば、図４の場合、テストケース生成装置１０は、最新バージョンのルール仕様１５１であるルール仕様Ｖ２の内容（ルールセットＲＳ１及びルールセットＲＳ２）に基づきルール仕様論理式を生成する。また範囲種別１５２４１に「仕様差分」が設定されているテストケース生成条件がテストケース生成条件情報１５２に存在する場合、テストケース生成装置１０は、他のバージョンのルール仕様１５１に基づくルール仕様論理式も生成する。図５の場合、範囲種別１５２４１に「仕様差分」が設定されているテストケース生成条件がテストケース生成条件情報１５２に存在するので、テストケース生成装置１０は、図４のルール仕様Ｖ１の内容（ルールセットＲＳ１及びルールセットＲＳ２）に基づくルール仕様論理式も生成する。

例えば、ルール仕様Ｖ１のルールセットＲＳ１を表す論理式をＲＳ１Ｖ２と表し、ルール仕様Ｖ２のルールセットＲＳ１を表す論理式をＲＳ１Ｖ２と表した場合、テストケース生成装置１０は「ＲＳ１Ｖ２∧ＲＳ２Ｖ２」というルール仕様論理式を生成する。例えば、図４の場合、ＲＳ１Ｖ１は「（Ａｍｏｕｎｔ＜２００００∧ＲａｎｋＶ１＝Ｒｅｇｕｌａｒ）∨（２００００＜＝Ａｍｏｕｎｔ＜５００００∧ＲａｎｋＶ１＝Ｓｉｌｖｅｒ）∨（Ａｍｏｕｎｔ＞＝５００００∧ＲａｎｋＶ１＝Ｇｏｌｄ）」となる。尚、上記の論理式における「ＲａｎｋＶ１」のように、出力項目にはバージョンを識別する文字列（本例では「Ｖ１」）を付与している。範囲種別１５２４１に「仕様差分」が設定されているテストケース生成条件をテストケース生成条件情報１５２が含む場合、テストケース生成装置１０は、変更前のルール仕様１５１のルール仕様論理式も生成する。図４の場合、テストケース生成装置１０は「ＲＳ１Ｖ１∧ＲＳ２Ｖ１」というルール仕様論理式を生成する。

図７に戻り、以上の処理の後、テストケース生成装置１０は、テストケース生成条件情報１５２からテストケース生成条件を一つ選択し（Ｓ７１７）、テストケース生成条件情報１５２の各テストケース生成条件についてテストケースを生成する（Ｓ７１８）。この処理（以下、テストケース生成処理Ｓ７１８と称する。）の具体的な内容については後述する。テストケース生成条件情報１５２の全てのテストケース生成条件についてテストケースを生成すると（Ｓ７１９：ＮＯ）、メイン処理Ｓ７００は終了する。

尚、テストケース生成条件の内容によっては入力値の組み合わせが存在しない場合もあるが、入力値の組み合わせが存在するか否かは、例えば、Ｓ７１５等に後続して範囲条件論理式の充足可能性を判定することにより確認することができる。即ち、範囲条件論理式が充足可能な場合はテストケース生成条件を満たす入力値の組み合わせが存在し、範囲条件論理式が充足不能な場合は入力値の組み合わせが存在しないと判定することができる。そのような判定を行うことで、ユーザは無駄なテストケース生成条件が含まれていないかを容易に知ることができる。

図８は、図７のテストケース生成処理Ｓ７１８を説明するフローチャートであり、生成方式１５２５に「条件網羅」が設定されているテストケース生成条件に基づくテストケース生成処理Ｓ７１８を説明するフローチャートである。以下、同図とともに説明する。

同図に示すように、まずテストケース生成装置１０は、変更後のルール仕様１５１から条件項を抽出する（Ｓ８１１）。尚、テストケース生成装置１０は、図７のＳ７１２で読み込んだルール仕様１５１のルールセットに含まれている条件項のうち、他のルールセットの出力項目になっていない入力項目を含む条件項のみを抽出する。またテストケース生成装置１０は、同一の条件項が重複しないように条件項を抽出する。図４の例の場合、テストケース生成装置１０は、例えば、「Ａｍｏｕｎｔ＜２００００」、「２００００＜＝Ａｍｏｕｎｔ」、「Ａｍｏｕｎｔ＜５００００」、「５００００＜＝Ａｍｏｕｎｔ」、「Ａｍｏｕｎｔ＜１０００００」、「Ａｍｏｕｎｔ＞＝１０００００」、「Ａｇｅ＜＝３５」、「３５＜Ａｇｅ」、「Ａｇｅ＜６０」、「Ａｇｅ＞＝６０」を条件項として抽出する。尚、「Ｒａｎｋ＝Ｒｅｇｕｌａｒ」、「Ｒａｎｋ＝Ｓｉｌｖｅｒ」など「Ｒａｎｋ」に関する条件項は、ルールセットＲＳ１の出力項目に関する条件項であるため、テストケース生成装置１０はこれらについては抽出しない。

続いて、テストケース生成装置１０は、境界値ケース要否１５２６が「要」のテストケース生成条件について、ルール仕様１５１から境界値条件を抽出する（Ｓ８１２）。テストケース生成装置１０は、例えば、Ｓ８１１で抽出した条件項について不等号演算子を等号演算子（＝）に置き換えることにより境界値条件を抽出する。図４の例の場合、テストケース生成装置１０は、例えば、条件項「Ａｍｏｕｎｔ＜２００００」から「Ａｍｏｕｎｔ＝２００００」を、条件項「Ａｍｏｕｎｔ＜５００００」から「Ａｍｏｕｎｔ＝５００
００」を、条件項「Ａｍｏｕｎｔ＜１０００００」から「Ａｍｏｕｎｔ＝１０００００」を、条件項「Ａｇｅ＜＝３５」から「Ａｇｅ＝３５」を、条件項「Ａｇｅ＜６０」から「Ａｇｅ＝６０」を、夫々境界値条件として抽出する。

続いて、テストケース生成装置１０は、テストケースを生成するための論理式であるテストケース生成用論理式を生成する（Ｓ８１３）。具体的には、テストケース生成装置１０は、ルール仕様論理式と範囲条件論理式とを論理積で結合した論理式をテストケース生成用論理式として生成する。例えば、図４のルール仕様１５１に対して図５の条件ＩＤ１５２３が「Ｃ１」のテストケース生成条件に基づくテストケース生成用論理式は「（ＲＳ１Ｖ１∧ＲＳ２Ｖ１）∧（ＲＳ１Ｖ２∧ＲＳ２Ｖ２）∧（ＤｉｓｃｏｕｎｔＶ１≠ＤｉｓｃｏｕｎｔＶ２）」となる。

続いて、テストケース生成装置１０は、生成したテストケース生成用論理式の充足可能性を判定する（Ｓ８１４）。テストケース生成装置１０が充足可能と判定した場合（Ｓ８１４：ＹＥＳ）、処理はＳ８１５に進む。テストケース生成装置１０が充足不能と判定した場合（Ｓ８１４：ＮＯ）、テストケース生成処理Ｓ７１８は終了し、その後、処理は図７のＳ７１８に進む。

続いて、テストケース生成装置１０はモデルを取得する（Ｓ８１５）。ここでモデルとは、与えられた論理式をＴＲＵＥ（真）（充足可能）にする入力値と出力値の組み合わせのサンプルである。テストケース生成装置１０は、例えば、ＳＭＴソルバ（SMT solver）の機能を利用してモデルを取得する。

続いて、テストケース生成装置１０は、Ｓ８１５で取得したモデルに基づき、各入力項目と出力項目の値を特定することによりテストケースを生成する（Ｓ８１６）。

続いて、テストケース生成装置１０は、同一のテストケースが生成されないような論理式である条件網羅制約式を生成し、生成した条件網羅制約式とテストケース生成用論理式とを論理積で結合した論理式を、新たなテストケース生成用論理式として生成する（Ｓ８１７）。

具体的には、テストケース生成装置１０は、取得したモデルから条件項及び境界値条件の真偽値を特定し、特定した真偽値の組み合わせが成立しないような条件網羅制約式を生成する。例えば、真（Ｔｒｕｅ）となった条件項または境界値条件をＴｅｒｍＴ＿ｉ、偽（Ｆａｌｓｅ）となった条件項または境界値条件をＴｅｒｍＦ＿ｊと表すと、テストケース生成装置１０は「¬ＴｅｒｍＴ＿１∨¬ＴｅｒｍＴ＿２∨・・・∨ＴｅｒｍＦ＿１∨ＴｅｒｍＦ＿２∨・・・」という条件網羅制約式を生成する。

例えば、図６のテストケースＩＤ１５３１が「Ｔ１０１」の例では、「Ａｇｅ＝６０」、「Ａｍｏｕｎｔ＝１０００００」であることから、「２００００＜＝Ａｍｏｕｎｔ」、「５００００＜＝Ａｍｏｕｎｔ」、「Ａｍｏｕｎｔ＞＝１０００００」、「Ａｍｏｕｎｔ＝１０００００」、「３５＜Ａｇｅ」、「Ａｇｅ＞＝６０」、「Ａｇｅ＝６０」が真（Ｔｒｕｅ）となり、「Ａｍｏｕｎｔ＜２００００」、「Ａｍｏｕｎｔ＜５００００」、「Ａｍｏｕｎｔ＜１０００００」、「Ａｍｏｕｎｔ＝２００００」、「Ａｍｏｕｎｔ＝５００００」、「Ａｇｅ＜＝３５」、「Ａｇｅ＜６０」、「Ａｇｅ＝３５」が偽（Ｆａｌｓｅ）となる。この場合、テストケース生成装置１０は、「¬（２００００＜＝Ａｍｏｕｎｔ）∨¬（５００００＜＝Ａｍｏｕｎｔ）∨¬（Ａｍｏｕｎｔ＞＝１０００００）∨¬（Ａｍｏｕｎｔ＝１０００００）∨¬（３５＜Ａｇｅ）∨¬（Ａｇｅ＞＝６０）∨¬（Ａｇｅ＝６０）∨Ａｍｏｕｎｔ＜２００００∨Ａｍｏｕｎｔ＜５００００∨Ａｍｏｕｎｔ＜１０００００∨Ａｍｏｕｎｔ＝２００００∨Ａｍｏｕｎｔ＝５００００∨Ａｇｅ＜＝３５∨Ａｇ
ｅ＜６０∨Ａｇｅ＝３５」という条件網羅制約式を生成する。

Ｓ８１７の処理の後、処理はＳ８１４に戻り、テストケース生成装置１０は、条件網羅制約式を用いて新たに生成したテストケース生成用論理式の充足可能性を判定する。そしてテストケース生成装置１０は、Ｓ８１４で充足可能と判定される間、Ｓ８１４〜Ｓ８１７の処理を繰り返し実行する。Ｓ８１４でテストケース生成装置１０が充足不能と判定すると、処理は図７のＳ７１８に進む。

このように条件網羅制約式を用いることで、重複したテストケースの生成を効率よく排除することができ、テストケースを効率よく生成することができる。

図９は、図７のテストケース生成処理Ｓ７１８を説明するフローチャートであり、生成方式１５２５に「パス網羅」が設定されているテストケース生成条件に基づくテストケース生成処理Ｓ７１８を説明するフローチャートである。以下、同図とともに説明する。

まずテストケース生成装置１０は、図８のＳ８１３と同様の方法でテストケース生成用論理式を生成する（Ｓ９１１）。

続いて、テストケース生成装置１０は、生成したテストケース生成用論理式の充足可能性を判定する（Ｓ９１２）。テストケース生成装置１０がテストケース生成用論理式を充足可能と判定した場合（Ｓ９１２：ＹＥＳ）、処理はＳ９１３に進む。テストケース生成装置１０がテストケース生成用論理式を充足不能と判定した場合（Ｓ９１２：ＮＯ）、テストケース生成処理Ｓ７１８は終了する。その後、処理は図７のＳ７１８に進む。

続いて、テストケース生成装置１０は、図８のＳ８１５と同様の方法でモデルを取得し（Ｓ９１３）、取得したモデルに基づき、各入力項目と出力項目の値を特定することによりテストケースを生成する（Ｓ９１４）。

続いて、テストケース生成装置１０は、同一のテストケースが生成されないような論理式であるパス網羅制約式を生成し、当該パス網羅制約式とテストケース生成用論理式とを論理積で結合した論理式を、新たなテストケース生成用論理式として生成する（Ｓ９１５）。ここでテストケース生成装置１０は、モデルから各ルールの条件部の真偽値を特定し、真となるルールの条件部の組み合わせが同時に真とならないようなパス網羅制約式を生成する。具体的には、テストケース生成装置１０は、ルールセット毎に真となる条件部を特定し、これらの条件部を論理積で結合した論理式の否定をパス網羅制約式とする。尚、同一のルールセット内で複数の条件部が真となる場合は同一のルールセット内の真となった条件部を論理和で結合する。

例えば、図６のテストケースＩＤ１５３１が「Ｔ２０１」の例では、ＲＳ１Ｒ３Ｃ、ＲＳ２Ｒ４Ｃ、及びＲＳ２Ｒ５Ｃが真となる。尚、ＲＳ１Ｒ３Ｃは、ルールセットＲＳ１のＩＤがＲ３の条件部を意味する。ＲＳ２Ｒ４ＣとＲＳ２Ｒ５Ｃも同様の意味である。本例ではルールセットＲＳ２の２つの条件部が真となるため、パス網羅制約式は「¬（ＲＳ１Ｒ３Ｃ∧（ＲＳ２Ｒ４∨ＲＳ２Ｒ５））」となる。

Ｓ９１５の処理の後、処理はＳ９１２に戻り、テストケース生成装置１０は、新たなテストケース生成用論理式について充足可能性を判定する。そしてテストケース生成装置１０は、Ｓ９１２で充足可能と判定される間、Ｓ９１２〜Ｓ９１５の処理を繰り返し実行する。Ｓ９１２でテストケース生成装置１０が充足不能と判定すると、処理は図７のＳ７１８に進む。

このようにパス網羅制約式を用いた場合は重複したテストケースの生成を効率よく排除することができ、生成方式１５２５に「パス網羅」が指定されている場合のテストケースを効率よく生成することができる。

尚、生成方式１５２５に「ルール網羅」が指定されている場合のテストケースについても「パス網羅」と同様な手法によりテストケースを効率よく生成することができる。尚、この場合の制約式（以下、ルール網羅制約式と称する。）は、モデルから各ルールの条件部の真偽値を特定し、真となるルールの条件部が偽となるように、当該真となるルールの条件部の否定を論理積で結合することにより生成することができる。

また生成方式１５２５に「ＡｌｌＰａｉｒｓ／２因子」や「ＡｌｌＰａｉｒｓ／３因子」が指定されている場合には、ＰＩＣＴ（Pairwise Independent Combinatorial Testing
tool）などオープンソースソフトウェアを利用することで容易にテストケースを生成す
ることができる。

以上に説明したように、テストケース生成装置１０は、ルール仕様論理式と、範囲条件及び生成方式を含むテストケース生成条件に基づく範囲条件論理式とを論理積によって結合した論理式であるテストケース生成用論理式を生成し、テストケース生成用論理式に基づきテストケースを生成するので、テストケースの生成に関する多様なニーズに柔軟に対応することができる。

またテストケース生成装置１０は、テストケース生成条件の範囲種別１５２４１に「仕様差分」が設定されている場合、ルール仕様の変更前と変更後の差分に基づき範囲条件論理式を生成するので、ルール仕様の変更前と変更後の差分をテストするためのテストケースを効率よく生成することができる。

またテストケース生成装置１０は、テストケース生成条件の範囲種別１５２４１に「入力条件」が設定されている場合、テスト範囲１５２４２に設定されている条件に基づく範囲条件論理式を生成するので、ニーズに対応したテストケースを効率よく生成することができる。

またテストケース生成装置１０は、範囲条件論理式の間に重複が有る場合は重複が無くなるように範囲条件論理式を修正するので、重複したテストケースの生成を防いで効率よくテストケースを生成することができる。

以上、本発明について実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また上記の各構成、機能部、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、また
はＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており
、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。例えば、実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

また以上に説明したテストケース生成装置１０の各種機能部、各種処理部、各種データベースの配置形態は一例に過ぎない。各種機能部、各種処理部、各種データベースの配置形態は、テストケース生成装置１０が備えるハードウェアやソフトウェアの性能、処理効率、通信効率等の観点から最適な配置形態に変更し得る。

また前述した各種データベースの構成（スキーマ（Schema）等）は、リソースの効率的な利用、処理効率向上、アクセス効率向上、検索効率向上等の観点から柔軟に変更し得る。

１０ テストケース生成装置、１１０ テストケース設定編集部、１１１ ルール仕様論理式生成部、１１２ 範囲条件論理式生成部、１１３ テストケース生成用論理式生成部、１１４ テストケース生成部、１５０ 情報記憶部、１５１ ルール仕様、１５２ テストケース生成情報、１５２１ テスト対象、１５２２ テスト種別、１５２４ 範囲条件、１５２４１ 範囲種別、１５２４２ テスト範囲、１５２５ 生成方式、１５２６ 境界値ケース要否、１５２７ 優先度、１５３ テストケース、ＲＳ１，ＲＳ２ ルールセット、Ｓ７００ メイン処理、Ｓ７１８ テストケース生成処理

Claims (15)

1. 業務ルールの仕様を記述したルール仕様に基づき生成されるプログラムのテストに用いるテストケースを生成するテストケース生成装置であって、
   前記ルール仕様と、テストケースを生成する範囲に関する情報である範囲条件、及びテストケースの生成の方式を指定する情報である生成方式を含む、一つ以上のテストケース生成条件と、を記憶する情報記憶部と、
   前記ルール仕様を表す論理式であるルール仕様論理式を生成するルール仕様論理式生成部と、
   前記テストケース生成条件ごとに、テストケースを生成する範囲を表す論理式である範囲条件論理式を生成する、範囲条件論理式生成部と、
   前記ルール仕様論理式と前記範囲条件論理式とを論理積によって結合した論理式であるテストケース生成用論理式を生成するテストケース生成用論理式生成部と、
   前記テストケース生成用論理式に基づきテストケースを生成するテストケース生成部と、
   を備える、テストケース生成装置。
2. 請求項１に記載のテストケース生成装置であって、
   前記情報記憶部は、前記範囲条件として、前記ルール仕様の変更前と変更後の差分を示す情報が設定された前記テストケース生成条件を記憶し、
   前記範囲条件論理式生成部は、前記ルール仕様の変更前と変更後の差分に基づき前記範囲条件論理式を生成する、
   テストケース生成装置。
3. 請求項１に記載のテストケース生成装置であって、
   前記ルール仕様は、前記業務ルールを条件と結果を示す記述形式で記述した情報である複数のルールを含み、
   前記情報記憶部は、前記範囲条件として、前記ルール仕様における前記ルールの入力項目の値に関する条件を示す情報が設定された前記テストケース生成条件を記憶し、
   前記範囲条件論理式生成部は、前記ルールの入力項目の値に関する条件を示す情報に基づき前記範囲条件論理式を生成する、
   テストケース生成装置。
4. 請求項１乃至３のいずれか一項に記載のテストケース生成装置であって、
   前記ルール仕様は、前記業務ルールを条件と結果を示す記述形式で記述した情報である複数のルールを含み、
   前記生成方式は、
   前記ルールの前記条件の組み合わせを網羅するように前記テストケースを生成する方式である条件網羅、
   前記ルールセットの間の前記ルールの組み合わせを網羅するように前記テストケースを生成する方式であるパス網羅、
   前記ルールセットに含まれている前記ルールが少なくとも一回以上実行されるように前記テストケースを生成する方式であるルール網羅、
   ＡｌｌＰａｉｒｓ法を用いて２因子網羅となるように前記テストケースを生成する方式であるＡｌｌＰａｉｒｓ／２因子、及び、
   ＡｌｌＰａｉｒｓ法を用いて３因子網羅となるように前記テストケースを生成する方式であるＡｌｌＰａｉｒｓ／３因子、
   のうちの少なくともいずれかである、
   テストケース生成装置。
5. 請求項１乃至３のいずれか一項に記載のテストケース生成装置であって、
   前記情報記憶部は、前記テストケース生成条件の夫々について設定された優先度を示す情報を記憶し、
   前記テストケース生成部は、複数の前記テストケース生成条件の夫々の前記範囲条件論理式の間に重複が有るか否かを判定し、重複が有る場合、重複が無くなるように少なくともいずれかの前記範囲条件論理式を修正する、
   テストケース生成装置。
6. 請求項５に記載のテストケース生成装置であって、
   前記テストケース生成部は、前記判定に際し、前記判定の対象となる複数の前記範囲条件論理式の論理積の充足可能性を調べ、充足可能な場合は前記複数の範囲条件論理式の間に重複が有ると判定し、充足不能な場合は前記複数の範囲条件論理式の間に重複が無いと判定する、
   テストケース生成装置。
7. 請求項１乃至３のいずれか一項に記載のテストケース生成装置であって、
   前記テストケース生成部は、前記テストケース生成用論理式の充足可能性を判定し、充足可能な場合、充足可能となるような前記ルール仕様における入力項目の入力値の組合せを含むデータをテストケースとして生成する、
   テストケース生成装置。
8. 請求項７に記載のテストケース生成装置であって、
   前記テストケース生成部は、前記テストケース生成用論理式の充足可能性を判定し、充足可能な場合、充足可能となるルール仕様における入力項目の入力値の組合せと前記組み合わせに対して期待される出力項目の出力値とを含むデータをテストケースとして生成する、
   テストケース生成装置。
9. 情報処理装置が、
   業務ルールの仕様を記述したルール仕様に基づき生成されるプログラムのテストに用いるテストケースを生成する範囲に関する情報である範囲条件、及びテストケースの生成の方式を指定する情報である生成方式を含む、一つ以上のテストケース生成条件と、を記憶するステップ、
   前記ルール仕様を表す論理式であるルール仕様論理式を生成するステップ、
   前記テストケース生成条件ごとに、テストケースを生成する範囲を表す論理式である範囲条件論理式を生成するステップ、
   前記ルール仕様論理式と前記範囲条件論理式とを論理積によって結合した論理式であるテストケース生成用論理式を生成するステップ、
   前記テストケース生成用論理式に基づきテストケースを生成するステップ、
   を実行する、テストケース生成方法。
10. 請求項９に記載のテストケース生成方法であって、
    前記情報処理装置が、
    前記範囲条件として前記ルール仕様の変更前と変更後の差分を示す情報が設定された前記テストケース生成条件を記憶するステップ、
    前記ルール仕様の変更前と変更後の差分に基づき前記範囲条件論理式を生成するステップ、
    をさらに実行する、テストケース生成方法。
11. 請求項９に記載のテストケース生成方法であって、
    前記ルール仕様は、前記業務ルールを条件と結果を示す記述形式で記述した情報である複数のルールを含み、
    前記情報処理装置が、
    前記範囲条件として前記ルール仕様における前記ルールの入力項目の値に関する条件を示す情報が設定された前記テストケース生成条件を記憶するステップ、
    前記ルールの入力項目の値に関する条件を示す情報に基づき前記範囲条件論理式を生成するステップ、
    をさらに実行する、テストケース生成方法。
12. 請求項９乃至１１のいずれか一項に記載のテストケース生成方法であって、
    前記ルール仕様は、前記業務ルールを条件と結果を示す記述形式で記述した情報である複数のルールを含み、
    前記生成方式は、
    前記ルールの前記条件の組み合わせを網羅するように前記テストケースを生成する方式である条件網羅、
    前記ルールセットの間の前記ルールの組み合わせを網羅するように前記テストケースを生成する方式であるパス網羅、
    前記ルールセットに含まれている前記ルールが少なくとも一回以上実行されるように前記テストケースを生成する方式であるルール網羅、
    ＡｌｌＰａｉｒｓ法を用いて２因子網羅となるように前記テストケースを生成する方式であるＡｌｌＰａｉｒｓ／２因子、及び、
    ＡｌｌＰａｉｒｓ法を用いて３因子網羅となるように前記テストケースを生成する方式であるＡｌｌＰａｉｒｓ／３因子、
    のうちの少なくともいずれかである、
    テストケース生成方法。
13. 請求項９乃至１１のいずれか一項に記載のテストケース生成方法であって、
    前記情報処理装置が、
    前記テストケース生成条件の夫々について設定された優先度を示す情報を記憶するステップ、
    複数の前記テストケース生成条件の夫々の前記範囲条件論理式の間に重複が有るか否かを判定し、重複が有る場合、重複が無くなるように少なくともいずれかの前記範囲条件論理式を修正するステップ、
    をさらに実行する、テストケース生成方法。
14. 請求項１３に記載のテストケース生成方法であって、
    前記情報処理装置が、
    前記判定に際し、前記判定の対象となる複数の前記範囲条件論理式の論理積の充足可能性を調べ、充足可能な場合は前記複数の範囲条件論理式の間に重複が有ると判定し、充足不能な場合は前記複数の範囲条件論理式の間に重複が無いと判定するステップ、
    をさらに実行する、テストケース生成方法。
15. 請求項９乃至１１のいずれか一項に記載のテストケース生成方法であって、
    前記情報処理装置が、
    前記テストケース生成用論理式の充足可能性を判定し、充足可能な場合、充足可能となるような前記ルール仕様における入力項目の入力値の組合せを含むデータをテストケースとして生成するステップ、
    をさらに実行する、テストケース生成方法。

Images