JP2011044111A

JP2011044111A - ソフトウェアのテスト方法及びプログラム

Info

Publication number: JP2011044111A
Application number: JP2009193500A
Authority: JP
Inventors: Takashi Asahina; 崇朝日奈
Original assignee: Fujitsu Semiconductor Ltd
Current assignee: Fujitsu Semiconductor Ltd
Priority date: 2009-08-24
Filing date: 2009-08-24
Publication date: 2011-03-03
Anticipated expiration: 2029-08-24
Also published as: JP5444939B2

Abstract

【課題】テスト時間を短縮することができるソフトウェアのテスト方法及びプログラムを提供する。
【解決手段】テストケースを分類したカテゴリに対して、統計重み付け比率、基準重み付け比率、上限値、下限値が設定されたカテゴリ重み付けテーブル２５を設けた。ＣＰＵは、各カテゴリにおいて、基準重み付け比率の上限値から下限値の範囲に統計重み付け比率が入っている否かに応じて、基準重み付け比率又は統計重み付け比率のいずれかをカテゴリ重み付け比率として設定するようにした。次に、ＣＰＵは、カテゴリ重み付け比率の最も高いカテゴリ重み付け比率のカテゴリを検証実行カテゴリとして設定した。続いて、ＣＰＵは、検証実行カテゴリとなったカテゴリに分類されたテストケースについてソースコード２１の論理検証を行うようにした。
【選択図】図２

Description

ソフトウェアのテスト方法及びプログラムに関するものである。

電子機器に搭載される集積回路は、一般的に、Ｖｅｒｉｌｏｇ−ＨＤＬやＶＨＤＬ（ＶＨＳＩＣＨａｒｄｗａｒｅＤｅｓｃｒｉｐｔｉｏｎＬａｎｇｕａｇｅ）に代表されるハードウェア記述言語を用いて設計されている。

ハードウェア記述言語を用いて設計される集積回路は、ハードウェア記述言語で記述されたソースコードの状態で、仕様書通りの動作を行うかどうか論理検証される。詳しくは、検証作業者は、仕様書から入力データと、入力データに対する出力期待値を含むテストケースを作成する。検証装置は、テストケースについてソースコードの論理検証を行って、「良」又は「不良」の判定をする。

つまり、検証装置は、ソフトウェアによりテストケースの入力データを処理して出力された出力データがテストケースの出力期待値と等しいか否かを判定する。検証装置は、出力データと出力期待値が等しい場合、「良」と判定し、反対に、検証装置は、出力データと出力期待値が等しくない場合、「不良」と判定する。

そして、検証作業者は、「不良」判定となったテストケースに基づいてソースコードの修正（デバッグ）を行う。検証装置は、テストケースについて、修正を行ったソースコードの論理検証を行って、「良」又は「不良」の判定をする。以後、全てのテストケースについて「良」判定となるまで、ソースコードの論理検証を行っていく。そして、全てのテストケースについて「良」判定になると、仕様書通りに正しくソースコードが記述されているとしてソースコードの論理検証を完了する。

近年、電子機器に求められる機能は複雑化および多機能化しており、それに伴い集積回路の機能も複雑化および多機能化している。これにより、集積回路のソースコードの論理検証では、テストケースの数が飛躍的に増大し、全てのテストケースについて論理検証を行う時間とコスト、及び、デバッグに要する時間とコストは膨大なものとなっている。

そこで、従来、検証作業者は、実験計画法に沿って要因分析表及び直交表により、これまでソースコードの論理検証を行っていたテストケースを絞り込み、少ないテストケースについてソースコードの論理検証を行っていた。この結果、少ないテストケースについてソースコードの論理検証を行うだけで、これまでのソースコードの論理検証を行った効果と同等な効果を得ていた（例えば、特許文献１参照）。

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

しかしながら、上記のソースコードの論理検証では、テストケースについてソースコードの論理検証を行って「不良」と判定された場合、修正されたソースコードの論理検証を全てのテストケースについて同じ順番で行っていた。

従って、ソースコードの論理検証を行って１度「良」と判定されたテストケースについて、最初の段階でソースコードの論理検証を行うことになる。しかし、ソースコードの論理検証を行っていないテストケースについてソースコードの論理検証を行って「不良」と判定される比率より、１度「良」と判定されたテストケースについて修正されたソースコードの論理検証を行って「不良」と判定される比率は低い。このため、ソースコードの論理検証を行うテストケースの順番について考慮することで、ソースコードの論理検証を行う時間をさらに短縮する余地が残されている。

このソフトウェアのテスト方法及びプログラムは、テスト時間を短縮することを目的とする。

本発明の一側面によれば、ソフトウェアのテスト方法は、設計仕様に含まれる各機能について、ソフトウェアが入力データを設計仕様通りに処理するか否かを判定するための前記入力データと、該入力データに対する出力期待値とを有するテストケースを複数作成し、複数の前記テストケースの中から１つの前記テストケースを選択し、ソフトウェアにより前記選択したテストケースの入力データを処理して出力された出力データが前記選択したテストケースの出力期待値と等しいか否かを判定するソフトウェアのテスト方法であって、定量情報及び定性情報に基づいて前記テストケースを分類したカテゴリに対して、分類された前記テストケースが不良と判定される可能性を示す重み付け比率がそれぞれ設定された重み付けテーブルを有し、前記重み付けテーブルの各カテゴリに対する前記重み付け比率に基づいて、ソフトウェアのテストを行う前記カテゴリを選択するカテゴリ選択工程と、前記カテゴリ選択工程において選択された前記カテゴリに分類された前記テストケースについてソフトウェアのテストを行うソフトウェアテスト工程と、前記ソフトウェアテスト工程においてソフトウェアのテストを行った結果に基づいて、ソフトウェアのテストを行ったカテゴリに対する前記重み付けテーブルの重み付け比率を算出し、その算出結果に基づいて重み付けテーブルを変更するテーブル変更工程と、を有する。

