JP2003256206A - ソフトウェアシステムのテスト計画作成支援方法およびテスト計画作成支援プログラム - Google Patents

Abstract

(57)【要約】 【課題】 ソフトウェアシステムのテストにどれだけの
リソースをどのように割り当てるべきかを、テスト計画
として決定することを支援する方法およびプログラムの
提供。 【解決手段】 ソフトウェアシステムのプログラムモジ
ュールごとの品質情報を設定する工程２４と、前記品質
情報から前記プログラムモジュールの不具合検出工数を
予測する工程２６と、前記モジュールと前記ソフトウェ
アシステムの仕様書から抽出される仕様項目との対応関
係を表すモジュール・仕様項目対応関係情報を作成する
工程２２と、前記不具合検出工数と前記モジュール・仕
様項目対応関係情報とから仕様項目不具合検出工数を予
測する工程２８と、前記仕様項目不具合検出工数に基づ
いて、前記ソフトウェアシステムのテストに利用可能な
テストリソースを配分するテスト計画を作成する工程３
０とを備えたことを特徴とするテスト計画作成支援方法
およびプログラム。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ソフトウェアシ
ステムの信頼性を向上させるためのテスト技術ならびに
検証技術に関係し、これらのテスト・検証を効率的に行
うテスト計画の作成を支援する方法ならびにプログラム
に関する。

【０００２】

【従来の技術】従来、ソフトウェアシステムの信頼性を
保証するためにソフトウェアテスト技術が広く用いられ
ている。ソフトウェアテスト技術では、テスト対象とな
るソフトウェアに対してどのようなテストケースをどの
ようなテスト計画で利用するかが重要となる。テストケ
ースとテスト計画の良し悪しによって、テストの品質と
効率が大きく異なってくる。

【０００３】テストケースは、対象ソフトウェアの機能
を網羅的にテストするように設計する必要があるが、最
近のソフトウェアシステムは大規模化・複雑化してお
り、すべての機能を網羅的にテストするためには、膨大
な工数を用いて膨大なテストケースを消化する必要があ
る。一方でソフトウェアシステム開発に当てられる開発
期間には限度があるため、限られた時間内にすべてを実
施することは不可能に近い。そのため、信頼性や重要度
などの基準に応じてテストする部分に優先順位をつけ、
優先順位によってテストケースの詳細度を変えること
で、必要十分な量の効率的なテストケースを設計するこ
とが必要となってきている。これに対して、発明者ら
は、システム仕様書などからシステムの特徴を表現し、
そのシステムにとって適当なテスト戦略を選択する手段
を提供して、重要な機能を優先的にテストできるテスト
ケースの設計支援方法を提案している(特願２００１−
２９０３８０)。

【０００４】一方で、テストの実行には、テストケース
と並んでテスト計画も必要である。テスト計画とは、具
体的に誰が、どのテストケースを、いつ、どれだけの工
数をかけて行うかを定めたものである。同一のテストケ
ースを用いても、そのテストを担当する技術者の力量
や、実際にテストで不具合を検出するのにかかる工数な
どテスト作業に関するメトリクスによって、テストの効
果は異なるものとなる。したがって、テストケースの作
成と同様、テスト計画の作成においても、どのメトリク
スを重視するかの判定基準を、テストの戦略として意図
的に設定しなければ、効率的なテストの実現は難しい。

【０００５】従来技術では、テスト作業に関するメトリ
クスに注目してテスト計画を作成することはしていなか
ったが、より効率の良いテストを実現するためには、こ
のようなテスト計画作成手法が必要とされる。

【０００６】

【発明が解決しようとする課題】このように、従来の技
術では、システム仕様書などからそのシステムの特徴を
表現し、そのシステムにとって適当なテスト戦略を選択
して、品質上重要な機能かそうでない機能かを判断する
テスト優先度を導出してテストケースを設計している
が、そのテストケースを効率的に実行するためのテスト
計画を、テスト作業に関するメトリクスに注目して作成
してはいなかった。

【０００７】そこで本発明では、優先的にテストできる
ように設計されたテストケースに対して、モジュールご
とに測定されるプログラムの品質メトリクスや、開発し
たプログラマの技術力などの要因を分析することで、ど
のテストにおいて不具合が発生する可能性が高いかを予
測し、どのテストにどれだけのリソースをどのように割
り当てるべきかを、テスト計画として決定することを支
援する方法およびプログラムを提供する。

【０００８】

【課題を解決するための手段】上記課題を解決するため
に、本発明では、ソフトウェアシステムのプログラムモ
ジュールごとの品質情報を設定するモジュール品質情報
設定工程と、前記品質情報から前記プログラムモジュー
ルの不具合検出工数を予測するモジュール不具合検出工
数予測工程と、前記モジュールと前記ソフトウェアシス
テムの仕様書から抽出される仕様項目との対応関係を表
すモジュール・仕様項目対応関係情報を作成するモジュ
ール・仕様項目対応関係設定工程と、前記不具合検出工
数と前記モジュール・仕様項目対応関係情報とから仕様
項目不具合検出工数を予測する仕様項目不具合検出工数
予測工程と、前記仕様項目不具合検出工数に基づいて、
前記ソフトウェアシステムのテストに利用可能なテスト
リソースを配分するテスト計画を作成するテスト計画作
成工程とを備えたことを特徴とするテスト計画作成支援
方法を提供する。

【０００９】また、本発明では、ソフトウェアシステム
のプログラムモジュールごとの品質情報を設定するモジ
ュール品質情報設定機能と、前記品質情報から前記プロ
グラムモジュールの不具合検出工数を予測するモジュー
ル不具合検出工数予測機能と、前記モジュールと前記ソ
フトウェアシステムの仕様書から抽出される仕様項目と
の対応関係を表すモジュール・仕様項目対応関係情報を
作成するモジュール・仕様項目対応関係設定機能と、前
記不具合検出工数と前記モジュール・仕様項目対応関係
情報とから仕様項目不具合検出工数を予測する仕様項目
不具合検出工数予測機能と、前記仕様項目不具合検出工
数の基づいて、前記ソフトウェアシステムのテストにか
けることのできるテストリソースを配分するテスト計画
を作成するテスト計画作成機能とをコンピュータに実現
させることを特徴とするテスト計画作成支援プログラム
を提供する。

【００１０】上記した本発明によれば、各モジュールの
品質に関わる情報を設定・利用して、モジュールごとの
不具合検出工数を予測し、モジュール・仕様項目対応関
係情報から仕様項目ごとの不具合検出工数を予測するこ
とが可能となった。その結果、仕様項目ごとのテスト優
先度、不具合検出工数予測、および利用可能なテストリ
ソースから、効率的なソフトウェアテストを実現するた
めのテスト計画を作成することが可能となった。

【００１１】

