知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023143220
(43)【公開日】2023-10-06
(54)【発明の名称】テストケース生成装置及びテストケース生成方法
(51)【国際特許分類】
G06F 11/36 20060101AFI20230928BHJP
【ＦＩ】
G06F11/36 184
【審査請求】未請求
【請求項の数】4
【出願形態】ＯＬ
(21)【出願番号】P 2022050481
(22)【出願日】2022-03-25
(71)【出願人】
【識別番号】000233295
【氏名又は名称】株式会社日立情報通信エンジニアリング
(74)【代理人】
【識別番号】110000442
【氏名又は名称】弁理士法人武和国際特許事務所
(72)【発明者】
【氏名】中島 孝次
(72)【発明者】
【氏名】三宅 光夫
(72)【発明者】
【氏名】吉田 達哉
【テーマコード（参考）】
5B042
【Ｆターム（参考）】
5B042HH08
5B042HH11
5B042HH17
5B042MA14
(57)【要約】
【課題】担当者の知見や経験によることなく、より適切なテストケースを抽出してプログラムのバグテストのテスト品質を向上する。
【解決手段】プログラムに対して実施するバグテストのテスト項目を生成するテストケース生成装置（１００）は、バグテストの対象となるプログラムのソースコードを含む設計データを取得する設計データ取得部（１１０）と、設計データに基づいてプログラムに含まれる各機能の分析観点を設定する分析観点設定部（１２０）と、各機能毎に各分析観点からみた判定値を算出する判定値算出部（１３０）と、判定値に基づいてバグテストに用いるテストパラメータの抽出網羅性を決定し、決定した抽出網羅性に基づいて前記テストパラメータの組み合わせを抽出するテストパラメータ抽出部（１４０）と、を備える。
【選択図】図２
【解決手段】プログラムに対して実施するバグテストのテスト項目を生成するテストケース生成装置（１００）は、バグテストの対象となるプログラムのソースコードを含む設計データを取得する設計データ取得部（１１０）と、設計データに基づいてプログラムに含まれる各機能の分析観点を設定する分析観点設定部（１２０）と、各機能毎に各分析観点からみた判定値を算出する判定値算出部（１３０）と、判定値に基づいてバグテストに用いるテストパラメータの抽出網羅性を決定し、決定した抽出網羅性に基づいて前記テストパラメータの組み合わせを抽出するテストパラメータ抽出部（１４０）と、を備える。
【選択図】図２
【特許請求の範囲】
【請求項1】
プログラムに対して実施するバグテストのテスト項目を生成するテストケース生成装置であって、
バグテストの対象となるプログラムのソースコードを含む設計データを取得する設計データ取得部と、
前記設計データに基づいてプログラムに含まれる各機能の分析観点を設定する分析観点設定部と、
前記機能毎に各分析観点からみた判定値を算出する判定値算出部と、
前記判定値に基づいてバグテストに用いるテストパラメータの抽出網羅性を決定し、決定した抽出網羅性に基づいて前記テストパラメータの組み合わせを抽出するテストパラメータ抽出部と、
を備えることを特徴とするテストケース生成装置。
バグテストの対象となるプログラムのソースコードを含む設計データを取得する設計データ取得部と、
前記設計データに基づいてプログラムに含まれる各機能の分析観点を設定する分析観点設定部と、
前記機能毎に各分析観点からみた判定値を算出する判定値算出部と、
前記判定値に基づいてバグテストに用いるテストパラメータの抽出網羅性を決定し、決定した抽出網羅性に基づいて前記テストパラメータの組み合わせを抽出するテストパラメータ抽出部と、
を備えることを特徴とするテストケース生成装置。
【請求項2】
請求項１に記載のテストケース生成装置において
前記判定値算出部は、
一つの機能に対して複数の分析観点からみた複数の前記分析観点毎の判定値を求め、
前記複数の分析観点毎に重みづけを行い、各分析観点から見た判定値に当該分析観点に対して行われた重みづけを乗算し、重みづけされた前記各分析観点から見た判定値を合計して前記一つの機能の判定値合計を求め、当該判定値合計に応じて前記テストパラメータの抽出網羅性を決定する、
ことを特徴とするテストケース生成装置。
前記判定値算出部は、
一つの機能に対して複数の分析観点からみた複数の前記分析観点毎の判定値を求め、
前記複数の分析観点毎に重みづけを行い、各分析観点から見た判定値に当該分析観点に対して行われた重みづけを乗算し、重みづけされた前記各分析観点から見た判定値を合計して前記一つの機能の判定値合計を求め、当該判定値合計に応じて前記テストパラメータの抽出網羅性を決定する、
ことを特徴とするテストケース生成装置。
【請求項3】
請求項１に記載のテストケース生成装置において
前記分析観点設定部は、前記機能に対応付けられた前記ソースコードのサイクロマティック複雑度、最近行ったバグ修正回数、工程別バグの密度の高さ、過去プロジェクトのバグの密度の高さ、及びレビュー議事録によるバグ修正回数の少なくとも一つ以上を前記分析観点として用いる、
ことを特徴とするテストケース生成装置。
前記分析観点設定部は、前記機能に対応付けられた前記ソースコードのサイクロマティック複雑度、最近行ったバグ修正回数、工程別バグの密度の高さ、過去プロジェクトのバグの密度の高さ、及びレビュー議事録によるバグ修正回数の少なくとも一つ以上を前記分析観点として用いる、
ことを特徴とするテストケース生成装置。
【請求項4】
プログラムに対して実施するバグテストのテスト項目を生成するテストケース生成装置で実行されるテストケース生成方法であって、
バグテストの対象となるプログラムのソースコードを含む設計データを取得するステップと、
前記設計データに基づいてプログラムに含まれる各機能の分析観点を設定するステップと、
前記各機能毎に各分析観点からみた判定値を算出するステップと、
前記判定値に基づいてバグテストに用いるテストパラメータの抽出網羅性を決定し、決定した抽出網羅性に基づいて前記テストパラメータの組み合わせを抽出するステップと、
を含むことを特徴とするテストケース生成方法。
バグテストの対象となるプログラムのソースコードを含む設計データを取得するステップと、
前記設計データに基づいてプログラムに含まれる各機能の分析観点を設定するステップと、
前記各機能毎に各分析観点からみた判定値を算出するステップと、
前記判定値に基づいてバグテストに用いるテストパラメータの抽出網羅性を決定し、決定した抽出網羅性に基づいて前記テストパラメータの組み合わせを抽出するステップと、
を含むことを特徴とするテストケース生成方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、テストケース生成装置及びテストケース生成方法に係り、特にプログラムのバグ修正テスト項目の抽出に関する。
【背景技術】
【0002】
プログラムが正常に動作するかを検査するためのテストケースを生成するための技術として、特許文献１には特定条件を入力としてテストケースを出力するテストケースを生成する技術が開示されている。
【0003】
また特許文献２には、テストの重要度の重みづけを行うことでテストケースを抽出する技術が開示されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２０２１－１６３１１１号公報
【特許文献2】特開昭６３－７８２３２１号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
特許文献１では、特定条件を入力としてテストケースを出力することによりできるだけ少ないテストケースで網羅性を確保している。また特許文献２では、テスト結果の入力を基にしたテストパラメータの重要度判定とテストの観点作成及びテストケースを作成している。これらの方法では、担当者の知見や経験でテストパラメータの選出やテストケース抽出アルゴリズムの決定を行うため、テストパラメータの選出不足、テストケース抽出アルゴリズムの選択誤りにより最適なテストケースの組み合わせ抽出ができないという課題ある。
【0006】
本発明は上記課題を解決するためになされたものであり、担当者の知見や経験によることなく、より適切なテストケースを抽出してプログラムのバグテストのテスト品質を向上することを目的とする。
【課題を解決するための手段】
【0007】
上記課題を解決するため、本発明は特許請求の範囲に記載の構成を備える。その一例をあげるならば、プログラムに対して実施するバグテストのテスト項目を生成するテストケース生成装置であって、バグテストの対象となるプログラムのソースコードを含む設計データを取得する設計データ取得部と、前記設計データに基づいてプログラムに含まれる各機能の分析観点を設定する分析観点設定部と、前記各機能毎に各分析観点からみた判定値を算出する判定値算出部と、前記判定値に基づいてバグテストに用いるテストパラメータの抽出網羅性を決定し、決定した抽出網羅性に基づいて前記テストパラメータの組み合わせを抽出するテストパラメータ抽出部と、を備えることを特徴とする。
【発明の効果】
【0008】
本発明によれば、担当者の知見や経験によることなく、より適切なテストケースを抽出してプログラムのバグテストのテスト品質を向上することができる。なお、上述した以外の目的、構成、効果については以下の実施形態において明らかにされる。
【図面の簡単な説明】
【0009】
【図1】テストケース生成装置のハードウェア構成図。
【図2】テストケース生成装置の機能ブロック図。
【図3】初回のバグテストの動作フローを示す図。
【図4】初回のバグテストで参照又は出力するデータを示す図であって、（ａ）は重点テスト項目とテスト抽出条件、（ｂ）は抽出組み合わせテストパラメータである。
【図5】初回のテスト又は追加テスト実行後におこなわれる追加テストの動作フローを示す図。
【図6】テスト実行後の追加テストで参照又は出力するデータを示す図であって、（ａ）は抽出テストパラメータ＋テスト実行後の摘出バグテーブル、(ｂ)追加重点テスト項目とテスト抽出条件テーブル、（ｃ）追加抽出組み合わせテストパラメータテーブルである。
【図7】テストケース生成装置の処理ブロックを示す説明図。
【図8】サイクロマティック複雑度に応じた判定値の算出フローを示す図。
【図9】サイクロマティック複雑度に応じた判定値の算出に関するテーブルを示す図であり、（ａ）はサイクロマティック複雑度の点数変換テーブル、（ｂ）はサイクロマティック複雑度の重みづけテーブル、（ｃ）はサイクロマティック複雑度の機能毎の判定値算出結果テーブルである。
【図10】ソースコード修正チケット例に関する図であり、（ａ）はソースコード修正チケット例を示し、（ｂ）は最近行ったバグ修正例を示す。
【図11】最近行ったバクの修正回数に応じた判定値の算出フローを示す図。
【図12】最近行ったバクの修正回数に応じた判定値の算出に関するテーブルを示す図であり、（ａ）はバグ修正回数の点数変換テーブル、（ｂ）はバグ修正回数の重みづけテーブル、（ｃ）は最近行ったバグ修正回数の機能毎の判定値算出結果テーブルである。
【図13】工程別バグの密度の高さに応じた判定値の算出フローを示す図。
【図14】工程別バグの密度の高さに応じた判定値の算出に関するテーブルを示す図であり、（ａ）は工程別バグ密度の高さ点数変換テーブル、（ｂ）は工程別バグ密度の高さ重みづけテーブル、（ｃ）は工程別バグ密度の高さの機能毎の判定値算出結果テーブルである。
【図15】過去プロジェクトのバグ密度の高さに応じた判定値の算出フローを示す図。
【図16】過去プロジェクトのバグ密度の高さに応じた判定値の算出に関するテーブルを示す図であり、（ａ）は過去プロジェクトのバグ密度の高さ点数変換テーブル、（ｂ）は過去プロジェクトのバグ密度の高さ重みづけテーブル、（ｃ）は過去プロジェクトのバグ密度の機能毎の判定値算出結果テーブルである。
【図17】レビュー議事録による仕様書バグ密度の高さに応じた判定値の算出フローを示す図。
【図18】レビュー議事録例を示す図。
【図19】レビュー議事録による仕様書バグ密度の高さに応じた判定値の算出に関するテーブルを示す図であり、（ａ）はレビュー議事録によるバグ密度の高さ点数変換テーブル、（ｂ）はレビュー議事録によるバグ密度の高さ重みづけテーブル、（ｃ）はレビュー議事録によるバグ密度の機能毎の判定値算出結果テーブルである。
【図20】分析観点毎の判定値からテストパラメータ抽出するフローを示す図。
【図21】機能組み合わせテスト項目パラメータ方式判定に関連するテーブルであり、（ａ）は機能毎の分析データによる重みづけテーブルであり、（ｂ）は機能毎の判定値合計とテストパラメータ抽出方式テーブルである。
【図22】機能毎の判定値計算とテストパラメータ抽出方式の決定テーブル。
【図23】テスト実行後のバグ摘出からテストパラメータを追加抽出するフローを示す図。
【図24】テスト実行後のバグ摘出からテストパラメータを追加抽出するフローに関するテーブルであって、（ａ）は再テスト結果の重み変換テーブル、（ｂ）は再テスト結果のバグ密度重みづけテーブル、（ｃ）は機能毎の差分判定値とパラメータ抽出方式変換テーブル、（ｄ）はテスト実行後のバグの重みと追加項目のパラメータ抽出方式テーブルである。
【発明を実施するための形態】
【0010】
以下、図面を参照しながら本発明の実施形態を説明する。全図と通じて同一の構成には同一の符号を付し、重複説明を省略する。
【0011】
＜テストケース生成装置の全体構成＞
本実施形態に係るテストケース生成装置は、プログラムのバグを検出するためのテストパラメータを生成するための装置である。ユーザは、設計データをテストケース生成装置に入力すると、テストケース生成装置が設計データに基づいてバグ検出のためのテストを生成するためのテストパラメータを出力する。ユーザは、テストパラメータに基づいてテストケースを生成し、そのテストを実行してバグを抽出し、バグを修正する。この処理をバグが抽出されなくなるまで繰り返す。
本実施形態に係るテストケース生成装置は、プログラムのバグを検出するためのテストパラメータを生成するための装置である。ユーザは、設計データをテストケース生成装置に入力すると、テストケース生成装置が設計データに基づいてバグ検出のためのテストを生成するためのテストパラメータを出力する。ユーザは、テストパラメータに基づいてテストケースを生成し、そのテストを実行してバグを抽出し、バグを修正する。この処理をバグが抽出されなくなるまで繰り返す。
【0012】
図１は、テストケース生成装置のハードウェア構成図である。
【0013】
テストケース生成装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０２、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０３、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１０４、入力Ｉ／Ｆ１０５、及び出力Ｉ／Ｆ１０６を含み、これらがバス１０７を介して互いに接続されたコンピュータを用いて構成される。入力Ｉ／Ｆ１０５にはキーボードやマウスなどの入力装置１０８が接続される。出力Ｉ／Ｆ１０６にはディスプレイやプリンタ、サーバなどの出力装置１０９が出力される。なお、テストケース生成装置１００のハードウェア構成は上記に限定されず、制御回路と記憶装置との組み合わせにより構成されてもよい。
【0014】
図２は、テストケース生成装置の機能ブロック図である。
【0015】
テストケース生成装置１００は、設計データ取得部１１０、分析観点設定部１２０、判定値算出部１３０、及びテストパラメータ抽出部１４０を含む。各部は、テストケース生成装置１００の機能を実現するプログラムをＣＰＵ１０１がＲＡＭ１０２にロードして実行することにより実現する。各部の処理内容については後述する。
【0016】
またテストケース生成装置１００は、仕様書記憶部１７１、仕様書レビュー議事録記憶部１７２、ソースコード記憶部１７３、ソースコード修正チケット記憶部１７４、各種テーブル記憶部１８１、判定値記憶部１８２、テストパラメータ記憶部１８３を含む。これら各記憶部は、ＲＡＭ１０２又はＨＤＤ１０４の記憶領域に形成される。
【0017】
＜バグテストの全体概要＞
プログラムのバグテストには、一般的に初回のバグテストと、２回目以降の追加テスト項目を含んだ追加バグテストとを含む。
プログラムのバグテストには、一般的に初回のバグテストと、２回目以降の追加テスト項目を含んだ追加バグテストとを含む。
【0018】
＜＜初回の動作フロー＞＞
図３は、初回のバグテストの動作フローを示す図である。図４は、初回のバグテストで参照又は出力するデータを示す図であって、（ａ）は重点テスト項目とテスト抽出条件、（ｂ）は抽出組み合わせテストパラメータである。以下、初回のバグテストの大まかな手順について図３のステップ順に沿って初回の動作を説明する。
図３は、初回のバグテストの動作フローを示す図である。図４は、初回のバグテストで参照又は出力するデータを示す図であって、（ａ）は重点テスト項目とテスト抽出条件、（ｂ）は抽出組み合わせテストパラメータである。以下、初回のバグテストの大まかな手順について図３のステップ順に沿って初回の動作を説明する。
【0019】
（１）設計データ入力では、「設計書」、「設計書レビュー議事録」、「ソースコード」、「ソースコード修正チケット」、及び「ソースコードコミットログ」を準備し、ユーザがテストケース生成装置１００に設計データを入力する（Ｓ１）。なお上記「ソースコードコミットログ」とはソースコードとソースコード修正チケットを結びつけるために必要なデータである。
【0020】
設計データ取得部１１０は、入力された各設計データを仕様書記憶部１７１、仕様書レビュー議事録記憶部１７２、ソースコード記憶部１７３、ソースコード修正チケット記憶部１７４に記憶する。
【0021】
（２）では、分析観点設定部１２０は設計データの分析観点毎（ソースコードの複雑さ、最近行ったバグの修正回数、工程別バグ密度の高さ、過去プロジェクトのバグ密度の高さ、レビュー議事録による仕様書バグ密度の高さ等）（ここまでは初回テスト及び追加テストで共有）、及び追加テストではテスト実施後のバグ抽出の各分析観点を設定する（Ｓ２）。
【0022】
判定値算出部１３０は、バグ検出の対象となるプログラムの各機能について設定された分析観点毎に重みづけを行い、機能毎の判定値を算出する。
【0023】
（３）では、テストパラメータ抽出部１４０は、機能毎の判定値に対応した「重点テスト項目とテスト項目抽出条件」をテストパラメータ抽出ツールに入力して実行し、「抽出組み合わせテストパラメータ」を出力する（Ｓ３）。
【0024】
（４）では、ユーザは「抽出組み合わせテストパラメータ」を基に機能１、機能２、機能３の組み合わせテスト項目作成・実行する（Ｓ４）。
【0025】
（３）の「抽出組み合わせテストパラメータ」で出力される組み合わせテスト項目は項目の抽出のみでテストをすぐに実行できる形になっていないので、（４）にてテスト項目作成・実行を行う。このテストにより、バグが残っていれば抽出されるのでユーザはバグ修正を行う。そしてバグ修正後のプログラムに対して、更にバグの抽出を行うための追加テストを行う。
【0026】
＜＜テスト実行後の追加テスト項目作成・実行＞＞
図５は、初回のテスト又は追加テスト実行後におこなわれる追加テストの動作フローを示す図である。図６は、テスト実行後の追加テストで参照又は出力するデータを示す図であって、（ａ）は抽出テストパラメータ＋テスト実行後の摘出バグテーブル、(ｂ)追加重点テスト項目とテスト抽出条件テーブル、（ｃ）追加抽出組み合わせテストパラメータテーブルである。以下、図５のステップ順に沿って初回の動作を説明する。
図５は、初回のテスト又は追加テスト実行後におこなわれる追加テストの動作フローを示す図である。図６は、テスト実行後の追加テストで参照又は出力するデータを示す図であって、（ａ）は抽出テストパラメータ＋テスト実行後の摘出バグテーブル、(ｂ)追加重点テスト項目とテスト抽出条件テーブル、（ｃ）追加抽出組み合わせテストパラメータテーブルである。以下、図５のステップ順に沿って初回の動作を説明する。
【0027】
（１１）にてユーザは、抽出テストパラメータに基づき実施したテスト項目にてバグを摘出した項目にチェックを入れ、設計データ取得部１１０が設計データを更新する（Ｓ１１）。
【0028】
（１２）にて分析観点設定部１２０及び判定値算出部１３０は、ステップＳ２で算出した判定値にテスト実施後のバグ摘出を加え再分析し、機能毎に重みづけを行い機能毎の判定値を算出する。テストパラメータ抽出部１４０は、その結果から追加重点テスト項目とテスト項目抽出条件を出力する（Ｓ１２）。これにより、機能毎にプロジェクト内の開発結果を反映し、各機能の開発経緯を分析し、開発経緯に合わせて重みを変化させることで、テスト優先度の高い機能を重点項目に選定してバグテストの抽出アルゴリズムを決定することができる。
【0029】
（１３）にてテストパラメータ抽出部１４０は、追加重点テスト項目とテスト項目抽出条件をテストパラメータ抽出ツールに入力して実行し、追加抽出組み合わせテストパラメータが出力される（Ｓ１３）。
【0030】
（１４）にてユーザは「抽出組み合わせテストパラメータ」を基に機能１、機能２、機能３の組み合わせテスト項目を作成する（Ｓ１４）。バグが摘出されるとテスト実行結果を反映させて、テスト項目バグ摘出が無くなるまでステップ（１２）～（１４）を繰り返し実行する（Ｓ１５）。上記条件で抽出したテストケースのテスト実行結果のバグ情報を反映し、上記分析観点の重みを変化させることで、テスト後バグ流出の多い機能を重点パラメータとした抽出アルゴリズムを再設定でき、テストケースを自動的に追加することができる。これを繰り返し、不足した抽出テストケースを充足することで、プロジェクトの品質状況に合わせてテストケースの質を向上させるテストケースが抽出できる。
【0031】
＜テストケース生成装置の処理概要＞
図７は、テストケース生成装置の処理ブロックを示す説明図である。
図７は、テストケース生成装置の処理ブロックを示す説明図である。
【0032】
（１）設計データ入力
ユーザは、テストの対象となるプログラムの設計データをテストケース生成装置１００に入力する。設定データには、設計書、設計書レビュー議事録、ソースコード、ソースコード修正チケット、ソースコードコミットログが含まれる。設計データ入力作業は、ユーザがテストケース生成装置１００に対して行う人手作業である。設計データ取得部１１０は、入力された設計データをＨＤＤ１０４の各記憶領域に記憶する。
ユーザは、テストの対象となるプログラムの設計データをテストケース生成装置１００に入力する。設定データには、設計書、設計書レビュー議事録、ソースコード、ソースコード修正チケット、ソースコードコミットログが含まれる。設計データ入力作業は、ユーザがテストケース生成装置１００に対して行う人手作業である。設計データ取得部１１０は、入力された設計データをＨＤＤ１０４の各記憶領域に記憶する。
【0033】
（２１）「設計データ分析観点」
分析観点設定部１２０は、「ソースコード構造の複雑さ」、「最近行ったバグの修正回数」、「工程別バグ密度の高さ」、「過去プロジェクトのバグ密度の高さ」、及び「レビュー議事録による仕様書バグ密度の高さ」を分析観点として設定する。追加テストでは分析観点として更に「テスト実施後のバグ抽出」を設定する。
分析観点設定部１２０は、「ソースコード構造の複雑さ」、「最近行ったバグの修正回数」、「工程別バグ密度の高さ」、「過去プロジェクトのバグ密度の高さ」、及び「レビュー議事録による仕様書バグ密度の高さ」を分析観点として設定する。追加テストでは分析観点として更に「テスト実施後のバグ抽出」を設定する。
【0034】
（２２）分析観点毎の判定値算出
判定値算出部１３０は、「サイクロマティック複雑度（ＣＣＮ）」、「バグ修正（回）」、「工程別バグ密度（件／ｋｓｔｅｐ）」、「過去プロジェクトのバグ密度（件／ｋｓｔｅｐ）」、及び「仕様書バグ密度（件／ｋｓｔｅｐ）」、追加テストでは更に「テスト実施後のバグ抽出（件／ｋｓｔｅｐ）」の各分析観点で機能ごとに数値化し、分析観点毎の重みを加味して分析観点毎に判定値を算出する。分析観点毎の判定値算出の処理については後述する。
判定値算出部１３０は、「サイクロマティック複雑度（ＣＣＮ）」、「バグ修正（回）」、「工程別バグ密度（件／ｋｓｔｅｐ）」、「過去プロジェクトのバグ密度（件／ｋｓｔｅｐ）」、及び「仕様書バグ密度（件／ｋｓｔｅｐ）」、追加テストでは更に「テスト実施後のバグ抽出（件／ｋｓｔｅｐ）」の各分析観点で機能ごとに数値化し、分析観点毎の重みを加味して分析観点毎に判定値を算出する。分析観点毎の判定値算出の処理については後述する。
【0035】
（２３）機能毎に判定値合計を集計
判定値算出部１３０は、各機能について分析観点毎に算出された判定値を集計し、機能毎の判定値の合計値を算出する。
判定値算出部１３０は、各機能について分析観点毎に算出された判定値を集計し、機能毎の判定値の合計値を算出する。
【0036】
（２４）機能毎の分析データによる重みづけ
判定値算出部１３０は、機能毎の分析データを加味した重みを判定する。
判定値算出部１３０は、機能毎の分析データを加味した重みを判定する。
【0037】
（２５）機能毎の判定値算出
判定値算出部１３０は、機能毎に判定値の合計値に重みを乗算して各機能の判定値を算出する。
判定値算出部１３０は、機能毎に判定値の合計値に重みを乗算して各機能の判定値を算出する。
【0038】
（２６）機能組み合わせテスト項目パラメータ方式判定
テストパラメータ抽出部１４０は、各機能の判定値から機能毎のテスト項目の重要度を決定する。更に判定値に応じて網羅や間引きを決定する「テストパラメータ抽出方式」を決定する。つまり、テストパラメータ抽出方式を決定するとは、テストパラメータの抽出網羅性を決めることと同義である。
テストパラメータ抽出部１４０は、各機能の判定値から機能毎のテスト項目の重要度を決定する。更に判定値に応じて網羅や間引きを決定する「テストパラメータ抽出方式」を決定する。つまり、テストパラメータ抽出方式を決定するとは、テストパラメータの抽出網羅性を決めることと同義である。
【0039】
（３）パラメータ抽出ツール実行
テストパラメータ抽出部１４０は、抽出したテストパラメータをパラメータ抽出ツールに入力して実行し、最適な組み合わせテストパラメータが抽出される。パラメータ抽出ツールは既存ツールである。
テストパラメータ抽出部１４０は、抽出したテストパラメータをパラメータ抽出ツールに入力して実行し、最適な組み合わせテストパラメータが抽出される。パラメータ抽出ツールは既存ツールである。
【0040】
上記「設計データ分析観点の設定」から「機能組み合わせテスト項目パラメータ方式判定」までテストケース生成装置１００の内部処理により実行される。そして、最適な組み合わせテストパラメータが出力される。
【0041】
（４）テスト項目作成、テスト実施
ユーザは、最適な組み合わせテストパラメータに基づきテスト項目を作成する。そしてバグ摘出の対象となるプログラムに対して初期のバグテスト又は追加のバグテストを実施する。
ユーザは、最適な組み合わせテストパラメータに基づきテスト項目を作成する。そしてバグ摘出の対象となるプログラムに対して初期のバグテスト又は追加のバグテストを実施する。
【0042】
（４１）テスト結果バグ摘出
バグテストの結果に基づきバグを摘出し、修正する。修正履歴は記録する。
バグテストの結果に基づきバグを摘出し、修正する。修正履歴は記録する。
【0043】
＜＜（２２） 分析観点毎の判定値算出の具体例＞＞
分析観点１：サイクロマティック複雑度
図８は、サイクロマティック複雑度に応じた判定値の算出フローを示す図である。図９は、サイクロマティック複雑度に応じた判定値の算出に関するテーブルを示す図であり、（ａ）はサイクロマティック複雑度の点数変換テーブル、（ｂ）はサイクロマティック複雑度の重みづけテーブル、（ｃ）はサイクロマティック複雑度の機能毎の判定値算出結果テーブルである。サイクロマティック複雑度の点数変換テーブル及びサイクロマティック複雑度の重みづけテーブルはテストケース生成装置１００のＨＤＤ１０４に予め格納しておく。図１０は、ソースコード修正チケット例に関する図であり、（ａ）はソースコード修正チケット例を示し、（ｂ）は最近行ったバグ修正例を示す。
分析観点１：サイクロマティック複雑度
図８は、サイクロマティック複雑度に応じた判定値の算出フローを示す図である。図９は、サイクロマティック複雑度に応じた判定値の算出に関するテーブルを示す図であり、（ａ）はサイクロマティック複雑度の点数変換テーブル、（ｂ）はサイクロマティック複雑度の重みづけテーブル、（ｃ）はサイクロマティック複雑度の機能毎の判定値算出結果テーブルである。サイクロマティック複雑度の点数変換テーブル及びサイクロマティック複雑度の重みづけテーブルはテストケース生成装置１００のＨＤＤ１０４に予め格納しておく。図１０は、ソースコード修正チケット例に関する図であり、（ａ）はソースコード修正チケット例を示し、（ｂ）は最近行ったバグ修正例を示す。
【0044】
図９（ａ）のサイクロマティック複雑度の点数変換テーブルに示すように、サイクロマティック複雑度が相対的に高いほどプログラムが複雑であることからバグが生じやすいと考えられるので、サイクロマティック複雑度が高いほど相対的に高い点数を付与する。
【0045】
また図９（ｂ）のサイクロマティック複雑度の重みづけテーブルに示すように、サイクロマティック複雑度の重みづけは、サイクロマティック複雑度を算出した機能の開発内容に応じて重みづけを行う。各機能の開発内容は、ソースコード修正チケットから情報を取得する。
【0046】
サイクロマティック複雑度の重みづけテーブルでは、より多くのバグを含む可能性が高い開発ステージとして「新規開発」の重みづけが高く、バグがすでに修正されている可能性が高い「流用母体又は無改造」が最も重みづけが低く規定されている。
【0047】
「ソースコード修正チケット」とは、プロジェクト管理のタスクやバグを管理するチケットシステムにおいて、ソースコードの修正指示を行う際に発行される指示データやバグの修正履歴を記録したデータである。
【0048】
図１０の（ａ）に示すように、ソースコード修正チケットには修正順序、バグ内容等が書き込まれているのでソースコード修正チケットを参照することでソースコードの修正履歴、修正内容がわかり、そのソースコードに対応する機能がサイクロマティック複雑度の重みづけテーブルに規定した５つの開発ステージのどれに対応するかを判定することができる。
【0049】
図１０の（ｂ）に示すように、最近行ったバグ修正データ例を示している。例えば機能１ではテスト４週目でもバグ修正回数が高い、即ちテスト終盤でバグが多発しておりバグが収束していない可能性がある。よって、機能１は、他の機能と比べて相対的により網羅的なパラメータの組み合わせを用いたテストを行う必要がある。
【0050】
図８に示すように、サイクロマティック複雑度を分析観点とする機能の判定値の算出処理では、まず、分析観点設定部１２０は、設計データ、より詳しくは仕様書及びソースコードを取得し（Ｓ２２１１）、取得した設計データから機能毎にソースコードを結びつける（Ｓ２２１２）。
【0051】
判定値算出部１３０はソースコード毎に複雑度計測ツールを実行，複雑度(CCN)を出力し、機能毎に集計する（Ｓ２２１３）。
【0052】
判定値算出部１３０は、集計した複雑度を「サイクロマティック複雑度の重み変換テーブル」に基づき点数化し、「サイクロマティック複雑度の重みづけテーブル」に基づき重みづけする。（Ｓ２２１４）。
【0053】
判定値算出部１３０は、算出した点数に重みを乗算し、機能毎の判定値を算出、出力する（Ｓ２２１５）。
【0054】
判定値算出部１３０は、機能の数だけＳ２２１３～Ｓ２２１６を繰り返し、「サイクロマティック複雑度の機能毎の判定値算出」表を作成する。判定値算出部１３０は、全ての機能についてサイクロマティック複雑度からみた判定値の算出が終わっていなければ（Ｓ２２１６：はい）、他の機能についてステップＳ２２１３からの処理を繰り返す。一方、機能の数だけ処理を繰り返して全ての機能についてサイクロマティック複雑度からみた判定値の算出が終了すると（Ｓ２２１６：いいえ）処理を終了する。
【0055】
分析観点２：最近行ったバグの修正回数
図１１は、最近行ったバクの修正回数に応じた判定値の算出フローを示す図である。図１２は、最近行ったバクの修正回数に応じた判定値の算出に関するテーブルを示す図であり、（ａ）はバグ修正回数の点数変換テーブル、（ｂ）はバグ修正回数の重みづけテーブル、（ｃ）は最近行ったバグ修正回数の機能毎の判定値算出結果テーブルである。
図１１は、最近行ったバクの修正回数に応じた判定値の算出フローを示す図である。図１２は、最近行ったバクの修正回数に応じた判定値の算出に関するテーブルを示す図であり、（ａ）はバグ修正回数の点数変換テーブル、（ｂ）はバグ修正回数の重みづけテーブル、（ｃ）は最近行ったバグ修正回数の機能毎の判定値算出結果テーブルである。
【0056】
ここでいう「最近行った」とは、ある時点の起点（現在等）から過去１週間または過去１カ月という期間を設け遡ったとき、その間に修正を行った回数を指します。
【0057】
図１２（ａ）の最近行ったバクの修正回数の点数変換テーブルに示すように、最近行ったバグの修正回数が多いほどバグを含む確率が高いと考えられるので、バグの修正回数が高いほど相対的に高い点数を付与する。
【0058】
また図１２（ｂ）の最近行ったバクの修正回数の重みづけテーブルに示すように、バグ修正の内容に応じて重みづけを行う。バグ修正の内容が他のソースコードに与える影響が小さいほど、相対的に小さい重みづけを行い、相対的に大きな影響を与えると予想される内容のバグ修正であるほど相対的に大きな重みづけを行う。例えば機能に影響がないバグが最小の重み１とし、仕様誤りに起因するバグ修正は修正対象ではないソースコードにも影響が出る可能性が大なので最大の重み５と判定する。
【0059】
図９に示すように、最近行ったバグの修正回数を分析観点とする機能の判定値の算出処理では、まず分析観点設定部１２０は、設計データ、より詳しくは仕様書、ソースコード、ソースコード修正チケットを取得し（Ｓ２２２１）、取得した設計データから機能毎にソースコードを結びつける（Ｓ２２２２）。
【0060】
判定値算出部１３０は機能のソースコードの最近行ったバグ件数を機能毎に集計する（Ｓ２２２３）。
【0061】
判定値算出部１３０は集計したバグ件数を「バグ修正回数の点数変換テーブル」に基づき点数化し、「バグ修正回数の重みづけテーブル」に基づき重みづけする。
（Ｓ２２２４）。
（Ｓ２２２４）。
【0062】
判定値算出部１３０は、算出した点数に重みを乗算することで各機能毎の判定値を算出，出力する（Ｓ２２２５）。
【0063】
判定値算出部１３０は、機能の数だけＳ２２２３～Ｓ２２１６を繰り返し、「最近行ったバグ修正回数の機能毎の判定値算出」表を作成する。判定値算出部１３０は、全ての機能について最近行ったバグの修正回数を分析観点とする判定値の算出が終わっていなければ（Ｓ２２２６：はい）、他の機能についてステップＳ２２１３からの処理を繰り返す。一方、機能の数だけ処理を繰り返して全ての機能について最近行ったバグの修正回数からみた判定値の算出が終了すると（Ｓ２２２６：いいえ）処理を終了する。
【0064】
分析観点３：工程別バグの密度の高さ
図１３は、工程別バグの密度の高さに応じた判定値の算出フローを示す図である。図１４は、工程別バグの密度の高さに応じた判定値の算出に関するテーブルを示す図であり、（ａ）は工程別バグ密度の高さ点数変換テーブル、（ｂ）は工程別バグ密度の高さ重みづけテーブル、（ｃ）は工程別バグ密度の高さの機能毎の判定値算出結果テーブルである。工程別バグ密度の高さ点数変換テーブル及び工程別バグ密度の高さ重みづけテーブルはテストケース生成装置１００のＨＤＤ１０４に予め格納しておく。
図１３は、工程別バグの密度の高さに応じた判定値の算出フローを示す図である。図１４は、工程別バグの密度の高さに応じた判定値の算出に関するテーブルを示す図であり、（ａ）は工程別バグ密度の高さ点数変換テーブル、（ｂ）は工程別バグ密度の高さ重みづけテーブル、（ｃ）は工程別バグ密度の高さの機能毎の判定値算出結果テーブルである。工程別バグ密度の高さ点数変換テーブル及び工程別バグ密度の高さ重みづけテーブルはテストケース生成装置１００のＨＤＤ１０４に予め格納しておく。
【0065】
図１４（ａ）の工程別バグ密度の高さ点数変換テーブルに示すように、バグ密度(件/kstep)及びバグ密度指標との差異が高いほどバグが含まれていると考えられるので相対的に高い点数を付与する。
【0066】
また図１４（ｂ）の工程別バグ密度の高さ重みづけテーブルに示すように、ソースコード修正チケットより得た情報を用いて前工程で摘出すべき不良の割合を求め、当該割合が高いほど大きな重みづけを行う。
【0067】
図１３に示すように、工程別バグの密度の高さを分析観点とする機能の判定値の算出処理では、まず、分析観点設定部１２０は、設計データ、より詳しくは仕様書、仕様書レビュー議事録、ソースコード、及びソースコード修正チケットを取得し（Ｓ２２３１）、)取得した設計データから機能毎にソースコードを結びつける（Ｓ２２３２）。
【0068】
判定値算出部１３０は、各機能のソースコードの工程別バグ件数を機能毎に集計する（Ｓ２２３３）。
【0069】
判定値算出部１３０は、機能のソースコードのステップ数で工程別バグ件数を除算してバグ密度を計算する（Ｓ２２３４）。
【0070】
判定値算出部１３０は、集計したバグ密度を「工程別バグ密度の高さ点数変換テーブル」に基づき点数化し、「工程別バグ密度の高さ重みづけテーブル」に基づき重みづけする（Ｓ２２３５）。
【0071】
判定値算出部１３０は、算出した点数に重みを乗算することで各機能毎の判定値を算出，出力する（Ｓ２２３６）。
【0072】
判定値算出部１３０は、機能の数だけＳ２２３３～Ｓ２２３６を繰り返し、「工程別バグ密度の高さの機能毎の判定値算出」点数表を作成する。全ての機能について工程別バグの密度の高さからみた判定値の算出が終わっていなければ（Ｓ２２３７：はい）、他の機能についてステップＳ２２３３からの処理を繰り返す。一方、機能の数だけ処理を繰り返して全ての機能について工程別バグの密度の高さからみた判定値の算出が終了すると（Ｓ２２３７：いいえ）処理を終了する。
【0073】
分析観点４：過去プロジェクトのバグ密度の高さ
図１５は、過去プロジェクトのバグ密度の高さに応じた判定値の算出フローを示す図である。図１６は、過去プロジェクトのバグ密度の高さに応じた判定値の算出に関するテーブルを示す図であり、（ａ）は過去プロジェクトのバグ密度の高さ点数変換テーブル、（ｂ）は過去プロジェクトのバグ密度の高さ重みづけテーブル、（ｃ）は過去プロジェクトのバグ密度の機能毎の判定値算出結果テーブルである。過去プロジェクトのバグ密度の高さ点数変換テーブル、過去プロジェクトのバグ密度の高さ重みづけテーブルはテストケース生成装置１００のＨＤＤ１０４に予め格納しておく。
図１５は、過去プロジェクトのバグ密度の高さに応じた判定値の算出フローを示す図である。図１６は、過去プロジェクトのバグ密度の高さに応じた判定値の算出に関するテーブルを示す図であり、（ａ）は過去プロジェクトのバグ密度の高さ点数変換テーブル、（ｂ）は過去プロジェクトのバグ密度の高さ重みづけテーブル、（ｃ）は過去プロジェクトのバグ密度の機能毎の判定値算出結果テーブルである。過去プロジェクトのバグ密度の高さ点数変換テーブル、過去プロジェクトのバグ密度の高さ重みづけテーブルはテストケース生成装置１００のＨＤＤ１０４に予め格納しておく。
【0074】
図１５（ａ）の過去プロジェクトのバグ密度の高さ点数変換テーブルに示すように、バグ密度(件/kstep)及びバグ密度指標との差異が高いほどバグが含まれていると考えられるので相対的に高い点数を付与する。
【0075】
また図１５（ｂ）の過去プロジェクトのバグ密度の高さ重みづけテーブルに示すように、ソースコード修正チケットより得た情報を用いて規模に対する過去からのテスト密度指標との差異を求め、当該差異が高いほど大きな重みづけを行う。
【0076】
図１４に示すように、工程別バグの密度の高さを分析観点とする機能の判定値の算出処理では、まず、分析観点設定部１２０は、設計データ、より詳しくは仕様書、仕様書レビュー議事録、ソースコード、及びソースコード修正チケットを取得し（Ｓ２２４１）、取得した設計データから機能毎にソースコードを結びつける機能毎にソースコードを結び付ける（Ｓ２２４２）。
【0077】
判定値算出部１３０は、機能のソースコードの過去プロジェクトからのバグ件数を機能毎に集計する（Ｓ２２４３）。
【0078】
判定値算出部１３０は、集計したバグ件数を機能のソースコードのステップ数で除算してバグ密度を計算する（Ｓ２２４４）。
【0079】
判定値算出部１３０は、集計したバグ密度を「過去プロジェクトのバグ密度の高さ点数変換テーブル」に基づき点数化し、「過去プロジェクトのバグ密度の高さ重みづけテーブル」に基づき重みづけする。
（Ｓ２２４５）。
（Ｓ２２４５）。
【0080】
判定値算出部１３０は、算出した点数に重みを乗算することで各機能毎の判定値を算出、出力する（Ｓ２２４６）。
【0081】
判定値算出部１３０は、機能の数だけＳ２２４３～Ｓ２２４６を繰り返し、「過去プロジェクトのバグ密度の機能毎の判定値算出結果テーブル」を作成する。全ての機能について過去プロジェクトのバグ密度の高さからみた判定値の算出が終わっていなければ（Ｓ２２４７：はい）、他の機能についてステップＳ２２４３からの処理を繰り返す。一方、機能の数だけ処理を繰り返して全ての機能について過去プロジェクトのバグ密度の高さからみた判定値の算出が終了すると（Ｓ２２４７：いいえ）処理を終了する。
【0082】
分析観点５：レビュー議事録による仕様書バグ密度の高さ
図１７は、レビュー議事録による仕様書バグ密度の高さに応じた判定値の算出フローを示す図である。図１８は、レビュー議事録例を示す図である。図１９は、レビュー議事録による仕様書バグ密度の高さに応じた判定値の算出に関するテーブルを示す図であり、（ａ）はレビュー議事録によるバグ密度の高さ点数変換テーブル、（ｂ）はレビュー議事録によるバグ密度の高さ重みづけテーブル、（ｃ）はレビュー議事録によるバグ密度の機能毎の判定値算出結果テーブルである。
図１７は、レビュー議事録による仕様書バグ密度の高さに応じた判定値の算出フローを示す図である。図１８は、レビュー議事録例を示す図である。図１９は、レビュー議事録による仕様書バグ密度の高さに応じた判定値の算出に関するテーブルを示す図であり、（ａ）はレビュー議事録によるバグ密度の高さ点数変換テーブル、（ｂ）はレビュー議事録によるバグ密度の高さ重みづけテーブル、（ｃ）はレビュー議事録によるバグ密度の機能毎の判定値算出結果テーブルである。
【0083】
図１８のレビュー議事録はチケットしてＤＢに登録される。
【0084】
図１９（ａ）のレビュー議事録によるバグ密度の高さ点数変換テーブル、及び（ｂ）のレビュー議事録によるバグ密度の高さ重みづけテーブルはＨＤＤ１０４に予め格納しておく。
【0085】
図１９（ａ）のレビュー議事録によるバグ密度の高さ点数変換テーブルに示すように、バグ密度(件/kstep)及びバグ密度指標との差異が高いほどバグが含まれていると考えられるので相対的に高い点数を付与する。
【0086】
また図１９（ｂ）のレビュー議事録によるバグ密度の高さ重みづけテーブルに示すように、レビュー議事録より得た情報を用いてレビュー指摘内容に応じた重みづけを行う。
【0087】
図１７に示すように、レビュー議事録による仕様書バグ密度の高さを分析観点とする機能の判定値の算出処理では、まず、分析観点設定部１２０は、設計データ、より詳しくは仕様書、仕様書レビュー議事録、ソースコード、及びソースコード修正チケットを取得し（Ｓ２２４１）、取得した設計データから機能毎にソースコードを結びつける（Ｓ２２５２）。
【0088】
判定値算出部１３０は、機能のソースコードの仕様書レビュー議事録を参照してバグ件数を機能毎に集計（Ｓ２２５３）。
【0089】
判定値算出部１３０は、集計したバグ件数を機能のソースコードのステップ数で除算してバグ密度を計算する（Ｓ２２５４）。
【0090】
判定値算出部１３０は、バグ密度を「レビュー議事録によるバグ密度の高さ点数変換テーブル」に基づき点数化し、「レビュー議事録によるバグ密度の高さ重みづけテーブル」に基づき重みづけする（Ｓ２２５５）。
【0091】
判定値算出部１３０は、算出した点数に重みを乗算することで各機能毎の判定値を算出、出力する。（Ｓ２２５６）。
【0092】
判定値算出部１３０は、機能の数だけＳ２２５３～Ｓ２２５６を繰り返し、「レビュー議事録によるバグ密度の機能毎の判定値算出結果テーブル」を作成する。全ての機能についてレビュー議事録による仕様書バグ密度の高さからみた判定値の算出が終わっていなければ（Ｓ２２５６：はい）、他の機能についてステップＳ２２５３からの処理を繰り返す。一方、機能の数だけ処理を繰り返して全ての機能についてレビュー議事録による仕様書バグ密度の高さからみた判定値の算出が終了すると（Ｓ２２５６：いいえ）処理を終了する。
【0093】
＜（２６）機能組み合わせテスト項目パラメータ方式判定＞
図２０は、分析観点毎の判定値からテストパラメータ抽出するフロー（（２６）機能組み合わせテスト項目パラメータ方式判定に相当する）を示す図である。図２１は、機能組み合わせテスト項目パラメータ方式判定に関連するテーブルであり、（ａ）は機能毎の分析データによる重みづけテーブルであり、（ｂ）は機能毎の判定値合計とテストパラメータ抽出方式テーブルである。図２２は、機能毎の判定値計算とテストパラメータ抽出方式の決定テーブルである。
図２０は、分析観点毎の判定値からテストパラメータ抽出するフロー（（２６）機能組み合わせテスト項目パラメータ方式判定に相当する）を示す図である。図２１は、機能組み合わせテスト項目パラメータ方式判定に関連するテーブルであり、（ａ）は機能毎の分析データによる重みづけテーブルであり、（ｂ）は機能毎の判定値合計とテストパラメータ抽出方式テーブルである。図２２は、機能毎の判定値計算とテストパラメータ抽出方式の決定テーブルである。
【0094】
テストパラメータ抽出部１４０は、分析観点毎の判定値を機能毎に集計する（Ｓ２６１）。
【0095】
テストパラメータ抽出部１４０は、「機能毎の分析データによる重みづけ」テーブルを用いて機能毎の分析データから機能毎の重みづけを設定する（Ｓ２６２）。
【0096】
テストパラメータ抽出部１４０は、「機能毎の判定値計算とテストパラメータ抽出方式の決定」テーブルを用いて機能毎の判定値を算出する（Ｓ２６３）。
【0097】
テストパラメータ抽出部１４０は、「機能毎の判定値合計とテストパラメータ抽出方式」及び「機能毎の判定値計算とテストパラメータ抽出方式の決定」に従い、機能毎のテストパラメータ抽出方式を決定する（Ｓ２６４）。
【0098】
テストパラメータ抽出部１４０は、テストパラメータ抽出ツールを実行しテストパラメータを抽出する（Ｓ３）。
【0099】
＜（４）テスト項目抽出フロー＞
テスト項目抽出フローのうち「テスト実行後のバグ摘出からテストパラメータを追加抽出するフロー」の動作を説明する。図２３は、テスト実行後のバグ摘出からテストパラメータを追加抽出するフローを示す図である。図２４は、テスト実行後のバグ摘出からテストパラメータを追加抽出するフローに関するテーブルであって、（ａ）は再テスト結果の重み変換テーブル、（ｂ）は再テスト結果のバグ密度重みづけテーブル、（ｃ）は機能毎の差分判定値とパラメータ抽出方式変換テーブル、（ｄ）はテスト実行後のバグの重みと追加項目のパラメータ抽出方式テーブルである。
テスト項目抽出フローのうち「テスト実行後のバグ摘出からテストパラメータを追加抽出するフロー」の動作を説明する。図２３は、テスト実行後のバグ摘出からテストパラメータを追加抽出するフローを示す図である。図２４は、テスト実行後のバグ摘出からテストパラメータを追加抽出するフローに関するテーブルであって、（ａ）は再テスト結果の重み変換テーブル、（ｂ）は再テスト結果のバグ密度重みづけテーブル、（ｃ）は機能毎の差分判定値とパラメータ抽出方式変換テーブル、（ｄ）はテスト実行後のバグの重みと追加項目のパラメータ抽出方式テーブルである。
【0100】
ユーザは、ステップ（３）で抽出したパラメータに基づき、バグ修正の対象となるプログラムに対してバグテストを実行する（Ｓ４０１）。
【0101】
バグテストの結果バグ摘出が無い場合は（Ｓ４０２：いいえ）終了する。バグ摘出がある場合（Ｓ４０２：はい）、ユーザがバグの修正を行い、テストケース生成装置１００にバグ摘出及び修正履歴を記載したソースコード修正チケットを入力する。設計データ取得部１１０は、入力されたソースコード修正チケットをソースコード修正チケット記憶部１７４に追加する更新記録を行う。
【0102】
判定値算出部１３０は、機能毎にテスト後のバグを集計する（Ｓ４０３）。
【0103】
判定値算出部１３０は、機能毎のテスト後のバグ密度を計算する（Ｓ４０４）。
【0104】
判定値算出部１３０は、「４－１ 再テスト結果の重み変換テーブル」及び「４－２ 再テスト結果のバグ密度重みづけテーブル」に基づき機能毎に重みづけを行う（Ｓ４０５）。
【0105】
テストパラメータ抽出部１４０は、「４－３ 機能毎の差分判定値とパラメータ抽出方式変換テーブル」に基づき、「４－４ テスト実行後のバグの重みと追加項目のパラメータ抽出方式で追加項目のテストパラメータの抽出方式」を決定する（Ｓ４０６）。
【0106】
テストパラメータ抽出部１４０は、ステップＳ３で抽出したテストパラメータに、４－４で追加するテストパラメータ抽出方式を加え、テストパラメータ抽出ツールを実行し、不足したテストパラメータを追加抽出する（図６（ｃ）参照）（Ｓ４０７）。
【0107】
本実施形態によれば、テストケース生成において、チケット、コミットログ、ソースコード、設計書、レビュー議事録などのプロジェクトデータに基づき、ソースコードの複雑さ、バグ修正の傾向、各工程のバグ密度などの分析観点を設け、各分析観点毎に重要度に応じて重みづけを行うテスト項目抽出方式において、機能毎にプロジェクト内の開発結果を反映し、各機能の開発経緯を分析し、開発経緯に合わせて重みを変化させることで、テスト優先度の高い機能を重点項目に選定し、抽出アルゴリズムを決定するテストケースの生成が行える。
【0108】
また、上記条件で抽出したテストケースのテスト実行結果のバグ情報を反映し、上記分析観点の重みを変化させることで、テスト後バグ流出の多い機能を重点パラメータとした抽出アルゴリズムを再設定することでテストケースを自動的に追加するテスト項目抽出が行える。これを繰り返し、不足した抽出テストケースを充足することで、プロジェクトの品質状況に合わせてテストケースの質を向上させることができる。
【0109】
本実施形態に係るテストケース生成装置１００では、設計データに基づいて機能毎のテストの網羅性の多少を判定することから、従来のようにバグテストの担当者の経験値や感に頼ることなくバグテストが行えるので、人為的な能力や経験値に影響されることなく、必要十分なバグテストを行いやすくなる。
【0110】
また初回のバグテストでバグ摘出を行い、バグを修正すると、そのバグ修正履歴を反映させて追加抽出した組み合わせテストパラメータを抽出できる（図６（ｃ）参照）。これにより、バグ修正に伴い組み合わせテストパラメータを追加して追加のバグテスト項目を生成できる。その際も、設計データに依存するがユーザの知見には依存しないので、客観的に過不足がないバグテストが行える。
【0111】
上記実施形態は本発明を限定するものではなく、本発明の趣旨を逸脱しない変形例は本発明に含まれる。例えば、設計データに基づく分析観点は上記の一部でもよいし、設計データに基づく分析観点であれば追加してもよい。
【符号の説明】
【0112】
１００ ：テストケース生成装置
１０１ ：ＣＰＵ
１０２ ：ＲＡＭ
１０４ ：ＨＤＤ
１０５ ：入力Ｉ／Ｆ
１０６ ：出力Ｉ／Ｆ
１０７ ：バス
１０８ ：入力装置
１０９ ：出力装置
１１０ ：設計データ取得部
１２０ ：分析観点設定部
１３０ ：判定値算出部
１４０ ：テストパラメータ抽出部
１７１ ：仕様書記憶部
１７２ ：仕様書レビュー議事録記憶部
１７３ ：ソースコード記憶部
１７４ ：ソースコード修正チケット記憶部
１８１ ：テーブル記憶部
１８２ ：判定値記憶部
１８３ ：テストパラメータ記憶部
１０１ ：ＣＰＵ
１０２ ：ＲＡＭ
１０４ ：ＨＤＤ
１０５ ：入力Ｉ／Ｆ
１０６ ：出力Ｉ／Ｆ
１０７ ：バス
１０８ ：入力装置
１０９ ：出力装置
１１０ ：設計データ取得部
１２０ ：分析観点設定部
１３０ ：判定値算出部
１４０ ：テストパラメータ抽出部
１７１ ：仕様書記憶部
１７２ ：仕様書レビュー議事録記憶部
１７３ ：ソースコード記憶部
１７４ ：ソースコード修正チケット記憶部
１８１ ：テーブル記憶部
１８２ ：判定値記憶部
１８３ ：テストパラメータ記憶部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】