JP3883449B2

JP3883449B2 - Software system test plan creation support method and test plan creation support program

Info

Publication number: JP3883449B2
Application number: JP2002053210A
Authority: JP
Inventors: 徹也山本; 二郎岡安; 雅之平山
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2002-02-28
Filing date: 2002-02-28
Publication date: 2007-02-21
Anticipated expiration: 2022-02-28
Also published as: JP2003256206A

Description

【０００１】
【発明の属する技術分野】
この発明は、ソフトウェアシステムの信頼性を向上させるためのテスト技術ならびに検証技術に関係し、これらのテスト・検証を効率的に行うテスト計画の作成を支援する方法ならびにプログラムに関する。
【０００２】
【従来の技術】
従来、ソフトウェアシステムの信頼性を保証するためにソフトウェアテスト技術が広く用いられている。ソフトウェアテスト技術では、テスト対象となるソフトウェアに対してどのようなテストケースをどのようなテスト計画で利用するかが重要となる。テストケースとテスト計画の良し悪しによって、テストの品質と効率が大きく異なってくる。
【０００３】
テストケースは、対象ソフトウェアの機能を網羅的にテストするように設計する必要があるが、最近のソフトウェアシステムは大規模化・複雑化しており、すべての機能を網羅的にテストするためには、膨大な工数を用いて膨大なテストケースを消化する必要がある。一方でソフトウェアシステム開発に当てられる開発期間には限度があるため、限られた時間内にすべてを実施することは不可能に近い。そのため、信頼性や重要度などの基準に応じてテストする部分に優先順位をつけ、優先順位によってテストケースの詳細度を変えることで、必要十分な量の効率的なテストケースを設計することが必要となってきている。これに対して、発明者らは、システム仕様書などからシステムの特徴を表現し、そのシステムにとって適当なテスト戦略を選択する手段を提供して、重要な機能を優先的にテストできるテストケースの設計支援方法を提案している(特願２００１−２９０３８０)。
【０００４】
一方で、テストの実行には、テストケースと並んでテスト計画も必要である。テスト計画とは、具体的に誰が、どのテストケースを、いつ、どれだけの工数をかけて行うかを定めたものである。同一のテストケースを用いても、そのテストを担当する技術者の力量や、実際にテストで不具合を検出するのにかかる工数などテスト作業に関するメトリクスによって、テストの効果は異なるものとなる。したがって、テストケースの作成と同様、テスト計画の作成においても、どのメトリクスを重視するかの判定基準を、テストの戦略として意図的に設定しなければ、効率的なテストの実現は難しい。
【０００５】
従来技術では、テスト作業に関するメトリクスに注目してテスト計画を作成することはしていなかったが、より効率の良いテストを実現するためには、このようなテスト計画作成手法が必要とされる。
【０００６】
【発明が解決しようとする課題】
このように、従来の技術では、システム仕様書などからそのシステムの特徴を表現し、そのシステムにとって適当なテスト戦略を選択して、品質上重要な機能かそうでない機能かを判断するテスト優先度を導出してテストケースを設計しているが、そのテストケースを効率的に実行するためのテスト計画を、テスト作業に関するメトリクスに注目して作成してはいなかった。
【０００７】
そこで本発明では、優先的にテストできるように設計されたテストケースに対して、モジュールごとに測定されるプログラムの品質メトリクスや、開発したプログラマの技術力などの要因を分析することで、どのテストにおいて不具合が発生する可能性が高いかを予測し、どのテストにどれだけのリソースをどのように割り当てるべきかを、テスト計画として決定することを支援する方法およびプログラムを提供する。
【０００８】
【課題を解決するための手段】
上記課題を解決するために、本発明では、ソフトウェアシステムのプログラムモジュールごとの品質情報を設定するモジュール品質情報設定工程と、前記品質情報から前記プログラムモジュールの不具合検出工数を予測するモジュール不具合検出工数予測工程と、前記モジュールと前記ソフトウェアシステムの仕様書から抽出される仕様項目との対応関係を表すモジュール・仕様項目対応関係情報を作成するモジュール・仕様項目対応関係設定工程と、前記不具合検出工数と前記モジュール・仕様項目対応関係情報とから仕様項目不具合検出工数を予測する仕様項目不具合検出工数予測工程と、前記仕様項目不具合検出工数に基づいて、前記ソフトウェアシステムのテストに利用可能なテストリソースを配分するテスト計画を作成するテスト計画作成工程とを備えたことを特徴とするテスト計画作成支援方法を提供する。
【０００９】
また、本発明では、ソフトウェアシステムのプログラムモジュールごとの品質情報を設定するモジュール品質情報設定機能と、前記品質情報から前記プログラムモジュールの不具合検出工数を予測するモジュール不具合検出工数予測機能と、前記モジュールと前記ソフトウェアシステムの仕様書から抽出される仕様項目との対応関係を表すモジュール・仕様項目対応関係情報を作成するモジュール・仕様項目対応関係設定機能と、前記不具合検出工数と前記モジュール・仕様項目対応関係情報とから仕様項目不具合検出工数を予測する仕様項目不具合検出工数予測機能と、前記仕様項目不具合検出工数の基づいて、前記ソフトウェアシステムのテストにかけることのできるテストリソースを配分するテスト計画を作成するテスト計画作成機能とをコンピュータに実現させることを特徴とするテスト計画作成支援プログラムを提供する。
【００１０】
上記した本発明によれば、各モジュールの品質に関わる情報を設定・利用して、モジュールごとの不具合検出工数を予測し、モジュール・仕様項目対応関係情報から仕様項目ごとの不具合検出工数を予測することが可能となった。その結果、仕様項目ごとのテスト優先度、不具合検出工数予測、および利用可能なテストリソースから、効率的なソフトウェアテストを実現するためのテスト計画を作成することが可能となった。
【００１１】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照しつつ詳細に説明する。
【００１２】
図１は本発明の全体の流れを、ブロック図を用いて示したものである。同図において、２２はモジュール・仕様項目対応関係設定部、２４はモジュール品質情報設定部、２６はモジュール不具合検出工数予測部、２８は仕様項目不具合検出工数予測部、３０はテスト計画作成部、１６はテストケース設計部、１８はテスト実行・結果出力部である。
【００１３】
本発明では、テスト対象となるソフトウェアシステム製品のモジュールリスト３２をもとに、モジュール品質情報設定部２４を利用してモジュールごとの品質情報を設定し、モジュール品質情報２５からモジュール不具合検出工数予測部２６を利用してモジュール不具合検出工数２７を予測する。さらに、システム仕様書から抽出された仕様項目リスト１と、モジュール・仕様項目対応関係設定部２２を利用してモジュール・仕様項目対応関係情報２３を作成する。これらモジュール不具合検出工数２７とモジュール・仕様項目対応関係情報２３とから、仕様項目不具合検出工数予測部２８を利用して仕様項目不具合検出工数２９を予測する。そして、テストに利用される資源やスケジュールなどからなるテストリソース１３、どの仕様項目を優先的にテストするかを表わすテスト優先度つき仕様項目リスト１０、仕様項目不具合検出工数２９からテスト計画作成部３０を利用して、効率的なソフトウェアテストを可能にするテスト計画３１を作成する。
【００１４】
次に、テスト優先度つき仕様項目リスト１０と、テストリソース１３、テストケース設計部１６を利用して、テスト対象ソフトウェアにとって最適なテストケース１７を作成する。このテストケース１７とテスト計画３１にもとづいてテスト実行された結果発見された不具合情報は、テスト実行・結果出力部１８を利用してテスト結果１９として出力される。なお、本発明は、テスト計画の作成までを主として支援するものであり、テスト実行・結果出力部は設けなくても良い。また、テスト優先度つき仕様項目リストの情報はテスト計画の作成にあたって使用しなくても良い。
【００１５】
以下、上記した各部の機能について詳細に説明する。なお、各機能はソフトウェアによりコンピュータを用いて実現されるものであっても良い。
【００１６】
＜モジュール品質情報の設定＞
本発明では、ソフトウェアを構成するプログラムモジュールごとに、その品質に関する情報（モジュール品質情報）を設定する。設定された品質情報を用いて、後に、その不具合検出工数を予測することになる。
【００１７】
まずは、設定される品質情報の例を図２に示す。図２にあるように、品質情報にはその開発プロセスに関する特徴と、開発されたモジュールのソースコードに関する特徴とに大きく分けられる。開発プロセスに関する特徴は、主に主観的に設定されるものであり、一方、ソースコードに関する特徴は、機械的に測定可能なものである。なお、テスト計画を作成するのはテスト実行にかなり近い段階でも良いので、ソースコードを利用することが可能となる。
【００１８】
モジュール品質情報設定の具体的な手順の例を図３に示す。まず、設定する品質情報を一つ選択する（Ｓ８１）。それが開発プロセスに関する品質情報か否かを判断し（Ｓ８２）、そうである場合には、その開発プロセスについての調査を行い（Ｓ８３）、その結果について主観的あるいは客観的に評価して、１−１０の点数を与える（Ｓ８４）。他にも評価したいモジュール品質情報がある場合には、Ｓ８１に戻って作業を繰り返す（Ｓ８５）。一方、選択した品質情報が、モジュールソースコードに関する品質情報の場合には（Ｓ８６）、その品質情報に対応するソースコードの特徴値あるいはメトリクスを、ツールを利用、もしくは手作業にて測定する（Ｓ８７）。さらに測定結果にもとづいて、１−１０の点数を与える（Ｓ８８）。他にも評価したい品質情報がある場合には、Ｓ８１に戻って作業を繰り返す。
【００１９】
＜モジュール不具合検出工数の予測＞
モジュールごとに、そのモジュールからどの程度の不具合が検出され、その検出工数がそのモジュールのトータルでどの程度になるかを予測する。どのようにモジュール検出工数を予測するかには、様々な手順が考えられるが、ここでは、最も基本的な手順を図４にて説明する。まず、不具合検出工数を予測するモジュールを一つ選択する（Ｓ９１）。つづいて不具合数の予測に有効な品質情報を選択し（Ｓ９２）、それらから、ソースコードの単位規模に対する不具合の数を予測する（Ｓ９３）。また、不具合検出工数の予測に有効な品質情報を選択し（Ｓ９４）、それらから、不具合当たりの検出工数を予測する（Ｓ９５）。最後に、それらの積をとることで、トータルの不具合検出工数を算出する（Ｓ９６）。不具合検出工数が未知のモジュールが残っていたら、Ｓ９１へ戻って作業を繰り返す（Ｓ９７）。
【００２０】
前記した品質情報の例（図２参照）の一部を利用して、不具合検出工数予測の例を以下に述べる。まず、不具合数の予測に有効な品質情報として、ソース規模と担当者のスキルを利用する。担当者のスキルを把握すれば、そのレベルのプログラマが作成したプログラムに、例えば１０００行あたりに何個程度の不具合が含まれているかを予測することができる。例えば、プログラム経験の浅いプログラマの担当したモジュールについては、１０００行あたりに５個の不具合を仮定して、ソース規模からモジュールの総不具合数を予測する、などである。この情報を用いて、トータルで何個程度の不具合が含まれているかを予測する。次に、不具合検出工数の予測に有効な品質情報として、ソースコードの複雑さを利用する。ソースコードが複雑であれば、そのソースコードの実行パスも多岐に渡り、特定のパスに存在する不具合を検出するのに、より多くの工数が必要となる。通常の一個あたりの検出工数を設定し、複雑さに応じてそれに調整をほどこす。例えば、一定レベル以上の複雑さをもつモジュールについては、単位あたりの不具合検出工数を通常の１．５倍にする、などである。この検出工数と、予測した不具合数との積をとることで、トータルの不具合検出工数を予測することができる。
【００２１】
＜モジュール・仕様項目対応関係情報の設定＞
一般にシステム仕様書には、ソフトウェアシステムで実現される機能が仕様項目として記述されている。これらの項目の一覧をリストとして抽出した仕様項目リスト（詳細は後述）と、その仕様項目の実現に利用されるモジュールとの対応関係の情報を設定する。この情報は、後に仕様項目ごとの不具合検出工数を予測するために必要となる。設定すべき情報は、図５のようである。各仕様項目の実現に際して、どのモジュールが使用されているか、またその寄与の度合はどの程度になるか、を設定する。実際の手順としても、図のような表を埋めていく形で行われる。基本的な手順は、図６のようである。一つの仕様項目を選択し（Ｓ１０１）、その仕様項目を実現するために使用されるモジュールを洗い出し（Ｓ１０２）、各モジュールのこの仕様項目実現への寄与の度合を、比率（パーセント）で設定する（Ｓ１０３）。以上の手順を、すべての仕様項目に対して繰り返す（Ｓ１０４）。
【００２２】
＜仕様項目不具合検出工数の予測＞
モジュール・仕様項目対応関係情報と、モジュールごとの不具合検出工数予測とから、それぞれの仕様項目ごとに、仕様項目不具合検出工数を予測する。基本的な手順例は図７のようである。一つのモジュールに対して（Ｓ１１１）そのモジュールの、各仕様項目への寄与の度合の比率を計算する（Ｓ１１２）。そのモジュールの寄与する仕様項目ごとに、不具合検出工数の予測値を、（Ｓ１１２）にて決定した比率で分配する（Ｓ１１３）。この分配をすべてのモジュールについて繰り返す（Ｓ１１４）。次に、一つの仕様項目を選択し（Ｓ１１５）、各モジュールからこの仕様項目への不具合検出工数の分配値のトータルをとり、この仕様項目の不具合検出工数予測値とする（Ｓ１１６）。この手順をすべての仕様項目に対して繰り返す（Ｓ１１７）。図のようにして、仕様項目ごとの不具合検出工数を予測する。
【００２３】
例えば、あるモジュールの不具合検出工数が２人日であり、二つの仕様項目に寄与しているとする。この時、それぞれの仕様項目への寄与率がそれぞれ４０％、６０％であった場合は、寄与の比率は２：３となり、それぞれへの不具合検出工数の分配は、０．８人日、１．２人日になる。
【００２４】
＜テスト計画の作成＞
テストに利用される資源やスケジュールなどを表わすテストリソース、テスト優先度付き仕様項目リスト、予測された仕様項目不具合検出工数の三つから、テスト計画を作成する。
【００２５】
テストリソースとしては、「担当」「期間」「資源」等の分類にしたがって、必要なリソースが定義されている（詳細は後述）。テスト優先度つき仕様項目リストは、仕様項目リストの各項目に対してテスト優先度という値が与えられたものである（詳細は後述）。テスト優先度とは、その値が大きいほどテストの実行順序やテストの量などに関して優先的・重点的にテストを実施することを表わす指標である。また、テスト計画とは、それぞれのテスト担当者に対して、誰が、どの仕様項目に対するテストを、どのタイミングで、どれだけの不具合検出工数をかけて、行うかを定めたものである。すなわち、テスト計画は、仕様項目不具合検出工数の予測値に基づいて、テストリソースの配分を決定するものである。テスト計画は、例えば図８のような線表として表現することができる。
【００２６】
ここでは、テスト計画作成の非常に基本的な手順を図９に示す。テストリソースとして、テスト期間、テスト担当者の人数構成と各担当者の能力が与えられたものとする。この例では、テスト担当者の能力は、基準とする担当者の能力を基準（１．０）にして、それに対して単位時間に処理できる不具合検出工数の相対比で表現する。したがって、基準となるものよりも２０％能力の高い技術者とは、同一時間に１．２倍の工数分のテストを行えるもののことである。その段階で割り当てられていない仕様項目のテストのうち、最もテスト優先度の高いものを選択し（Ｓ１２１）、途中段階の作業計画から、割り当て可能なテスト担当者を選択し（Ｓ１２２）、その仕様項目の不具合検出工数予測値をテスト担当者の能力比で割った値を、その仕様項目テスト期間として割り当てる（Ｓ１２３）。上記の手順をすべての仕様項目に対して行う（Ｓ１２４）。以上のようにして、テスト計画を作成することが可能となる。さらに図８の状況を例にとると、次に割り当てるべき仕様項目はＣａｓｅ２であり、その不具合検出工数は２．４、割り当て可能な担当者はB、能力は１．２である。この場合は、担当者Bに対して、２．４／１．２＝２日を割り当てることになる。
【００２７】
前記の通り、この手順は非常に基本的で単純な例を示したものである。テスト担当者の得手不得手によって、仕様項目ごとに担当者の能力比を変え、担当者の選択時に、最も能力の高い担当者を選ぶようにする、テスト優先度の高いものに対しては基本となる不具合検出工数にさらに予備の工数を付与する、優先度の高いものだけを集めた仕様項目のテストケースと、通常の全仕様項目のテストケースを用意して交互に繰り返しテストするなど、様々の工夫が可能である。
【００２８】
そこで、第二の実施形態として、予備の工数を利用したテスト計画作成のアルゴリズムを説明する。これは、テストに利用可能な工数をあらかじめ基本の不具合検出工数（基本工数）と予備の不具合検出工数（予備工数）として区別しておく。基本工数と予備工数の総和が、テストに利用可能な総不具合検出工数になる。基本工数は予測される仕様項目不具合検出工数にもとづいて配分し、予備の不具合検出工数はテスト優先度にもとづいて分配する、というアルゴリズムである。このアルゴリズムを利用することにより、テスト優先度の高い仕様項目については、テスト順序を先にするだけではなく、より多くの不具合検出工数を割り当てることが可能となり、テスト優先度の高い仕様項目に対するテストの十分性をさらに高めることができる。
【００２９】
図１０にこの例の手順を示す。まず、全仕様項目に関する不具合検出工数の予測値の和をとりＣｐ（Ｔ）とする（Ｓ１３１）。次に利用可能な工数を基本工数Ｃ（Ｂ）と予備工数Ｃ（Ｐ）とに、Ｃ（Ｂ）≦Ｃｐ（Ｔ）となるように分ける（Ｓ１３２）。このうち、予備工数の方をテスト優先度に基づいて分配することになる。まずは、基本工数を不具合検出工数の大きさにもとづいて分配する。Ｃ（Ｂ）＝Ｃｐ（Ｔ）の場合には（Ｓ１３３）、各仕様項目に不具合検出工数を分配することが可能なので、仕様項目（ｉ）ごとの不具合検出工数はＣ（ｉ）＝Ｃｐ（ｉ）とする（Ｓ１３４）。ただし、Ｃｐ（ｉ）は、仕様項目（ｉ）の不具合検出工数予測値である。Ｃ（Ｂ）＜Ｃｐ（Ｔ）の場合には、不具合検出工数をすべての仕様項目に割り振ることはできないので、基本工数を不具合検出工数予測値の比で分配し、Ｃ（ｉ）＝Ｃ（Ｂ）＊Ｃｐ（ｉ）／Ｃｐ（Ｔ）、となる（Ｓ１３５）。この時点でのＣ（ｉ）は基本工数を分配したものであり、この後、予備工数の分配に入る。予備工数の分配は、テスト仕様項目のテスト優先度値Ｐ（ｉ）のテスト優先度値の総和Ｐ（Ｔ）に対する比にもとづいて行う。Ｃ（ｉ）＝Ｃ（ｉ）＋Ｃ（Ｐ）＊Ｐ（ｉ）／Ｐ（Ｔ）という形で、予備工数の分配分を、仕様項目ごとの不具合検出工数に追加する。これにより、テスト優先度の高い仕様項目に対してより多くの工数を割り当てることができる（Ｓ１３６）。これより後のテスト計画作成は、前の例とほとんど同じである。その段階で割り当てられていない仕様項目のテストのうち、最もテスト優先度の高いものを選択し(Ｓ１３７)、途中段階の作業計画から、割り当て可能なテスト担当者について（Ｓ１３８）、その仕様項目の不具合検出工数予測値をテスト担当者の能力比で割った値を、その仕様項目テスト期間として割り当てる（Ｓ１３９）。上記の手順をすべての仕様項目に対して行う（Ｓ１４０）。以上のようにして、テスト計画を作成することが可能となる。
【００３０】
第三の実施形態として、不具合修正が頻繁に行われる開発形態でのリグレッションテストとして利用する例を示す。リグレッションテストとは、同じテストケースを、一定量の不具合が修正されるたびに繰り返し行うテストのことである。このテストは、不具合修正によってシステムに悪影響が出ていないかを調べるために実施される。
【００３１】
ここでは、優先度の高いものだけを集めた重要仕様項目リストと通常の全仕様項目リストの両方を用意して、二つの仕様項目リストのテストを交互に繰り返し実行するような、リグレッションテストの応用となるテスト計画作成アルゴリズムを説明する。このアルゴリズムを利用することにより、テスト優先度の高い仕様項目については、テスト優先度の低い仕様項目と比較してより多くの回数テストされ、より多くの不具合検出工数を割り当てることができる。重要仕様項目に対するテストと通常の全仕様項目に対するテストを組み合わせて利用することで、テスト効率とテスト十分性をさらに高めることができる。
【００３２】
図１１にこの例の手順を示す。まず、すべての仕様項目を集合Ｕｔにセットする（Ｓ１４１）。次にＵｔに属する仕様項目をテスト優先度値の大きいものから順に並べた配列Ａ（Ｕｔ）を作成する（Ｓ１４２）。次に、集合Ｕｔに属する全仕様項目に関する不具合検出工数の予測値の総和を計算してＣｐ（Ｔ）とする（Ｓ１４３）。重要仕様項目として選択したい項目の比率ｘ（０≦ｘ≦１）を決定する（Ｓ１４４）。配列Ａ（Ｕｔ）の先頭の仕様項目から順番に一つずつ取り出して集合Ｕｘに加え、Ｕｘに属する仕様項目に関する不具合検出工数の予測値の和Ｃｐ（ｘ）を計算する（Ｓ１４５）。ここで、Ｃｐ（ｘ）≦ｘ＊Ｃｐ（Ｔ）ならば（Ｓ１４６）、配列Ａ（Ｕｔ）から次の仕様項目を取り出して集合Ｕｘに加えて同様にＣｐ（ｘ）を計算する（Ｓ１４５）。もしＣｐ（ｘ）＞ｘ＊Ｃｐ（Ｔ）となれば（Ｓ１４６）、最後に加えた項目はＵｘから削除する（Ｓ１４７）。こうして求めた部分集合Ｕｘに対し、前述の第一、第二の実施形態に挙げたような任意のアルゴリズムを用いてテスト計画Ｐｘを立てる（Ｓ１４８）。次に仕様項目全体の集合Ｕｔに対して、同様に任意のアルゴリズムを用いてテスト計画Ｐｔを立てる（Ｓ１４９）。これらのテスト計画ＰｘとＰｔを任意に組み合わせることで、全体のテスト計画を作成する（Ｓ１５０）。全仕様項目のテスト計画Ｐｔの実行回数に対する重要仕様項目テスト計画Ｐｘの実行回数を増やすことで、テスト優先度の高い仕様項目により多くの不具合検出工数を割り当てることが可能になる。また、部分集合ＵｘをＵｔとみなし、再起的にこのアルゴリズムを適用して、さらに詳細なテスト計画を作成することも可能である。
【００３３】
＜テストの実行＞
こうして作成されたテスト計画と、公知の手段で設計されたテストケースによってテスト実行された結果は、テスト実行・結果出力部を利用してテスト結果として出力される。公知のテストケース設計手段としては、例えば特開２００１−１８４２３２のようにシステム仕様からテストケースを設計する手法を用いる。テスト実行・結果出力部における手順は後述する。
【００３４】
次に、システム仕様書などからシステムの特徴を表現し、そのシステムにとって適当なテスト戦略を選択する手段を提供して、重要な機能を優先的にテストできるテストケースの設計支援方法について説明する。
【００３５】
図１２は、かかる設計支援方法の全体の流れを、ブロック図を用いて示したものである。なお、ここには図１で示したテスト計画を設計する流れが併記されているが、ここでは該当部分に同じ符号を用いることにより説明を省略する。
【００３６】
図１２において３は仕様項目特性値設定部、５はテスト戦略作成部、７はテスト戦略選択部、９はテスト優先度導出部、１１はテスト戦略評価部、１６はテストケース設計部、１８はテスト実行・結果出力部、２１はテスト結果検証部である。
【００３７】
ここでは、まずテスト対象となるソフトウェアシステム製品のシステム仕様書から抽出された仕様項目リスト１と、ソフトウェアシステムの特徴を表現するために用意された評価観点データベース２をもとに、仕様項目特性値設定部３を利用して、そのソフトウェアシステムの特徴を表わす特性値つき仕様項目リスト４を作成する。
【００３８】
次に評価観点データベース２をもとにテスト戦略作成部５を利用して、どの評価観点にどれくらい重点をおいてテストするかを設定するためのテスト戦略を作成し、テスト戦略データベース６に登録する。
【００３９】
テスト戦略選択部７では、テスト戦略データベース６から任意のテスト戦略を選択してテスト優先度導出部９に出力する。テスト優先度導出部９では、与えられたテスト戦略と特性値つき仕様項目リスト４をもとに、どの仕様項目を優先的にテストするかを表わすテスト優先度つき仕様項目リスト１０が作成される。
【００４０】
テスト戦略評価部１１では、テスト優先度つき仕様項目リスト１０と過去の不具合データ１２を入力として、選択されたテスト戦略を適用して得られる不具合検出傾向をシミュレーションし、選択されたテスト戦略がテスト対象ソフトウェアシステムに適しているかどうかを判断する。必要ならば複数のテスト戦略を順次選択して不具合検出傾向をシミュレーションし、最適だと思われるテスト戦略およびテスト優先度つき仕様項目リストを、テストケース設計用に選択する。
【００４１】
次に、テストケース設計用に選択されたテスト優先度つき仕様項目リスト１０と、テストに利用される資源やスケジュールなどからなるテストリソース１３、過去に生成された類似テストケース１４、および不足分のテストケースの補充、過多なテストケースの削除をするためのテストケース設計手順１５をもとに、テストケース設計部１６を利用して、テスト対象ソフトウェアにとって最適なテストケース１７を作成する。このテストケース１７によりテスト実行された結果発見された不具合情報は、テスト実行・結果出力部１８を利用してテスト結果１９として出力される。通常のテストでは、開発・デバッグの進行に合わせてテストが繰り返し実行される。現在テスト対象となっているソフトウェアへのすべてのテスト結果は、現テスト対象の不具合データ２０に登録される。
【００４２】
テスト結果検証部２１では、現テスト対象の不具合データ２０と適用されたテスト優先度つき仕様項目リスト１０を入力として適用テスト戦略を再度検証し、テスト戦略評価部に記憶されている他のテスト戦略によるテスト優先度つき仕様項目リストとも比較して、必要ならば適用テスト戦略を入れ替えて再テストを実施する。このようにして、常に最適なテスト戦略を選択して、最も効果的なテストケースが生成されるようにする。
【００４３】
以下、上記した各部の機能について詳細に説明する。なお、各機能はソフトウェアによりコンピュータを用いて実現されるものであっても良い。
【００４４】
＜特性値つき仕様項目リストの作成＞
仕様項目特性値設定部３では、システム仕様書から抽出された仕様項目リスト１とシステムの特徴を表現するための評価観点データベース２を入力として、特性値つき仕様項目リスト４を作成する。様々な視点からシステムの特徴を表現するために、ソフトウェアシステムを構成している各仕様項目に対して、複数の評価観点に基づいて特性値を与えることができる。これにより、ソフトウェアシステムを複数の視点から仕様項目単位で評価することが可能となる。
【００４５】
一般にシステム仕様書には、ソフトウェアシステムで実現される機能が仕様項目として記述されている。これらの項目の一覧をリストとして抽出した仕様項目リスト１が仕様項目特性値設定部３の入力となる。一方、評価観点はシステムをいろいろな観点から評価してその特徴を表現するために用意されるもので、システム仕様書の内容や設計段階での開発情報などからシステム開発の早期に評価できるものが主として選ばれ、評価観点データベース２に蓄積される。評価観点として考えられる一例を図１３に示す。ここでは、評価観点をプログラムの品質等の分類ごとに整理して示している。
【００４６】
これらの仕様項目リスト１と評価観点データベース２を入力として仕様項目特性値設定部３に与え、各仕様項目に対して評価観点に基づいたパラメータを仕様項目特性値として指定することで、特性値つき仕様項目リスト３を生成する。その具体的な手順を図１４に示す。
【００４７】
まず、評価観点並びに仕様項目リストを読み込み（Ｓ１，Ｓ２）、設定する評価観点を一覧から選択する（Ｓ３）。続いて仕様項目リストから仕様項目を検索し（Ｓ４）、選択した評価観点で評価した特性値を検索した仕様項目に入力する（Ｓ５）。かかる操作を仕様項目の検索が終了するまで繰り返し行う（Ｓ６）。次に、入力された仕様項目特性値の正規化を行う（Ｓ７）。仕様項目特性値は一般に仕様項目間の比較による相対評価として与えられることが多い。そのため、各々の評価観点について特性値がすべての仕様項目に与えられた段階で、特性値が、例えば１から１０までの範囲に収まるように正規化を行い、評価観点間の基準をそろえる。こうして、必要となるすべての評価観点について特性値が仕様項目に与えられたかを確認し（Ｓ８）、特性値つき仕様項目リストが作成される（Ｓ９）。
【００４８】
特性値つき仕様項目リストの一例を図１５に示す。ここで、仕様項目は大項目と中項目とからなり、ここでは、「ファイル」と「編集」に関する各項目について、選択された「不具合致命度」「機能利用頻度」「複雑さ」の各評価観点について特性値が与えられている。
【００４９】
＜テスト戦略の作成＞
テスト戦略作成部５では、テストを実行する際にどの評価観点にどれだけ重点をおいたテストをするかを示すテスト戦略を作成する。テスト戦略とは、システムの特徴を表現するために仕様項目に与えられた複数の仕様項目特性値に対して、どの評価観点による特性値をどの程度重視したテストを行うかを表わしており、図１６のように各評価観点に対する重み付けとして表現される。より重視する評価観点ほど、設定される重みが大きくなる。例えば、致命度重視型のテスト戦略では、評価観点のうち「不具合致命度」に関する重みが最も高い０．７に設定され、「機能利用頻度」および「仕様の複雑さ」に関する重みはそれぞれ０．１５となっている。
【００５０】
テスト戦略を作成するテスト戦略作成部における手順を図１７に示す。まず、評価観点一覧の読み込みを行い（Ｓ１０）、テスト戦略を新規に作成する必要があるか否かの判断を行う（Ｓ１１）。ここで、テスト戦略を新たに作成しない場合は、テスト戦略データベースから編集したいテストデータを選択する（Ｓ１２）。テスト戦略作成部には、評価観点データベースから入力が与えられ、各評価観点に対する重みを設定することでテスト戦略を作成する。続いて、重みを設定する評価観点を一覧から選択し（Ｓ１３）、選択した評価観点に対して重みを設定する（Ｓ１４）。すべての評価観点に対して重みが設定されれば（Ｓ１５）、それらの合計が１になるように正規化する（Ｓ１６）。ここで、新たに作成されたテスト戦略若しくは編集されたテスト戦略は、テスト戦略データベースに登録される（Ｓ１７）。
【００５１】
＜テスト戦略の選択＞
テスト戦略選択部７では、テストを実行する際にどのようなテスト戦略に基づいてテストを行うかを決定する。
【００５２】
テスト戦略選択部７では、テスト戦略データベース６に登録されたテスト戦略の中から、テスト優先度導出部９に与えるテスト戦略８を選択して出力する。テスト戦略８を選択するテスト戦略選択部７における手順を図１８に示す。最初は任意のテスト戦略を選択するが（Ｓ２１）、テストサイクルの進行に伴い、テスト戦略評価部やテスト結果検証部からより最適なテスト戦略を選択するように指示が来るので（Ｓ２０）、その指示に基づいてテスト戦略をテスト戦略データベースから選択する。例えば、テスト戦略データベースからまだテスト優先度を導出していないテスト戦略を選択する（Ｓ２２）。指示に適したテスト戦略がデータベースに存在するか否かを確認し（Ｓ２３）、無い場合には、テスト戦略作成部でテスト戦略を作成してデータベースに登録した後、そのテスト戦略を選択する（Ｓ２４）。そして選択されたテスト戦略は出力するようにしても良い（Ｓ２５）。
【００５３】
＜テスト優先度つき仕様項目リストの作成＞
テスト優先度導出部９では、選択されたテスト戦略８を適用することでソフトウェアシステムのどの部分を特に重点的にテストする必要があるかを、仕様項目単位に評価した指標であるテスト優先度を導出する。ここで作成されるテスト優先度つき仕様項目リスト１０は、特性値つき仕様項目リスト４とテスト戦略８をもとにテスト優先度導出部９にて生成されるもので、図２０に示すように仕様項目リストの各項目に対してテスト優先度という値が与えられたものである。
【００５４】
テスト優先度とは、その値が大きいほどテストの実行順序やテストの量などに関して優先的・重点的にテストを実施することを表わす指標である。テスト優先度導出部９では、各仕様項目に与えられた評価観点ごとの特性値と、テスト戦略として設定された各評価観点への重みづけから、その仕様項目に対するテスト優先度を算出する。その具体的な手順を図１９に示す。まず、テスト戦略と特性値つき仕様項目リストが読み込まれる（Ｓ３１，Ｓ３２）。続いて、仕様項目リストから順次項目を検索し（Ｓ３３）、テスト戦略で設定された各評価観点への重みづけと、特性値つき仕様項目リストの各仕様項目に与えられた特性値とから、その項目のテスト優先度を算出する（Ｓ３４）。かかる優先度の算出は、仕様項目の検索が終了するまで繰り返し行われる（Ｓ３５）。一般にテスト優先度は、各仕様項目ｉに対してｎ個の評価観点に基づいた仕様項目特性値
【００５５】
【数１】

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

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