【発明の実施の形態】以下、本発明の実施の形態につい
て、図面を参照しつつ詳細に説明する。

【００１２】図１は本発明の全体の流れを、ブロック図
を用いて示したものである。同図において、２２はモジ
ュール・仕様項目対応関係設定部、２４はモジュール品
質情報設定部、２６はモジュール不具合検出工数予測
部、２８は仕様項目不具合検出工数予測部、３０はテス
ト計画作成部、１６はテストケース設計部、１８はテス
ト実行・結果出力部である。

【００１３】本発明では、テスト対象となるソフトウェ
アシステム製品のモジュールリスト３２をもとに、モジ
ュール品質情報設定部２４を利用してモジュールごとの
品質情報を設定し、モジュール品質情報２５からモジュ
ール不具合検出工数予測部２６を利用してモジュール不
具合検出工数２７を予測する。さらに、システム仕様書
から抽出された仕様項目リスト１と、モジュール・仕様
項目対応関係設定部２２を利用してモジュール・仕様項
目対応関係情報２３を作成する。これらモジュール不具
合検出工数２７とモジュール・仕様項目対応関係情報２
３とから、仕様項目不具合検出工数予測部２８を利用し
て仕様項目不具合検出工数２９を予測する。そして、テ
ストに利用される資源やスケジュールなどからなるテス
トリソース１３、どの仕様項目を優先的にテストするか
を表わすテスト優先度つき仕様項目リスト１０、仕様項
目不具合検出工数２９からテスト計画作成部３０を利用
して、効率的なソフトウェアテストを可能にするテスト
計画３１を作成する。

【００１４】次に、テスト優先度つき仕様項目リスト１
０と、テストリソース１３、テストケース設計部１６を
利用して、テスト対象ソフトウェアにとって最適なテス
トケース１７を作成する。このテストケース１７とテス
ト計画３１にもとづいてテスト実行された結果発見され
た不具合情報は、テスト実行・結果出力部１８を利用し
てテスト結果１９として出力される。なお、本発明は、
テスト計画の作成までを主として支援するものであり、
テスト実行・結果出力部は設けなくても良い。また、テ
スト優先度つき仕様項目リストの情報はテスト計画の作
成にあたって使用しなくても良い。

【００１５】以下、上記した各部の機能について詳細に
説明する。なお、各機能はソフトウェアによりコンピュ
ータを用いて実現されるものであっても良い。

【００１６】＜モジュール品質情報の設定＞本発明で
は、ソフトウェアを構成するプログラムモジュールごと
に、その品質に関する情報（モジュール品質情報）を設
定する。設定された品質情報を用いて、後に、その不具
合検出工数を予測することになる。

【００１７】まずは、設定される品質情報の例を図２に
示す。図２にあるように、品質情報にはその開発プロセ
スに関する特徴と、開発されたモジュールのソースコー
ドに関する特徴とに大きく分けられる。開発プロセスに
関する特徴は、主に主観的に設定されるものであり、一
方、ソースコードに関する特徴は、機械的に測定可能な
ものである。なお、テスト計画を作成するのはテスト実
行にかなり近い段階でも良いので、ソースコードを利用
することが可能となる。

【００１８】モジュール品質情報設定の具体的な手順の
例を図３に示す。まず、設定する品質情報を一つ選択す
る（Ｓ８１）。それが開発プロセスに関する品質情報か
否かを判断し（Ｓ８２）、そうである場合には、その開
発プロセスについての調査を行い（Ｓ８３）、その結果
について主観的あるいは客観的に評価して、１−１０の
点数を与える（Ｓ８４）。他にも評価したいモジュール
品質情報がある場合には、Ｓ８１に戻って作業を繰り返
す（Ｓ８５）。一方、選択した品質情報が、モジュール
ソースコードに関する品質情報の場合には（Ｓ８６）、
その品質情報に対応するソースコードの特徴値あるいは
メトリクスを、ツールを利用、もしくは手作業にて測定
する（Ｓ８７）。さらに測定結果にもとづいて、１−１
０の点数を与える（Ｓ８８）。他にも評価したい品質情
報がある場合には、Ｓ８１に戻って作業を繰り返す。

【００１９】＜モジュール不具合検出工数の予測＞モジ
ュールごとに、そのモジュールからどの程度の不具合が
検出され、その検出工数がそのモジュールのトータルで
どの程度になるかを予測する。どのようにモジュール検
出工数を予測するかには、様々な手順が考えられるが、
ここでは、最も基本的な手順を図４にて説明する。ま
ず、不具合検出工数を予測するモジュールを一つ選択す
る（Ｓ９１）。つづいて不具合数の予測に有効な品質情
報を選択し（Ｓ９２）、それらから、ソースコードの単
位規模に対する不具合の数を予測する（Ｓ９３）。ま
た、不具合検出工数の予測に有効な品質情報を選択し
（Ｓ９４）、それらから、不具合当たりの検出工数を予
測する（Ｓ９５）。最後に、それらの積をとることで、
トータルの不具合検出工数を算出する（Ｓ９６）。不具
合検出工数が未知のモジュールが残っていたら、Ｓ９１
へ戻って作業を繰り返す（Ｓ９７）。

【００２０】前記した品質情報の例（図２参照）の一部
を利用して、不具合検出工数予測の例を以下に述べる。
まず、不具合数の予測に有効な品質情報として、ソース
規模と担当者のスキルを利用する。担当者のスキルを把
握すれば、そのレベルのプログラマが作成したプログラ
ムに、例えば１０００行あたりに何個程度の不具合が含
まれているかを予測することができる。例えば、プログ
ラム経験の浅いプログラマの担当したモジュールについ
ては、１０００行あたりに５個の不具合を仮定して、ソ
ース規模からモジュールの総不具合数を予測する、など
である。この情報を用いて、トータルで何個程度の不具
合が含まれているかを予測する。次に、不具合検出工数
の予測に有効な品質情報として、ソースコードの複雑さ
を利用する。ソースコードが複雑であれば、そのソース
コードの実行パスも多岐に渡り、特定のパスに存在する
不具合を検出するのに、より多くの工数が必要となる。
通常の一個あたりの検出工数を設定し、複雑さに応じて
それに調整をほどこす。例えば、一定レベル以上の複雑
さをもつモジュールについては、単位あたりの不具合検
出工数を通常の１．５倍にする、などである。この検出
工数と、予測した不具合数との積をとることで、トータ
ルの不具合検出工数を予測することができる。