本発明の一側面によれば、ソフトウェアのテスト方法及びプログラムは、テスト時間を短縮することができる。

検証装置の概略構成図である。ソースコードの論理検証の説明図である。要因分析表の説明図である。直交表の説明図である。直交表の説明図である。テストケースファイルの説明図である。カテゴリ重み付けテーブルの説明図である。ソースコードの論理検証の説明図である。

以下、実施形態を図１〜図８に従って説明する。
図１は、ハードウェア記述言語で記述された集積回路のソースコードの論理検証を実施するためのコンピュータシステムの概略構成図である。

図１に示すように、このコンピュータ（検証装置）１１は、中央処理装置（以下、ＣＰＵという）１２、メモリ１３、記憶装置１４、表示装置１５、入力装置１６、及び、ドライブ装置１７を備え、それらはバス１８を介して相互にデータの授受を行っている。

ＣＰＵ１２は、メモリ１３を利用してプログラムを実行し、ソースコードの論理検証等に必要な処理を実現する。メモリ１３は、各種処理を提供するために必要なプログラムとデータを格納する。メモリ１３は、通常、キャッシュ・メモリ、システム・メモリおよびディスプレイ・メモリを含む。

表示装置１５は、各種ウインドウやデータ等の表示に用いられ、これにはＣＲＴ、ＬＣＤ、ＰＤＰ等が用いられる。入力装置１６は、ユーザからの要求や指示、パラメータの入力に用いられ、これにはキーボードおよびマウス装置（図示せず）等が用いられる。

記憶装置１４は、通常、磁気ディスク装置、光ディスク装置、光磁気ディスク装置を含む。この記憶装置１４には、ソースコードの論理検証を行うためのプログラムデータとファイルが格納されている。ファイルとしては、仕様書２０、ソースコード２１、要因分析表２２、直交表２３、テストケースファイル２４、カテゴリ重み付けテーブル２５、その他ソースコードの論理検証に必要なファイルが格納されている。

仕様書２０は、検証する集積回路の動作について規定されたデータである。ソースコード２１は、仕様書２０に基づいてハードウェア記述言語で記述されたデータである。
要因分析表２２は、ソースコード２１の論理検証を行う際のパラメータとなる因子と、その因子の値である水準の２次元の表のデータである。本実施形態では、図３に示すように、要因分析表２２は、仕様書２０から抽出された因子Ｆ１〜Ｆｎと、水準Ｌ１〜Ｌｎから構成されている。

さらに、要因分析表２２は、水準Ｌ１〜Ｌｎが最大値、最小値、同値クラス、境界値などの定量情報でカテゴリＣ１〜カテゴリＣｎに分類されている。ここで、最大値とは、検証する集積回路が正常動作可能な最大の入力値をいう。また、最小値とは、検証する集積回路が正常動作可能な最小の入力値をいう。さらに、同値クラスとは、検証する集積回路から同様な出力結果が得られる入力値の集合をいう。さらにまた、境界値とは、上記の各同値クラスの境界付近の代表値をいう。

直交表２３は、任意の２因子について、その水準の全ての組合せが同数回ずつ現れるという性質をもつ割り付け表のデータである。検証作業者は、直交表２３に基づいて、因子と水準の全ての組合せから、特定の因子と水準の組合せに絞り込む。そして、検証作業者は、直交表２３に基づいて絞り込んだ特定の因子と水準の組合せについて検証することで、因子及び水準の全ての組合せについて検証を行った場合と同様な効果を得ることができる。

例えば、図４の表３０に示すように、仕様書２０から２水準（０，１）の因子Ａ，Ｂ，Ｃを抽出した場合、全ての因子及び水準の組合せは「Ａ１」〜「Ａ８」の組合せの８通りになる。従って、検証作業者は、「Ａ１」〜「Ａ８」の８通りの組合せから作成された８つの入力データについてソースコード２１の論理検証を行うことになる。しかし、図５に示すような「Ｌ４」と呼ばれる直交表３１を用いることで、因子及び水準の組合せは「Ｂ１」〜「Ｂ４」の組合せの４通りに絞り込むことができる。

この場合、直交表３１では、因子Ａ，Ｂ，Ｃのうち任意の２因子間の水準（０，１）の組合せを全て示している。従って、検証作業者は、「Ｂ１」〜「Ｂ４」の組み合わせから作成された４つの入力データについてソースコード２１の論理検証を行うだけで、因子及び水準の全ての組合せから作成された８つの入力データについてソースコード２１の論理検証を行う場合と同様な効果を得ることができる。

テストケースファイル２４は、図６に示すように、直交表２３に基づいて作成された入力データと、入力データに対する出力期待値を含んだテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊが記憶されている。

テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊは、カテゴリＣ１〜Ｃｎにそれぞれ分類されている。ＣＰＵ１２は、カテゴリＣ１、カテゴリＣ２、……、カテゴリＣｎの順番で、分類されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊをテストケースファイル２４から読み出すようになっている。

さらに、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊは、カテゴリＣ１〜Ｃｎ毎に、「１番」から「ｊ番」の検証実行順位Ｐが設定されている。ＣＰＵ１２は、各カテゴリＣ１〜Ｃｎにおいて、検証実行順位Ｐの「１番」から「ｊ番」の順番でテストケースファイル２４から対応するテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを読み出すようになっている。

つまり、ＣＰＵ１２は、カテゴリＣ１に分類されているテストケースＴａ１〜Ｔａｊを検証実行順位Ｐが「１番」のテストケースＴａ１、検証実行順位Ｐが「２番」のテストケースＴａ２、……、検証実行順位Ｐが「ｎ番」のテストケースＴａｊの順番で読み出す。次に、ＣＰＵ１２は、カテゴリＣ２に分類されているテストケースＴｂ１〜Ｔｂｊを検証実行順位Ｐが「１番」のテストケースＴｂ１、検証実行順位Ｐが「２番」のテストケースＴｂ２、……、検証実行順位Ｐが「ｎ番」のテストケースＴｂｊの順番で読み出す。