【００６０】
ただしテスト優先度を導出する計算式は、仕様項目特性値と各評価観点への重みとを組み合わせたものであれば異なる計算式を用いてもよい。こうして得られたテスト優先度を各仕様項目に持たせて、図２０に示すようなテスト優先度つき仕様項目リストを作成する（Ｓ３６）。
【００６１】
＜適用テスト戦略の評価＞
テスト戦略評価部１１では、適用されたテスト戦略によって各仕様項目に与えられたテスト優先度に基づいたテストが、ソフトウェアシステムに対してどれだけ有効なのか、テストの目的に合致しているのかどうかを評価する。また評価結果はすべて記憶しておき、複数のテスト戦略から最適なものを選択するために比較・検討することができる。新規のシステム開発においてはこのフェーズは実行できないが、過去に類似のシステム仕様構成をもつソフトウェアシステムの開発情報があれば、これを利用して適用テスト戦略の評価が可能となる。
【００６２】
テスト戦略評価部１１では、テスト優先度つき仕様項目リスト１０と過去の不具合データ１２が入力として与えられ、過去の不具合データ１２と比較して適用したテスト戦略がテスト対象ソフトウェアシステムに対して適当かどうかを評価する。過去の不具合データ１２には、図２２に示すようにシステムをバージョンアップする前の開発情報などの、類似のシステム仕様構成を持つソフトウェアシステム開発プロジェクトの不具合情報が蓄積され、各仕様項目にどれだけの不具合が存在していたかを示すデータが含まれている。なお図２２中の不具合数で「＊」が記入されている仕様項目は、その開発バージョンではまだ実装されていなかったことを示している。
【００６３】
テスト戦略評価部における手順を図２１に示す。まず、テスト優先度つき仕様項目リストを読み込み（Ｓ４１）、過去の不具合データが存在するかを確認して（Ｓ４２）、存在する場合は入力されたテスト優先度つき仕様項目リストを、過去の不具合データと比較して不具合が多く存在しそうな項目がどの程度テスト優先度の上位に位置しているかをシミュレーションする。具体的には、テスト優先度つき使用項目リストと過去の不具合データから不具合検出傾向を予測し（Ｓ４３）、この予測した不具合検出傾向をテスト優先度つき仕様項目及びそのテスト戦略と対応付けて記憶し（Ｓ４４）、記憶されている不具合検出傾向一覧を比較して、最適なテスト優先度つき仕様項目リストを選択する（Ｓ４５）。別のテスト戦略についてもシミュレーションを実行したければ（Ｓ４６）、テスト戦略データベースから別のテスト戦略を選択するように、テスト戦略選択部に指示を出す。こうして選択された新たなテスト戦略からテスト優先度導出部にてテスト優先度つき仕様項目リストを導出し（Ｓ４７）、過去の不具合データと比較して同様に評価する。この手順を繰り返して記憶したテスト戦略評価の一覧を比較し、実際のテストケース設計に適用するテスト戦略をひとつ選択し、テストケース設計部に出力する（Ｓ４８）。
【００６４】
＜テストケース設計＞
テストケース設計部１６では、適用されたテスト戦略８によって導出したテスト優先度に基づいて、各仕様項目に対してどのくらい重点的にテストを実行するかを決定し、テストケースを設計する。
【００６５】
テストケース設計部１６では、テスト優先度つき仕様項目リスト１０と共に、テストリソース１３、過去の類似テストケース１４、テストケース設計手段１５が入力として与えられる。テストケース設計部１６における手順を図２４に示す。まず、テスト優先度つき仕様項目リストの読み込みが行われる（Ｓ５１）。次に、テストに利用される資源やスケジュールなどを表わすテストリソースを読み込み（Ｓ５２）、各仕様項目に与えられたテスト優先度に応じて仕様項目ごとに配分する（Ｓ５３）。テストリソースの例を図２３に挙げる。テストリソースとしては、「担当」「期間」「資源」等の分類にしたがって、必要なリソースが定義されている。
【００６６】
各仕様項目のテスト優先度と配分されたテストリソースに応じて、仕様項目ごとに必要十分なテストケース量を予測する。次に、類似のシステム仕様に対して過去に生成されたテストケースがあれば、それを読み込み（Ｓ５４）、仕様項目をリストから順次検索して（Ｓ３５）、その情報を利用してテストケースを設計する（Ｓ５６）。各仕様項目のテストケース量を検討し（Ｓ５７）、過去の類似テストケースが全く存在しないか、あるいは予測したテストケース量に比べてテストケースが不足していれば、その不足分を補充するために公知のテストケース設計手段を用いて不足分のテストケースを作成する（Ｓ５８）。公知のテストケース設計手段としては、特開２００１−１８４２３２のようにシステム仕様からテストケースを設計する手法を用いる。逆に予測したテストケース量に比べてテストケースが過多であるような場合には、テストケースを削減して適当な量にする（Ｓ５９）。こうして、全ての仕様項目について検索が終了すると（Ｓ６０）、テスト対象にとって最適なテストケースが生成される（Ｓ６１）。
【００６７】
＜テスト結果の再利用＞
こうして設計されたテストケースによりテスト実行された結果は、テスト実行・結果出力部１８を利用してテスト結果１９として出力される。テスト実行・結果出力部１８における手順を図２５に示す。テスト実行・結果出力部では、テストケースを読込み（Ｓ６５）、読込まれたテストケースに基づいてテストを実行し（Ｓ６６）、その結果発見された不具合とその重要度を、システムの各仕様項目と対応づけて記録する（Ｓ６７）。こうして各仕様項目に関係する不具合数および重要度を集計し、テスト結果として出力する（Ｓ６８）。出力されるテスト結果の例を図２６に示す。また、テストはソフトウェアの開発・デバッグを通じて繰り返し行われ、各テストサイクルでテスト結果が出力される。現テスト対象に対して行われる各テストサイクルのすべてのテスト結果は、何回目のテストサイクルで得られたテスト結果であるかとあわせて、現テスト対象の不具合データとして保存される。
【００６８】
テスト結果検証部２１では、現テスト対象の不具合データ２０と適用されたテスト優先度つき仕様項目リスト１０を入力として、適用テスト戦略が適当であったかどうかを検証する。テスト結果検証部２１における手順を図２７に示す。まず、テストケース設計に適用したテスト優先度つき仕様項目リストとテスト戦略部で記憶した不具合検出傾向予測を読込む（Ｓ７１，Ｓ７２）。入力される現テスト対象の不具合データには、何回目のテストサイクルで見つかった不具合なのか、またその不具合の重要度がどの程度であるかが、仕様項目ごとに記録されている。テスト結果検証部では、この不具合データとテスト優先度つき仕様項目リストを比較して（Ｓ７３）、適用テスト戦略で期待された通りの効果が得られているかどうかを検証する（Ｓ７４）。検証の結果、期待通りの効果が得られており、かつまだ不具合が収束していなければ（Ｓ７５）、再テストを同じテスト戦略を用いて再度実行して（Ｓ７６）、適用中のテスト優先度つき仕様項目リストを再出力する（Ｓ７７）。一方、期待通りの効果が得られていないか、効果は得られているが既に不具合が収束しているようならば（Ｓ７４，Ｓ７５）、別のテスト戦略を新たに選択することを決定し、テスト戦略選択部に指示を出す（Ｓ７８）。そして、適当なテスト優先度つき仕様項目リストが存在する場合は（Ｓ７９）、現テスト対象の不具合データから不具合検出傾向を検証し、より最適なテスト戦略を選択する（Ｓ８０）。一方、適当なテスト優先度つき仕様項目リストが存在しない場合は（Ｓ７９）、テスト戦略選択部において新たにテスト戦略を選択し、テスト優先度につき仕様項目リストを導出して、テスト戦略評価部で評価・記憶を行う（Ｓ８１）。なお、選択された最適なテスト戦略は別のテスト戦略と比較しても良く（Ｓ８２）、最終的に選択されたテスト優先度つき仕様項目リストが出力される（Ｓ８３）。
【００６９】
このようにテストサイクルを通して常に最適なテスト戦略を選択し、最も効果的なテストケースが生成されるようにする。
【００７０】
また現テスト対象の不具合データは過去の不具合データにも現バージョンでの不具合情報として登録され、次バージョンのテスト戦略評価の際に不具合データとして利用されることになる。
【００７１】
【発明の効果】
以上説明したように、本発明は、各モジュールの品質に関わる情報を設定し利用して、モジュールごとの不具合検出工数を予測し、モジュールとシステム仕様書から抽出された仕様項目との対応情報から、仕様項目ごとの不具合検出工数を予測することが可能となった。その結果、優先的にテストすべき仕様項目を示すテスト優先度、仕様項目不具合検出工数、および利用可能なテストリソースから、効率的なソフトウェアテストを実現するためのテスト計画を作成することが可能となっている。
【図面の簡単な説明】
【図１】本発明（テスト計画作成支援方法）の全体の流れを示すブロック図。
【図２】品質情報の一例を示す図。
【図３】品質情報を設定する過程を示すフローチャート。
【図４】モジュール不具合検出工数を予測する過程を示すフローチャート。
【図５】仕様項目とモジュールとの対応関係として設定する情報の一例を示す図。
【図６】仕様項目とモジュールとの対応関係情報を設定する過程を示すフローチャート。
【図７】仕様項目の不具合検出工数を予測する過程を示すフローチャート。
【図８】テスト計画の作成過程での一例を示す図。
【図９】テスト計画を作成する第一の例の過程を示すフローチャート。
【図１０】テスト計画を作成する第二の例の過程を示すフローチャート。
【図１１】テスト計画を作成する第三の例の過程を示すフローチャート。
【図１２】本発明の全体の流れを示すブロック図。
【図１３】評価観点の一例を示す図。
【図１４】特性値つき仕様項目リストを作成する過程を示すフローチャート。
【図１５】図１４で生成される特性値つき仕様項目リストの一例を示す図。
【図１６】テスト戦略の一例を示す図。
【図１７】テスト戦略を作成する過程を示すフローチャート。
【図１８】テスト戦略を選択する過程を示すフローチャート。
【図１９】特性値つき仕様項目リストとテスト戦略からテスト優先度つき仕様項目リストを作成する過程を示すフローチャート。
【図２０】図１９で作成されるテスト優先度つき仕様項目リストの一例を示す図。
【図２１】選択されたテスト戦略から作成されたテスト優先度つき仕様項目リストを、過去の不具合データを用いて評価する過程を示すフローチャート。
【図２２】図２１で利用する過去の不具合データの一例を示す図。
【図２３】テストリソースの一例を示す図。
【図２４】図１９で作成されるテスト優先度つき仕様項目リストとテストリソース、過去の類似テストケースおよび公知のテストケース設計手段から、テストケースを設計する過程を示すフローチャート。
【図２５】図２４で設計されたテストケースを用いてテスト実行した結果、発見された不具合をテスト結果として作成する過程を示すフローチャート。
【図２６】図２５で作成されるテスト結果の一例を示す図。
【図２７】図２６で作成されるテスト結果を利用してテスト戦略を再度検証する過程を示すフローチャート。
【符号の説明】
１システム仕様書仕様項目
２評価観点データベース
３仕様項目特性値設定部
４特性値つき仕様項目リスト
５テスト戦略作成部
６テスト戦略データベース
７テスト戦略選択部
８テスト戦略
９テスト優先度導出部
１０テスト優先度付き仕様項目リスト
１１テスト戦略評価部
１２過去の不具合データ
１３テストリソース
１４過去の類似テストケース
１５テストケース設計手段
１６テストケース設計部
１７テストケース
１８テスト実行・結果出力部
１９テスト結果
２０現テスト対象の不具合データ
２１テスト結果検証部
２２モジュール・仕様項目対応関係設定部
２３モジュール・仕様項目対応関係情報
２４モジュール品質情報設定部
２５モジュール品質情報
２６モジュール不具合検出工数予測部
２７モジュール不具合検出工数
２８仕様項目不具合検出工数予測部
２９仕様項目不具合検出工数
３０テスト計画作成部
３１テスト計画
３２モジュールリスト[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a test technique and a verification technique for improving the reliability of a software system, and relates to a method and a program for supporting the creation of a test plan for efficiently performing these tests and verifications.
[0002]
[Prior art]
Conventionally, software testing techniques have been widely used to guarantee the reliability of software systems. In software test technology, what test cases are used in what test plan for the software to be tested is important. The quality and efficiency of tests vary greatly depending on the quality of test cases and test plans.
[0003]
The test case needs to be designed to exhaustively test the functions of the target software, but recent software systems are becoming larger and more complex, and in order to test all functions exhaustively, It is necessary to digest enormous test cases using enormous man-hours. On the other hand, there is a limit to the development period for software system development, so it is almost impossible to implement everything within a limited time. Therefore, it is possible to design a necessary and sufficient amount of efficient test cases by giving priority to the parts to be tested according to criteria such as reliability and importance, and changing the degree of detail of test cases according to the priority. It has become necessary. On the other hand, the inventors express the characteristics of the system from the system specifications, etc., provide a means for selecting an appropriate test strategy for the system, and test cases that can test important functions with priority. A design support method is proposed (Japanese Patent Application No. 2001-290380).
[0004]
On the other hand, test execution requires a test plan along with test cases. The test plan specifically defines who, what test case, when and how much man-hours to perform. Even if the same test case is used, the effectiveness of the test differs depending on the metrics related to the test work such as the competence of the engineer in charge of the test and the man-hours required to actually detect the defect in the test. Therefore, as in the test case creation, in creating a test plan, it is difficult to realize an efficient test unless the criteria for determining which metric is important is intentionally set as a test strategy.
[0005]
In the prior art, a test plan was not created by paying attention to metrics related to test work, but such a test plan creation method is required to realize a more efficient test.
[0006]
[Problems to be solved by the invention]
In this way, in the conventional technology, the test priority that expresses the characteristics of the system from the system specifications, etc., selects an appropriate test strategy for the system, and determines whether the function is important for quality or not. However, the test plan for efficiently executing the test case was not created by paying attention to the metrics related to the test work.
[0007]
Therefore, in the present invention, the test cases designed to be tested preferentially are analyzed by analyzing factors such as the quality metrics of the program measured for each module and the technical capabilities of the developed programmer. The present invention provides a method and a program for predicting whether a failure is likely to occur and determining how many resources should be allocated to which test as a test plan.
[0008]
[Means for Solving the Problems]
In order to solve the above problems, in the present invention, a module quality information setting step for setting quality information for each program module of a software system, and a module defect detection man-hour prediction for predicting a defect detection man-hour of the program module from the quality information A module / specification item correspondence setting step for creating a module / specification item correspondence relationship information indicating a correspondence relationship between the module and a specification item extracted from the specification of the software system, and the defect detection man-hours and the step Specification item failure detection man-hour prediction process for predicting specification item failure detection man-hours from module / specification item correspondence information, and allocation of test resources available for testing the software system based on the specification item failure detection man-hours Test to create a test plan Providing test planning support method characterized by comprising the image forming process.
[0009]
In the present invention, a module quality information setting function for setting quality information for each program module of the software system, a module defect detection man-hour prediction function for predicting a defect detection man-hour of the program module from the quality information, and the module Module / specification item correspondence setting function for creating a module / specification item correspondence information indicating a correspondence relationship with the specification item extracted from the specification of the software system, the defect detection man-hour and the module / specification item correspondence Create a test plan that allocates test resources that can be used to test the software system based on the specification item defect detection man-hour prediction function that predicts specification item defect detection man-hours from information and the specification item defect detection man-hours Test plan creation function Be realized to a computer to provide a test plan creation support program characterized.
[0010]
According to the present invention described above, information related to the quality of each module is set and used to predict the defect detection man-hour for each module, and the defect detection man-hour for each specification item is predicted from the module / specification item correspondence information. It became possible. As a result, it has become possible to create a test plan for realizing an efficient software test from the test priority for each specification item, the prediction of defect detection man-hours, and the available test resources.
[0011]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
[0012]
FIG. 1 shows the overall flow of the present invention using a block diagram. In this figure, 22 is a module / specification item correspondence setting unit, 24 is a module quality information setting unit, 26 is a module defect detection man-hour prediction unit, 28 is a specification item defect detection man-hour prediction unit, 30 is a test plan creation unit, 16 Is a test case design unit, and 18 is a test execution / result output unit.
[0013]
In the present invention, based on the module list 32 of the software system product to be tested, the module quality information setting unit 24 is used to set quality information for each module. 26 is used to predict the module failure detection man-hour 27. Further, the module / specification item correspondence information 23 is created using the specification item list 1 extracted from the system specification and the module / specification item correspondence setting unit 22. The specification item defect detection man-hour 29 is predicted from the module defect detection man-hour 27 and the module / specification item correspondence information 23 by using the specification item defect detection man-hour prediction unit 28. A test resource 13 including resources and schedules used for testing, a specification item list with test priority 10 indicating which specification items are preferentially tested, a test item creation unit 30 based on specification item defect detection man-hours 29 Is used to create a test plan 31 that enables efficient software testing.
[0014]
Next, by using the specification item list with test priority 10, the test resource 13, and the test case design unit 16, a test case 17 optimum for the software to be tested is created. The defect information discovered as a result of the test execution based on the test case 17 and the test plan 31 is output as the test result 19 using the test execution / result output unit 18. The present invention mainly supports the creation of a test plan, and the test execution / result output unit may not be provided. In addition, the information on the specification item list with test priority may not be used when creating a test plan.
[0015]
Hereinafter, the function of each unit described above will be described in detail. Each function may be realized by software using a computer.
[0016]
<Setting module quality information>
In the present invention, quality information (module quality information) is set for each program module constituting the software. Using the set quality information, the defect detection man-hour is predicted later.
[0017]
First, an example of the set quality information is shown in FIG. As shown in FIG. 2, the quality information is roughly divided into characteristics relating to the development process and characteristics relating to the source code of the developed module. Features related to the development process are mainly subjectively set, while features related to the source code are measurable mechanically. Note that the test plan can be created at a stage that is very close to the test execution, so that the source code can be used.
[0018]
An example of a specific procedure for setting module quality information is shown in FIG. First, one piece of quality information to be set is selected (S81). It is judged whether or not it is quality information relating to the development process (S82). If so, the development process is investigated (S83), and the result is evaluated subjectively or objectively. A score of −10 is given (S84). If there is other module quality information to be evaluated, the process returns to S81 and the operation is repeated (S85). On the other hand, when the selected quality information is quality information related to the module source code (S86), the characteristic value or metric of the source code corresponding to the quality information is measured using a tool or manually (S87). ). Further, a score of 1-10 is given based on the measurement result (S88). If there is other quality information to be evaluated, the process returns to S81 and the operation is repeated.
[0019]
<Prediction of module failure detection man-hours>
For each module, it is predicted how many defects are detected from the module and how much the detection man-hours will be in the module. Various procedures are conceivable as to how the module detection man-hour is predicted. Here, the most basic procedure will be described with reference to FIG. First, one module for predicting the defect detection man-hour is selected (S91). Subsequently, quality information effective for predicting the number of defects is selected (S92), and the number of defects for the unit scale of the source code is predicted therefrom (S93). Further, quality information effective for prediction of the defect detection man-hour is selected (S94), and the detection man-hour per defect is predicted from them (S95). Finally, the total defect detection man-hour is calculated by taking the product of them (S96). If a module with an unknown defect detection man-hour remains, the process returns to S91 and the operation is repeated (S97).
[0020]
An example of failure detection man-hour prediction will be described below using a part of the above-described example of quality information (see FIG. 2). First, the source scale and the skill of the person in charge are used as quality information effective in predicting the number of defects. If the skill of the person in charge is grasped, it is possible to predict how many defects are included per 1000 lines in the program created by the programmer at that level. For example, for a module handled by a programmer who has little program experience, the total number of defects of the module is predicted from the source scale assuming five defects per 1000 lines. Using this information, it is predicted how many defects are included in total. Next, the complexity of the source code is used as quality information effective for predicting the defect detection man-hours. If the source code is complex, the execution path of the source code is also diverse, and more man-hours are required to detect a defect existing in a specific path. Set a normal detection man-hour and adjust it according to the complexity. For example, for a module having a certain level of complexity, the number of defect detection man-hours per unit is 1.5 times the normal. By taking the product of this detected man-hour and the predicted number of defects, the total number of detected defects can be predicted.
[0021]
<Setting module / specification item correspondence information>
In general, in a system specification, functions realized by a software system are described as specification items. A specification item list (details will be described later) obtained by extracting the list of these items as a list and information on the correspondence relationship between the modules used for realizing the specification items are set. This information will be required later to predict the defect detection man-hours for each specification item. Information to be set is as shown in FIG. In realizing each specification item, it is set which module is used and the degree of contribution. The actual procedure is also performed by filling the table as shown in the figure. The basic procedure is as shown in FIG. One specification item is selected (S101), modules used to realize the specification item are identified (S102), and the degree of contribution of each module to the specification item is set as a ratio (percent). (S103). The above procedure is repeated for all the specification items (S104).
[0022]
<Prediction of specification item defect detection man-hours>
The specification item failure detection man-hour is predicted for each specification item from the module / specification item correspondence information and the failure detection man-hour prediction for each module. An example of a basic procedure is as shown in FIG. For one module (S111), the ratio of the degree of contribution of each module to each specification item is calculated (S112). For each specification item contributed by the module, the predicted value of the defect detection man-hour is distributed at the ratio determined in (S112) (S113). This distribution is repeated for all modules (S114). Next, one specification item is selected (S115), and a total of the distribution values of defect detection man-hours from each module to this specification item is taken as a defect detection man-hour predicted value of this specification item (S116). This procedure is repeated for all the specification items (S117). As shown in the figure, the failure detection man-hours for each specification item are predicted.
[0023]
For example, it is assumed that the trouble detection man-hour of a certain module is 2 man-days and contributes to two specification items. At this time, if the contribution rate to each specification item is 40% and 60%, respectively, the contribution ratio is 2: 3, and the distribution of defect detection man-hours to each is 0.8 man-days, 1 It will be 2 man-days.
[0024]
<Create test plan>
A test plan is created from test resources representing the resources and schedule used for testing, a specification item list with test priority, and predicted specification item defect detection man-hours.
[0025]
As the test resources, necessary resources are defined according to the classifications such as “charge”, “period”, and “resource” (details will be described later). In the specification item list with test priority, a value called test priority is given to each item in the specification item list (details will be described later). The test priority is an index that indicates that the test is performed with priority and priority with respect to the test execution order, the amount of tests, and the like as the value increases. In addition, the test plan defines for each person in charge of the test who performs a test for which specification item at which timing and how much trouble detection man-hours. That is, the test plan is to determine the allocation of test resources based on the predicted value of the specification item defect detection man-hour. The test plan can be expressed as a line table as shown in FIG.
[0026]
Here, FIG. 9 shows a very basic procedure for creating a test plan. Assume that the test resources, the number of testers, and the capabilities of each person are given as test resources. In this example, the ability of the tester is expressed as a relative ratio of defect detection man-hours that can be processed per unit time with reference to the ability of the person in charge as a reference (1.0). Therefore, an engineer who is 20% more capable than the standard one is capable of testing 1.2 times as many man-hours at the same time. Among the tests of the specification items that are not assigned at that stage, the test with the highest test priority is selected (S121), the assignable tester is selected from the work plan at the intermediate stage (S122), and the specification is selected. A value obtained by dividing the defect detection man-hour predicted value of the item by the ability ratio of the person in charge of the test is assigned as the specification item test period (S123). The above procedure is performed for all the specification items (S124). As described above, a test plan can be created. Further, taking the situation of FIG. 8 as an example, the specification item to be assigned next is Case 2, the defect detection man-hour is 2.4, the assignable person in charge is B, and the ability is 1.2. In this case, 2.4 / 1.2 = 2 days are assigned to the person in charge B.
[0027]
As mentioned above, this procedure is a very basic and simple example. Basically for those with high test priorities, which changes the ability ratio of the person in charge for each specification item depending on the pros and cons of the person in charge of the test person, and selects the person with the highest ability when selecting the person in charge Various test items such as test cases for spec items that collect only high-priority items and test cases for all normal spec items are repeatedly tested alternately. Can be devised.
[0028]
Therefore, as a second embodiment, an algorithm for creating a test plan using spare man-hours will be described. In this method, the man-hours that can be used for the test are distinguished in advance as a basic defect detection man-hour (basic man-hour) and a spare defect detection man-hour (preliminary man-hour). The sum of the basic man-hour and the spare man-hour becomes the total defect detection man-hour that can be used for the test. The algorithm is such that the basic man-hour is allocated based on the predicted specification item defect detecting man-hours, and the spare defect detecting man-hour is distributed based on the test priority. By using this algorithm, it is possible not only to put the test order first, but also to allocate more defect detection man-hours for the specification items with high test priority. The sufficiency of can be further increased.
[0029]
FIG. 10 shows the procedure of this example. First, the sum of the predicted values of defect detection man-hours for all the specification items is taken as Cp (T) (S131). Next, the available man-hours are divided into a basic man-hour C (B) and a spare man-hour C (P) so that C (B) ≦ Cp (T) (S132). Of these, the spare man-hour is distributed based on the test priority. First, the basic man-hours are distributed based on the size of the trouble-detecting man-hours. If C (B) = Cp (T) (S133), it is possible to distribute the defect detection man-hours to each specification item, so the defect detection man-hours for each specification item (i) is C (i) = Cp ( i) (S134). However, Cp (i) is a failure detection man-hour predicted value of the specification item (i). In the case of C (B) <Cp (T), the defect detection man-hour cannot be allocated to all the specification items, so the basic man-hour is distributed by the ratio of the defect detection man-hour predicted value, and C (i) = C ( B) * Cp (i) / Cp (T) (S135). C (i) at this time is obtained by distributing the basic man-hours, and thereafter, the preliminary man-hours are distributed. The preliminary man-hours are distributed based on the ratio of the test priority value P (i) of the test specification item to the sum P (T) of the test priority values. In the form of C (i) = C (i) + C (P) * P (i) / P (T), the preliminary man-hour distribution is added to the defect detection man-hour for each specification item. As a result, more man-hours can be assigned to the specification items having a high test priority (S136). Subsequent test planning is almost the same as the previous example. Among the tests of the specification items not assigned at that stage, the test with the highest test priority is selected (S137). From the work plan at the intermediate stage, the assignable test personnel (S138), A value obtained by dividing the failure detection man-hour predicted value by the ability ratio of the tester is assigned as the specification item test period (S139). The above procedure is performed for all the specification items (S140). As described above, a test plan can be created.
[0030]
As a third embodiment, an example of using as a regression test in a development mode in which defect correction is frequently performed will be described. A regression test is a test in which the same test case is repeated each time a certain amount of defects are corrected. This test is conducted to check if the system has been adversely affected by the defect correction.
[0031]
Here, application of the regression test that prepares both the important specification item list that collects only high priority items and the normal all specification item list, and repeatedly executes the tests of the two specification item lists alternately. The test plan creation algorithm will be described. By using this algorithm, a specification item with a high test priority is tested more times than a specification item with a low test priority, and more defect detection man-hours can be assigned. Test efficiency and test sufficiency can be further improved by using a test for important specification items in combination with a test for all normal specification items.
[0032]
FIG. 11 shows the procedure of this example. First, all the specification items are set in the set Ut (S141). Next, an array A (Ut) is created in which the specification items belonging to Ut are arranged in descending order of the test priority value (S142). Next, the sum of the predicted values of the defect detection man-hours related to all the specification items belonging to the set Ut is calculated as Cp (T) (S143). The ratio x (0 ≦ x ≦ 1) of items to be selected as important specification items is determined (S144). A sum Cp (x) of predicted values of defect detection man-hours related to the specification items belonging to Ux is calculated in addition to the set Ux one by one from the first specification item of the array A (Ut) (S145). If Cp (x) ≦ x * Cp (T) (S146), the next specification item is extracted from the array A (Ut) and added to the set Ux to calculate Cp (x) in the same manner (S145). . If Cp (x)> x * Cp (T) is satisfied (S146), the last added item is deleted from Ux (S147). With respect to the subset Ux thus obtained, a test plan Px is established using an arbitrary algorithm as described in the first and second embodiments (S148). Next, a test plan Pt is established for the set Ut of the entire specification items using an arbitrary algorithm in the same manner (S149). An overall test plan is created by arbitrarily combining these test plans Px and Pt (S150). By increasing the number of executions of the important specification item test plan Px with respect to the number of executions of the test plan Pt of all the specification items, it becomes possible to allocate more trouble detection man-hours to the specification items having a high test priority. It is also possible to consider the subset Ux as Ut and apply this algorithm recursively to create a more detailed test plan.
[0033]
<Test execution>
The test plan created in this way and the result of the test execution by the test case designed by a known means are output as test results using the test execution / result output unit. As a known test case design means, for example, a method for designing a test case from a system specification as in JP-A-2001-184232 is used. The procedure in the test execution / result output unit will be described later.
[0034]
Next, a test case design support method capable of expressing features of a system from a system specification and the like, providing a means for selecting an appropriate test strategy for the system, and preferentially testing important functions will be described.
[0035]
FIG. 12 shows the overall flow of the design support method using a block diagram. In addition, although the flow which designs the test plan shown in FIG. 1 is written together here, description is abbreviate | omitted by using the same code | symbol for a relevant part here.
[0036]
12, 3 is a specification item characteristic value setting unit, 5 is a test strategy creation unit, 7 is a test strategy selection unit, 9 is a test priority derivation unit, 11 is a test strategy evaluation unit, 16 is a test case design unit, and 18 is A test execution / result output unit 21 is a test result verification unit.
[0037]
Here, based on the specification item list 1 extracted from the system specification of the software system product to be tested and the evaluation viewpoint database 2 prepared for expressing the characteristics of the software system, the specification item characteristic value Using the setting unit 3, a specification item list 4 with characteristic values representing the characteristics of the software system is created.
[0038]
Next, using the test strategy creation unit 5 based on the evaluation viewpoint database 2, a test strategy for setting how much emphasis is placed on which evaluation viewpoint is created and registered in the test strategy database 6. .
[0039]
The test strategy selection unit 7 selects an arbitrary test strategy from the test strategy database 6 and outputs it to the test priority deriving unit 9. The test priority deriving unit 9 creates a specification item list with test priority 10 indicating which specification item is preferentially tested based on the given test strategy and the specification item list 4 with characteristic values. .
[0040]
The test strategy evaluation unit 11 uses the specification item list with test priority 10 and the past defect data 12 as inputs, simulates the defect detection tendency obtained by applying the selected test strategy, and the selected test strategy is tested. Determine whether it is suitable for the target software system. If necessary, a plurality of test strategies are sequentially selected to simulate a defect detection tendency, and a test strategy and a specification item list with test priority that are considered optimal are selected for test case design.
[0041]
Next, a specification item list 10 with test priority selected for test case design, a test resource 13 including resources and schedules used for the test, similar test cases 14 generated in the past, and a shortage Based on the test case design procedure 15 for replenishing test cases and deleting excessive test cases, a test case design unit 16 is used to create a test case 17 optimum for the test target software. The defect information discovered as a result of the test execution by the test case 17 is output as the test result 19 using the test execution / result output unit 18. In a normal test, the test is repeatedly executed as development / debugging progresses. All test results for the software currently being tested are registered in the defect data 20 for the current test.
[0042]
The test result verification unit 21 verifies the applied test strategy again by inputting the defect data 20 to be tested and the specification item list 10 with the applied test priority as input, and other test strategies stored in the test strategy evaluation unit. Compared with the specification item list with test priority according to, retest by replacing the applied test strategy if necessary. In this way, the optimal test strategy is always selected to generate the most effective test case.
[0043]
Hereinafter, the function of each unit described above will be described in detail. Each function may be realized by software using a computer.
[0044]
<Creation of specification item list with characteristic values>
The specification item characteristic value setting unit 3 receives the specification item list 1 extracted from the system specification and the evaluation viewpoint database 2 for expressing the features of the system, and creates a specification item list 4 with characteristic values. In order to express the features of the system from various viewpoints, characteristic values can be given to each specification item constituting the software system based on a plurality of evaluation viewpoints. This makes it possible to evaluate the software system in units of specification items from a plurality of viewpoints.
[0045]
In general, in a system specification, functions realized by a software system are described as specification items. A specification item list 1 obtained by extracting a list of these items as a list is input to the specification item characteristic value setting unit 3. On the other hand, the evaluation viewpoint is prepared to evaluate the system from various viewpoints and express its characteristics. There are things that can be evaluated at an early stage of system development from the contents of the system specifications and development information at the design stage. Mainly selected and stored in the evaluation viewpoint database 2. An example considered as an evaluation viewpoint is shown in FIG. Here, the evaluation viewpoints are shown organized by classification such as program quality.
[0046]
The specification item list 1 and the evaluation viewpoint database 2 are input to the specification item characteristic value setting unit 3, and a parameter based on the evaluation viewpoint is designated as the specification item characteristic value for each specification item. A specification item list 3 is generated. The specific procedure is shown in FIG.
[0047]
First, the evaluation viewpoint and the specification item list are read (S1, S2), and the evaluation viewpoint to be set is selected from the list (S3). Subsequently, the specification item is searched from the specification item list (S4), and the characteristic value evaluated from the selected evaluation viewpoint is input to the searched specification item (S5). This operation is repeated until the specification item search is completed (S6). Next, the input specification item characteristic value is normalized (S7). In general, specification item characteristic values are often given as relative evaluations by comparison between specification items. Therefore, at the stage where the characteristic values are given to all the specification items for each evaluation viewpoint, normalization is performed so that the characteristic values fall within a range of, for example, 1 to 10, and the standards between the evaluation viewpoints are aligned. In this way, it is confirmed whether or not the characteristic values are given to the specification items for all necessary evaluation viewpoints (S8), and a specification item list with characteristic values is created (S9).
[0048]
An example of the specification item list with characteristic values is shown in FIG. Here, the specification items consist of large items and medium items. Here, for each item related to "File" and "Edit", each evaluation of the selected "Failure criticality", "Function usage frequency" and "Complexity" A characteristic value is given for the viewpoint.
[0049]
<Create test strategy>
The test strategy creation unit 5 creates a test strategy that indicates how much emphasis is placed on which evaluation viewpoint when executing a test. The test strategy represents the degree of emphasis placed on the characteristic value from which evaluation viewpoint to the characteristic value of multiple specification items given to the specification item in order to express the characteristics of the system. 16 is expressed as a weight for each evaluation viewpoint. The more weighted evaluation viewpoint is, the larger the set weight is. For example, in the criticality-oriented test strategy, the highest weight related to the “fault criticality” among the evaluation viewpoints is set to 0.7, and the weight related to the “functional usage frequency” and the “complexity of the specification” is set to 0. 0, respectively. It is 15.
[0050]
FIG. 17 shows a procedure in the test strategy creation unit for creating a test strategy. First, the evaluation viewpoint list is read (S10), and it is determined whether or not a new test strategy needs to be created (S11). Here, when a test strategy is not newly created, test data to be edited is selected from the test strategy database (S12). The test strategy creation unit receives input from the evaluation viewpoint database, and creates a test strategy by setting a weight for each evaluation viewpoint. Subsequently, an evaluation viewpoint for setting a weight is selected from the list (S13), and a weight is set for the selected evaluation viewpoint (S14). If weights are set for all evaluation viewpoints (S15), normalization is performed so that the sum of them is 1 (S16). Here, the newly created test strategy or the edited test strategy is registered in the test strategy database (S17).
[0051]
<Select test strategy>
The test strategy selection unit 7 determines what test strategy is used for the test when the test is executed.
[0052]
The test strategy selection unit 7 selects and outputs a test strategy 8 to be given to the test priority deriving unit 9 from the test strategies registered in the test strategy database 6. The procedure in the test strategy selection unit 7 for selecting the test strategy 8 is shown in FIG. At first, an arbitrary test strategy is selected (S21), but as the test cycle progresses, the test strategy evaluation unit and the test result verification unit give instructions to select a more optimal test strategy (S20). A test strategy is selected from the test strategy database based on the instructions. For example, a test strategy for which test priority has not yet been derived from the test strategy database is selected (S22). It is confirmed whether or not a test strategy suitable for the instruction exists in the database (S23). If there is no test strategy, the test strategy creation unit creates the test strategy and registers it in the database, and then selects the test strategy ( S24). The selected test strategy may be output (S25).
[0053]
<Create specification item list with test priority>
In the test priority deriving unit 9, the test priority, which is an index evaluated for each specification item, indicates which part of the software system needs to be particularly focused by applying the selected test strategy 8. To derive. The specification item list 10 with test priority created here is generated by the test priority deriving unit 9 based on the specification item list 4 with characteristic values and the test strategy 8, and as shown in FIG. A value called test priority is given to each item in the specification item list.
[0054]
The test priority is an index that indicates that the test is performed with priority and priority with respect to the test execution order, the amount of tests, and the like as the value increases. The test priority deriving unit 9 calculates the test priority for the specification item from the characteristic value for each evaluation viewpoint given to each specification item and the weighting to each evaluation viewpoint set as the test strategy. The specific procedure is shown in FIG. First, a test strategy and a specification item list with characteristic values are read (S31, S32). Subsequently, the items are sequentially searched from the specification item list (S33). From the weighting to each evaluation viewpoint set in the test strategy and the characteristic values given to the specification items in the specification item list with characteristic values, The test priority of the item is calculated (S34). Such priority calculation is repeated until the specification item search is completed (S35). Generally, the test priority is a specification item characteristic value based on n evaluation viewpoints for each specification item i.
[0055]
[Expression 1]