【００２１】＜モジュール・仕様項目対応関係情報の設
定＞一般にシステム仕様書には、ソフトウェアシステム
で実現される機能が仕様項目として記述されている。こ
れらの項目の一覧をリストとして抽出した仕様項目リス
ト（詳細は後述）と、その仕様項目の実現に利用される
モジュールとの対応関係の情報を設定する。この情報
は、後に仕様項目ごとの不具合検出工数を予測するため
に必要となる。設定すべき情報は、図５のようである。
各仕様項目の実現に際して、どのモジュールが使用され
ているか、またその寄与の度合はどの程度になるか、を
設定する。実際の手順としても、図のような表を埋めて
いく形で行われる。基本的な手順は、図６のようであ
る。一つの仕様項目を選択し（Ｓ１０１）、その仕様項
目を実現するために使用されるモジュールを洗い出し
（Ｓ１０２）、各モジュールのこの仕様項目実現への寄
与の度合を、比率（パーセント）で設定する（Ｓ１０
３）。以上の手順を、すべての仕様項目に対して繰り返
す（Ｓ１０４）。

【００２２】＜仕様項目不具合検出工数の予測＞モジュ
ール・仕様項目対応関係情報と、モジュールごとの不具
合検出工数予測とから、それぞれの仕様項目ごとに、仕
様項目不具合検出工数を予測する。基本的な手順例は図
７のようである。一つのモジュールに対して（Ｓ１１
１）そのモジュールの、各仕様項目への寄与の度合の比
率を計算する（Ｓ１１２）。そのモジュールの寄与する
仕様項目ごとに、不具合検出工数の予測値を、（Ｓ１１
２）にて決定した比率で分配する（Ｓ１１３）。この分
配をすべてのモジュールについて繰り返す（Ｓ１１
４）。次に、一つの仕様項目を選択し（Ｓ１１５）、各
モジュールからこの仕様項目への不具合検出工数の分配
値のトータルをとり、この仕様項目の不具合検出工数予
測値とする（Ｓ１１６）。この手順をすべての仕様項目
に対して繰り返す（Ｓ１１７）。図のようにして、仕様
項目ごとの不具合検出工数を予測する。

【００２３】例えば、あるモジュールの不具合検出工数
が２人日であり、二つの仕様項目に寄与しているとす
る。この時、それぞれの仕様項目への寄与率がそれぞれ
４０％、６０％であった場合は、寄与の比率は２：３と
なり、それぞれへの不具合検出工数の分配は、０．８人
日、１．２人日になる。

【００２４】＜テスト計画の作成＞テストに利用される
資源やスケジュールなどを表わすテストリソース、テス
ト優先度付き仕様項目リスト、予測された仕様項目不具
合検出工数の三つから、テスト計画を作成する。

【００２５】テストリソースとしては、「担当」「期
間」「資源」等の分類にしたがって、必要なリソースが
定義されている（詳細は後述）。テスト優先度つき仕様
項目リストは、仕様項目リストの各項目に対してテスト
優先度という値が与えられたものである（詳細は後
述）。テスト優先度とは、その値が大きいほどテストの
実行順序やテストの量などに関して優先的・重点的にテ
ストを実施することを表わす指標である。また、テスト
計画とは、それぞれのテスト担当者に対して、誰が、ど
の仕様項目に対するテストを、どのタイミングで、どれ
だけの不具合検出工数をかけて、行うかを定めたもので
ある。すなわち、テスト計画は、仕様項目不具合検出工
数の予測値に基づいて、テストリソースの配分を決定す
るものである。テスト計画は、例えば図８のような線表
として表現することができる。

【００２６】ここでは、テスト計画作成の非常に基本的
な手順を図９に示す。テストリソースとして、テスト期
間、テスト担当者の人数構成と各担当者の能力が与えら
れたものとする。この例では、テスト担当者の能力は、
基準とする担当者の能力を基準（１．０）にして、それ
に対して単位時間に処理できる不具合検出工数の相対比
で表現する。したがって、基準となるものよりも２０％
能力の高い技術者とは、同一時間に１．２倍の工数分の
テストを行えるもののことである。その段階で割り当て
られていない仕様項目のテストのうち、最もテスト優先
度の高いものを選択し（Ｓ１２１）、途中段階の作業計
画から、割り当て可能なテスト担当者を選択し（Ｓ１２
２）、その仕様項目の不具合検出工数予測値をテスト担
当者の能力比で割った値を、その仕様項目テスト期間と
して割り当てる（Ｓ１２３）。上記の手順をすべての仕
様項目に対して行う（Ｓ１２４）。以上のようにして、
テスト計画を作成することが可能となる。さらに図８の
状況を例にとると、次に割り当てるべき仕様項目はＣａ
ｓｅ２であり、その不具合検出工数は２．４、割り当て
可能な担当者はB、能力は１．２である。この場合は、
担当者Bに対して、２．４／１．２＝２日を割り当てる
ことになる。

【００２７】前記の通り、この手順は非常に基本的で単
純な例を示したものである。テスト担当者の得手不得手
によって、仕様項目ごとに担当者の能力比を変え、担当
者の選択時に、最も能力の高い担当者を選ぶようにす
る、テスト優先度の高いものに対しては基本となる不具
合検出工数にさらに予備の工数を付与する、優先度の高
いものだけを集めた仕様項目のテストケースと、通常の
全仕様項目のテストケースを用意して交互に繰り返しテ
ストするなど、様々の工夫が可能である。

【００２８】そこで、第二の実施形態として、予備の工
数を利用したテスト計画作成のアルゴリズムを説明す
る。これは、テストに利用可能な工数をあらかじめ基本
の不具合検出工数（基本工数）と予備の不具合検出工数
（予備工数）として区別しておく。基本工数と予備工数
の総和が、テストに利用可能な総不具合検出工数にな
る。基本工数は予測される仕様項目不具合検出工数にも
とづいて配分し、予備の不具合検出工数はテスト優先度
にもとづいて分配する、というアルゴリズムである。こ
のアルゴリズムを利用することにより、テスト優先度の
高い仕様項目については、テスト順序を先にするだけで
はなく、より多くの不具合検出工数を割り当てることが
可能となり、テスト優先度の高い仕様項目に対するテス
トの十分性をさらに高めることができる。