そして、カテゴリＣ３〜Ｃｎに分類されているテストケースＴｃ１〜Ｔｃｊ、……、テストケースＴｎ１〜Ｔｎｊについて、ＣＰＵ１２が、カテゴリＣ１，Ｃ２に続いて、テストケースＴｃ１、……、Ｔｃｊ、……、テストケースＴｎ１、……、Ｔｎｊの順番に読み出すようになっている。

カテゴリ重み付けテーブル２５は、テストケースファイル２４に記憶されているどのカテゴリＣ１〜ＣｎのテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行うかを判定するためのテーブルである。

カテゴリ重み付けテーブル２５は、図７に示すように、各カテゴリＣ１〜Ｃｎに対して、統計重み付け比率ＲＳ１〜ＲＳｎ、基準重み付け比率ＲＫ１〜ＲＫｎ、上限値Ｕ１〜Ｕｎ、及び、下限値ＬＯ１〜ＬＯｎが設定されている。なお、重み付け比率は、その値が高いほどソースコード２１の論理検証を行って「不良」と判定される可能性が高く、その値が低いほどソースコード２１の論理検証を行って「不良」と判定される可能性が低くなっている。

統計重み付け比率ＲＳ１〜ＲＳｎは、各カテゴリＣ１〜Ｃｎにおいて、ＣＰＵ１２がソースコード２１の論理検証を行って「不良」と判定されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊの数と、ＣＰＵ１２がソースコード２１の論理検証を行ったテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊの数との比率をいう。

つまり、統計重み付け比率ＲＳ１〜ＲＳｎは、ＣＰＵ１２が対応するカテゴリＣ１〜Ｃｎに分類されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行って「不良」と判定する可能性を示している。なお、分類されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行っていないカテゴリは、対応する統計重み付け比率ＲＳ１〜ＲＳｎを算出することができないため、統計重み付け比率ＲＳ１〜ＲＳｎを設定されていない。

また、基準重み付け比率ＲＫ１〜ＲＫｎは、ＣＰＵ１２が対応するカテゴリＣ１〜Ｃｎに分類されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行って「不良」と判定する比率を検証作業者が予め予測したものをいう。

因みに、基準重み付け比率ＲＫ１〜ＲＫｎは、基準重み付け比率ＲＫ１、基準重み付け比率ＲＫ２、・・・・・・、基準重み付け比率ＲＫｎの順でその比率が高くなっている。言い換えると、検証作業者は、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行うと、基準重み付け比率ＲＫ１に対応するカテゴリＣ１、基準重み付け比率ＲＫ２に対応するカテゴリＣ２、……、基準重み付け比率ＲＫｎに対応するカテゴリＣｎの順で、分類されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについて「不良」と判定される可能性が高いと予測している。

ＣＰＵ１２は、各カテゴリＣ１〜Ｃｎにおいて、統計重み付け比率ＲＳ１〜ＲＳｎ又は基準重み付け比率ＲＫ１〜ＲＫｎのいずれかをカテゴリ重み付け比率として選択する。
詳述すると、各カテゴリＣ１〜Ｃｎにおいて、統計重み付け比率ＲＳ１〜ＲＳｎが上限値Ｕ１〜Ｕｎ（＜基準重み付け比率ＲＳ１〜ＲＳｎ）より低い場合、ＣＰＵ１２は、統計重み付け比率ＲＳ１〜ＲＳｎをカテゴリ重み付け比率として選択する。また、各カテゴリＣ１〜Ｃｎにおいて、統計重み付け比率ＲＳ１〜ＲＳｎが上限値Ｕ１〜Ｕｎ（＜基準重み付け比率ＲＳ１〜ＲＳｎ）以上、且つ、下限値ＬＯ１〜ＬＯｎ（＞基準重み付け比率ＲＳ１〜ＲＳｎ）以下の場合、ＣＰＵ１２は、基準重み付け比率ＲＳ１〜ＲＳｎをカテゴリ重み付け比率として選択する。さらに、各カテゴリＣ１〜Ｃｎにおいて、統計重み付け比率ＲＳ１〜ＲＳｎが下限値ＬＯ１〜ＬＯｎ（＞基準重み付け比率ＲＳ１〜ＲＳｎ）より高い場合、ＣＰＵ１２は、統計重み付け比率ＲＳ１〜ＲＳｎをカテゴリ重み付け比率として選択する。

すなわち、ＣＰＵ１２は、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行った結果、予測した基準重み付け比率ＲＳ１〜ＲＳｎ付近（上限値Ｕ１〜Ｕｎから下限値ＬＯ１〜ＬＯｎ）に統計重み付け比率ＲＳ１〜ＲＳｎが入っていれば、基準重み付け比率ＲＳ１〜ＲＳｎをカテゴリ重み付け比率として選択する。一方、ＣＰＵ１２は、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行った結果、予測した基準重み付け比率ＲＳ１〜ＲＳｎ付近（上限値Ｕ１〜Ｕｎから下限値ＬＯ１〜ＬＯｎ）に統計重み付け比率ＲＳ１〜ＲＳｎが入っていないと、統計重み付け比率ＲＳ１〜ＲＳｎをカテゴリ重み付け比率としてそれぞれ選択する。

従って、ＣＰＵ１２は、テストケースファイル２４からソースコード２１の論理検証を行って「不良」と判定される可能性が高いカテゴリＣ１〜Ｃｎの順番で、分類されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを読み出すようになっている。

そして、ＣＰＵ１２は、入力装置１６による指示に応答して、記憶装置１４に格納されている。ＣＰＵ１２は、プログラムデータ、ファイルのデータをメモリ１３へ転送し、それを実行する。

ドライブ装置１７は、記録媒体１９を駆動し、その記憶内容にアクセスする。ＣＰＵ１２は、ドライブ装置１７を介して記録媒体１９からプログラムデータを読み出し、それを記憶装置１４に格納する。

