(57)【要約】【課題】ソフトウェア仕様から、当該ソフト仕様上出力しうる値を網羅したテストケースを生成する。【解決手段】ソフトウェア仕様を受け付け、このソフトウェア仕様から、当該ソフトウェアに対するテスト入力値と、前記テスト入力値を入力として前記ソフトウェアを実行したときに出力値として得られることが期待される期待出力値と、を含むテストケースを生成し、前記ソフトウェア仕様上出力しうる値が、前記期待出力値に含まれているかどうかを確認し、前記確認の結果、ソフトウェア仕様上出力しうる値が、前記期待出力値に含まれていないと判断された場合に、前記ソウフトウェア仕様上出力しうる値と、それに対応するテスト入力値とから構成されるテストケースを生成し、前記生成したテストケースに追加する。【選択図】  図１
2014186407.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェア仕様からテストケースを生成するテストケース生成装置におけるテストケース生成方法であって、
前記ソフトウェア仕様を受け付け、記憶部に記憶する処理と、
前記ソフトウェア仕様から、当該ソフトウェアに対するテスト入力値と、前記テスト入力値を入力として前記ソフトウェアを実行したときに出力値として得られることが期待される期待出力値と、を含むテストケースを生成し、前記記憶部に記憶する処理と、
前記ソフトウェア仕様上出力しうる値が、前記期待出力値に含まれているかどうかを確認する処理と、
前記確認の結果、ソフトウェア仕様上出力しうる値が、前記期待出力値に含まれていないと判断した場合に、前記ソウフトウェア仕様上出力しうる値と、それに対応するテスト入力値とから構成されるテストケースを生成し、前記記憶部に記憶されている前記テストケースに追加する処理とを実施する、
ことを特徴とするテストケース生成方法。
【請求項２】
前記ソフトウェア仕様は、ソフトウェア実行前の条件とその実行後の結果との対応関係を表形式で定義した決定表である、
ことを特徴とする請求項１に記載のテストケース生成方法。
【請求項３】
前記テストケース生成装置により、前記ソフトウェア仕様上出力しうる値が、前記期待出力値に含まれているかどうかを確認する処理は、前記決定表の結果因子の組み合わせとして定義される結果値候補それぞれに対し、すでに生成されたテストケースに前記結果値候補が含まれているか、と、前記結果値候補が前記決定表によって定義された処理結果として生じうるか、とを確認する処理である、
ことを特徴とする請求項２に記載のテストケース生成方法。
【請求項４】
前記テストケース生成装置により、
前記確認の結果、前記決定表の結果因子の組み合わせとして定義される結果値候補それぞれに対し、前記すでに生成されたテストケースに前記結果値候補が含まれておらず、かつ前記結果値候補が前記決定表によって定義された処理結果として生じうるものであった場合に、前記結果値候補を与える入力値をひとつ算出し、新たなテストケースとして、前記記憶部に記憶されている前記テストケースに追加する処理を実施する、
ことを特徴とする請求項３に記載のテストケース生成方法。
【請求項５】
ソフトウェア仕様からテストケースを生成する装置であって、
前記ソフトウェア仕様を受け付け、記憶部に記憶する仕様受付手段と、
前記ソフトウェア仕様から、当該ソフトウェアに対するテスト入力値と、前記テスト入力値を入力として前記ソフトウェアを実行したときに出力値として得られることが期待される期待出力値と、を含むテストケースを生成し、前記記憶部に記憶するテストケース生成手段と、
前記ソフトウェア仕様上出力しうる値が、前記期待出力値に含まれているかどうかを確認する期待出力確認手段と、
前記期待出力確認手段により、ソフトウェア仕様上出力しうる値が、前記期待出力値に含まれていないと判断された場合に、前記ソウフトウェア仕様上出力しうる値と、それに対応するテスト入力値とから構成されるテストケースを生成し、前記記憶部に記憶されている前記テストケースに追加するテストケース追加手段と、を備える、
ことを特徴とするテストケース生成装置。
【請求項６】
前記ソフトウェア仕様は、ソフトウェア実行前の条件とその実行後の結果との対応関係を表形式で定義した決定表である、
ことを特徴とする請求項５に記載のテストケース生成装置。
【請求項７】
前記期待出力確認手段は、
前記決定表の結果因子の組み合わせとして定義される結果値候補それぞれに対し、すでに生成されたテストケースに当該結果値候補が含まれているかどうかを確認する第１の確認手段と、前記結果値候補が前記決定表によって定義された処理結果として生じうるかどうかを確認する第２の確認手段を備える、
ことを特徴とする請求項６に記載のテストケース生成装置。
【請求項８】
前記テストケース追加手段は、
前記第１の確認手段と前記第２の確認手段の結果、前記決定表の結果因子の組み合わせとして定義される結果値候補それぞれに対し、前記すでに生成されたテストケースに当該結果値候補が含まれておらず、かつ前記結果値候補が前記決定表によって定義された処理結果として生じうるものであった場合に、前記結果値候補を与える入力値をひとつ算出し、新たなテストケースとして、前記記憶部に記憶されている前記テストケースに追加する、
ことを特徴とする請求項７に記載のテストケース生成装置。
【請求項９】
コンピュータを制御するためのプログラムであって、
前記コンピュータを、
ソフトウェア仕様を受け付け、記憶部に記憶する仕様受付手段、
前記ソフトウェア仕様から、当該ソフトウェアに対するテスト入力値と、該テスト入力値を入力として前記ソフトウェアを実行したときに出力値として得られることが期待される期待出力値と、を含むテストケースを生成し、前記記憶部に記憶するテストケース生成手段、
前記ソフトウェア仕様上出力しうる値が、前記期待出力値に含まれているかどうかを確認する期待出力確認手段、
前記期待出力確認手段によって、前記ソフトウェア仕様上出力しうる値が、期待出力値に含まれていないと判断された場合に、当該ソウフトウェア仕様上出力しうる値と、それに対応するテスト入力値とから構成されるテストケースを生成し、前記記憶部に記憶されている前記テストケースに追加するテストケース追加手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア開発を支援する技術に関し、特に、仕様からテストケースを作成する技術に関する。
【背景技術】
【０００２】
ソフトウェアの仕様を、ソフトウェア実行前の条件とその実行後の結果の対応関係で定義する場合がある。このような仕様を、ソフトウェアを外部から見たときの機能として定義されていることから、外部仕様、あるいは、機能仕様と呼ぶことがある。外部仕様の表現方法として、この条件と結果の対応関係を決定表（デシジョンテーブル）と呼ばれる表形式で表現できることが知られており、ソフトウェア開発工程において頻繁に使用される。
【０００３】
また、開発されたソフトウェアが外部仕様で規定された通りの振る舞いをするかどうかを確認する手法として、ソフトウェアテスト手法が知られている。ソフトウェアテストは、テストケースを単位として実施されることがある。ここでテストケースとは、当該ソフトウェアに対する入力値（入力データ）となるテスト入力値（テスト入力データ）と、当該テスト入力値を入力としてソフトウェアを実行したときに出力値として得られることが期待される期待出力値（期待出力データ）、とからなるデータである。実際にテスト入力値を与えてソフトウェアを実行したときに、期待出力値どおりの出力値が得られた場合、当該テストケースについてはテストを合格した、という。
【０００４】
仕様との対応をより厳密に確認するという観点からは、できるだけ多くのテストケースに対してテストを実施することが好ましい。たとえば、仕様上許される取りうる全ての入力に対するテストケースを実行し合格した場合、当該ソフトウェアは、仕様で規定されたとおりの振る舞いをしていることが、すべての値に対して確認できたことになる。
【０００５】
しかし、たとえば、入力が複数の因子の組み合わせとして表される場合、入力として取りうる値の範囲の大きさは、各因子がとりうる値（これを水準値と呼ぶ）の数の積となるため、非常に大きくなる。このような場合、すべてのテストケースに対してテストを実行することは、現実的な時間内に終了しないため、困難となる。
【０００６】
このような場合において、現実的に実施可能な個数のテストケースを抽出する方法として、非特許文献１では、Ｐａｉｒｗｉｓｅ法（ａｌｌ−ｐａｉｒ法とも呼ばれる）という方法が知られている。これは、入力が複数の因子の組み合わせとして表される場合に、不具合の多くがｎ個（ｎは比較的少ない数）の因子の組み合わせに起因していることに着目したｎ因子網羅という考え方により、テストケースを大幅削減する方法である。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】Ａ．Ｂｌａｓｓ ａｎｄ Ｙ．Ｇｕｒｅｖｉｃｈ，“Ｐａｉｒｗｉｓｅ Ｔｅｓｔｉｎｇ”，Ｂｕｌｌｅｔｉｎ ｏｆ ｔｈｅ Ｅｕｒｏｐｅａｎ Ａｓｓｏｃｉａｔｉｏｎ ｆｏｒ Ｔｈｅｏｒｅｔｉｃａｌ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ Ｎｕｍｂｅｒ ７８，Ｏｃｔｏｂｅｒ ２００２，１００−１３２．
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上記非特許文献１に開示された先行技術によれば、テスト対象となるソフトウェアにおいて仕様上取りうる全ての入力の範囲が非常に大きい場合であっても、現実的に実施可能な個数のテストケースを抽出可能となる。しかし、この抽出は、入力の因子に基づくものであり、出力については特段の考慮がなされていない。すなわち、テストケースを構成するテスト入力値については、その分布に一定の考慮がされているが、対応する期待出力値に対しては、なんら考慮されていない。
【０００９】
そのため、上記先行技術に基づいて抽出されたテストケースに含まれる期待出力値の分布は、テスト対象となるソフトウェアが仕様上出力しうる値の範囲の中で偏っている可能性が否定できない。たとえば、抽出されたテストケースに含まれる期待出力値が、すべて同じ値であった場合、テスト対象となるソフトウェアに、当該期待出力値とは異なる値を出力する処理に関わる不具合が含まれていたとしても、その不具合を検出できないことになる。この場合、ソフトウェア仕様からのテストケース生成において、仕様上出力しうる結果値の範囲の中のごく一部しかカバーしないようなテストケースを生成してしまう。
【００１０】
本発明は、ソフトウェア仕様から、当該ソフト仕様上出力しうる値を網羅したテストケースを生成するテストケース生成方法、これを実施するテストケース生成装置およびプログラムを提供することを課題とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するための本発明の代表的な一例は、以下の通りである。すなわち、本発明は、ソフトウェア仕様からテストケースを生成するテストケース生成装置におけるテストケース生成方法である。前記テストケース生成装置は、前記ソフトウェア仕様を受け付け、記憶部に記憶する処理と、前記ソフトウェア仕様から、当該ソフトウェアに対するテスト入力値と、前記テスト入力値を入力として前記ソフトウェアを実行したときに出力値として得られることが期待される期待出力値と、を含むテストケースを生成し、前記記憶部に記憶する処理と、ソフトウェア仕様上出力しうる値が、前記期待出力値に含まれているかどうかを確認する処理と、前記確認の結果、前記ソフトウェア仕様上出力しうる値が、前記期待出力値に含まれていないと判断された場合に、当該ソウフトウェア仕様上出力しうる値と、それに対応するテスト入力値とから構成されるテストケースを生成し、前記記憶部に記憶されている前記テストケースに追加する処理とを実施する。
【発明の効果】
【００１２】
本発明によれば、ソフトウェア仕様から、当該ソフト仕様上出力しうる値を網羅したテストケースを生成することができる。
【図面の簡単な説明】
【００１３】
【図１】第１の実施形態に係る、テストケース生成装置１０１のハードウェアおよびソフトウェア構成の一例を示す図である。
【図２】第１の実施形態に係る、ソフトウェア仕様１３１の一例を示す図である。
【図３】第１の実施形態に係る、ソフトウェア仕様からテストケースを生成する処理の概要を示すフロー図である。
【図４】第１の実施形態に係る、Ｐａｉｒｗｉｓｅ法によって選ばれた２因子網羅する値の組の一例を示す図である。
【図５】第１の実施形態に係る、期待出力確認処理（図３＿ステップ３０４）およびテストケース追加処理（図３＿ステップ３０５）の詳細を示すフロー図である。
【図６】第１の実施形態に係る、図３および図５に示す処理にしたがって生成されるテストケースの一例を示す図である。
【図７】第２の実施形態に係る、期待出力確認処理およびテストケース追加処理の詳細を示すフロー図である。
【発明を実施するための形態】
【００１４】
以降に、本発明の実施形態を、図面等を参照しつつ詳細に説明する。
（第１の実施形態）
図１は、第１の実施形態に係る、テストケース生成装置１０１のハードウェアおよびソフトウェア構成の一例を示す図である。
【００１５】
テストケース生成装置１０１は、ＣＰＵ等の中央制御装置（制御部）１０２と、ＲＡＭ等の中央制御装置１０２のワークエリアとして機能する主記憶装置（記憶部）１０３と、ハードディスク装置等の外部記憶装置（記憶部）１０４と、ＣＤ−ＲＯＭやＦＤ等の可搬性を有する記憶媒体１０５からデータを読取る読み取り装置１０６と、キーボードやマウス等の入力装置１０７と、ディスプレイ等の表示装置１０８と、ネットワークを介して他の装置と通信を行うための通信装置１０９と、前記各装置間のデータ送受を司る外部インターフェイス１１０を備えた、一般的な電子計算機で構築することができる。なお、テストケース生成装置１０１の操作を、もっぱらネットワークを介して行う場合には、表示装置１０８や、入力装置１０７が接続されていなくてもよい。
【００１６】
テストケース生成装置１０１の外部記憶装置１０４には、仕様受付プログラム１２１、テストケース生成プログラム１２２、期待出力確認プログラム１２３、テストケース追加プログラム１２４、テストケース出力プログラム１２５が格納されている。これらのプログラムは、主記憶装置１０３上にロードされ、中央制御装置１０２により、仕様受付処理部１４１、テストケース生成処理部１４２、期待出力確認処理部１４３、テストケース追加処理部１４４、テストケース出力処理部１４５という機能として具現化される。各処理部を実現するプログラムは、予め外部記憶装置１０４に格納されていてもよいし、記憶媒体１０５に格納されており読み取り装置１０６を介して必要に応じて読み出されてもよいし、あるいは、電子計算機が利用可能な通信媒体であるネットワークまたはネットワーク上を伝搬する搬送波を利用する通信装置１０９と接続された他の装置から必要に応じてダウンロードされて外部記憶装置１０４に格納されるものであってもよい。
【００１７】
また、外部記憶装置１０４には、ソフトウェア仕様１３１、テストケース１３２が格納される。テストケースは、テスト入力値１３３と期待出力値１３４を含んで構成される。
【００１８】
図２は、第２の実施形態に係る、ソフトウェア仕様１３１の一例を示す図である。ここでは、ソフトウェア仕様１３１として、特開２０１２−１９０２０３号公報に開示された決定表（デシジョンテーブル）形式で記載された仕様を例に説明する。
【００１９】
ソフトウェア仕様１３１（決定表）は、ソフトウェア実行前の条件とその実行後の結果の対応関係を表形式で定義したもので、条件定義部２０１と結果定義部２０２を含む。条件定義部２０１は、ひとつまたは複数の条件因子２１１を含み、各条件因子はさらに二つ以上の条件値２１２を含む。同様に、結果定義部２０２は、ひとつまたは複数の結果因子２２１を含み、各結果因子はさらに二つ以上の結果値２２２を含む。
【００２０】
表の各列には、各条件／結果因子ごとに１箇所ずつ印付けされている。各列は、印付けられた位置によって、各条件因子がどのような条件値（入力値）をとる場合に、各結果因子がどのような結果値（出力値）となるか、という入出力関係を示している。たとえば図２の一番左の列は、「保険加入有無」が「加入済み」で、「保険納入額」が「０円」で、「収入」が「０円以上５００万円未満」であれば、「補助金」は「交付あり」で、「納税義務」は「義務あり」である、ことをあらわす。
【００２１】
図３は、第１の実施形態に係る、ソフトウェア仕様からテストケースを生成する処理の概要を示すフロー図である。
【００２２】
ステップ３０１：はじめ。
【００２３】
ステップ３０２：仕様受付処理部１４１は、入力装置１０７を介して、あるいは記憶媒体１０５から読み取り装置１０６を介して、あるいは通信装置１０９を介して、ソフトウェア仕様１３１である決定表を受け付け、外部記憶装置１０４に記憶する。
【００２４】
ステップ３０３：テストケース生成処理部１４２は、Ｐａｉｒｗｉｓｅ法に従い、外部記憶装置１０４に記憶されているソフトウェア仕様（決定表）１３１の中から、条件因子について２因子網羅を満たすような列の集合を抽出してテストケース（各列の条件定義部２０１がテスト入力値に相当し、結果定義部２０２が期待出力値に相当する）を生成し、生成したテストケースを外部記憶装置１０４に記憶する。ステップ３０３の処理により、ソフトウェア仕様１３１から、ソフトウェア仕様１３１を満たすテスト入力値と期待出力値とを含む、すくなくともひとつのテストケースが生成される。
【００２５】
ここでステップ３０３におけるＰａｉｒｗｉｓｅ法とは、複数因子のそれぞれがいくつかの値のうちのいずれかひとつをとる場合に、すべての２因子の組み合わせに対して網羅するような（これを２因子網羅と呼ぶ）値の組を選ぶ方法である。具体的な方法は、たとえば非特許文献１に開示されている。
【００２６】
たとえば図２に示したソフトウェア仕様（決定表）１３１の場合、条件因子は「保険加入有無」「保険納入額」「収入」の３因子が存在する。このなかの２因子の組として、たとえば「保険加入有無」と「保険納入額」を取り上げると、この２因子がとりうる値の組は、「加入済み、０円」「加入済み、０円以上から２万円未満」「加入済み、２万円以上」「未加入、０円」「未加入、０円以上から２万円未満」「未加入、２万円以上」の６通りがある。同様に、「保険納入額」と「収入」の２因子がとりうる値の組は６通り、「保険加入有無」と「収入」の２因子がとりうる値の組は４通りある。Ｐａｉｒｗｉｓｅ法では、これらすべてを含むような全因子の値の組が選ばれる。
【００２７】
図４は、Ｐａｉｒｗｉｓｅ法によって選ばれた２因子網羅する値の組の一例を示している。図４中の破線で囲んだ６つの列（４０１〜４０６）を選べば、実際に２因子網羅していることが確認できる。この場合、２つ以下の条件因子に起因するソフトウェアの不具合は、すべて検出できることになる。
【００２８】
以上に述べたステップ３０３における公知のＰａｉｒｗｉｓｅ法においては、テストケースの生成にあたって、条件因子だけを参照しており、結果因子については参照していないことに注意を要する。すなわちテストケースに含まれるテスト入力値については、２因子網羅などのなんらかの網羅性を保証するものが選ばれているのに対し、期待出力値については網羅性を保証し得ない。そこで、次のステップ３０４に示すように、期待出力確認プログラム１２３が、期待出力値を網羅しているか確認し、不足しているテストケースがあれば、ステップ３０５に示すように、テストケース追加プログラム１２４がテストケースを追加する処理を行うことにより、条件因子に関して２因子網羅を実現し、かつ、ソフトウェア仕様上出力しうる値をすべて網羅するテストケースを生成できる。
【００２９】
ステップ３０４：期待出力確認処理部１４３は、ステップ３０３で生成されたテストケースに含まれる期待出力値を確認し、ソフトウェア仕様（決定表）１３１の結果定義部２０２に現れる結果値の全ての組み合わせを網羅しているか確認する。網羅していなければステップ３０５へ進み、網羅していればステップ３０６へ進む。
【００３０】
ステップ３０５：テストケース追加処理部１４４は、ソフトウェア仕様（決定表）の結果定義部２０２に現れる結果値の全ての組み合わせのうち、ステップ３０３で生成されたテストケースに含まれなかった組み合わせを含む列（テストケース）を、外部記憶装置１０４に記憶されているテストケースに追加する。
【００３１】
ステップ３０６：テストケース出力処理部１４５は、得られたテストケースを表示装置１０８や図示していないプリンタ等の出力装置に出力する。
【００３２】
ステップ３０７：おわり。
【００３３】
図５は、期待出力確認処理（図３＿ステップ３０４）およびテストケース追加処理（図３＿ステップ３０５）の詳細を示すフロー図である。
【００３４】
ステップ５０１：はじめ。
【００３５】
ステップ５０２：期待出力確認処理部１４３は、結果値候補として、ソフトウェア仕様（決定表）１３１の結果値２２２の組（結果因子２２１の各因子に対して結果値２２２をひとつずつ選択したもの）のうち、まだ確認していないものをひとつ選ぶ。すべての結果値の組（結果値候補）に対して確認が終わっていれば、ステップ５０５へ進む。すなわち、結果出力確認プログラム１２３は、結果値２２２としてありうる組み合わせ（結果値候補）をすべて順に確認する。図２に示すソフトウェア仕様１３１の例では、１．「交付あり」「義務あり」、２．「交付あり」「義務なし」、３．「交付なし」「義務あり」、４．「交付なし」「義務なし」の４つの結果値候補を順に確認する。
【００３６】
ステップ５０３：期待出力確認処理部１４３は、ステップ３０３で生成されたテストケースの中に、期待出力値が、５０２で選択された結果値候補と一致するものがあるかどうかを確認する。あればステップ５０２に戻る。
【００３７】
ステップ５０４：テストケース追加処理部１４４は、ステップ３０２で受け付けたソフトウエア仕様（決定表）１３１の各列のなかに、結果定義部２０２が、５０２で選択された結果値候補と一致するものがあるかどうか、すなわち、ステップ５０２で選択された結果値候補がソフトウェア仕様１３１によって定義された処理結果として生じうるか、を確認する。テストケース追加処理部１４４は、ステップ３０２で受け付けたソフトウエア仕様（決定表）１３１の各列のなかに、結果定義部２０２が、ステップ５０２で選択された結果値候補と一致するものがある、すなわち、ステップ５０２で選択された結果値候補がソフトウェア仕様１３１によって定義された処理結果として生じうるものであることを確認した場合、当該列の情報を新たなテストケースとして、ステップ３０３で生成されたテストケースに追加し、ステップ５０２に戻る。なければ、そのままステップ５０２に戻る。
【００３８】
このように、ステップ５０２−ステップ５０４に示す処理では、結果値候補を順次変更しながら、当該結果値候補が、（１）すでに出力されたテストケースに含まれている、（２）テストケースには含まれておらずそもそもソフトウェア仕様上出力し得ない値である、（３）テストケースには含まれていないが、ソフトウェア仕様上は出力しうる値である、のいずれかであるかを判定し、（３）の場合には、追加すべきテストケースとして追加する、ことにより、得られたテストケースが期待出力値を網羅していることを保証する。
【００３９】
図６は、図３および図５に示す処理にしたがって生成されたテストケースの一例を示す図である。破線で囲んだ６つの列（６０１〜６０６）が、図３のステップ３０３に示す処理によって生成されたテストケースであり、実線で囲んだ１つの列（６０７）が、図３のステップ３０４−ステップ３０５に示す処理、より詳細には図５のステップ５０２−ステップ５０４に示す処理、にしたがって追加されたテストケースである。これら合計７つのテストケースによって、条件因子に関して２因子網羅を実現し、かつ、仕様上出力しうる値をすべて網羅するテストケースとなっている。
【００４０】
ステップ５０５：ステップ３０６と同様、得られたテストケースを表示装置１０８や図示していないプリンタ等の出力装置に出力する。
【００４１】
ステップ５０６：おわり。
【００４２】
以上説明したように、第１の実施形態によれば、期待出力値の網羅性を保証したテストケースを、ソフトウェア仕様（決定表）１３１から生成することが可能となる。
（第２の実施形態）
第１の実施形態で示した方法によれば、ソフトウェア仕様（決定表）１３１として与えられたソフトウェア仕様から、期待出力値の網羅性を保証したテストケースを生成することが可能となる。
【００４３】
ソフトウェア仕様（決定表）１３１は、条件因子や条件値の数が増えるにしたがってサイズが大きくなるため、処理をするために記憶容量の大きな主記憶装置１０３が必要となることがある。一方、特開２０１２−１９０２０３号公報では、命題形式の仕様（以下、命題仕様と呼ぶ）を与えて、決定表を作成する方法が開示されている。命題仕様とは、『「保険加入有無」が「加入済み」である  かつ  「保険納入額」が「２万円以上」である場合、「補助金」は「交付あり」である  かつ  「納税義務」は「義務あり」である』というような「（条件部）の場合（結果部）である」という形をしたルールを示すものである。特開２０１２−１９０２０３号公報に開示された方法によれば、このようなルールの集合により、決定表を生成することができる。すなわち、ソフトウェア仕様を表形式に展開したデータとしてではなく、ルールの集合を表現するデータとして保持することが可能となる。ひとつのルールで、ソフトウェア仕様上の複数列を定義できることがあるので、表形式に展開して保持する場合と比較し、より小さなサイズの主記憶装置１０３や外部記憶装置１０４で、決定表を管理可能となる。
【００４４】
第２の実施形態は、基本的に第１の実施形態と同様であるが、ソフトウェア仕様を、表形式に展開したデータとしてではなく、命題仕様として保持する。このような命題仕様として管理された決定表をソフトウェア仕様とした際に、期待出力値の網羅性を保証したテストケースを生成することが可能となる。この際、一旦表形式のデータとして展開することなく、期待出力値の網羅性を保証できるため、処理に必要な主記憶装置１０３の記憶容量を小さくできる点で好ましい。
【００４５】
命題仕様では、ルールを命題変数による命題論理式として記述する。各ルールの条件部は、以下のようにして命題論理式として記述できる。まず条件因子Ａの取りうる値ごとにＡ１、Ａ２、・・・Ａｎと命題変数を割り当てる。「条件因子ＡがＡ１である」という記述に対してＡ１∧¬Ａ２∧…∧¬Ａｎ（“∧”は論理積、“¬”は否定）という命題論理式を対応させる。「条件因子ＡがＡ１であり、かつ、条件因子ＢがＢ２である」のように複数の条件が「かつ」で接続されている場合には、それぞれに対応する命題論理式を「∧」で結合した命題論理式を対応させればよい。結果部についても同様にして命題論式を対応させることができる。命題仕様は、条件部と結果部それぞれに対応する命題論理式の組として表現できる。
【００４６】
命題仕様の集合によって定義される決定表は、以下のようにして作成できる。決定表の各列に対して、条件定義部の印付けられた箇所に応じて、以下のような真理値割り当てを考える。条件因子Ｘについてｋ番目の値に印がついている場合、Ｘｋ＝Ｔｒｕｅ、Ｘｉ＝Ｆａｌｓｅ(ｉ≠ｋ)と真理値を割り当てる。このとき、当該列の結果値は、次のように定義される。（１）上記真理値割り当てによって、条件部が充足される命題仕様をすべて集める。（２）集まった命題仕様の結果部に対応する命題論理式を「∧」で結合した命題論理式をつくる。さらに各結果因子に対して結果値に対応する命題変数がちょうどひとつだけＴｒｕｅで、それ以外の結果値に対応する命題変数がＦａｌｓｅになるときに充足される節を「∧」で結合する。（３）（２）で作られた命題論理式を充足する真理値割り当てを探す。これはＳＡＴソルバを利用することで探索可能である。そのような真理値割り当てがちょうどひとつ見つかった場合、その真理値割り当てに相当する結果値の組み合わせが、当該列の結果値となる。なお、真理値割り当てが存在しないときは、命題仕様間に何らかの矛盾があることを意味する。また真理値割り当てが２以上存在する場合は、結果が一意に決まらない、すなわち仕様に曖昧さがあることを意味する。
【００４７】
第２の実施形態における、各処理フローは、基本的に第１の実施形態と同様であるが、図５に示した期待出力確認処理およびテストケース追加処理の一部が変更される。
【００４８】
図７は、第２の実施形態に係る、期待出力確認処理およびテストケース追加処理の詳細を示すフロー図である。
【００４９】
ステップ７０１：はじめ。
【００５０】
ステップ７０２：ステップ５０２と同様。期待出力確認処理部１４３は、結果値候補として、ソフトウェア仕様１３１（命題仕様）の結果値の組（結果因子の各因子に対して結果値をひとつずつ選択したもの）のうち、まだ確認していないものをひとつ選ぶ。すべての結果値の組に対して確認が終わっていれば、ステップ７０５へ進む。
【００５１】
ステップ７０３：ステップ５０３と同様。期待出力確認処理部１４３は、ステップ３０３で生成されたテストケースの中に、期待出力値が、ステップ７０２で選択された結果値候補と一致するものがあるかどうかを確認する。あればステップ７０２に戻る。
【００５２】
ステップ７０４：ステップ７０２で選択された結果値候補が、ステップ３０２で受け付けたソフトウェア仕様（命題仕様）によって出力されうるかどうかを、以下のようにして確認する。テストケース追加処理部１４４は、当該結果値候補に相当する真理値割り当てによって充足される命題仕様をすべて集める。以下、この集合を充足命題仕様集合と呼ぶ。充足命題仕様集合が空集合なら、当該結果値候補は出力されえないので、ステップ７０２に戻る。
【００５３】
ステップ７０５：テストケース追加処理部１４４は、充足命題仕様集合の部分集合であって、以下を満たすものを見つける。（１）当該部分集合に含まれるすべての命題仕様の結果部の命題論理式を「∧」で結合した命題論理式を生成したとき、この命題論理式を充足させる真理値割り当てが、上記の当該結果値候補に相当する真理値割り当て以外に存在しない。（２）当該部分集合に含まれるすべての命題仕様の条件部の命題論理式を「∧」で結合した命題論理式が充足可能である。このような部分集合が存在すれば、テストケース追加処理部１４４は、このとき（２）を充足させる真理値割り当てに相当する条件値をテスト入力値、ステップ７０２で選択された結果値候補を期待出力値とするテストケースを新たなテストケースとして、ステップ３０３で生成されたテストケースに追加し、ステップ７０２にも戻る。存在しなければ、そのままステップ７０２に戻る。
【００５４】
ステップ７０６：ステップ３０６と同様。テストケース出力処理部１４５は、得られたテストケースを表示装置１０８や図示していないプリンタ等の出力装置に出力する。
【００５５】
ステップ７０７：おわり。
【００５６】
図７に示した処理フローにおいても、図５に示した処理フロー同様、結果値候補を順次変更しながら、当該結果値候補が、（１）すでに出力されたテストケースに含まれている、（２）テストケースには含まれておらずそもそも仕様上出力し得ない値である、（３）テストケースには含まれていないが、仕様上は出力しうる値である、のいずれかであるかを判定し、（３）の場合には、追加すべきテストケースとして追加する、ことにより、得られたテストケースが期待出力値を網羅していることが保証する。
【００５７】
以上説明した第２の実施形態によれば、命題仕様として与えられたソフトウェア仕様から、表形式に展開することなく、期待出力値の網羅性を保証したテストケースを生成することが可能となる。
（他の実施形態）
第１の実施形態において、ソフトウェア仕様（決定表）１３１は、図２に示した記法とは異なる記法を用いて表現されることもある。第１の実施形態は、特定の表記方法に限定されるものではなく、他の表記方法で示されたソフトウェア仕様に対しても適用可能である。また、これらの表記方法に従った情報を外部記憶装置１０４に格納する際には、適当なエンコード方法にしたがってコード化したデータを格納すればよい。エンコード方法としては、たとえばＸＭＬ形式や、ＣＳＶ（カンマ区切り）方式などを用いればよい。
【００５８】
また、第１の実施形態では、図３のステップ３０３で、ソフトウェア仕様（決定表）１３１の中から、条件因子について２因子網羅を満たすような列の集合を抽出してテストケースを生成する場合を例に挙げて説明したが、より一般にはすべてのｎ因子の組み合わせに対して網羅するように（これをｎ因子網羅とよぶ。ただしｎは２以上で全因子数以下）抽出してテストケースを生成してもよい。この場合、ｎ個以下の条件因子に起因するソフトウェアの不具合がすべて検出できることになるので、ｎが大きくなるほどテストケースの品質という観点では優れる。一方、ｎが小さいほど、テストケース数は減るためテスト実行時間の観点からは優れる。また、２因子網羅を達成しつつ、３因子以上についても高い網羅率を実現する方法として、直交表法という方法も知られている。第１の実施形態は、２因子網羅するＰａｉｒｗｉｓｅ法に限らず、ｎ因子網羅するＰａｉｒｗｉｓｅ法や直交表法など、他のテストケース抽出方法により生成されたテストケースに対しても適用可能である。
【００５９】
また、期待出力確認処理およびテストケース追加処理は、たとえば、はじめにソフトウェア仕様上出力しうる値の一覧を作成した後に、結果候補値を当該一覧の範囲内で順次変更しながら処理を行うなど、図５に示す処理フローとは異なる処理フローにより実現してもよい。この場合、上記（２）テストケースには含まれておらずそもそもソフトウェア仕様上出力し得ない値であるか、の判定を行う必要がなく、すでに出力されたテストケースに含まれているか否かだけを判定すればよいので、判定処理を軽減できる。
【００６０】
また、第１の実施形態では、ソフトウェア仕様上出力しうる値をすべて網羅するテストケースを生成する場合を例に挙げて説明したが、網羅条件を変更しても、同様に第１の実施形態を適用可能である。たとえば、結果因子に対してＰａｉｒｗｉｓｅ法を適用し、２因子網羅するような結果値候補を選択した上で、上記処理フローを適用するようにしてもよい。この場合、仕様上出力しうる値をすべて網羅するとは限らないが、得られたテストケースに含まれる期待出力値が極端に偏ることを避けつつ、仕様上出力しうる値をすべて網羅する場合と比較して少ない数のテストケースを得られるため、テスト実行時間の観点からは好ましい。
【符号の説明】
【００６１】
１０１・・・テストケース生成装置、１０２・・・中央制御装置（制御部）、１０３・・・主記憶装置（記憶部）、１０４・・・外部記憶装置（記憶部）、１０５・・・記憶媒体、１０６・・・読み取り装置、１０７・・・入力装置、１０８・・・表示装置、１０９・・・通信装置。
【図１】
2014186407.tif 000003
【図２】
2014186407.tif 000004
【図３】
2014186407.tif 000005
【図４】
2014186407.tif 000006
【図５】
2014186407.tif 000007
【図６】
2014186407.tif 000008
【図７】
2014186407.tif 000009