【００２９】図１０にこの例の手順を示す。まず、全仕
様項目に関する不具合検出工数の予測値の和をとりＣｐ
（Ｔ）とする（Ｓ１３１）。次に利用可能な工数を基本
工数Ｃ（Ｂ）と予備工数Ｃ（Ｐ）とに、Ｃ（Ｂ）≦Ｃｐ
（Ｔ）となるように分ける（Ｓ１３２）。このうち、予
備工数の方をテスト優先度に基づいて分配することにな
る。まずは、基本工数を不具合検出工数の大きさにもと
づいて分配する。Ｃ（Ｂ）＝Ｃｐ（Ｔ）の場合には（Ｓ
１３３）、各仕様項目に不具合検出工数を分配すること
が可能なので、仕様項目（ｉ）ごとの不具合検出工数は
Ｃ（ｉ）＝Ｃｐ（ｉ）とする（Ｓ１３４）。ただし、Ｃ
ｐ（ｉ）は、仕様項目（ｉ）の不具合検出工数予測値で
ある。Ｃ（Ｂ）＜Ｃｐ（Ｔ）の場合には、不具合検出工
数をすべての仕様項目に割り振ることはできないので、
基本工数を不具合検出工数予測値の比で分配し、Ｃ
（ｉ）＝Ｃ（Ｂ）＊Ｃｐ（ｉ）／Ｃｐ（Ｔ）、となる
（Ｓ１３５）。この時点でのＣ（ｉ）は基本工数を分配
したものであり、この後、予備工数の分配に入る。予備
工数の分配は、テスト仕様項目のテスト優先度値Ｐ
（ｉ）のテスト優先度値の総和Ｐ（Ｔ）に対する比にも
とづいて行う。Ｃ（ｉ）＝Ｃ（ｉ）＋Ｃ（Ｐ）＊Ｐ
（ｉ）／Ｐ（Ｔ）という形で、予備工数の分配分を、仕
様項目ごとの不具合検出工数に追加する。これにより、
テスト優先度の高い仕様項目に対してより多くの工数を
割り当てることができる（Ｓ１３６）。これより後のテ
スト計画作成は、前の例とほとんど同じである。その段
階で割り当てられていない仕様項目のテストのうち、最
もテスト優先度の高いものを選択し(Ｓ１３７)、途中段
階の作業計画から、割り当て可能なテスト担当者につい
て（Ｓ１３８）、その仕様項目の不具合検出工数予測値
をテスト担当者の能力比で割った値を、その仕様項目テ
スト期間として割り当てる（Ｓ１３９）。上記の手順を
すべての仕様項目に対して行う（Ｓ１４０）。以上のよ
うにして、テスト計画を作成することが可能となる。

【００３０】第三の実施形態として、不具合修正が頻繁
に行われる開発形態でのリグレッションテストとして利
用する例を示す。リグレッションテストとは、同じテス
トケースを、一定量の不具合が修正されるたびに繰り返
し行うテストのことである。このテストは、不具合修正
によってシステムに悪影響が出ていないかを調べるため
に実施される。

【００３１】ここでは、優先度の高いものだけを集めた
重要仕様項目リストと通常の全仕様項目リストの両方を
用意して、二つの仕様項目リストのテストを交互に繰り
返し実行するような、リグレッションテストの応用とな
るテスト計画作成アルゴリズムを説明する。このアルゴ
リズムを利用することにより、テスト優先度の高い仕様
項目については、テスト優先度の低い仕様項目と比較し
てより多くの回数テストされ、より多くの不具合検出工
数を割り当てることができる。重要仕様項目に対するテ
ストと通常の全仕様項目に対するテストを組み合わせて
利用することで、テスト効率とテスト十分性をさらに高
めることができる。

【００３２】図１１にこの例の手順を示す。まず、すべ
ての仕様項目を集合Ｕｔにセットする（Ｓ１４１）。次
にＵｔに属する仕様項目をテスト優先度値の大きいもの
から順に並べた配列Ａ（Ｕｔ）を作成する（Ｓ１４
２）。次に、集合Ｕｔに属する全仕様項目に関する不具
合検出工数の予測値の総和を計算してＣｐ（Ｔ）とする
（Ｓ１４３）。重要仕様項目として選択したい項目の比
率ｘ（０≦ｘ≦１）を決定する（Ｓ１４４）。配列Ａ
（Ｕｔ）の先頭の仕様項目から順番に一つずつ取り出し
て集合Ｕｘに加え、Ｕｘに属する仕様項目に関する不具
合検出工数の予測値の和Ｃｐ（ｘ）を計算する（Ｓ１４
５）。ここで、Ｃｐ（ｘ）≦ｘ＊Ｃｐ（Ｔ）ならば（Ｓ
１４６）、配列Ａ（Ｕｔ）から次の仕様項目を取り出し
て集合Ｕｘに加えて同様にＣｐ（ｘ）を計算する（Ｓ１
４５）。もしＣｐ（ｘ）＞ｘ＊Ｃｐ（Ｔ）となれば（Ｓ
１４６）、最後に加えた項目はＵｘから削除する（Ｓ１
４７）。こうして求めた部分集合Ｕｘに対し、前述の第
一、第二の実施形態に挙げたような任意のアルゴリズム
を用いてテスト計画Ｐｘを立てる（Ｓ１４８）。次に仕
様項目全体の集合Ｕｔに対して、同様に任意のアルゴリ
ズムを用いてテスト計画Ｐｔを立てる（Ｓ１４９）。こ
れらのテスト計画ＰｘとＰｔを任意に組み合わせること
で、全体のテスト計画を作成する（Ｓ１５０）。全仕様
項目のテスト計画Ｐｔの実行回数に対する重要仕様項目
テスト計画Ｐｘの実行回数を増やすことで、テスト優先
度の高い仕様項目により多くの不具合検出工数を割り当
てることが可能になる。また、部分集合ＵｘをＵｔとみ
なし、再起的にこのアルゴリズムを適用して、さらに詳
細なテスト計画を作成することも可能である。

【００３３】＜テストの実行＞こうして作成されたテス
ト計画と、公知の手段で設計されたテストケースによっ
てテスト実行された結果は、テスト実行・結果出力部を
利用してテスト結果として出力される。公知のテストケ
ース設計手段としては、例えば特開２００１−１８４２
３２のようにシステム仕様からテストケースを設計する
手法を用いる。テスト実行・結果出力部における手順は
後述する。

【００３４】次に、システム仕様書などからシステムの
特徴を表現し、そのシステムにとって適当なテスト戦略
を選択する手段を提供して、重要な機能を優先的にテス
トできるテストケースの設計支援方法について説明す
る。

【００３５】図１２は、かかる設計支援方法の全体の流
れを、ブロック図を用いて示したものである。なお、こ
こには図１で示したテスト計画を設計する流れが併記さ
れているが、ここでは該当部分に同じ符号を用いること
により説明を省略する。

【００３６】図１２において３は仕様項目特性値設定
部、５はテスト戦略作成部、７はテスト戦略選択部、９
はテスト優先度導出部、１１はテスト戦略評価部、１６
はテストケース設計部、１８はテスト実行・結果出力
部、２１はテスト結果検証部である。

【００３７】ここでは、まずテスト対象となるソフトウ
ェアシステム製品のシステム仕様書から抽出された仕様
項目リスト１と、ソフトウェアシステムの特徴を表現す
るために用意された評価観点データベース２をもとに、
仕様項目特性値設定部３を利用して、そのソフトウェア
システムの特徴を表わす特性値つき仕様項目リスト４を
作成する。