[0056]
Is given to each evaluation viewpoint by the test strategy.
[0057]
[Expression 2]

[0058]
Then, the test priority is expressed by the following formula (1).
[0059]
[Equation 3]

[0060]
However, the calculation formula for deriving the test priority may be a different calculation formula as long as the specification item characteristic value and the weight for each evaluation viewpoint are combined. A test item list with test priorities as shown in FIG. 20 is created by giving each test item the test priorities obtained in this way (S36).
[0061]
<Evaluation of application test strategy>
In the test strategy evaluation unit 11, how effective the test based on the test priority given to each specification item by the applied test strategy is valid for the software system, and whether it matches the purpose of the test. To evaluate. All evaluation results are memorized and can be compared and examined in order to select the most suitable test strategy. This phase cannot be executed in new system development, but if there is development information of a software system having a similar system specification configuration in the past, it is possible to evaluate an applied test strategy.
[0062]
In the test strategy evaluation unit 11, a specification item list with test priority 10 and past defect data 12 are given as inputs, and whether the test strategy applied in comparison with the past defect data 12 is appropriate for the software system to be tested. Evaluate whether. In the past defect data 12, as shown in FIG. 22, defect information of a software system development project having a similar system specification configuration, such as development information before upgrading the system, is accumulated. Data indicating whether or not there was a bug was included. Note that the specification item in which “*” is entered as the number of defects in FIG. 22 indicates that the development version has not been implemented yet.
[0063]
The procedure in the test strategy evaluation unit is shown in FIG. First, a specification item list with test priority is read (S41), and it is checked whether past defect data exists (S42). If it exists, the input specification item list with test priority is displayed as a past defect. Simulate how many items that are likely to have more defects than the data are positioned at the top of the test priority. Specifically, a defect detection tendency is predicted from the use item list with test priority and past defect data (S43), and the predicted defect detection tendency is stored in association with the specification item with test priority and its test strategy. Then, the stored defect detection tendency lists are compared, and the optimum specification item list with test priority is selected (S45). If another test strategy is to be simulated (S46), the test strategy selection unit is instructed to select another test strategy from the test strategy database. A test priority derivation list is derived from the new test strategy selected in this way by the test priority deriving unit (S47), and similarly compared with past defect data. The list of test strategy evaluations stored by repeating this procedure is compared, and one test strategy to be applied to the actual test case design is selected and output to the test case design unit (S48).
[0064]
<Test case design>
The test case design unit 16 determines how much the test is to be executed for each specification item based on the test priority derived by the applied test strategy 8 and designs the test case.
[0065]
In the test case design unit 16, a test resource 13, a past similar test case 14, and a test case design unit 15 are given as inputs together with the specification item list 10 with test priority. The procedure in the test case design unit 16 is shown in FIG. First, a specification item list with test priority is read (S51). Next, test resources representing resources and schedules used for the test are read (S52), and distributed to the specification items according to the test priority assigned to the specification items (S53). Examples of test resources are given in FIG. As test resources, necessary resources are defined according to the classifications such as “charge”, “period”, and “resource”.
[0066]
A necessary and sufficient amount of test cases is predicted for each specification item according to the test priority of each specification item and the allocated test resources. Next, if there is a test case generated in the past for a similar system specification, it is read (S54), the specification items are sequentially searched from the list (S35), and the test case is obtained using the information. Design (S56). The amount of test cases for each specification item is examined (S57), and if there are no past similar test cases or if there are insufficient test cases compared to the predicted test case amount, the shortage is replenished. A test case for the shortage is created using a known test case design means (S58). As a known test case design means, a method for designing a test case from a system specification as in JP-A-2001-184232 is used. Conversely, if there are too many test cases compared to the predicted test case amount, the test cases are reduced to an appropriate amount (S59). Thus, when the search is completed for all the specification items (S60), a test case optimal for the test target is generated (S61).
[0067]
<Reuse of test results>
The result of the test execution by the designed test case is output as the test result 19 using the test execution / result output unit 18. The procedure in the test execution / result output unit 18 is shown in FIG. The test execution / result output unit reads the test case (S65), executes the test based on the read test case (S66), and finds the defect found as a result and its importance as each specification item of the system. Corresponding recording is performed (S67). In this way, the number of faults and importance related to each specification item are totaled and output as a test result (S68). An example of the output test result is shown in FIG. The test is repeatedly performed through software development and debugging, and a test result is output in each test cycle. All the test results of each test cycle performed on the current test object are stored as defect data of the current test object together with the test results obtained in the number of test cycles.
[0068]
The test result verification unit 21 verifies whether or not the applied test strategy is appropriate, using the defect data 20 of the current test target and the applied specification item list 10 with test priority as inputs. The procedure in the test result verification unit 21 is shown in FIG. First, the specification item list with test priority applied to the test case design and the defect detection tendency prediction stored in the test strategy section are read (S71, S72). The entered defect data for the current test records for each specification item the number of test cycles and the degree of importance of the defect. The test result verification unit compares the defect data with the specification item list with test priority (S73), and verifies whether the effect as expected in the applied test strategy is obtained (S74). As a result of the verification, if the expected effect is obtained and the defect has not yet converged (S75), the retest is performed again using the same test strategy (S76), and the test priority being applied The specification item list is output again (S77). On the other hand, if the expected effect is not obtained or if the effect is obtained but the defect has already converged (S74, S75), it is decided to newly select another test strategy, An instruction is issued to the test strategy selection unit (S78). If there is a specification item list with appropriate test priority (S79), the failure detection tendency is verified from the failure data of the current test target, and a more optimal test strategy is selected (S80). On the other hand, when there is no specification item list with appropriate test priority (S79), a test strategy selection unit newly selects a test strategy, a specification item list is derived for the test priority, and the test strategy evaluation unit Evaluation and storage are performed (S81). The selected optimal test strategy may be compared with another test strategy (S82), and the finally selected specification item list with test priority is output (S83).
[0069]
In this way, the optimum test strategy is always selected throughout the test cycle so that the most effective test case is generated.
[0070]
The defect data for the current test is also registered as defect information in the current version in the past defect data, and is used as the defect data in the next version test strategy evaluation.
[0071]
【The invention's effect】
As described above, the present invention sets and uses information related to the quality of each module, predicts the defect detection man-hours for each module, and uses the correspondence information between the modules and the specification items extracted from the system specifications. This makes it possible to predict the number of trouble detection steps for each specification item. As a result, it is possible to create a test plan for realizing efficient software testing from the test priority indicating the specification items to be preferentially tested, specification item defect detection man-hours, and available test resources. It has become.
[Brief description of the drawings]
FIG. 1 is a block diagram showing the overall flow of the present invention (test plan creation support method).
FIG. 2 is a diagram showing an example of quality information.
FIG. 3 is a flowchart showing a process of setting quality information.
FIG. 4 is a flowchart showing a process of predicting module failure detection man-hours.
FIG. 5 is a diagram showing an example of information set as a correspondence relationship between a specification item and a module.
FIG. 6 is a flowchart showing a process of setting correspondence information between specification items and modules.
FIG. 7 is a flowchart showing a process of predicting a defect detection man-hour of a specification item.
FIG. 8 is a diagram showing an example in the process of creating a test plan.
FIG. 9 is a flowchart showing a process of a first example for creating a test plan.
FIG. 10 is a flowchart showing a process of a second example for creating a test plan.
FIG. 11 is a flowchart showing a process of a third example for creating a test plan.
FIG. 12 is a block diagram showing the overall flow of the present invention.
FIG. 13 is a diagram showing an example of an evaluation viewpoint.
FIG. 14 is a flowchart showing a process of creating a specification item list with characteristic values.
FIG. 15 is a diagram showing an example of a specification item list with characteristic values generated in FIG. 14;
FIG. 16 is a diagram showing an example of a test strategy.
FIG. 17 is a flowchart showing a process of creating a test strategy.
FIG. 18 is a flowchart showing a process of selecting a test strategy.
FIG. 19 is a flowchart showing a process of creating a specification item list with test priority from a specification item list with characteristic values and a test strategy.
FIG. 20 is a diagram showing an example of a specification item list with test priority created in FIG. 19;
FIG. 21 is a flowchart showing a process of evaluating a specification item list with a test priority created from a selected test strategy using past defect data.
FIG. 22 is a diagram showing an example of past defect data used in FIG. 21;
FIG. 23 is a diagram showing an example of a test resource.
FIG. 24 is a flowchart showing a process of designing a test case from the specification item list with test priority created in FIG. 19 and test resources, past similar test cases, and known test case design means.
FIG. 25 is a flowchart showing a process of creating, as a test result, a defect found as a result of performing a test using the test case designed in FIG. 24;
FIG. 26 is a diagram showing an example of a test result created in FIG.
FIG. 27 is a flowchart showing a process of re-verifying the test strategy using the test result created in FIG. 26;
[Explanation of symbols]
1 System specification specification items
2 Evaluation viewpoint database
3 Specification item characteristic value setting section
4 Specification item list with characteristic values
5 Test strategy creation department
6 Test strategy database
7 Test strategy selection section
8 Test strategy
9 Test priority deriving section
10 List of specification items with test priority
11 Test Strategy Evaluation Department
12 past defect data
13 Test resources
14 Past similar test cases
15 Test case design means
16 Test case design department
17 Test case
18 Test execution / result output section
19 Test results
20 Defect data for the current test
21 Test result verification unit
22 Module / Specification Item Correspondence Setting Section
23 Module / Specification Item Correspondence Information
24 Module quality information setting section
25 Module quality information
26 Module failure detection man-hour prediction part
27 Module failure detection man-hours
28 Specification Item Defect Detection Effort Prediction Unit
29 Specification Item Defect Detection Effort
30 Test plan creation department
31 Test plan
32 Module list