記録媒体１９としては、磁気テープ（ＭＴ）、メモリカード、フレキシブルディスク、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、…）、光磁気ディスク（ＭＯ、ＭＤ、…）等、任意のコンピュータ読み取り可能な記録媒体を使用することができる。この記録媒体１９に、上述のプログラムデータを格納しておき、必要に応じて、メモリ１３にロードして使用することもできる。

尚、記録媒体１９には、通信媒体を介してアップロード又はダウンロードされたプログラムデータを記録した媒体、ディスク装置を含む。更に、コンピュータによって直接実行可能なプログラムを記録した記録媒体だけでなく、一旦他の記録媒体（ハードディスク等）にインストールすることによって実行可能となるようなプログラムを記録した記録媒体や、暗号化されたり、圧縮されたりしたプログラムを記録した記録媒体も含む。

次に、上記の検証装置１１を用いて、仕様書２０に基づいてＶｅｒｉｌｏｇ−ＨＤＬやＶＨＤＬなどのハードウェア記述言語で記述されたソースコード２１の論理検証を行う処理について図２に従って説明する。

まず、検証作業者は、入力装置１６を操作し、仕様書２０から図３に示す要因分析表２２を作成する（ステップＳ１）。すなわち、検証作業者は、仕様書２０から、ソースコード２１の論理検証を行いたい集積回路の動作において影響を及ぼすパラメータと、そのパラメータにどのような値があるかを抽出している。また、検証作業者は、抽出した水準Ｌ１〜Ｌｎを最大値、最小値、同値クラス、境界値などの定量情報でカテゴリＣ１〜Ｃｎに分類する。次に、検証作業者は、抽出した水準Ｌ１〜ＬｎがどのカテゴリＣ１〜Ｃｎに分類されるかを要因分析表２２に記述する。そして、検証作業者は、作成した要因分析表２２を記憶装置１４に格納する。

そして、検証作業者は、入力装置１６を操作し、ステップＳ１において作成して記憶装置１４に格納した要因分析表２２に基づいて直交表２３を作成する（ステップＳ２）。
つまり、要因分析表２２の因子Ｆ１〜Ｆｎ及び水準Ｌ１〜Ｌｎの全ての組合せについて入力データを作成すると莫大な数になってしまう。このため、作成した莫大な数の入力データについてソースコード２１の論理検証を行うと、ソースコード２１の論理検証の検証時間は増大してしまう。そこで、直交表２３を用いて因子Ｆ１〜Ｆｎ及び水準Ｌ１〜Ｌｎの組合せを絞り込み、ソースコード２１の論理検証を行う入力データの数を削減している。そして、検証作業者は、作成した直交表２３を記憶装置１４に格納する。

次に、検証作業者は、入力装置１６を操作し、ステップＳ２において生成した直交表２３に基づいて、テストケースを生成する（ステップＳ３）。すなわち、まず、検証作業者は、入力装置１６を操作し、記憶装置１４から直交表２３を読み出す。次に、検証作業者は、直交表２３の因子及び水準の組合せから入力データを作成するとともに、入力データに対する出力期待値を算出する。続いて、検証作業者は、入力データと、入力データに対する出力期待値を含んだテストケースを作成する。

さらに、検証作業者は、作成したテストケースを、対応する入力データに含まれる水準が分類されているカテゴリＣ１〜Ｃｎに分類する。具体的には、検証作業者は、カテゴリＣ１にテストケースＴａ１〜Ｔａｊを分類し、カテゴリＣ２にテストケースＴｂ１〜Ｔｂｊを分類し、・・・・・・、カテゴリＣｎにテストケースＴｎ１〜Ｔｎｊを分類する。

次に、検証作業者は、カテゴリＣ１〜Ｃｎ毎に分類されたテストケースＴａ１〜Ｔａｊ，Ｔｂ１〜Ｔｂｊ，……，Ｔｎ１〜Ｔｎｊを、図６に示すような順番でテストケースファイル２４に格納する。

そして、ＣＰＵ１２は、図７に示すカテゴリ重み付けテーブル２５に基づいて、ステップＳ３においてテストケースファイル２４に格納されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行うカテゴリ（検証実行カテゴリ）を設定する（ステップＳ４、カテゴリ選択工程）。

この時点では、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行っていないため、統計重み付け比率ＲＳ１〜ＲＳｎが設定されていない。これにより、ＣＰＵ１２は、各カテゴリＣ１〜Ｃｎにおいて、基準重み付け比率ＲＳ１〜ＲＳｎをカテゴリ重み付け比率としてそれぞれ選択する。

因みに、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行っている場合、ＣＰＵ１２は、検証実行カテゴリとなったカテゴリＣ１〜Ｃｎでは、基準重み付け比率ＲＳ１〜ＲＳｎ又は統計重み付け比率ＲＳ１〜ＲＳｎのいずれかをカテゴリ重み付け比率として選択している。

続いて、ＣＰＵ１２は、カテゴリ重み付けテーブル２５においてカテゴリ重み付け比率の最も高いカテゴリＣ１〜Ｃｎを検証実行カテゴリとして設定する。すなわち、ＣＰＵ１２は、分類されているテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行って「不良」と判定する可能性が最も高いカテゴリＣ１〜Ｃｎを検証実行カテゴリとして設定している。

次に、ＣＰＵ１２は、検証実行カテゴリとなったカテゴリＣ１〜Ｃｎに分類されたテストケースファイル２４のテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを検証実行順位Ｐの高い順番で読み出す。

この時点では、ＣＰＵ１２は、カテゴリ重み付けテーブル２５においてカテゴリ重み付け比率の最も高いカテゴリＣ１を検証実行カテゴリとして設定する。次に、ＣＰＵ１２は、検証実行カテゴリとなったカテゴリＣ１に分類されたテストケースファイル２４のテストケースＴａ１〜Ｔａｊを検証実行順位Ｐの高い順番で読み出す。

そして、ＣＰＵ１２は、読み出した検証実行カテゴリのカテゴリＣ１〜Ｃｎに分類されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊ（この場合、カテゴリＣ１に分類されたテストケースＴａ１〜Ｔａｊ）についてソースコード２１の論理検証を行う（ステップＳ５、ソフトウェアテスト工程）。