【００３８】次に評価観点データベース２をもとにテス
ト戦略作成部５を利用して、どの評価観点にどれくらい
重点をおいてテストするかを設定するためのテスト戦略
を作成し、テスト戦略データベース６に登録する。

【００３９】テスト戦略選択部７では、テスト戦略デー
タベース６から任意のテスト戦略を選択してテスト優先
度導出部９に出力する。テスト優先度導出部９では、与
えられたテスト戦略と特性値つき仕様項目リスト４をも
とに、どの仕様項目を優先的にテストするかを表わすテ
スト優先度つき仕様項目リスト１０が作成される。

【００４０】テスト戦略評価部１１では、テスト優先度
つき仕様項目リスト１０と過去の不具合データ１２を入
力として、選択されたテスト戦略を適用して得られる不
具合検出傾向をシミュレーションし、選択されたテスト
戦略がテスト対象ソフトウェアシステムに適しているか
どうかを判断する。必要ならば複数のテスト戦略を順次
選択して不具合検出傾向をシミュレーションし、最適だ
と思われるテスト戦略およびテスト優先度つき仕様項目
リストを、テストケース設計用に選択する。

【００４１】次に、テストケース設計用に選択されたテ
スト優先度つき仕様項目リスト１０と、テストに利用さ
れる資源やスケジュールなどからなるテストリソース１
３、過去に生成された類似テストケース１４、および不
足分のテストケースの補充、過多なテストケースの削除
をするためのテストケース設計手順１５をもとに、テス
トケース設計部１６を利用して、テスト対象ソフトウェ
アにとって最適なテストケース１７を作成する。このテ
ストケース１７によりテスト実行された結果発見された
不具合情報は、テスト実行・結果出力部１８を利用して
テスト結果１９として出力される。通常のテストでは、
開発・デバッグの進行に合わせてテストが繰り返し実行
される。現在テスト対象となっているソフトウェアへの
すべてのテスト結果は、現テスト対象の不具合データ２
０に登録される。

【００４２】テスト結果検証部２１では、現テスト対象
の不具合データ２０と適用されたテスト優先度つき仕様
項目リスト１０を入力として適用テスト戦略を再度検証
し、テスト戦略評価部に記憶されている他のテスト戦略
によるテスト優先度つき仕様項目リストとも比較して、
必要ならば適用テスト戦略を入れ替えて再テストを実施
する。このようにして、常に最適なテスト戦略を選択し
て、最も効果的なテストケースが生成されるようにす
る。

【００４３】以下、上記した各部の機能について詳細に
説明する。なお、各機能はソフトウェアによりコンピュ
ータを用いて実現されるものであっても良い。

【００４４】＜特性値つき仕様項目リストの作成＞仕様
項目特性値設定部３では、システム仕様書から抽出され
た仕様項目リスト１とシステムの特徴を表現するための
評価観点データベース２を入力として、特性値つき仕様
項目リスト４を作成する。様々な視点からシステムの特
徴を表現するために、ソフトウェアシステムを構成して
いる各仕様項目に対して、複数の評価観点に基づいて特
性値を与えることができる。これにより、ソフトウェア
システムを複数の視点から仕様項目単位で評価すること
が可能となる。

【００４５】一般にシステム仕様書には、ソフトウェア
システムで実現される機能が仕様項目として記述されて
いる。これらの項目の一覧をリストとして抽出した仕様
項目リスト１が仕様項目特性値設定部３の入力となる。
一方、評価観点はシステムをいろいろな観点から評価し
てその特徴を表現するために用意されるもので、システ
ム仕様書の内容や設計段階での開発情報などからシステ
ム開発の早期に評価できるものが主として選ばれ、評価
観点データベース２に蓄積される。評価観点として考え
られる一例を図１３に示す。ここでは、評価観点をプロ
グラムの品質等の分類ごとに整理して示している。

【００４６】これらの仕様項目リスト１と評価観点デー
タベース２を入力として仕様項目特性値設定部３に与
え、各仕様項目に対して評価観点に基づいたパラメータ
を仕様項目特性値として指定することで、特性値つき仕
様項目リスト３を生成する。その具体的な手順を図１４
に示す。

【００４７】まず、評価観点並びに仕様項目リストを読
み込み（Ｓ１，Ｓ２）、設定する評価観点を一覧から選
択する（Ｓ３）。続いて仕様項目リストから仕様項目を
検索し（Ｓ４）、選択した評価観点で評価した特性値を
検索した仕様項目に入力する（Ｓ５）。かかる操作を仕
様項目の検索が終了するまで繰り返し行う（Ｓ６）。次
に、入力された仕様項目特性値の正規化を行う（Ｓ
７）。仕様項目特性値は一般に仕様項目間の比較による
相対評価として与えられることが多い。そのため、各々
の評価観点について特性値がすべての仕様項目に与えら
れた段階で、特性値が、例えば１から１０までの範囲に
収まるように正規化を行い、評価観点間の基準をそろえ
る。こうして、必要となるすべての評価観点について特
性値が仕様項目に与えられたかを確認し（Ｓ８）、特性
値つき仕様項目リストが作成される（Ｓ９）。

【００４８】特性値つき仕様項目リストの一例を図１５
に示す。ここで、仕様項目は大項目と中項目とからな
り、ここでは、「ファイル」と「編集」に関する各項目
について、選択された「不具合致命度」「機能利用頻
度」「複雑さ」の各評価観点について特性値が与えられ
ている。

【００４９】＜テスト戦略の作成＞テスト戦略作成部５
では、テストを実行する際にどの評価観点にどれだけ重
点をおいたテストをするかを示すテスト戦略を作成す
る。テスト戦略とは、システムの特徴を表現するために
仕様項目に与えられた複数の仕様項目特性値に対して、
どの評価観点による特性値をどの程度重視したテストを
行うかを表わしており、図１６のように各評価観点に対
する重み付けとして表現される。より重視する評価観点
ほど、設定される重みが大きくなる。例えば、致命度重
視型のテスト戦略では、評価観点のうち「不具合致命
度」に関する重みが最も高い０．７に設定され、「機能
利用頻度」および「仕様の複雑さ」に関する重みはそれ
ぞれ０．１５となっている。

【００５０】テスト戦略を作成するテスト戦略作成部に
おける手順を図１７に示す。まず、評価観点一覧の読み
込みを行い（Ｓ１０）、テスト戦略を新規に作成する必
要があるか否かの判断を行う（Ｓ１１）。ここで、テス
ト戦略を新たに作成しない場合は、テスト戦略データベ
ースから編集したいテストデータを選択する（Ｓ１
２）。テスト戦略作成部には、評価観点データベースか
ら入力が与えられ、各評価観点に対する重みを設定する
ことでテスト戦略を作成する。続いて、重みを設定する
評価観点を一覧から選択し（Ｓ１３）、選択した評価観
点に対して重みを設定する（Ｓ１４）。すべての評価観
点に対して重みが設定されれば（Ｓ１５）、それらの合
計が１になるように正規化する（Ｓ１６）。ここで、新
たに作成されたテスト戦略若しくは編集されたテスト戦
略は、テスト戦略データベースに登録される（Ｓ１
７）。