Claims

A method for creating a test plan for a software system having a plurality of program modules using a computer,
A module quality information setting step for setting, in the quality information storage means of the computer, a value corresponding to at least the source scale and the skill of the person in charge as quality information effective for predicting the number of defects for each program module of the software system;
The arithmetic means of the computer, using the value set in the quality information storage unit predicts the number of faults for each of the program modules, and predicts the fault detection steps are steps required for detection the problem A module defect detection man-hour predicting step for storing the defect detection man- hour and the defect number in a defect storage means of the computer ;
The correspondence relationship storage means of the computer, correspondence, module specification item to set a value indicating the degree program module to the specification item contributes to the specification item extracted with the program module from the specifications of the software system A correspondence setting process;
The arithmetic means of the computer, using the value indicating the degree the program module contributes the fault detection steps and the number of faults and the correspondence relationship storage means of said fault storage means, the fault detection steps of each specification item A specification item defect detection man-hour prediction step for predicting and storing the defect detection man-hour in the specification item defect detection man-hour storage means of the computer ,
Based on the defect detection man-hours for each specification item of the specification item defect detection man-hour storage means by the computing means of the computer , at least a test period, the number of persons in charge of the test, and test resources available for testing the software system A test plan creation support method comprising: a test plan creation step of creating a capability allocation as a test plan and storing the allocated test resources in a resource allocation storage unit of the computer .