従って、ＣＰＵ１２は、ソースコード２１の論理検証を行って「不良」と判定される可能性が最も高いテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊから先にソースコード２１の論理検証を行うことで、少ない検証回数で「不良」と判定されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを検出している。

この結果、ＣＰＵ１２は、「良」と判定される可能性が高いテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてのソースコード２１の論理検証が後回しになり、そのテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについて仕様書２０の通りに正しく記述されていないソースコード２１の論理検証を行う必要がなくなる。これに伴い、ＣＰＵ１２は、仕様書２０の通りに正しく記述されていないソースコード２１の論理検証の検証回数を削減することができる。

そして、ＣＰＵ１２は、検証実行カテゴリのカテゴリＣ１〜Ｃｎに分類されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行うと、その検証結果をカテゴリ重み付けテーブル２５に反映する（ステップＳ６、テーブル変更工程）。

すなわち、ＣＰＵ１２は、検証実行カテゴリのカテゴリＣ１〜Ｃｎに分類されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行った結果を、その検証実行カテゴリのカテゴリＣ１〜Ｃｎに対する統計重み付け比率ＲＳ１〜ＲＳｎに反映する。

具体的には、ＣＰＵ１２は、検証実行カテゴリのカテゴリＣ１〜Ｃｎに分類されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行った結果、「不良」と判定されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊがないとき、検証実行カテゴリのカテゴリＣ１〜Ｃｎに対する統計重み付け比率ＲＳ１〜ＲＳｎを「０％」にする。

一方、ＣＰＵ１２は、検証実行カテゴリのカテゴリＣ１〜Ｃｎに分類されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行った結果、「不良」と判定されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊがあるとき、「不良」と判定されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊの数に応じて、検証実行カテゴリのカテゴリＣ１〜Ｃｎに対する統計重み付け比率ＲＳ１〜ＲＳｎを増減する。

詳しくは、上記のように、統計重み付け比率ＲＳ１〜ＲＳｎは、各カテゴリＣ１〜Ｃｎにおいて、ＣＰＵ１２がソースコード２１の論理検証を行って「不良」と判定されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊの数と、ＣＰＵ１２がソースコード２１の論理検証を行ったテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊの数との比率である。

このため、ＣＰＵ１２は、「不良」と判定されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊが多いほど、検証実行カテゴリのカテゴリＣ１〜Ｃｎに対する統計重み付け比率ＲＳ１〜ＲＳｎを高くする。反対に、ＣＰＵ１２は、「不良」と判定されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊが少ないほど、検証実行カテゴリのカテゴリＣ１〜Ｃｎに対する統計重み付け比率ＲＳ１〜ＲＳｎを低くする。

この時点では、ＣＰＵ１２は、検証実行カテゴリであるカテゴリＣ１に分類されるテストケースＴａ１〜Ｔａｊについてソースコード２１の論理検証を行った結果を、カテゴリＣ１に対する統計重み付け比率ＲＳ１に反映している。

そして、ＣＰＵ１２は、ステップＳ５において検証実行カテゴリのカテゴリＣ１〜Ｃｎに分類されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行った結果、「不良」と判定されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊがあるかどうかを検出する（ステップＳ７）。

そして、ＣＰＵ１２が「不良」と判定されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを検出する場合（ステップＳ７でＹＥＳ）、検証作業者は、「不良」と判定されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊから不良原因を判断する。次に、検証作業者は、その不良原因がソースコード２１に記述された論理が仕様書２０の通りに記述されていなかったこと（論理障害）によるものか否かを判断する（ステップＳ８）。なお、論理障害以外の不良原因としては、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊの入力データ及び出力期待値の内容に間違いがある場合、又は、仕様書２０の内容に間違いがある場合がある。

すなわち、検証作業者は、「不良」と判定されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊに基づいて、不良原因がソースコード２１の記述間違いによるものか、又は、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊの内容及び仕様書２０の内容の間違いによるものかを判断している。言い換えると、検証作業者は、「不良」と判定されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊに基づいて、仕様書２０、ソースコード２１、又は、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊのうち、どの記述又は内容を修正するかを判断している。

そして、不良原因が論理障害によるものと判断すると（ステップＳ８でＹＥＳ）、検証作業者は、入力装置１６を操作し、記憶装置１４からソースコード２１を読み出してソースコード２１の記述に間違いがある箇所を修正する（ステップＳ９）。

続いて、修正したソースコード２１を記憶装置１４に格納すると、ＣＰＵ１２は、ステップＳ４に戻り、再度、カテゴリ重み付けテーブル２５に基づいてカテゴリ重み付け比率が最も高い検証実行カテゴリとしてのカテゴリＣ１〜Ｃｎを設定する。

この時点では、ＣＰＵ１２は、カテゴリ重み付けテーブル２５のカテゴリＣ１に対する統計重み付け比率ＲＳ１に、カテゴリＣ１に分類されたテストケースＴａ１〜Ｔａｊについてソースコード２１の論理検証が行われた結果を反映している。ＣＰＵ１２は、カテゴリＣ１において、統計重み付け比率ＲＳ１と基準重み付け比率ＲＫ１を比較し、その比較結果に応じて統計重み付け比率ＲＳ１又は基準重み付け比率ＲＫ１のいずれかをカテゴリ重み付け比率として選択する。

ＣＰＵ１２は、統計重み付け比率ＲＳ１が基準重み付け比率ＲＫ１の上限値Ｕ１以上、又は、統計重み付け比率ＲＳ１が基準重み付け比率ＲＫ１の下限値ＬＯ１〜ＬＯｎ以下のとき、基準重み付け比率ＲＫ１をカテゴリ重み付け比率として選択する。この場合、ＣＰＵ１２は、カテゴリＣ１において基準重み付け比率ＲＫ１を選択したため、カテゴリＣ１〜Ｃｎのカテゴリ重み付け比率に変更ない。