【００５１】＜テスト戦略の選択＞テスト戦略選択部７
では、テストを実行する際にどのようなテスト戦略に基
づいてテストを行うかを決定する。

【００５２】テスト戦略選択部７では、テスト戦略デー
タベース６に登録されたテスト戦略の中から、テスト優
先度導出部９に与えるテスト戦略８を選択して出力す
る。テスト戦略８を選択するテスト戦略選択部７におけ
る手順を図１８に示す。最初は任意のテスト戦略を選択
するが（Ｓ２１）、テストサイクルの進行に伴い、テス
ト戦略評価部やテスト結果検証部からより最適なテスト
戦略を選択するように指示が来るので（Ｓ２０）、その
指示に基づいてテスト戦略をテスト戦略データベースか
ら選択する。例えば、テスト戦略データベースからまだ
テスト優先度を導出していないテスト戦略を選択する
（Ｓ２２）。指示に適したテスト戦略がデータベースに
存在するか否かを確認し（Ｓ２３）、無い場合には、テ
スト戦略作成部でテスト戦略を作成してデータベースに
登録した後、そのテスト戦略を選択する（Ｓ２４）。そ
して選択されたテスト戦略は出力するようにしても良い
（Ｓ２５）。

【００５３】＜テスト優先度つき仕様項目リストの作成
＞テスト優先度導出部９では、選択されたテスト戦略８
を適用することでソフトウェアシステムのどの部分を特
に重点的にテストする必要があるかを、仕様項目単位に
評価した指標であるテスト優先度を導出する。ここで作
成されるテスト優先度つき仕様項目リスト１０は、特性
値つき仕様項目リスト４とテスト戦略８をもとにテスト
優先度導出部９にて生成されるもので、図２０に示すよ
うに仕様項目リストの各項目に対してテスト優先度とい
う値が与えられたものである。

【００５４】テスト優先度とは、その値が大きいほどテ
ストの実行順序やテストの量などに関して優先的・重点
的にテストを実施することを表わす指標である。テスト
優先度導出部９では、各仕様項目に与えられた評価観点
ごとの特性値と、テスト戦略として設定された各評価観
点への重みづけから、その仕様項目に対するテスト優先
度を算出する。その具体的な手順を図１９に示す。ま
ず、テスト戦略と特性値つき仕様項目リストが読み込ま
れる（Ｓ３１，Ｓ３２）。続いて、仕様項目リストから
順次項目を検索し（Ｓ３３）、テスト戦略で設定された
各評価観点への重みづけと、特性値つき仕様項目リスト
の各仕様項目に与えられた特性値とから、その項目のテ
スト優先度を算出する（Ｓ３４）。かかる優先度の算出
は、仕様項目の検索が終了するまで繰り返し行われる
（Ｓ３５）。一般にテスト優先度は、各仕様項目 ｉに
対してｎ個の評価観点に基づいた仕様項目特性値

【００５５】

【数１】

【００５６】が与えられたとき、テスト戦略による各評
価観点への重みが

【００５７】

【数２】

【００５８】ならば、テスト優先度 は以下の数式
（１）で表現される。

【００５９】

【数３】

【００６０】ただしテスト優先度を導出する計算式は、
仕様項目特性値と各評価観点への重みとを組み合わせた
ものであれば異なる計算式を用いてもよい。こうして得
られたテスト優先度を各仕様項目に持たせて、図２０に
示すようなテスト優先度つき仕様項目リストを作成する
（Ｓ３６）。

【００６１】＜適用テスト戦略の評価＞テスト戦略評価
部１１では、適用されたテスト戦略によって各仕様項目
に与えられたテスト優先度に基づいたテストが、ソフト
ウェアシステムに対してどれだけ有効なのか、テストの
目的に合致しているのかどうかを評価する。また評価結
果はすべて記憶しておき、複数のテスト戦略から最適な
ものを選択するために比較・検討することができる。新
規のシステム開発においてはこのフェーズは実行できな
いが、過去に類似のシステム仕様構成をもつソフトウェ
アシステムの開発情報があれば、これを利用して適用テ
スト戦略の評価が可能となる。

【００６２】テスト戦略評価部１１では、テスト優先度
つき仕様項目リスト１０と過去の不具合データ１２が入
力として与えられ、過去の不具合データ１２と比較して
適用したテスト戦略がテスト対象ソフトウェアシステム
に対して適当かどうかを評価する。過去の不具合データ
１２には、図２２に示すようにシステムをバージョンア
ップする前の開発情報などの、類似のシステム仕様構成
を持つソフトウェアシステム開発プロジェクトの不具合
情報が蓄積され、各仕様項目にどれだけの不具合が存在
していたかを示すデータが含まれている。なお図２２中
の不具合数で「＊」が記入されている仕様項目は、その
開発バージョンではまだ実装されていなかったことを示
している。

【００６３】テスト戦略評価部における手順を図２１に
示す。まず、テスト優先度つき仕様項目リストを読み込
み（Ｓ４１）、過去の不具合データが存在するかを確認
して（Ｓ４２）、存在する場合は入力されたテスト優先
度つき仕様項目リストを、過去の不具合データと比較し
て不具合が多く存在しそうな項目がどの程度テスト優先
度の上位に位置しているかをシミュレーションする。具
体的には、テスト優先度つき使用項目リストと過去の不
具合データから不具合検出傾向を予測し（Ｓ４３）、こ
の予測した不具合検出傾向をテスト優先度つき仕様項目
及びそのテスト戦略と対応付けて記憶し（Ｓ４４）、記
憶されている不具合検出傾向一覧を比較して、最適なテ
スト優先度つき仕様項目リストを選択する（Ｓ４５）。
別のテスト戦略についてもシミュレーションを実行した
ければ（Ｓ４６）、テスト戦略データベースから別のテ
スト戦略を選択するように、テスト戦略選択部に指示を
出す。こうして選択された新たなテスト戦略からテスト
優先度導出部にてテスト優先度つき仕様項目リストを導
出し（Ｓ４７）、過去の不具合データと比較して同様に
評価する。この手順を繰り返して記憶したテスト戦略評
価の一覧を比較し、実際のテストケース設計に適用する
テスト戦略をひとつ選択し、テストケース設計部に出力
する（Ｓ４８）。

【００６４】＜テストケース設計＞テストケース設計部
１６では、適用されたテスト戦略８によって導出したテ
スト優先度に基づいて、各仕様項目に対してどのくらい
重点的にテストを実行するかを決定し、テストケースを
設計する。