A test plan creation support program for operating a computer so as to support creation of a test plan for a software system having a plurality of program modules,
A module quality information setting function for causing the quality information storage means of the computer to set at least a value corresponding to the source scale and the skill of the person in charge as quality information effective for predicting the number of defects for each program module of the software system;
Predicting the number of defects for each of the program modules using the value of the quality information storage means in the computing means of the computer, and predicting the defect detection man-hours that are man-hours required for detecting the defects , A module defect detection man-hour prediction function for storing the defect detection man-hour and the defect number in a defect storage means of the computer ;
The correspondence relationship storage means of the computer, the program module and the software correspondence between specification items extracted from the specifications of the system, the specification program module to the item causes sets a value indicating the degree contribute Module Specifications Item Correspondence setting function,
The calculation means of the computer uses the defect detection man-hours of the defect storage means and the number of defects and a value indicating the degree to which the program module of the correspondence storage means contributes to calculate the defect detection man-hours for each specification item. A specification item defect detection man-hour prediction function for predicting and storing the defect detection man-hour in the specification item defect detection man-hour storage means of the computer ;
Based on the defect detection man-hours for each specification item in the specification item defect detection man-hour storage means , the computer calculation means has at least a test period, the number of test personnel as test resources available for testing the software system, and create an allocation of capacity as a test plan, test planning support program characterized by comprising a test plan creation function to be stored in the resource allocation storage means of the computer the allocated test resource.