つまり、ＣＰＵ１２は、カテゴリＣ１に分類されたテストケースＴａ１〜Ｔａｊについてソースコード２１の論理検証を行った結果、統計重み付け比率ＲＳ１が基準重み付け比率ＲＫ１の上限値Ｕ１から下限値ＬＯ１の範囲に入って検証作業者の予測通りになったため、基準重み付け比率ＲＫ１としてのカテゴリＣ１のカテゴリ重み付け比率を変更しない。この場合、ＣＰＵ１２は、検証実行カテゴリに変更がないため、カテゴリＣ１に分類されたテストケースＴａ１〜Ｔａｊについてソースコード２１の論理検証を再度行う（ステップＳ５）。

一方、統計重み付け比率ＲＳ１が基準重み付け比率ＲＫ１の上限値Ｕ１より低い、又は、統計重み付け比率ＲＳ１が基準重み付け比率ＲＫ１の下限値ＬＯ１より高い場合、ＣＰＵ１２は、統計重み付け比率ＲＳ１をカテゴリ重み付け比率として選択する。

すなわち、ＣＰＵ１２は、カテゴリＣ１に分類されたテストケースＴａ１〜Ｔａｊについてソースコード２１の論理検証を行った結果、統計重み付け比率ＲＳ１が予測した基準重み付け比率ＲＫ１の上限値Ｕ１から下限値ＬＯ１以内に入らなかったため、統計重み付け比率ＲＳ１をカテゴリ重み付け比率として選択する。

これにより、カテゴリＣ１のカテゴリ重み付け比率がカテゴリＣ２のカテゴリ重み付け比率より高い場合、カテゴリＣ１のカテゴリ重み付け比率が最も高いため、カテゴリＣ１を検証実行カテゴリとして再度設定する。この場合、ＣＰＵ１２は、検証実行カテゴリに変更がないため、カテゴリＣ１に分類されたテストケースＴａ１〜Ｔａｊについてソースコード２１の論理検証を再度行う（ステップＳ５）。

換言すると、ＣＰＵ１２は、検証実行カテゴリのカテゴリＣ１に分類されたテストケースＴａ１〜Ｔａｊについてソースコード２１の論理検証を行った結果、カテゴリＣ１のカテゴリ重み付け比率が高くなっても、カテゴリＣ１のカテゴリ重み付け比率が最も高いため、カテゴリＣ１としての検証実行カテゴリを維持している。

反対に、カテゴリＣ１のカテゴリ重み付け比率がカテゴリＣ２のカテゴリ重み付け比率より低い場合、カテゴリＣ２のカテゴリ重み付け比率が最も高くなるため、ＣＰＵ１２は、カテゴリＣ２を検証実行カテゴリとして設定する。この場合、ＣＰＵ１２は、検証実行カテゴリのカテゴリＣ２に分類されたテストケースＴｂ１〜Ｔｂｊについてソースコード２１の論理検証を行う（ステップＳ５）。

すなわち、検証実行カテゴリのカテゴリＣ１に分類されたテストケースＴａ１〜Ｔａｊについてソースコード２１の論理検証を行った結果、カテゴリＣ１のカテゴリ重み付け比率が２番目に高かったカテゴリＣ２のカテゴリ重み付け比率より低くなって、ＣＰＵ１２は、検証実行カテゴリをカテゴリＣ１からカテゴリＣ２に変更している。

「不良」と判定されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊに基づいて不良原因が論理障害によるものではないと判断すると（ステップＳ８でＮＯ）、検証作業者は、ステップＳ１に戻って、入力装置１６を操作し、不良原因を踏まえて仕様書２０又は要因分析表２２を再度作成する。

つまり、検証作業者は、仕様書２０又は要因分析表２２の内容に間違いがあったため、仕様書２０又は要因分析表２２を修正する。検証作業者は、仕様書２０及び要因分析表２２に基づいて、直交表２３及びテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを再度作成し、新たに作成したテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行うようになっている。

「不良」と判定されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを検出しない場合（ステップＳ７でＮＯ）、ＣＰＵ１２は、テストケースファイル２４に記憶されているテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊが全て「良」と判定されたかどうかを判断する（ステップＳ１０）。そして、ＣＰＵ１２は、「良」と判定されていないテストケースがある場合（ステップＳ１０でＹＥＳ）、再度、カテゴリ重み付けテーブル２５に基づいてカテゴリ重み付け比率が最も高い検証実行カテゴリのカテゴリＣ１〜Ｃｎを設定する（ステップＳ４）。

この時点で、ＣＰＵ１２は、カテゴリ重み付けテーブル２５のカテゴリＣ１に対する統計重み付け比率ＲＳ１に、カテゴリＣ１に分類されたテストケースＴａ１〜Ｔａｊについてソースコード２１の論理検証を行った結果を反映している。

この場合、カテゴリＣ１に分類されたテストケースＴａ１〜Ｔａｊについてソースコード２１の論理検証を行った結果、全てのテストケースＴａ１〜Ｔａｊについて「良」と判定されたため、ＣＰＵ１２は、カテゴリＣ１の統計重み付け比率ＲＳ１を「０％」にしている。これにより、ＣＰＵ１２は、カテゴリＣ１において、「０％」の統計重み付け比率ＲＳ１をカテゴリ重み付け比率として選択する。

従って、カテゴリＣ１のカテゴリ重み付け比率が、カテゴリＣ２のカテゴリ重み付け比率より低くなる。この結果、ＣＰＵ１２は、検証実行カテゴリをカテゴリＣ２に設定し（ステップＳ４）、カテゴリＣ２に分類されるテストケースＴｂ１〜Ｔｂｊについてソースコード２１の論理検証を行う（ステップＳ５）。

換言すると、ＣＰＵ１２は、カテゴリＣ１に分類されたテストケースＴａ１〜Ｔａｊについてソースコード２１の論理検証を行って問題がなかったため、２番目にカテゴリ重み付け比率が高かったカテゴリＣ２に分類されるテストケースＴｂ１〜Ｔｂｊについてソースコード２１の論理検証を行うようにしている。