【００６５】テストケース設計部１６では、テスト優先
度つき仕様項目リスト１０と共に、テストリソース１
３、過去の類似テストケース１４、テストケース設計手
段１５が入力として与えられる。テストケース設計部１
６における手順を図２４に示す。まず、テスト優先度つ
き仕様項目リストの読み込みが行われる（Ｓ５１）。次
に、テストに利用される資源やスケジュールなどを表わ
すテストリソースを読み込み（Ｓ５２）、各仕様項目に
与えられたテスト優先度に応じて仕様項目ごとに配分す
る（Ｓ５３）。テストリソースの例を図２３に挙げる。
テストリソースとしては、「担当」「期間」「資源」等
の分類にしたがって、必要なリソースが定義されてい
る。

【００６６】各仕様項目のテスト優先度と配分されたテ
ストリソースに応じて、仕様項目ごとに必要十分なテス
トケース量を予測する。次に、類似のシステム仕様に対
して過去に生成されたテストケースがあれば、それを読
み込み（Ｓ５４）、仕様項目をリストから順次検索して
（Ｓ３５）、その情報を利用してテストケースを設計す
る（Ｓ５６）。各仕様項目のテストケース量を検討し
（Ｓ５７）、過去の類似テストケースが全く存在しない
か、あるいは予測したテストケース量に比べてテストケ
ースが不足していれば、その不足分を補充するために公
知のテストケース設計手段を用いて不足分のテストケー
スを作成する（Ｓ５８）。公知のテストケース設計手段
としては、特開２００１−１８４２３２のようにシステ
ム仕様からテストケースを設計する手法を用いる。逆に
予測したテストケース量に比べてテストケースが過多で
あるような場合には、テストケースを削減して適当な量
にする（Ｓ５９）。こうして、全ての仕様項目について
検索が終了すると（Ｓ６０）、テスト対象にとって最適
なテストケースが生成される（Ｓ６１）。

【００６７】＜テスト結果の再利用＞こうして設計され
たテストケースによりテスト実行された結果は、テスト
実行・結果出力部１８を利用してテスト結果１９として
出力される。テスト実行・結果出力部１８における手順
を図２５に示す。テスト実行・結果出力部では、テスト
ケースを読込み（Ｓ６５）、読込まれたテストケースに
基づいてテストを実行し（Ｓ６６）、その結果発見され
た不具合とその重要度を、システムの各仕様項目と対応
づけて記録する（Ｓ６７）。こうして各仕様項目に関係
する不具合数および重要度を集計し、テスト結果として
出力する（Ｓ６８）。出力されるテスト結果の例を図２
６に示す。また、テストはソフトウェアの開発・デバッ
グを通じて繰り返し行われ、各テストサイクルでテスト
結果が出力される。現テスト対象に対して行われる各テ
ストサイクルのすべてのテスト結果は、何回目のテスト
サイクルで得られたテスト結果であるかとあわせて、現
テスト対象の不具合データとして保存される。

【００６８】テスト結果検証部２１では、現テスト対象
の不具合データ２０と適用されたテスト優先度つき仕様
項目リスト１０を入力として、適用テスト戦略が適当で
あったかどうかを検証する。テスト結果検証部２１にお
ける手順を図２７に示す。まず、テストケース設計に適
用したテスト優先度つき仕様項目リストとテスト戦略部
で記憶した不具合検出傾向予測を読込む（Ｓ７１，Ｓ７
２）。入力される現テスト対象の不具合データには、何
回目のテストサイクルで見つかった不具合なのか、また
その不具合の重要度がどの程度であるかが、仕様項目ご
とに記録されている。テスト結果検証部では、この不具
合データとテスト優先度つき仕様項目リストを比較して
（Ｓ７３）、適用テスト戦略で期待された通りの効果が
得られているかどうかを検証する（Ｓ７４）。検証の結
果、期待通りの効果が得られており、かつまだ不具合が
収束していなければ（Ｓ７５）、再テストを同じテスト
戦略を用いて再度実行して（Ｓ７６）、適用中のテスト
優先度つき仕様項目リストを再出力する（Ｓ７７）。一
方、期待通りの効果が得られていないか、効果は得られ
ているが既に不具合が収束しているようならば（Ｓ７
４，Ｓ７５）、別のテスト戦略を新たに選択することを
決定し、テスト戦略選択部に指示を出す（Ｓ７８）。そ
して、適当なテスト優先度つき仕様項目リストが存在す
る場合は（Ｓ７９）、現テスト対象の不具合データから
不具合検出傾向を検証し、より最適なテスト戦略を選択
する（Ｓ８０）。一方、適当なテスト優先度つき仕様項
目リストが存在しない場合は（Ｓ７９）、テスト戦略選
択部において新たにテスト戦略を選択し、テスト優先度
につき仕様項目リストを導出して、テスト戦略評価部で
評価・記憶を行う（Ｓ８１）。なお、選択された最適な
テスト戦略は別のテスト戦略と比較しても良く（Ｓ８
２）、最終的に選択されたテスト優先度つき仕様項目リ
ストが出力される（Ｓ８３）。

【００６９】このようにテストサイクルを通して常に最
適なテスト戦略を選択し、最も効果的なテストケースが
生成されるようにする。

【００７０】また現テスト対象の不具合データは過去の
不具合データにも現バージョンでの不具合情報として登
録され、次バージョンのテスト戦略評価の際に不具合デ
ータとして利用されることになる。

【００７１】

【発明の効果】以上説明したように、本発明は、各モジ
ュールの品質に関わる情報を設定し利用して、モジュー
ルごとの不具合検出工数を予測し、モジュールとシステ
ム仕様書から抽出された仕様項目との対応情報から、仕
様項目ごとの不具合検出工数を予測することが可能とな
った。 その結果、優先的にテストすべき仕様項目を示
すテスト優先度、仕様項目不具合検出工数、および利用
可能なテストリソースから、効率的なソフトウェアテス
トを実現するためのテスト計画を作成することが可能と
なっている。

【図面の簡単な説明】

【図１】 本発明（テスト計画作成支援方法）の全体の
流れを示すブロック図。

【図２】 品質情報の一例を示す図。

【図３】 品質情報を設定する過程を示すフローチャー
ト。

【図４】 モジュール不具合検出工数を予測する過程を
示すフローチャート。

【図５】 仕様項目とモジュールとの対応関係として設
定する情報の一例を示す図。

【図６】 仕様項目とモジュールとの対応関係情報を設
定する過程を示すフローチャート。

【図７】 仕様項目の不具合検出工数を予測する過程を
示すフローチャート。

【図８】 テスト計画の作成過程での一例を示す図。

【図９】 テスト計画を作成する第一の例の過程を示す
フローチャート。

【図１０】 テスト計画を作成する第二の例の過程を示
すフローチャート。