すなわち、ＣＰＵ１２は、ステップＳ４→ステップＳ５→ステップＳ６→ステップＳ７→ステップＳ１０の順番で処理を繰り返し、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行っていく。その後、ＣＰＵ１２は、「不良」と判定されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを検出するまで（ステップＳ７でＹＥＳ）、最初の段階のカテゴリ重み付け比率が高いカテゴリＣ１〜Ｃｎの順番で、そのカテゴリＣ１〜Ｃｎに対応するテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行うようになっている。

この場合、ＣＰＵ１２は、それまでにソースコード２１の論理検証を行った検証結果を、ソースコード２１の論理検証を行ったテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊが分類されたカテゴリＣ１〜Ｃｎに対する統計重み付け比率ＲＳ１〜ＲＳｎに反映している（ステップＳ６）。

続いて、ＣＰＵ１２は、カテゴリ重み付けテーブル２５のカテゴリＣ１〜Ｃｎのカテゴリ重み付け比率が最も高いカテゴリＣ１〜Ｃｎを検証実行カテゴリとして再度設定する（ステップＳ４）。つまり、ＣＰＵ１２は、「不良」と判定されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊが分類されているカテゴリＣ１〜Ｃｎ、又は、そのカテゴリＣ１〜Ｃｎの次にカテゴリ重み付け比率が高かったカテゴリＣ１〜Ｃｎのいずれかを検証実行カテゴリとして設定する。

その後、ＣＰＵ１２は、ステップＳ４→ステップＳ５→ステップＳ６→ステップＳ７→ステップＳ１０の順番で処理を繰り返し、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行っていく。その後、ＣＰＵ１２は、「不良」と判定されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを検出するまで、最初の段階のカテゴリ重み付け比率が高いカテゴリＣ１〜Ｃｎの順番で、そのカテゴリＣ１〜Ｃｎに対応するテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行うようになっている。

そして、テストケースファイル２４に記憶されているテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊが全て「良」と判定されると（ステップＳ１０でＮＯ）、ＣＰＵ１２は、仕様書２０の通りにソースコード２１が正しく記述されていると判断してソースコード２１の論理検証を完了する。

図８に示す波形５０，５１は、一般的に「バグ曲線」と呼ばれ、ソースコード２１の論理検証期間において、検出する仕様書２０、ソースコード２１、及び、要因分析表２２の間違いを検出した累積検出件数を図示したものである。

ソースコード２１の論理検証等のソフトウェアの検証では、バグ（本実施形態では、仕様書２０、ソースコード２１、及び、要因分析表２２の間違い）は、検証の初期段階で多く検出され、その後、累積検出数が徐々に収束していく傾向がある。このようなバグ曲線では、ソフトウェアのテストを行ってバグの累積検出数がなだらかになる付近の目標累積検出数Ｄに到達すると、ソフトウェアの品質が安定していると判定することができる。

そこで、本実施形態では、ソースコード２１の論理検証を行ってテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについて全て「良」と判定されると、仕様書２０、ソースコード２１、及び、要因分析表２２の間違いを検出した累積検出数が、目標累積検出数Ｄに到達するようになっている。

従来、テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊの順番を変更せずにソースコード２１の論理検証を行うと、バグ曲線は図８に示す波形５０のようになっていた。
本実施形態では、ＣＰＵ１２が検証カテゴリとなったカテゴリＣ１〜Ｃｎに分類されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行う毎に、カテゴリ重み付けテーブル２５のカテゴリＣ１〜Ｃｎに対するカテゴリ重み付け比率に基づいて、カテゴリＣ１〜Ｃｎの中から検証カテゴリを設定している。

これにより、ＣＰＵ１２は、その時々で、最も「不良」と判定される可能性が高いテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行うことができるため、少ない検証回数で仕様書２０、ソースコード２１、及び、要因分析表２２の間違いを検証することができる。

従って、従来よりも少ない検証回数でソースコード２１の論理検証を完了することができるとともに、図８に示す波形５１のように、従来に比べて早く目標累積検出数Ｄに到達し、ソースコード２１の論理検証の検証時間を短縮することができる。

以上記述したように、本実施の形態によれば、以下の効果を奏する。
（１）テストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを分類したカテゴリＣ１〜Ｃｎに対して、統計重み付け比率ＲＳ１〜ＲＳｎ、基準重み付け比率ＲＫ１〜ＲＫｎ、上限値Ｕ１〜Ｕｎ、下限値ＬＯ１〜ＬＯｎが設定されたカテゴリ重み付けテーブル２５を設けた。ＣＰＵ１２は、各カテゴリＣ１〜Ｃｎにおいて、基準重み付け比率ＲＫ１〜ＲＫｎの上限値Ｕ１〜Ｕｎから下限値ＬＯ１〜ＬＯｎの範囲に統計重み付け比率ＲＳ１〜ＲＳｎが入っている否かに応じて、基準重み付け比率ＲＫ１〜ＲＫｎ又は統計重み付け比率ＲＳ１〜ＲＳｎのいずれかをカテゴリ重み付け比率として設定するようにした。次に、ＣＰＵ１２は、カテゴリ重み付け比率の最も高いカテゴリ重み付け比率のカテゴリＣ１〜Ｃｎを検証実行カテゴリとして設定した。続いて、ＣＰＵ１２は、検証実行カテゴリとなったカテゴリＣ１〜Ｃｎに分類されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行うようにした。

従って、ＣＰＵ１２は、不良と判定される可能性が高いテストケースＴａ１〜Tｎｊについてソースコード２１の論理検証を行うことができるため、少ない検証回数で不良と判定されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを検出することができる。これに伴い、ソースコード２１の論理検証の検証時間を短縮することができる。

（２）さらに、ＣＰＵ１２は、ソースコード２１の論理検証を行った結果を、カテゴリ重み付けテーブル２５の統計重み付け比率に反映するようにした。
従って、ＣＰＵ１２は、検証実行カテゴリとなったカテゴリＣ１〜Ｃｎに分類されたテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊについてソースコード２１の論理検証を行う毎に、その検証結果が反映されたカテゴリ重み付けテーブル２５に基づいて検証実行カテゴリを設定することができる。この結果、ＣＰＵ１２は、さらに少ない検証回数で不良と判定されるテストケースＴａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊを検出することができる。これに伴い、ソースコード２１の論理検証の検証時間をさらに短縮することができる。

尚、上記実施の形態は、以下の態様で実施してもよい。
・本実施形態では、ハードウェア記述言語で記述された集積回路のソースコードの論理検証に具体化していたが、ソフトウェアであればそのテスト方法に違いはないため、具体化するソフトウェアは特に制限されない。

・本実施形態では、検証作業者は、水準Ｌ１〜Ｌｎを最大値、最小値、同値クラス、境界値などの定量情報に基づいてカテゴリＣ１〜Ｃｎに分類した。これに限らず、因子Ｆ１〜Ｆｎを定性情報に基づいてカテゴリＣ１〜Ｃｎに分類してもよい。

・本実施形態では、ＣＰＵ１２は、検証実行カテゴリを、カテゴリ重み付けテーブル２５の統計重み付け比率ＲＳ１〜ＲＳｎが最も高いカテゴリＣ１〜Ｃｎに設定していた。これに限らず、検証カテゴリを、カテゴリ重み付けテーブル２５の統計重み付け比率ＲＳ１〜ＲＳｎが高い複数のカテゴリＣ１〜Ｃｎに設定してもよい。

１１コンピュータ
２０設計仕様（仕様書）
２１ソフトウェア（ソースコード）
２５重み付けテーブル（カテゴリ重み付けテーブル）
Ｃ１〜Ｃｎカテゴリ
ＬＯ１〜ＬＯｎ下限値
ＲＫ１〜ＲＫｎ基準重み付け比率
ＲＳ１〜ＲＳｎ統計重み付け比率
Ｔａ１〜Ｔａｊ，……，Ｔｎ１〜Ｔｎｊテストケース
Ｕ１〜Ｕｎ上限値

Claims

設計仕様に含まれる各機能について、ソフトウェアが入力データを前記設計仕様の通りに処理するか否かを判定するための前記入力データと、該入力データに対する出力期待値とを有するテストケースを複数作成し、複数の前記テストケースの中から１つの前記テストケースを選択し、前記ソフトウェアにより選択した前記テストケースの入力データを処理して出力された出力データが選択した前記テストケースの出力期待値と等しいか否かを判定するソフトウェアのテスト方法であって、
定量情報及び定性情報に基づいて前記テストケースを分類したカテゴリに対して、分類された前記テストケースが不良と判定される可能性を示す重み付け比率がそれぞれ設定された重み付けテーブルを有し、
前記重み付けテーブルの各カテゴリに対する前記重み付け比率に基づいて、前記ソフトウェアのテストを行う前記カテゴリを選択するカテゴリ選択工程と、
前記カテゴリ選択工程において選択された前記カテゴリに分類された前記テストケースについて前記ソフトウェアのテストを行うソフトウェアテスト工程と、
前記ソフトウェアテスト工程においてソフトウェアのテストを行った結果に基づいて、前記ソフトウェアのテストを行った前記カテゴリに対する前記重み付けテーブルの重み付け比率を算出し、その算出結果に基づいて前記重み付けテーブルを変更するテーブル変更工程と、
を有することを特徴とするソフトウェアのテスト方法。
請求項１に記載のソフトウェアのテスト方法において、
前記カテゴリ選択工程は、
前記重み付けテーブルの各カテゴリに対する前記重み付け比率のうち、最も高い前記重み付け比率のカテゴリを選択することを特徴とするソフトウェアのテスト方法。
請求項１又は２に記載のソフトウェアのテスト方法において、
前記重み付けテーブルは、
予め設定された基準重み付け比率と、その基準重み付け比率の上限値及び下限値と、前記ソフトウェアのテストを行った結果に基づいて算出される統計重み付け比率とを有し、
前記カテゴリ選択工程は、
前記統計重み付け比率が前記基準重み付け比率の上限値から下限値の範囲に入ると前記基準重み付け比率を前記重み付け比率として選択し、
前記統計重み付け比率が前記基準重み付け比率の上限値から下限値の範囲に入らないと前記統計重み付け比率を前記重み付け比率として選択することを特徴とするソフトウェアのテスト方法。
請求項１〜３のいずれか１つに記載のソフトウェアのテスト方法において、
前記ソフトウェアは、
プログラミング言語又はハードウェア記述言語で記述されたソースコードであることを特徴とするソフトウェアのテスト方法。
コンピュータが、入力データと、該入力データに対する出力期待値とを有する複数のテストケースの中から１つの前記テストケースを選択し、ソフトウェアにより選択した前記テストケースの入力データを処理して出力された出力データが選択した前記テストケースの出力期待値と等しいか否かを判定する処理が記述されたプログラムであって、
定量情報及び定性情報に基づいて前記テストケースを分類したカテゴリに対して、分類された前記テストケースが不良と判定される可能性を示す重み付け比率がそれぞれ設定された重み付けテーブルを有し、
前記重み付けテーブルの各カテゴリに対する前記重み付け比率に基づいて、前記ソフトウェアのテストを行う前記カテゴリを選択するカテゴリ選択工程と、
前記カテゴリ選択工程において選択された前記カテゴリに分類された前記テストケースについて前記ソフトウェアのテストを行うソフトウェアテスト工程と、
前記ソフトウェアテスト工程において前記ソフトウェアのテストを行った結果に基づいて、前記ソフトウェアのテストを行った前記カテゴリに対する前記重み付けテーブルの重み付け比率を算出し、その算出結果に基づいて前記重み付けテーブルを変更するテーブル変更工程と、
を有することを特徴とするプログラム。