【図１１】 テスト計画を作成する第三の例の過程を示
すフローチャート。

【図１２】 本発明の全体の流れを示すブロック図。

【図１３】 評価観点の一例を示す図。

【図１４】 特性値つき仕様項目リストを作成する過程
を示すフローチャート。

【図１５】 図１４で生成される特性値つき仕様項目リ
ストの一例を示す図。

【図１６】 テスト戦略の一例を示す図。

【図１７】 テスト戦略を作成する過程を示すフローチ
ャート。

【図１８】 テスト戦略を選択する過程を示すフローチ
ャート。

【図１９】 特性値つき仕様項目リストとテスト戦略か
らテスト優先度つき仕様項目リストを作成する過程を示
すフローチャート。

【図２０】 図１９で作成されるテスト優先度つき仕様
項目リストの一例を示す図。

【図２１】 選択されたテスト戦略から作成されたテス
ト優先度つき仕様項目リストを、過去の不具合データを
用いて評価する過程を示すフローチャート。

【図２２】 図２１で利用する過去の不具合データの一
例を示す図。

【図２３】 テストリソースの一例を示す図。

【図２４】 図１９で作成されるテスト優先度つき仕様
項目リストとテストリソース、過去の類似テストケース
および公知のテストケース設計手段から、テストケース
を設計する過程を示すフローチャート。

【図２５】 図２４で設計されたテストケースを用いて
テスト実行した結果、発見された不具合をテスト結果と
して作成する過程を示すフローチャート。

【図２６】 図２５で作成されるテスト結果の一例を示
す図。

【図２７】 図２６で作成されるテスト結果を利用して
テスト戦略を再度検証する過程を示すフローチャート。

【符号の説明】

１ システム仕様書仕様項目 ２ 評価観点データベース ３ 仕様項目特性値設定部 ４ 特性値つき仕様項目リスト ５ テスト戦略作成部 ６ テスト戦略データベース ７ テスト戦略選択部 ８ テスト戦略 ９ テスト優先度導出部 １０ テスト優先度付き仕様項目リスト １１ テスト戦略評価部 １２ 過去の不具合データ １３ テストリソース １４ 過去の類似テストケース １５ テストケース設計手段 １６ テストケース設計部 １７ テストケース １８ テスト実行・結果出力部 １９ テスト結果 ２０ 現テスト対象の不具合データ ２１ テスト結果検証部 ２２ モジュール・仕様項目対応関係設定部 ２３ モジュール・仕様項目対応関係情報 ２４ モジュール品質情報設定部 ２５ モジュール品質情報 ２６ モジュール不具合検出工数予測部 ２７ モジュール不具合検出工数 ２８ 仕様項目不具合検出工数予測部 ２９ 仕様項目不具合検出工数 ３０ テスト計画作成部 ３１ テスト計画 ３２ モジュールリスト

───────────────────────────────────────────────────── フロントページの続き (72)発明者 平山 雅之 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 Ｆターム(参考） 5B042 HH17 HH19 5B076 EC08 EC09 EC10

Claims (8)

【特許請求の範囲】
1. 【請求項１】 ソフトウェアシステムのプログラムモジ
   ュールごとの品質情報を設定するモジュール品質情報設
   定工程と、 前記品質情報から前記プログラムモジュールの不具合検
   出工数を予測するモジュール不具合検出工数予測工程
   と、 前記モジュールと前記ソフトウェアシステムの仕様書か
   ら抽出される仕様項目との対応関係を表すモジュール・
   仕様項目対応関係情報を設定するモジュール・仕様項目
   対応関係設定工程と、 前記不具合検出工数と前記モジュール・仕様項目対応関
   係情報とから仕様項目不具合検出工数を予測する仕様項
   目不具合検出工数予測工程と、 前記仕様項目不具合検出工数に基づいて、前記ソフトウ
   ェアシステムのテストに利用可能なテストリソースを配
   分するテスト計画を作成するテスト計画作成工程とを備
   えたことを特徴とするテスト計画作成支援方法。
2. 【請求項２】 前記ソフトウェアシステムのテストを実
   行する仕様項目のテスト優先度を導出するテスト優先度
   導出工程を更に備えたことを特徴とする請求項１記載の
   テスト計画作成支援方法。
3. 【請求項３】 前記テスト計画作成工程は、前記テスト
   リソースの配分にあたり、基本工数と予備工数を設定
   し、該基本工数を前記仕様項目不具合検出工数に基づい
   て配分し、該予備工数を前記テスト優先度に基づいて配
   分するようにしたことを特徴とする請求項２記載のテス
   ト計画作成支援方法。
4. 【請求項４】 前記テスト計画作成工程は、全仕様項目
   に関するテスト計画と前記テスト優先度に基づいて選択
   される重要仕様項目に関するテスト計画とを任意に組み
   合わせて実行するテスト計画を作成するものであること
   を特徴とする請求項２記載のテスト計画作成支援方法。
5. 【請求項５】 ソフトウェアシステムのプログラムモジ
   ュールごとの品質情報を設定するモジュール品質情報設
   定機能と、 前記品質情報から前記プログラムモジュールの不具合検
   出工数を予測するモジュール不具合検出工数予測機能
   と、 前記モジュールと前記ソフトウェアシステムの仕様書か
   ら抽出される仕様項目との対応関係を表すモジュール・
   仕様項目対応関係情報を設定するモジュール・仕様項目
   対応関係設定機能と、 前記不具合検出工数と前記モジュール・仕様項目対応関
   係情報とから仕様項目不具合検出工数を予測する仕様項
   目不具合検出工数予測機能と、 前記仕様項目不具合検出工数に基づいて、前記ソフトウ
   ェアシステムのテストに利用可能なテストリソースを配
   分するテスト計画を作成するテスト計画作成機能とをコ
   ンピュータに実現させることを特徴とするテスト計画作
   成支援プログラム。
6. 【請求項６】 前記ソフトウェアシステムのテストを実
   行する仕様項目のテスト優先度を導出するテスト優先度
   導出機能を更に備えたことを特徴とする請求項５記載の
   テスト計画作成支援プログラム。
7. 【請求項７】 前記テスト計画作成機能は、前記テスト
   リソースの配分にあたり、基本工数と予備工数を設定
   し、該基本工数を前記仕様項目不具合検出工数に基づい
   て配分し、該予備工数を前記テスト優先度に基づいて配
   分するようにしたことを特徴とする請求項６記載のテス
   ト計画作成支援プログラム。
8. 【請求項８】 前記テスト計画作成機能は、全仕様項目
   に関するテスト計画と前記テスト優先度に基づいて作成
   される重要仕様項目に関するテスト計画とを任意に組み
   合わせて実行するテスト計画を作成するものであること
   を特徴とする請求項６記載のテスト計画作成支援プログ
   ラム。