JPH05324309A - Device and method for evaluating software quality - Google Patents
Device and method for evaluating software qualityInfo
- Publication number
- JPH05324309A JPH05324309A JP4122233A JP12223392A JPH05324309A JP H05324309 A JPH05324309 A JP H05324309A JP 4122233 A JP4122233 A JP 4122233A JP 12223392 A JP12223392 A JP 12223392A JP H05324309 A JPH05324309 A JP H05324309A
- Authority
- JP
- Japan
- Prior art keywords
- test
- software
- test case
- estimation
- defects
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
Abstract
Description
【０００１】[0001]
【産業上の利用分野】本発明は開発中のソフトウェアの
信頼性や完成度を評価するためのソフトウェア品質評価
装置および品質評価方法に関するものであって、評価対
象となるソフトウェアについて、評価テストを行った際
に得られた故障や欠陥が見付けられたときのテスト情報
を記録した時系列データから、そのソフトウェアの故障
・欠陥の総数を高い信頼度で推定できるようにするもの
である。BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software quality evaluation device and a quality evaluation method for evaluating the reliability and completeness of software under development. An evaluation test is performed on software to be evaluated. It is possible to estimate with high reliability the total number of failures / defects of the software from time-series data recording test information obtained when a failure or defect is found.
【０００２】[0002]
【従来の技術】開発したソフトウェアが目的に適合した
処理を実施できるものとなっているか否か、誤動作や欠
陥のないものとなっているか否かは、信頼性の面で極め
て重要なことである。そこで、従来においては、開発し
たソフトウェアを実際に種々のテストケース（テスト用
の模擬情報）を用意してこれに従い、実行させてみるこ
とにより、故障（フェイリア）や欠陥（フォルト）の存
在を調べ、信頼性を推定していた。2. Description of the Related Art It is extremely important in terms of reliability whether or not developed software is capable of performing processing suited to its purpose and is free of malfunctions and defects. .. Therefore, in the past, the existence of a failure (feria) or a defect (fault) was investigated by actually preparing the developed software with various test cases (simulated information for testing) and executing them. , Had estimated reliability.
【０００３】具体的には、様々な場面を想定してのテス
トケースを用意して、これを開発中のソフトウェア（被
テストプログラム）に与えて実行させてみる。そして、
これにより故障や欠陥を発見したときの、それまでに費
やしたテスト時間の時系列データまたはテスト回数のみ
によって信頼性の推定を行う。Specifically, a test case assuming various situations is prepared, and this is given to software under development (program under test) to be executed. And
As a result, when a failure or defect is found, the reliability is estimated only by the time-series data of the test time spent up to that point or the number of tests.
【０００４】[0004]
【発明が解決しようとする課題】上述の如く、従来の方
式では、開発中のソフトウェアの信頼性を、用意したテ
ストケースに従って実行させて見ることにより生じた故
障や欠陥について、それを発見したときの、それまでに
費やしたテスト時間の時系列データまたはテスト回数の
みによって信頼性の推定を行っていた。つまり、テスト
時間の時系列データのみを使用し、最適と思われる信頼
性モデルに従って計算して推定した残存潜在欠陥数を用
いて信頼性の推定を行うようにしていた。As described above, in the conventional method, when the reliability of the software under development is executed according to the prepared test case and the failure or defect caused by the failure is found. , The reliability was estimated only by the time-series data of the test time spent till then or the number of tests. That is, only the time series data of the test time is used, and the reliability is estimated by using the number of residual latent defects calculated and estimated according to the reliability model considered to be optimal.
【０００５】そのため、信頼性の推定値が、ソフトウェ
ア開発に携わる者の側から見てその感覚や経験と大きく
かけ離れたものとなっていたり、推定結果に基づいてソ
フトウェアに含まれる全てのバグ（故障や欠陥）を見付
けるのに要する時間を算出すると、その値が現実には実
行不可能なものであったりすると云った問題があった。Therefore, the estimated value of the reliability is far from the sense and experience of the person involved in software development, or all the bugs (failures) included in the software based on the estimation result. When calculating the time required to find (defects), there is a problem that the value is actually unexecutable.
【０００６】これはもともと信頼性モデルにより、ある
いはテストケースにより、多種多様な結果を呈すること
から、費やしたテスト時間の時系列データのみでは信頼
性推定する上で情報が極めて不十分であることによる。[0006] This is because the reliability model or the test case gives various kinds of results, so that the time-series data of the spent test time is extremely insufficient for reliability estimation. ..
【０００７】また、テスト工程におけるその他の情報を
信頼性の推定に活かそうとしても、どのような情報をど
のように利用すれば信頼性の推定値を高い精度で得るこ
とができるかその指標がない。Further, even if other information in the test process is used to estimate reliability, what kind of information is used and how to obtain an estimated value of reliability with high accuracy is an index. Absent.
【０００８】ソフトウェアの開発現場では、信頼性の推
定値がある程度の高いレベルに達した段階で製品として
リリース可能と判断して出荷することになるが、信頼性
の推定値が信用のないものであれば、リリース可能であ
るのか否かさえ掴むことができず、また、推定結果に基
づいてソフトウェアに含まれる全ての故障や欠陥を見付
けるのに要する時間がどの位かを知ることができないこ
とになって、開発計画も思うようにたてられないことと
なる。At the software development site, when the reliability estimation value reaches a certain high level, it is determined that the product can be released and shipped, but the reliability estimation value is not reliable. If so, they cannot even know if they can be released or not, and they cannot know how long it will take to find all the defects and defects in the software based on the estimation results. As a result, the development plan cannot be set up as expected.
【０００９】また、経験が豊富な技術者がテストを実施
したり、テストの目的を例えば機能テストから構造テス
トに変えたりすると、多くの故障が見付けられることが
多く、このような一時的な変化により推定値が大きくふ
らつくと云った問題も指摘されている。このため、既存
の信頼性推定技術はそれほど実際の開発現場には普及し
ておらず、新たな信頼性推定技術の開発が嘱望されてい
る。Further, when an experienced engineer carries out a test or changes the purpose of the test from, for example, a functional test to a structural test, many failures are often found, and such a temporary change occurs. It has been pointed out that the estimation value fluctuates greatly. Therefore, the existing reliability estimation technology is not so popular in actual development sites, and there is a strong demand for the development of a new reliability estimation technology.
【００１０】そこで、この発明の目的とするところは、
テスト進捗に伴って得られる検出バグ数、テストカバレ
ッジおよびテストケース数に基づいて評価対象ソフトウ
ェアの全バグ数を推定し、開発中のソフトウェアである
評価対象ソフトウェアの信頼性向上を支援すると共に、
使用しているテストケースの能力に関する情報をも出力
できるようにしてテストケースの選択を支援し、効率の
良いテストを可能にするソフトウェア品質評価装置およ
びソフトウェア品質評価方法を提供することにある。Therefore, the object of the present invention is to
Estimate the total number of bugs of the evaluation target software based on the number of detected bugs, test coverage and the number of test cases obtained with the progress of the test, and support the reliability improvement of the evaluation target software that is under development.
An object of the present invention is to provide a software quality evaluation device and a software quality evaluation method that enable output of information regarding the capabilities of the test cases being used to assist selection of test cases and enable efficient testing.
【００１１】[0011]
【課題を解決するための手段】上記目的を達成するた
め、本発明は次のように構成する。すなわち、第１に
は、テストのために用意した各種の条件群であるテスト
ケースに従って評価対象のソフトウェアを実行させる実
行手段と、この実行手段による実行に使用したテストケ
ース数の情報と、前記実行手段により前記評価対象のソ
フトウェアを実行させた際におけるこの評価対象のソフ
トウェアの実行済み部分の割合を示すテストカバレッジ
情報と、前記実行により検出された故障・欠陥の数とを
データ収集するテストデータ収集手段と、この収集した
データをもとに、テストケースの有する前記評価対象の
ソフトウェアに対する故障・欠陥発見能力のパラメータ
であるテストケースの能力を推定するテストケース能力
推定手段と、この推定されたテストケースの能力につい
て経験に基づく所定の規則に従って補正し、テストカバ
レッジの情報を用いて処理することにより、テストケー
スの良さを算出する手段と、前記テストデータ収集手段
の収集したデ−タをもとに、ソフトウェア信頼性成長モ
デルに基づいて前記評価対象ソフトウェアに潜在の故障
・欠陥の総数推定値を得る第１の推定手段と、前記テス
トデータ収集手段の収集したデ−タのうち、テストケー
ス数の情報と検出故障・欠陥の数とを用い、ソフトウェ
ア信頼性成長モデルに基づいて前記評価対象ソフトウェ
アに潜在の故障・欠陥の総数推定値を得る第２の推定手
段と、これら第１および第２の推定手段により推定され
た各推定値に対して、経験に基づく所定の規則に従って
処理することにより、故障・欠陥の総数の推定結果を得
る総合判断手段とより構成する。In order to achieve the above object, the present invention is configured as follows. That is, first, execution means for executing software to be evaluated according to test cases, which are various condition groups prepared for testing, information on the number of test cases used for execution by this execution means, and the execution Test data collection for collecting data of the test coverage information indicating the ratio of the executed portion of the software to be evaluated when the software to be evaluated is executed by means, and the number of failures / defects detected by the execution. Means, a test case capability estimating means for estimating the capability of the test case, which is a parameter of the fault / defect finding capability of the software to be evaluated included in the test case, based on the collected data, and the estimated test The ability of the case is corrected according to predetermined rules based on experience and the test coverage is corrected. Based on the software reliability growth model based on the data collected by the means for calculating the goodness of the test case and the data collected by the test data collecting means by processing using the information of the test data. First estimation means for obtaining the total estimated value of latent failures / defects, and information of the number of test cases and the number of detected failures / defects among the data collected by the test data collection means Second estimating means for obtaining a total estimated value of potential failures / defects in the evaluation target software based on the reliability growth model, and each estimated value estimated by the first and second estimating means, It comprises a comprehensive judgment means for obtaining an estimation result of the total number of failures / defects by processing according to a predetermined rule based on experience.
【００１２】また、第２には、テストのために用意した
各種の条件群であるテストケースに従って評価対象のソ
フトウェアを実行させる実行ステップと、この実行ステ
ップでの実行に使用したテストケース数の情報と、実行
ステップでの前記評価対象のソフトウェアを実行させた
際におけるこの評価対象のソフトウェアの実行済み部分
の割合を示すテストカバレッジ情報と、前記実行により
検出された故障・欠陥の数とをデータ収集するテストデ
ータ収集ステップと、この収集したデータをもとに、テ
ストケースの有する前記評価対象のソフトウェアに対す
る故障・欠陥発見能力のパラメータであるテストケース
の能力を推定するテストケース能力推定ステップと、こ
の推定されたテストケースの能力について経験に基づく
所定の規則に従って補正し、テストカバレッジの情報を
用いて処理することにより、テストケースの良さを算出
する算定ステップと、前記テストデータ収集ステップで
の収集デ−タをもとに、ソフトウェア信頼性成長モデル
に基づいて前記評価対象ソフトウェアに潜在の故障・欠
陥の総数推定値を得る第１の推定ステップと、前記テス
トデータ収集ステップでの収集デ−タのうち、テストケ
ース数の情報と検出故障・欠陥の数とを用い、ソフトウ
ェア信頼性成長モデルに基づいて前記評価対象ソフトウ
ェアに潜在の故障・欠陥の総数推定値を得る第２の推定
ステップと、これら第１および第２の推定ステップによ
り推定された各推定値に対して、蓄積された経験に基づ
く所定の規則に従って処理することにより、故障・欠陥
の総数の推定結果を得る総合判断ステップとより構成す
る。Secondly, information about the execution steps for executing the software to be evaluated according to the test cases, which are various condition groups prepared for the test, and the number of test cases used for the execution in this execution step. And test coverage information indicating the ratio of the executed portion of the evaluation target software when the evaluation target software is executed in the execution step, and the number of failures / defects detected by the execution data collection. And a test case capability estimating step of estimating a test case capability, which is a parameter of a failure / defect finding capability of the evaluation target software included in the test case, based on the collected data. Follow predetermined rules based on experience for estimated test case capabilities Based on the software reliability growth model based on the calculation step of calculating the goodness of the test case by correcting and processing using the test coverage information, and the collected data in the test data collecting step. A first estimation step of obtaining a total estimated value of potential failures / defects in the evaluation target software; and information on the number of test cases and the number of detected failures / defects of the collected data in the test data collecting step. And a second estimation step of obtaining a total estimated value of latent failures / defects in the software to be evaluated based on a software reliability growth model, and each estimated value estimated by these first and second estimation steps. , The total judgment score to obtain the estimation result of the total number of failures / defects by processing according to a predetermined rule based on the accumulated experience. -Up and more configuration.
【００１３】[0013]
【作用】上記の構成において、テストのために用意した
各種の条件群であるテストケースに従って評価対象のソ
フトウェアを実行手段に実行させると、テストデータ収
集手段はこの実行手段による実行に使用したテストケー
ス数の情報と、前記実行手段により前記評価対象のソフ
トウェアを実行させた際におけるこの評価対象のソフト
ウェアの実行済み部分の割合を示すテストカバレッジ情
報と、前記実行により検出された故障・欠陥の数とをデ
ータ収集する。そして、テストケース能力推定手段はテ
ストデータ収集手段の収集したデータをもとに、テスト
ケースの有する前記評価対象のソフトウェアに対する故
障・欠陥発見能力のパラメータであるテストケースの能
力を推定する。In the above configuration, when the execution means executes the software to be evaluated according to the test cases which are various condition groups prepared for the test, the test data collection means causes the test case to be used by the execution means. Number information, test coverage information indicating the ratio of the executed portion of the evaluation target software when the evaluation target software is executed by the execution unit, and the number of failures / defects detected by the execution. To collect data. Then, the test case ability estimating means estimates the ability of the test case, which is a parameter of the failure / defect finding ability of the software to be evaluated included in the test case, based on the data collected by the test data collecting means.
【００１４】一方、算出手段はテストケース能力推定手
段により推定されたテストケースの能力について、蓄積
された経験に基づく所定の規則に従って補正し、これと
テストカバレッジの情報とを用いて所定の演算処理をす
ることにより、テストケースの良さを算出する。On the other hand, the calculating means corrects the ability of the test case estimated by the test case ability estimating means according to a predetermined rule based on accumulated experience, and uses this and the information of the test coverage to perform a predetermined arithmetic processing. By doing, the goodness of the test case is calculated.
【００１５】また、第１の推定手段は前記テストデータ
収集手段の収集したデ−タをもとに、ソフトウェア信頼
性成長モデルに基づいて前記評価対象ソフトウェアに潜
在の故障・欠陥の総数推定値（バグ総数推定値）を得、
第２の推定手段は前記テストデータ収集手段の収集した
デ−タのうち、テストケース数の情報と検出故障・欠陥
の数とを用い、ソフトウェア信頼性成長モデルに基づい
て前記評価対象ソフトウェアに潜在の故障・欠陥の総数
推定値を得る。そして、総合判断手段はこれら第１およ
び第２の推定手段により推定された各推定値に対して、
経験に基づく所定の規則に従って重み付け処理すること
により、両推定値を経験的に加味した現実に近い故障・
欠陥の総数の推定結果を得る。Further, the first estimating means uses the data collected by the test data collecting means to estimate the total number of potential failures / defects in the evaluation target software based on the software reliability growth model ( Estimated total number of bugs)
The second estimating means uses the information on the number of test cases and the number of detected failures / defects of the data collected by the test data collecting means, and the latent image is included in the evaluation target software based on the software reliability growth model. Get the total estimate of the number of failures / defects in. Then, the comprehensive judgment means, for each estimated value estimated by these first and second estimation means,
By performing weighting according to a predetermined rule based on experience, a failure that is close to the reality
Get an estimate of the total number of defects.
【００１６】このように本発明はテストケース数とバグ
数から全バグ数を推定し、また、テストケース数、バグ
数とテストカバレッジの時系列データから全バグ数を推
定すると共に、テストケース数、バグ数と、テストカバ
レッジの時系列データからテストケースの能力を推定
し、これらのうち、テストケースの能力から過去の経験
に基づくルールを適用することにより、テストケースの
全体としての良さを求め、また、バグ推定方法の異なる
上記２つの推定値について信頼性推定結果を比較し、過
去の経験に基づくルールを適用することにより、最終的
な結果を出力すると云うものである。As described above, the present invention estimates the total number of bugs from the number of test cases and the number of bugs, and also estimates the total number of bugs from the time series data of the number of test cases, the number of bugs and test coverage, and the number of test cases. , The number of bugs and the ability of the test case is estimated from the time-series data of the test coverage, and of these, the rule based on past experience is applied from the ability of the test case to obtain the overall goodness of the test case. It is also said that the final results are output by comparing the reliability estimation results for the above two estimated values having different bug estimation methods and applying the rule based on past experience.
【００１７】本発明はソフトウェアのテスト中にバグ数
の検出ができると共に、テストケース数とテストカバレ
ッジを測定することができることを利用している。しか
も、テストカバレッジはテストにおいて実行された範囲
を示すものであり、モジュール、タスク、ステートメン
ト、ブランチカバレッジなどがあるが、テストの信頼性
を把握するに重要な意味合いを持っている。ソフトウェ
アのテスト中に故障（フェイリア）が生じると、その故
障の原因であるソフトウェア中のバグ（フォルト、欠
陥）を修正しなければならない。従って、テストカバレ
ッジによりどの部分をテストしたかを認識し、また、バ
グはいくつ含まれているか等を知ることは重要である。
本発明は信頼性予測にあたり、超幾何分布（ＨＧＤＭ）
モデルをソフトウェア信頼度成長モデルとして使用し、
一つはテストケース数と検出バグ総数とによる一般的手
法により、またもう一つはこれにさらにテストカバレッ
ジを加味してバグ総数を推定するものであって、これら
を熟練したソフトウェア開発技術者の経験と勘に基づく
ルールに当て嵌めて最終的な故障・欠陥の総数（バグ総
数）の推定値を得るものであるから、より現実味を帯び
た精度の高いものとなり、しかも、こうして得た故障・
欠陥総数の推定結果およびその時点までに使用したテス
トケースの良さに関する情報を算出して合わせて提供す
るものであるから、現在のバグ総数の推定値をもとに、
被テストソフトウェアの抱える処置しなければならない
バグ数が掴めることになり、従って、被テストソフトウ
ェアを製品としてリリース可能となるに要する開発期間
の予測が立つようになって、開発スケジュールをたてる
ことができるようになる他、テストケースの良さの指標
を出力できるので、現在使用しているテストケースの適
不適が途中段階でわかり、従って、不適の場合にはテス
トケースの変更を早目に行うことができて、その分、無
駄なテストを行わずにすむようになり、開発コストの低
減を図ることができるようになる。The present invention takes advantage of the fact that the number of bugs can be detected during the testing of software, and the number of test cases and test coverage can be measured. Moreover, the test coverage indicates the range executed in the test, and includes modules, tasks, statements, branch coverage, and the like, and has an important meaning in grasping the reliability of the test. When a failure (feria) occurs during software testing, the bug (fault, defect) in the software that causes the failure must be corrected. Therefore, it is important to recognize which part was tested by test coverage, and how many bugs are included.
The present invention uses the hypergeometric distribution (HGDM) for reliability prediction.
Use the model as a software confidence growth model,
One is a general method based on the number of test cases and the total number of detected bugs, and the other is to estimate the total number of bugs by adding test coverage to them. Since the final estimated total number of failures / defects (total number of bugs) is obtained by applying rules based on experience and intuition, it becomes more realistic and highly accurate.
It calculates and provides information about the total number of defects and the goodness of the test cases used up to that point, so based on the current estimated total number of bugs,
It is possible to grasp the number of bugs of the software under test that must be dealt with. Therefore, it becomes possible to predict the development period required for the software under test to be released as a product, and to develop a development schedule. In addition to being able to do so, it is possible to output the indicator of the goodness of the test case, so that the suitability of the test case currently in use can be known at an intermediate stage, so if it is not suitable, change the test case early. As a result, it is possible to avoid unnecessary tests, and it is possible to reduce the development cost.
【００１８】[0018]
【実施例】本発明はテストカバレッジを用いた超幾何分
布（ＨＧＤＭ）モデルに基づいた信頼性推定方式を提供
するものであり、以下、本発明の一実施例について、図
面を参照して説明する。BEST MODE FOR CARRYING OUT THE INVENTION The present invention provides a reliability estimation method based on a hypergeometric distribution (HGDM) model using test coverage. An embodiment of the present invention will be described below with reference to the drawings. ..
【００１９】これまでの技術では、故障数と修正数を見
て、ソフトウェアの信頼性モデルでバグ数を推定してい
たが、テストにおいて、カバレッジは、どの部分をテス
トしたかを表わす重要な情報であり、信頼性と深い関係
がある。従って、カバレッジを除外した信頼性推定にお
いては推定の信頼性そのものに問題が残ることになる
が、本発明では信頼性推定にテストカバレッジ情報をも
旨く取り入れ、信頼性確保を図るようにしている。In the conventional technology, the number of failures and the number of repairs are used to estimate the number of bugs by the software reliability model. In the test, the coverage is an important information indicating which part is tested. And has a strong relationship with credibility. Therefore, in the reliability estimation excluding the coverage, there remains a problem in the reliability of the estimation itself, but in the present invention, the test coverage information is properly incorporated into the reliability estimation to ensure the reliability.
【００２０】図１は本発明の一実施例を示すブロック図
であり、図２および図３はその部分拡大図である。図１
〜図３において、１はテストケース入力手段、２は被テ
ストプログラムを格納した記憶装置、３はテストケース
処理部、４は構文解析部、５はカバレッジ処理部、６は
テスト結果期待値保持部、７はバグ検出部、９はテスト
ケースレジスタ、１０はプログラム修正部である。FIG. 1 is a block diagram showing an embodiment of the present invention, and FIGS. 2 and 3 are partially enlarged views thereof. Figure 1
In FIG. 3, 1 is a test case input means, 2 is a storage device storing a program under test, 3 is a test case processing unit, 4 is a syntax analysis unit, 5 is a coverage processing unit, and 6 is a test result expected value holding unit. , 7 is a bug detection unit, 9 is a test case register, and 10 is a program correction unit.
【００２１】また、１１ａ，１１ｂはそれぞれデータ記
憶部、１２ａ〜１２ｃはそれぞれ推定部、１３は判断
部、１４は知識部、１５は第２の判断部、１６は判断結
果抽出部である。Reference numerals 11a and 11b are data storage units, 12a to 12c are estimation units, 13 is a determination unit, 14 is a knowledge unit, 15 is a second determination unit, and 16 is a determination result extraction unit.
【００２２】上記テストケース入力手段１は、テストケ
ース（テスト用の模擬情報）を入力するためのものであ
る。テストケースには目的に合わせた様々なパラメータ
や具体的データ、コマンド、フラグなどがあり、テスト
の目的に合わせて用意される。また、テストケース入力
手段１からは上述のテストケースの情報の他に、そのテ
ストケースに従っての実行の結果、本来得られるべき結
果である期待値も入力させるものとする。The test case input means 1 is for inputting a test case (simulation information for testing). The test case has various parameters, specific data, commands, flags, etc., according to the purpose and is prepared according to the purpose of the test. In addition to the above-mentioned test case information, the test case input means 1 also inputs an expected value which is a result that should be originally obtained as a result of execution according to the test case.
【００２３】上記記憶装置２は被テストプログラム（テ
スト対象である開発中のプログラム）を記憶するもので
ある。テストケース処理部３はテストケース入力手段１
から入力されたテストケースの情報を保持し、また、期
待値をテスト結果期待値保持部６に与える共に、記憶装
置２から被テストプログラムを読み込み、テストケース
の情報を用いてこの被テストプログラムを実行させ、そ
の結果をテスト結果期待値保持部６に与えると云った処
理を行うものである。The storage device 2 stores a program under test (a program under development which is a test target). The test case processing unit 3 is the test case input means 1
Holds the information of the test case input from the device, provides the expected value to the test result expected value holding unit 6, reads the program under test from the storage device 2, and uses the information of the test case to load the program under test. The processing is executed such that it is executed and the result is given to the test result expected value holding unit 6.
【００２４】構文解析部４は記憶装置２から被テストプ
ログラムを読み込み、プログラムの構文を解析するもの
で、プログラム上での分岐位置、パスの経路（処理の流
れの辿るルート）、機能（関数：ファンクション）の種
類等を解析するものである。カバレッジ処理部５は構文
解析部４からの解析情報と、記憶装置２からの被テスト
プログラムと、テストケース処理部３からの現在のプロ
グラム上での処理位置等の情報とをもとに、被テストプ
ログラムのどの経路を実施しているかを解析し、カバレ
ッジを求めると云った処理をするものである。テスト結
果期待値保持部６はテストケース処理部３から出力され
たテスト結果と期待値とを保持するためのものである。The syntax analysis unit 4 reads the program under test from the storage device 2 and analyzes the syntax of the program. The branch position on the program, the path of the path (route along which the processing flow follows), and the function (function: It analyzes the type of function). Based on the analysis information from the syntax analysis unit 4, the program under test from the storage device 2, and the information such as the processing position in the current program from the test case processing unit 3, the coverage processing unit 5 receives the information about the target program. This is a process of analyzing which route of the test program is being executed and obtaining the coverage. The test result expected value holding unit 6 is for holding the test result and the expected value output from the test case processing unit 3.
【００２５】また、バグ検出部７はテスト結果期待値保
持部６の保持したテスト結果と期待値とを参照してバグ
の有無を検出するものであり、また、テストケースレジ
スタ９はテストケース処理部３が使用したテストケース
数を累算するためのものである。The bug detection unit 7 detects the presence / absence of a bug by referring to the test result and the expected value held by the test result expected value holding unit 6, and the test case register 9 is used for the test case processing. This is for accumulating the number of test cases used by the section 3.
【００２６】プログラム修正部１０は被テストプログラ
ムにおけるバグの修正を行うためのものである。プログ
ラム修正部１０は自動修正可能なバグに対しては自動修
正処理できるような処理システムとしてあっても良い
し、人手に頼るものであれば、キーボード等の入力装置
とエディタ等の編集装置とによる構成等が考えられる。The program correction section 10 is for correcting a bug in the program under test. The program correction unit 10 may be a processing system capable of automatically correcting a bug that can be automatically corrected. If it depends on human hands, an input device such as a keyboard and an editing device such as an editor may be used. The configuration etc. can be considered.
【００２７】また、データ記憶部１１ａはテストカバレ
ッジ処理部５から出力されるテストカバレッジの情報
（ＴＣ）とバグ検出部７の検出したバグ数の情報（Ｎ）
とテストケースレジスタ９の保持した値（テストケース
数）ＴＮとを保持するためのものであり、データ記憶部
１１ｂはテストケースレジスタ９の保持した値（テスト
ケース数）ＴＮとバグ検出部７の検出したバグ数の情報
（Ｎ）とを保持するためのものである。Further, the data storage unit 11a has information of the test coverage output from the test coverage processing unit 5 (TC) and information of the number of bugs detected by the bug detection unit 7 (N).
And the value (the number of test cases) TN held in the test case register 9 and the data storage unit 11b stores the value (the number of test cases) TN held in the test case register 9 and the bug detection unit 7. This is for holding information (N) on the number of detected bugs.
【００２８】推定部１２ａはデータ記憶部１１ａが時系
列的に記憶しているテストカバレッジの情報（ＴＣ）と
バグ数の情報（Ｎ）とテストケース数（ＴＮ）とをもと
に、後述する演算式を使用してテストケースの能力（す
なわち、バグを発見する力）を例えば値として推定する
ものである。The estimating unit 12a will be described later based on the test coverage information (TC), the number of bugs information (N), and the number of test cases (TN) stored in the data storage unit 11a in time series. The calculation method is used to estimate the ability of the test case (that is, the ability to find a bug) as a value, for example.
【００２９】また、推定部１２ｂはデータ記憶部１１ａ
の記憶しているテストカバレッジの情報（ＴＣ）とテス
トケース数（ＴＮ）とバグ数（Ｎ）とをもとに、後述す
るＨＧＤＭソフトウェア信頼性モデルを含む後述する所
定の演算式に基づき、演算して被テストプログラムの有
していた全バグ数を推定するものである。Further, the estimating unit 12b includes a data storage unit 11a.
Based on the test coverage information (TC), the number of test cases (TN), and the number of bugs (N) stored in the above, the calculation is performed based on a predetermined calculation formula including an HGDM software reliability model described below. Then, the total number of bugs of the tested program is estimated.
【００３０】また、推定部１２ｃはデータ記憶部１１ｂ
の記憶しているテストケース数（ＴＮ）とバグ数とをも
とに、後述するＨＧＤＭソフトウェア信頼性モデルを含
む後述する所定の演算式に基づき、演算して被テストプ
ログラムの有している全バグ数を推定するものである。The estimating unit 12c also includes a data storage unit 11b.
Based on the number of test cases (TN) and the number of bugs stored by the above, based on a predetermined arithmetic expression described later including an HGDM software reliability model described later, all of the programs under test have. It estimates the number of bugs.
【００３１】知識部１４はソフトウェア開発技術者の経
験的な情報を集めた部分である。判断部１３は各推定部
１２ｂ，１２ｃの推定結果に対し、知識部１４に格納さ
れた知識を用いて総合的に判定して被テストプログラム
の有している全バグ数の推定値を決定するものであり、
第２の判断部１５は推定部１２ａの推定したテストケー
スの能力をもとにテストケースの「良さ」を判定（推
定）するものである。すなわち、第２の判断部１５はテ
ストケースの能力からテストケースの集合で見た場合
に、それ全体としてテストケースが良かったか否かを判
断する。判断結果抽出部１６はこれら判定部１３と判定
部１５の推定した情報を出力するものである。次に推定
部１２ａにおけるテストケースの能力の推定処理、そし
て、推定部１２ｂと推定部１２ｃにおける全バグ数推定
処理の内容を説明する。The knowledge section 14 is a section that collects empirical information of software development engineers. The judgment unit 13 comprehensively judges the estimation results of the estimation units 12b and 12c using the knowledge stored in the knowledge unit 14 to determine the estimated value of the total number of bugs of the program under test. Is something
The second determination unit 15 determines (estimates) the "goodness" of the test case based on the capability of the test case estimated by the estimation unit 12a. That is, the second determination unit 15 determines whether or not the test case is good as a whole when the test case is viewed as a set of test cases from the capability of the test case. The judgment result extraction unit 16 outputs the information estimated by the judgment units 13 and 15. Next, the contents of the test case capability estimation process in the estimation unit 12a and the total bug number estimation process in the estimation units 12b and 12c will be described.
【００３２】ソフトウェアの信頼性を推定する方法の一
つに超幾何分布（ＨＧＤＭ）モデルによるソフトウェア
の信頼性成長モデルを用いる方法がある。このモデルは
様々な種類の実データに対する推定が行えることが知ら
れている。しかし、このモデルはテスト時間、テストケ
ース数などと、不具合件数から信頼度を推定するもので
あり、テストケースの良さなどの情報は含めずに推定し
ている。One of the methods for estimating the reliability of software is to use a software reliability growth model based on a hypergeometric distribution (HGDM) model. It is known that this model can estimate various kinds of real data. However, this model estimates the reliability from the test time, the number of test cases, and the number of defects, and does not include information such as the goodness of the test cases.
【００３３】本発明ではテストケース数と不具合件数と
から信頼度を推定する一般的な推定方法と、テストケー
スの良さも加味した信頼度を推定する方法の二種を併用
し、二つの推定方法にてそれぞれ得られた信頼度につい
て、経験者の知識を加味した最終的な信頼度を求めるよ
うにすると云う手法を用いるようにした。そして、テス
トケースの良さを計る尺度として、テストカバレッジを
ＨＧＤＭモデルに組み込み、信頼度を推定するようにす
る。ＨＧＤＭ（超幾何分布モデル）による信頼度成長曲
線は次式のように表現される。In the present invention, two kinds of estimation methods are used by combining two methods, a general estimation method for estimating the reliability from the number of test cases and the number of defects, and a method for estimating the reliability in consideration of the goodness of the test cases. With respect to the reliability obtained in each, the method of obtaining the final reliability with the knowledge of the experienced person is used. Then, as a measure for measuring the goodness of the test case, the test coverage is incorporated into the HGDM model to estimate the reliability. The reliability growth curve based on HGDM (hypergeometric distribution model) is expressed by the following equation.
【００３４】[0034]
【数１】 [Equation 1]
【００３５】ここでＥ［Ｃ（ｉ）］はテストインタンス
（テストケースの集合からなる）ｔ（ｉ）までに新しく
発見されたバグの累積数の推定値であり、Ｅ［ｍ］はテ
スト対象であるソフトウェアに潜在するバグ総数の推定
値である。このモデルではパラメータｗ（ｉ）＝Ｅ
［ｍ］＊ｐ（ｉ）の計算が必要であり、それらの推定方
法としては種々のものが考えられているが、ここではｐ
（ｉ）＝Ｅ［ａ］＊Ｅ［ｂ］なる１次式の推定方法を用
いることとする。Here, E [C (i)] is an estimate of the cumulative number of newly discovered bugs up to the test instance (comprising a set of test cases) t (i), and E [m] is the test. It is an estimate of the total number of potential bugs in the target software. In this model, the parameter w (i) = E
It is necessary to calculate [m] * p (i), and various estimation methods thereof are considered, but here, p
(I) = E [a] * E [b] The estimation method of the linear expression is used.
【００３６】テストカバレッジはソフトウェアの信頼性
を評価する方法の一つと考えられている。テストカバレ
ッジはテスト対象のソフトウェアについて、テストした
結果、全体に対して、実行された部分の割合を示すもの
であるから、高い信頼性を得るためには１００％のカバ
レッジであることが望ましい。しかし、現実には１００
％のカバレッジを達成することは非常に難しいものであ
る。そこで、テストカバレッジから見た信頼度推定をし
て、総合的な信頼度推定に寄与させるようにする。各テ
ストインスタンスｔ（ｉ）に対するテストカバレッジＴ
Ｃ（ｉ）を次のような１次式であると考える。 ＴＣ（ｉ）＝ａtc＊ｉ＋ｂtc ０＜ｉ＜ｎ 但し、ｎはテストインンスタンス数を表わし、ａtcとｂ
tcは０＜ｉ＜ｎにおいて0.0 ＜ＴＣ（ｉ）＜1.0 となる
任意の実数である。Test coverage is considered as one of the methods for evaluating the reliability of software. The test coverage indicates the ratio of the executed part to the whole of the test result of the software to be tested, and therefore 100% coverage is desirable to obtain high reliability. However, in reality, 100
Achieving% coverage is very difficult. Therefore, the reliability is estimated from the viewpoint of test coverage so as to contribute to the comprehensive reliability estimation. Test coverage T for each test instance t (i)
Consider C (i) as a linear expression as follows. TC (i) = a tc * i + b tc 0 < i < n where n represents the number of test instances, a tc and b
tc is an arbitrary real number such that 0.0 < TC (i) < 1.0 in 0 < i < n.
【００３７】上述したように、パラメータｗ（ｉ）＝Ｅ
［ｍ］＊ｐ（ｉ）であり、このｐ（ｉ）はテストインス
タンスｔ（ｉ）でバグ（フォールト（欠陥）やフェイリ
ア（故障））を発見（再発見も含む）する時のエフォー
トと考えられている。一方、テストカバレッジはテスト
時のエフォートをとらえる一つの尺度と考えることがで
きるので、パラメータｗ（ｉ）とテストカバレッジＴＣ
（ｉ）は深い関係があると考えられる。そこで、次にこ
れらの関係を説明する。１．パラメータｗ（ｉ）の値に
は制限がある。 ｗ（ｉ）＜Ｅ［ｍ］， ０＜ｉ＜ｎAs described above, the parameter w (i) = E
It is [m] * p (i), and this p (i) is considered as an effort when a bug (fault (defect) or felia (fault)) is found (including rediscovery) in the test instance t (i). Has been. On the other hand, the test coverage can be considered as one measure for capturing the effort during the test, so the parameter w (i) and the test coverage TC
(I) is considered to have a deep relationship. Therefore, these relationships will be described next. 1. There is a limit to the value of the parameter w (i). w (i) < E [m], 0 < i < n
【００３８】２．テストカバレッジの情報はテスト時の
エフォート関数と見做せる。テストカバレッジが０であ
れば、バグは発見されないので、 ＴＣ（ｉ）＝０ ---> ｗ（ｉ）＝０ である。
もし、0.0 ＜ＴＣ（ｉ）＜1.0 であれば、ｗ（ｉ）は0.
0 ＜ｗ（ｉ）＜Ｅ［ｍ］を満たしながら変化する。この
場合、潜在するバグ総数推定値Ｅ［ｍ］に相当するバグ
のうち、いくつのバグが発見できるかはテストケースに
大きく依存する。2. Information of test coverage can be regarded as an effort function at the time of testing. If the test coverage is 0, no bug is found, so TC (i) = 0 ---> w (i) = 0.
If 0.0 <TC (i) < 1.0, then w (i) is 0.
It changes while satisfying 0 < w (i) < E [m]. In this case, how many bugs can be found among the bugs corresponding to the latent bug total number estimation value E [m] largely depend on the test case.
【００３９】現実にはバグはプログラム全体に均一に分
布して潜在すると云うケースは少なく、偏在するケース
の方が多いから、カバレッジの大きいテストケースでも
少ししかバグが発見できない場合や、逆にカバレッジの
小さいテストケースでも多くのバグが発見できる場合も
ある。そこで、新しくテストカバレッジに基づいた次の
ようなパラメータｗ（ｉ）を利用する。ｗ（ｉ）＝Ｅ
［ｍ］＊ｐ（ｉ）＝Ｅ［ｍ］＊ｃ＊ＴＣ（ｉ）In reality, there are few cases where bugs are evenly distributed and latent in the entire program, and there are many cases where they are unevenly distributed. Therefore, even if a few bugs can be found even in a test case with a large coverage, or conversely, there is coverage. Many bugs can be found even in small test cases. Therefore, the following parameter w (i) based on new test coverage is used. w (i) = E
[M] * p (i) = E [m] * c * TC (i)
【００４０】ここで、パラメータｃは経験に基づいた発
見能力であり、バグ潜在部に特化してテストできた場合
にはテストカバレッジが小さくとも多くのバグを発見で
きることを示している。Here, the parameter c is an empirical finding ability, and shows that many bugs can be found even if the test coverage is small when the test can be conducted by focusing on the potential bug portion.
【００４１】上述したように、テストカバレッジは Ｔ
Ｃ（ｉ）＝ａtc＊ｉ＋ｂtcであるので、新しいパラメー
タｗ（ｉ）は ｗ（ｉ）＝Ｅ［ｍ］＊ｃ＊（ａtc＊１＋ｂtc）， ０＜
ｉ＜ｎ と表わされる。As mentioned above, the test coverage is T
Since C (i) = a tc * i + b tc , the new parameter w (i) is w (i) = E [m] * c * (a tc * 1 + b tc ), 0 <
It is expressed as i < n.
【００４２】ＴＣ（ｉ）＝1.0 の時、すべてのバグに相
当する推定値Ｅ［ｍ］が得られたならばそれは最強のテ
ストケースであり、 （ＴＣ（ｉ）＝1.0 ，ｗ（ｉ）＝Ｅ［ｍ］） --->
ｃ＝1.0 である。When TC (i) = 1.0, if the estimated value E [m] corresponding to all the bugs is obtained, it is the strongest test case, and (TC (i) = 1.0, w (i)). = E [m]) --->
c = 1.0.
【００４３】このようにしてテストケースの能力をテス
トケースの「良さ」の度合いとして推定することができ
る。上記の推定部１２ａはこのような演算を行ってテス
トケースの「良さ」を具体的な値として推定する。In this way, the ability of the test case can be estimated as the degree of "goodness" of the test case. The estimation unit 12a performs the above calculation to estimate the "goodness" of the test case as a specific value.
【００４４】『ソフトウェア信頼性モデルとして、ＨＧ
ＤＭ（超幾何分布モデル）を使用し、テストケースに基
づいての全バグ数の推定』ＨＧＤＭソフトウェア信頼性
モデルを用い、テストケースに基づいて信頼性の推定を
計算することができる。用意したｉ（ｉ＝１，２，３，
…）個のテストケースＴＣ（ｉ）を用いたテストによっ
て、それまでに発見されたバグに対する修正の総数（ｍ
（ＴＣ（ｉ）））の時系列データを、表１に示すＨＧＤ
Ｍ（超幾何分布）ソフトウェア信頼性モデルに当て嵌
め、当該モデルにおけるパラメータの近似解を求める。[As a software reliability model, HG
Using DM (Hypergeometric Distribution Model) to Estimate Total Number of Bugs Based on Test Cases ”The HGDM software reliability model can be used to calculate reliability estimates based on test cases. Prepared i (i = 1, 2, 3,
…) Total number of fixes (m) for bugs found so far by testing with test cases TC (i)
(TC (i))) time-series data are shown in Table 1.
It is applied to an M (hypergeometric distribution) software reliability model to find an approximate solution of the parameters in the model.
【００４５】[0045]
【表１】 [Table 1]
【００４６】ここで、ＴＣ（ｉ）はテストケース、Ｅ
［ｍ1 ］は潜在故障数で潜在するバグ総数、Ｅ［ａ］，
Ｅ［ｂ］はモデルのフィッティング・パラメータを表わ
す。また、ｐ（ｊ）はＨＧＤＭソフトウェア信頼性モデ
ルの努力関数である。この例でＨＧＤＭソフトウェア信
頼性モデルによる潜在故障数Ｅ［ｍ1 ］を推定すること
ができる。Where TC (i) is the test case, E
[M 1 ] is the total number of latent bugs, which is the number of latent failures, E [a],
E [b] represents the fitting parameter of the model. Also, p (j) is the effort function of the HGDM software reliability model. In this example, the number of latent failures E [m 1 ] based on the HGDM software reliability model can be estimated.
【００４７】図４はＨＧＤＭによる推定結果を示すもの
で、テストに使用したテストケース数が増えるにつれ
て、発見されるバグ件数（欠陥および故障の数）が増大
している様子が示されている。上記の推定部１２ｃはこ
のような演算を行ってテスト対象のソフトウェアの潜在
総バグ数を具体的な値として推定する。FIG. 4 shows an estimation result by HGDM, and shows that the number of found bugs (the number of defects and failures) increases as the number of test cases used for the test increases. The estimating unit 12c performs such an operation to estimate the latent total number of bugs of the software to be tested as a concrete value.
【００４８】『テストケースとバグ数とテストカバレッ
ジ情報とを用い、ＨＧＤＭソフトウェア信頼性モデルに
基づいての全バグ数の推定』これはテストケースとバグ
数とテストカバレッジ情報とから全バグ数を推定するも
のである。ＨＧＤＭソフトウェア信頼性モデルを使用し
た信頼度推定において、テストカバレッジ情報を加味
し、テストケースに基づいての信頼性の推定を計算する
には次のようにする。[Estimation of total number of bugs based on HGDM software reliability model using test case, number of bugs and test coverage information] This is to estimate the total number of bugs from the test case, the number of bugs and the test coverage information. To do. In the reliability estimation using the HGDM software reliability model, test coverage information is added and reliability estimation based on test cases is calculated as follows.
【００４９】図４はテストケースのテストカバレッジ情
報ｔｃｏ（ｉ）を示す。テストケースｔｃ（ｉ）による
テスト実施段階までにおいて発見されたバグに対する修
正の総数（ｍ（ｔｃ（ｉ）））の時系列データを表２に
示すようなＨＧＤＭソフトウェア信頼性モデルに当て嵌
め、モデルのパラメータの近似解を求める。FIG. 4 shows the test coverage information tco (i) of the test case. The time series data of the total number of modifications (m (tc (i))) to the bugs found by the test case tc (i) up to the test execution stage was applied to the HGDM software reliability model as shown in Table 2 to obtain a model. Find an approximate solution to the parameter of.
【００５０】[0050]
【表２】 [Table 2]
【００５１】ここで、ｔｃ（ｉ）はテストケース、Ｅ
［ｍ2 ］は潜在バグ数、Ｅ［ａts］，Ｅ［ｂts］はモデ
ルのフィッティング・パラメータを表わす。また、ｐ
（ｊ）はＨＧＤＭソフトウェア信頼性モデルの努力関数
である。テストケースのカバレッジｔｃｏ（ｊ）を求め
るのに使用するＥ［ａtco ］，Ｅ［ｂtco ］は最小２乗
法で時系列カバレッジデータから計算する。Here, tc (i) is a test case, E
[M 2 ] represents the number of latent bugs, and E [a ts ] and E [b ts ] represent model fitting parameters. Also, p
(J) is the effort function of the HGDM software reliability model. E [a tco ], E [b tco ] used to obtain the coverage tco (j) of the test case is calculated from the time series coverage data by the least square method.
【００５２】このようにテストケース数と不具合件数と
から信頼度を推定する一般的な推定方法に対して、さら
にテストカバレッジを加味することで、結果的にテスト
ケースの能力も加味した信頼度を推定することができ
る。By adding test coverage to the general estimation method for estimating the reliability from the number of test cases and the number of defects in this way, as a result, the reliability of the ability of the test case is also added. Can be estimated.
【００５３】図５はテストカバレッジの推定値を示すも
ので、使用したテストケース数の累積数とテストカバレ
ッジの割合の推移を示しており、使用したテストケース
数の累積数が増大するとテストカバレッジの割合も増大
している様子が読みとれる。FIG. 5 shows the estimated value of the test coverage and shows the transition of the cumulative number of used test cases and the ratio of the test coverage. When the cumulative number of used test cases increases, the test coverage of the test coverage increases. It can be seen that the proportion is increasing.
【００５４】このようにしてテストカバレッジの時系列
データを用いてＨＧＤＭソフトウェア信頼性モデルによ
り、潜在バグ数Ｅ［ｍ2 ］を推定することができると共
に、テストケースの能力の推定もできる。In this way, the number of latent bugs E [m 2 ] can be estimated by the HGDM software reliability model using the time-series data of the test coverage, and the ability of the test case can also be estimated.
【００５５】テストケースの能力とは、そのテストケー
スが発見できるバグの量の多さを表わす尺度である。プ
ログラム中にはバグは均一に存在しているとは限らない
ため、テストカバレッジが大きくても、発見できるバグ
数は少なかったり、逆にテストカバレッジが小さくとも
バグが多く存在する部分を通っていれば多くのバグが発
見される。これらの特徴を表わすのが、このテストケー
スの能力である。The ability of a test case is a measure of the amount of bugs that the test case can detect. Since bugs do not always exist uniformly in the program, even if the test coverage is large, the number of bugs that can be found is small, or conversely, even if the test coverage is small, it is possible to pass through the part where there are many bugs. Many bugs are discovered. It is this test case's ability to represent these characteristics.
【００５６】図６はＨＧＤＭによる推定結果を示すもの
で、テストに使用したテストケース数が増えるに連れて
発見されるバグ件数（欠陥および故障の数）が増大して
いる様子が示されている（符号６１で示される特性曲
線）。しかし、テストに使用したテストケース数が増え
てテストカバレッジが大きくなっても、発見できるバグ
数はあまり増えず、飽和状態になる場合もあり、この場
合は使用したテストケースの内容が良くないと言える。FIG. 6 shows an estimation result by the HGDM, and shows that the number of found bugs (the number of defects and failures) increases as the number of test cases used for the test increases. (Characteristic curve indicated by reference numeral 61). However, even if the number of test cases used for testing increases and the test coverage increases, the number of bugs that can be found does not increase so much and it may become saturated. In this case, the content of the test case used is not good. I can say.
【００５７】すなわち、図６においてａ部領域のように
テストに使用したテストケース数がまだ少ない状態であ
っても、発見されるバグ件数が増大している状態ではテ
ストケースの内容は「良い」とされるが、ｂ部領域のよ
うにテストに使用したテストケース数が増えてきても発
見されるバグ件数がほとんど増えなくなると、この段階
では使用しているテストケースの内容が「良くない」と
判断できる。That is, even if the number of test cases used for the test is still small like the area a in FIG. 6, the content of the test case is “good” when the number of detected bugs is increasing. However, even if the number of test cases used for testing increases like the part b area, if the number of found bugs hardly increases, the content of the test case used at this stage is “not good”. Can be judged.
【００５８】従って、この段階でテストに使用する予定
であるがまだ使用していないテストケースがいくつか、
あるいは多数残っているようなときは、テストケースが
不適として直ちにテストを中止させ、新たな別のテスト
ケースを用意してテストを続行させる。これにより、ｃ
部領域のように再び発見バグ数が増え、最終的にはある
推定値で飽和する（ｄ部領域参照）。Therefore, there are some test cases that we plan to use for testing at this stage but have not yet used,
If a large number of test cases remain, the test case is considered to be unsuitable and the test is immediately stopped, another new test case is prepared, and the test is continued. This gives c
The number of found bugs increases again as in the sub-region, and finally saturates at a certain estimated value (see the d-region).
【００５９】符号６２で示される一点鎖線のラインは実
際に発見されるバグ件数の推移を示す上述のライン６１
について直線近似で引いたラインを示しており、このラ
イン６２の傾きが急である程、使用したテストケースの
質が「良い」と判断できる。この場合、被テストプログ
ラムにおけるバグが多く存在する部分をテストしている
ことによりバグ発見率が高くなっていることもあり、従
って、テストカバレッジの割合も考慮して総合的にテス
トケースの「良さ」を判断する。The one-dot chain line indicated by reference numeral 62 is the above-mentioned line 61 showing the transition of the number of bugs actually found.
For the linear approximation, the steeper the slope of the line 62, the better the quality of the test case used. In this case, the bug detection rate may be high due to the fact that a lot of bugs in the program under test are being tested. Therefore, considering the rate of test coverage, the "goodness" of the test cases is comprehensively considered. To judge.
【００６０】このような処理を推定部１２ａに実施させ
ることにより、使用したテストケース数と発見されたバ
グ数とテストカバレッジ情報とから全バグ数とテストケ
ースの能力を推定することができる。By causing the estimating unit 12a to perform such processing, it is possible to estimate the total number of bugs and the performance of test cases from the number of used test cases, the number of discovered bugs, and the test coverage information.
【００６１】『推定したテストケースの能力から全体的
なテストケースの良さを推定する』上述のようにして推
定したテストケースの能力から全体的なテストケースを
良さを計るには次のようにする。 ［総合判断ルール１（推定結果の判断）］[Estimating Overall Goodness of Test Case from Estimated Test Case Capability] To measure overall goodness of test case from the performance of the test case estimated as described above, the following is performed. .. [Comprehensive judgment rule 1 (judgment of estimation result)]
【００６２】テストケースの良さの推定= Ｅ［ａts］*
gx(1)+Ｅ［ｂts］* gx(2) 但し、テストケースの能力はｔｓ（ｊ）＝Ｅ［ａts］＊
ｊ＋Ｅ［ｂts］である。また、gx(1) ，gx(2) はそれぞ
れ過去の経験に基づいて決められた重みである。なお、
上記したテストの良さの推定の式は１次式であり、直線
となる。Estimating Goodness of Test Case = E [a ts ] *
gx (1) + E [b ts ] * gx (2) However, the ability of the test case is ts (j) = E [a ts ] *
j + E [ bts ]. Further, gx (1) and gx (2) are weights determined based on past experience. In addition,
The above-described formula for estimating the goodness of the test is a linear formula and is a straight line.
【００６３】そして、この式において、フィッテング・
パラメータＥ［ａts］はテストケースの能力を傾きを示
すことになり、フィッテング・パラメータＥ［ｂts］は
Ｙ切片すなわちＹ座標軸との交点を示すことになり、ｇ
ｘは重みを与えることになる。従って、テストケースの
良さは上記直線の傾きとＹ切片の値との関係で推定す
る。Then, in this equation, the fitting
The parameter E [a ts ] will show the slope of the test case's capability, and the fitting parameter E [b ts ] will show the Y-intercept, ie the intersection with the Y coordinate axis, g
x will give a weight. Therefore, the goodness of the test case is estimated by the relationship between the slope of the straight line and the value of the Y intercept.
【００６４】つまり、信頼性モデルのフィッティング・
パラメータに経験に基づく重み付けをして得たテストケ
ースの能力ｔｓ（ｊ）とテストケースのカバレッジを考
慮した努力関数ｐ（ｊ）によってテストケースの良さを
推定することができる。そして、以上の推定は判定部１
５にて行われる。In other words, fitting the reliability model
The goodness of the test case can be estimated by the test case capability ts (j) obtained by weighting the parameters based on experience and the effort function p (j) considering the coverage of the test case. The above estimation is based on the determination unit 1
It will be held at 5.
【００６５】『推定部で推定されたそれぞれのバグ総数
をもとにした信頼度の高いバグ総数推定』この最終的な
推定は判断部１３で行う。ここでは推定部１２ｂ，１２
ｃにより上述の方法により得られた全バグ数の推定値で
ある潜在故障数Ｅ［ｍ1 ］，Ｅ［ｍ2 ］に対し、経験的
に得られたルールすなわち、熟練したソフトウェア技術
者がこれまでに蓄積したノウハウを基にして築き上げた
ルールを適用することによって、最終的なソフトウェア
の全バグ数（潜在する故障・欠陥の総数）を推定する。 推定の全バグ数 =Ｅ［ｍ1 ］*ex(1) +Ｅ［ｍ2 ］＊ ｅ
ｘ（２） ここでｅｘ（１），ｅｘ（２）はそれぞれ過去の経験に
基づいて定められた重みであり、[Estimation of total number of highly reliable bugs based on the total number of bugs estimated by the estimation unit] The determination unit 13 makes this final estimation. Here, the estimation units 12b and 12
With respect to the latent fault numbers E [m 1 ] and E [m 2 ] which are the estimated values of the total number of bugs obtained by the method c, the rule obtained empirically, that is, a skilled software engineer The total number of bugs (total number of potential failures / defects) of the final software is estimated by applying the rules built up based on the know-how accumulated up to now. Estimated total number of bugs = E [m 1 ] * ex (1) + E [m 2 ] * e
x (2) where ex (1) and ex (2) are weights determined based on past experience, respectively.
【００６６】[0066]
【数２】 ０．０ ＜ｅｘ（１），ｅｘ（２）＜ １．０ の値を持つ。次に上述のような処理手順を採用した本発
明の具体的な動作を図１乃至図３並びに図６のフローチ
ャートを用いて説明する。[Equation 2] It has a value of 0.0 < ex (1), ex (2) < 1.0. Next, a specific operation of the present invention that adopts the above-described processing procedure will be described with reference to the flowcharts of FIGS. 1 to 3 and FIG.
【００６７】ブロック図における符号１〜１０を付した
要素がプログラムテスト部を構成し、また、符号１１〜
１４を付した要素が推定部を構成し、また、符号１５，
１６を付した要素が信頼性判断部を構成している。Elements denoted by reference numerals 1 to 10 in the block diagram constitute a program test section, and reference numerals 11 to 11
Elements designated by 14 form an estimation unit, and reference numerals 15,
The elements with 16 form a reliability determination unit.
【００６８】まず初めに、テストケース入力手段１より
テストケース（テスト用の模擬情報）を入力し（Ｓ
１）、記憶装置２にテスト対象である開発中のプログラ
ムである被テストプログラムを格納する（Ｓ２）。First, a test case (simulated information for testing) is input from the test case input means 1 (S
1) First, a test program, which is a program under development and is a test target, is stored in the storage device 2 (S2).
【００６９】そして、システムを起動させると、システ
ムでは図示しない制御手段の制御のもとに、まず構文解
析部４が機能して構文解析が行われる（Ｓ３）。すなわ
ち、構文解析部４は記憶装置２から被テストプログラム
を読み込み、プログラムの構文を解析する。この構文解
析により、プログラム上での分岐位置、パスの経路（処
理の流れの辿るルート）、機能（関数：ファンクショ
ン）の種類等が解析される。Then, when the system is activated, the syntax analysis unit 4 first functions to perform syntax analysis under the control of the control means (not shown) in the system (S3). That is, the syntax analysis unit 4 reads the program under test from the storage device 2 and analyzes the syntax of the program. By this syntax analysis, the branch position on the program, the path of the path (route along which the processing flow follows), the type of function (function), and the like are analyzed.
【００７０】次にテストケース処理部３における処理が
実施される。ここでの処理はまず記憶装置２から被テス
トプログラムの読み込みが行われ、ついでテスト終了か
否かが判定され（Ｓ４）、テストが未終了であればテス
トケース処理部３はテストケース入力手段１より入力さ
れた未終了のテストケースの一つを用いて被テストプロ
グラムを実行させてみる（Ｓ５）。Next, the processing in the test case processing unit 3 is carried out. In this process, the test program is first read from the storage device 2, and then it is determined whether or not the test is completed (S4). If the test is not completed, the test case processing unit 3 causes the test case input means 1 The test program is executed by using one of the unfinished test cases input by the operator (S5).
【００７１】そして、テストケースをカウントし（Ｓ
６）、テストカバレッジを測定する（Ｓ８）。すなわ
ち、テストケース処理部３は処理を開始すると、テスト
ケースレジスタ９をインクリメントさせ、また、カバレ
ッジ処理部５に現在のプログラム処理位置の情報を与え
てテストカバレッジを測定させる。カバレッジ処理部５
は現在のプログラム処理位置の情報と被テストプログラ
ムおよび構文解析の情報をもとにカバレッジを測定して
ゆく。この測定結果はデータ記憶部１１ａ，１１ｂのう
ち、それぞれ対応するものに与えられ、累積されて保存
される。Then, the test cases are counted (S
6), test coverage is measured (S8). That is, when the test case processing unit 3 starts the processing, the test case register 9 is incremented, and the coverage processing unit 5 is given the information of the current program processing position to measure the test coverage. Coverage processing unit 5
Measures the coverage based on the information of the current program processing position and the information of the program under test and the syntax analysis. The measurement result is given to the corresponding one of the data storage units 11a and 11b, accumulated, and stored.
【００７２】テストケース処理部３は使用したテストケ
ースに基づく処理が終了するとこの処理で発生したバグ
を計数する（Ｓ９）。これはテストケース処理部３が処
理を実行するにあたり、テストケースと共に与えられて
いた期待値をテスト結果期待値保持部６に格納してお
り、また、テストケース処理部３での処理の結果、得ら
れるデータをテスト結果の情報としてテスト結果期待値
保持部６に格納しているので、これらテスト結果と期待
値をバグ検出部７が比較してバグの有無を調べ、バグ有
の時はその数を計数することで、当該実施に供したテス
トケースでのバグ数を求めることができる。When the processing based on the used test case ends, the test case processing unit 3 counts the bugs generated in this processing (S9). This is because when the test case processing unit 3 executes the processing, the expected value given together with the test case is stored in the test result expected value holding unit 6, and the result of the processing in the test case processing unit 3 is Since the obtained data is stored in the test result expected value holding unit 6 as the information of the test result, the bug detecting unit 7 compares the test result and the expected value with each other to check for a bug. By counting the number, the number of bugs in the test case used for the implementation can be obtained.
【００７３】バグの中には期待値と異なる結果を出すこ
とになったプログラム上の欠陥の他に、ハングアップす
るような欠陥もあり、テストケース処理部３がハングア
ップしてしまうような欠陥の場合はシステムが停止する
ことになるが、このようなハングアップについてもバグ
検出部７は検出して計数できるものとする。Among the bugs, in addition to defects in the program that result in a result different from the expected value, there is also a defect that causes a hangup, which causes the test case processing unit 3 to hang up. In this case, the system will be stopped, but the bug detection unit 7 can detect and count such a hang-up.
【００７４】一つのテストケースに基づく処理が終了す
るとテストケース処理部３は再びステップＳ４の処理に
戻り、テスト終了か否かが判定される。つまり、未終了
のテストケースが残っているか否かを調べて、未終了の
ものがあればその未終了のテストケースの一つを用いて
上述のテストを実施する。そして、ステップＳ５以下の
処理を行う。When the processing based on one test case is completed, the test case processing section 3 returns to the processing of step S4 again, and it is judged whether or not the test is completed. That is, it is checked whether or not an unfinished test case remains, and if there is an unfinished test case, the above-mentioned test is performed using one of the unfinished test cases. Then, the processing from step S5 onward is performed.
【００７５】ステップＳ４での処理の結果、未終了のも
のがなければ、テストケース処理部３はテストケースを
用いての処理を終了する。この終了により、図示しない
制御手段は次にデータ記憶部１１ａ，１１ｂに格納され
たデータを用いての推定演算処理に移るべく制御する。
また、このとき、バグ検出部７は計数したバグ数をデー
タ記憶部１１ａ，１１ｂに与えこれらに格納させると共
に、判断部１５にも与える。If there is no unfinished one as a result of the processing in step S4, the test case processing section 3 finishes the processing using the test case. With this end, the control means (not shown) controls to move to the estimation calculation processing using the data stored in the data storage units 11a and 11b.
At this time, the bug detection unit 7 gives the counted number of bugs to the data storage units 11a and 11b to store them in the data storage units 11a and 11b, and also gives them to the determination unit 15.
【００７６】データ記憶部１１ａ，１１ｂに格納された
データを用いての推定演算処理に移ると、各推定部１２
ａ，１２ｂ，１２ｃは対応するデータ記憶部１１ａ，１
１ｂに格納されたデータを用いて上述した所定の演算を
行い、テストケースの能力の推定、バグ数の推定を行
う。When the estimation calculation process using the data stored in the data storage units 11a and 11b is started, each estimation unit 12
a, 12b, 12c are corresponding data storage units 11a, 1
The above-described predetermined calculation is performed using the data stored in 1b to estimate the performance of the test case and the number of bugs.
【００７７】すなわち、データ記憶部１１ａにはテスト
カバレッジＴＣとバグ数ＮおよびテストケースＴＮが格
納されており、推定部（１）１２ａはこれらを用いて上
述の演算を行い、テストケースの能力を推定する（Ｓ１
１）。また、推定部（２）１２ｂはデータ記憶部１１ａ
に記憶されているテストカバレッジＴＣとバグ数Ｎおよ
びテストケースＴＮを用いて上述の演算を行い、潜在故
障および欠陥の総数を推定する（Ｓ１０）。また、デー
タ記憶部１１ｂにはテストケース数ＴＮとバグ数Ｎが格
納されており、推定部（３）１２ｃはこれらを用いて上
述の演算を行い、潜在故障および欠陥の総数を推定する
（Ｓ１２）。That is, the test coverage TC, the number of bugs N, and the test case TN are stored in the data storage unit 11a, and the estimation unit (1) 12a performs the above-mentioned calculation using these to determine the test case capability. Estimate (S1
1). Also, the estimation unit (2) 12b is the data storage unit 11a.
The above calculation is performed using the test coverage TC, the number of bugs N, and the test case TN stored in (3) to estimate the total number of latent failures and defects (S10). Further, the number of test cases TN and the number of bugs N are stored in the data storage unit 11b, and the estimation unit (3) 12c performs the above calculation using these to estimate the total number of latent failures and defects (S12). ).
【００７８】このようにして推定部１２ａによりテスト
ケースの能力が、また、各推定部１２ｂ，１２ｃにより
潜在故障および欠陥の総数が求まると、判断部（１）１
３による総合判断（推定）が行われ（Ｓ１３）、また、
判断部（２）１５によるテストケースの良さの判断（推
定）が行われる（Ｓ１４）。In this way, when the estimation unit 12a obtains the test case capability and the estimation units 12b and 12c obtain the total number of latent failures and defects, the determination unit (1) 1
A comprehensive judgment (estimation) based on 3 is made (S13), and
The determination unit (2) 15 determines (estimates) the goodness of the test case (S14).
【００７９】判断部（１）１３での総合判断は次のよう
にして行う。すなわち、２つの推定部１２ｂ，１２ｃか
ら得られた全バグ数の推定値である潜在故障数Ｅ［ｍ
１ ］，Ｅ［ｍ2 ］を知識部１４に格納された熟練ソフ
トウェア技術者（単数もしくは複数）の経験に基づくル
ールに従って重み付け演算する。そして、潜在故障・欠
陥の総数を得る。得られたものは推定値であるが、熟練
ソフトウェア技術者の経験を加味して重み付け演算して
あり、しかも、一般的なテストケースＴＮとバグ数Ｎと
を用いたＨＧＤＭモデルでのバグ推定値と、さらにこれ
にテストカバレッジＴＣを加味したＨＧＤＭモデルでの
バグ推定値とを利用していることから、最終結果として
得られる推定値は現場での経験や実感に極めて近い値と
なる。また、これと並行して判断部（２）１５によるテ
ストケースの良さの推定が行われる（Ｓ１４）。The comprehensive judgment by the judgment unit (1) 13 is performed as follows. That is, the potential failure count E [m, which is the estimated value of the total number of bugs obtained from the two estimation units 12b and 12c.
1 ] and E [m 2 ] are weighted according to a rule based on the experience of an experienced software engineer (single or plural) stored in the knowledge unit 14. Then, the total number of latent failures / defects is obtained. The obtained value is an estimated value, but the weighted operation is performed in consideration of the experience of a skilled software engineer, and the estimated value of a bug in an HGDM model using a general test case TN and the number of bugs N Further, since the bug estimation value in the HGDM model in which the test coverage TC is further added is used, the estimation value obtained as a final result is a value extremely close to the experience and actual feeling in the field. Further, in parallel with this, the judgment unit (2) 15 estimates the goodness of the test case (S14).
【００８０】そして、これらを判断結果抽出手段１６に
与えて処理を終了する。判断結果抽出手段１６では、上
述の推定した潜在故障・欠陥の総数とテストケースの良
さの情報を出力する。Then, these are given to the judgment result extracting means 16 and the processing is ended. The determination result extraction means 16 outputs the information on the estimated total number of latent failures / defects and the goodness of the test case.
【００８１】なお、本システムではバグが検出される
と、図示しない報知手段によりその内容が表示され、プ
ログラマあるいはオペレータに知らせる。プログラマは
これに基づき、プログラムの修正を行うことになる。In this system, when a bug is detected, the content is displayed by the notifying means (not shown) to notify the programmer or the operator. The programmer will modify the program based on this.
【００８２】このような処理の結果、本システムでは被
テストプログラムに対する現時点での潜在故障・欠陥の
総数と使用しているテストケースの良さを一定の確かさ
をもって得ることができる。As a result of such processing, the present system can obtain the total number of latent failures / defects for the program under test and the goodness of the test case being used with a certain degree of certainty.
【００８３】以上は一般的な動作を説明した。しかし、
被テストプログラムに対するテストカバレッジＴＣはど
のようなものかは触れていないので、わかり難い面があ
ることから、これについて具体的例をあげて説明してお
く。The general operation has been described above. But,
Since there is no mention of what the test coverage TC for the program under test is, it is difficult to understand, so this will be explained with a specific example.
【００８４】図８乃至図１１に被テストプログラム例を
示す。図８は全体の内容を示す図であり、図９乃至図１
１はその部分拡大図である。この被テストプログラムは
エンジンの制御プログラムの例であり、加速する場合は
ブレーキ操作がない状態に限られ、ブレーキが操作され
ている場合に加速制御されようとすると警報を出し、ま
た、定速維持の時はブレーキが操作されている場合に警
報を出し、そうでない場合にのみ、回転を維持するよう
に制御する。また、アクセルも踏まれず、定速維持でも
ない時は、ブレーキ操作されていないときにゆっくりと
低速回転方向に制御を移し、ブレーキ操作されている時
は速く低速回転方向に制御を移すと云った内容である。8 to 11 show examples of the program under test. FIG. 8 is a diagram showing the entire contents, and FIGS.
1 is a partially enlarged view thereof. This test program is an example of an engine control program.When accelerating, it is limited to the state where there is no brake operation.When the brake is being operated, an alarm is issued if an acceleration control is attempted and a constant speed is maintained. At the time of, the alarm is issued when the brake is operated, and only otherwise is controlled to maintain the rotation. Moreover, when the accelerator is not stepped on and the vehicle is not maintaining a constant speed, the control is slowly moved to the low speed rotation direction when the brake is not operated, and the control is quickly transferred to the low speed rotation direction when the brake is operated. It is the content.
【００８５】このプログラムをフローチャートで示すと
図１２の如きとなる。このプログラムにおいて、フロー
チャート上での長方形枠で囲まれる部分（図８〜図１１
に示したプログラム上では図１３に枠で囲んでわかり易
く示した部分）は機能（関数：ファンクション）部分で
あり、この例の場合、丸で囲んだ符号A1〜A11 を付して
示したように、１１個あるが同一名称の機能、例えば、
“ＷＡＲＮＩＮＧ”同士、“ＣＨＥＣＫ ＢＲＡＫＥ
Ｓ”同士は同じものである。The flow chart of this program is as shown in FIG. In this program, the part surrounded by the rectangular frame on the flowchart (see FIGS. 8 to 11).
In the program shown in Fig. 13, the portion (shown in a box for easy understanding) in Fig. 13 is a function (function) portion. In this example, as indicated by the circled symbols A1 to A11, , 11 functions with the same name, for example,
"WARNING" together, "CHECK BRAKE
The S's are the same.
【００８６】すなわち、プログラム上ではA1〜A11 を付
して示した各関数は、そのプログラム内容を示すと図１
４の如きであり、符号A1を付して示した関数名の関数は
図１４において符号B1を付して示したプログラム内容が
該当し、符号A2を付して示した関数名の関数は図１４に
おいて符号B2を付して示したプログラム内容が該当する
と云った具合に、番号で対応させて示してあるが、これ
によると、符号A3とA6で示した関数名“ＷＡＲＮＩＮＧ
（）”なる関数は図１４にB3，B6を付して示したよう
に、いずれも同一のプログラムモジュールを実行するこ
とになる。従って、同一関数名のプログラムモジュール
は１度実行されれば、パスが通ったことになり、実行結
果に問題がなければ以後検証する必要はないことにな
る。That is, each function shown by adding A1 to A11 on the program is shown in FIG.
4, the function having the function name indicated by reference numeral A1 corresponds to the program content indicated by reference numeral B1 in FIG. 14, and the function indicated by the reference numeral A2 indicates the function In FIG. 14, the program contents indicated by reference numeral B2 in FIG. 14 correspond to the program contents by numbers, and according to this, the function name “WARNING” indicated by reference numerals A3 and A6 is shown.
As shown by adding B3 and B6 in FIG. 14, the function "()" executes the same program module. Therefore, if the program modules with the same function name are executed once, It means that the path has passed, and if there is no problem in the execution result, there is no need to verify it.
【００８７】図８〜１１のサンプルプログラムにおい
て、今、テストケースとして“ACCELERATOR=1 （アクセ
ルは踏み込まない）”，“CONSTANT=1（アクセル位置を
キープする）”，“BREAK=1 （ブレーキを踏む）”，
“user*input（運転終了）”を設定してテストを開始さ
せたとする。In the sample programs of FIGS. 8 to 11, as test cases, "ACCELERATOR = 1 (accelerator does not press down)", "CONSTANT = 1 (keep accelerator position)", "BREAK = 1 (press brake) ) ”,
It is assumed that the test is started by setting "user * input (end of operation)".
【００８８】このテストケースの場合、設定は“ACCELE
RATOR=1 ”，“CONSTANT=1”，“BREAK=1 ”，“user*i
nput”だけであるから、プログラム上で実行されるのは
これらの関数に係わる部分のみとなる。そして、これら
の関数において関係することになるプログラム上のブラ
ンチ（分岐）は図１５に符号C1〜C6を付して示したアン
ダーラインの箇所（６箇所）のみであり、テストケース
の設定条件に従えば、図１６に示すフローチャート上に
符号Ｐを付して示した矢印のルートを辿るパスのみとな
る。そして、このルートでは通過したブランチの数は４
であり、通過した関数の数は５である。For this test case, the setting is "ACCELE
RATOR = 1 ”,“ CONSTANT = 1 ”,“ BREAK = 1 ”,“ user * i
Since it is only nput ”, only the part related to these functions is executed on the program. And the branch in the program which is related to these functions is C1 to C1 in FIG. Only the underlined portions (6 locations) indicated by C6 are provided, and according to the setting conditions of the test case, only the paths that follow the route of the arrow indicated by the symbol P on the flowchart shown in FIG. And the number of branches passed by this route is 4
And the number of passed functions is 5.
【００８９】サンプルプログラムの場合、ブランチの総
数はIF文で示される部分の数の２倍であり、これは１２
個であり、関数の総数は同一名称のものは一つとしてる
数えると８個であるから、上記のテストケースによりブ
ランチカバレッジは４／１２で３３．３３％、ファンク
ションカバレッジは５／８で６２．５％となる。In the case of the sample program, the total number of branches is twice the number of parts indicated by the IF statement, which is 12
The total number of functions is eight when the number of functions having the same name is counted as one. Therefore, according to the above test case, branch coverage is 4/12 and 33.33%, and function coverage is 5/8 and 62. It becomes 0.5%.
【００９０】カバレッジ処理部５には現在のプログラム
処理位置の情報と被テストプログラムおよび構文解析の
情報をもとにこのような処理を行わせることで、カバレ
ッジを測定させることができる。従って、この結果とバ
グ検出部７からの検出バグ数により、テストカバレッジ
による潜在故障および欠陥の総数ａ１と期待発見率ｂ１
との推定が可能になる。The coverage processing unit 5 can measure the coverage by performing such processing based on the information on the current program processing position, the program under test, and the information on the syntax analysis. Therefore, based on this result and the number of detected bugs from the bug detection unit 7, the total number of latent failures and defects due to the test coverage a1 and the expected discovery rate b1.
Can be estimated.
【００９１】以上、本発明はテストのために用意した各
種条件に従って評価対象のソフトウェアを実行させる実
行手段にて、テスト・ランを行い、これによりテストカ
バレッジおよびテストケース数および検出故障・欠陥数
を時系列情報として得、これらテストカバレッジおよび
テストケース数および検出故障・欠陥数の情報を利用し
てテストケース能力推定手段によりテストケースの能力
を推定し、これによってある時点までに使用したテスト
ケースにより検出された故障・欠陥数とテストカバレッ
ジの時系列情報をもとにした当該使用テストケースの能
力の推定値を得、また、第１の故障・欠陥総数推定手段
により上記テストカバレッジおよびテストケース数およ
び検出された故障・欠陥数とから、超幾何分布モデルを
用いての上記被テストソフトウェアの持つ故障・欠陥総
数を、上記情報取得時点までに使用したテストケース数
とその時点までのテストカバレッジとおよび検出故障・
欠陥数に基づく推定値として求め、また、第２の故障・
欠陥総数推定手段により、テストケース数および検出さ
れた故障・欠陥数とから、超幾何分布モデルを用いての
上記被テストソフトウェアの持つ故障・欠陥総数を推定
値として求め、これら各故障・欠陥総数推定手段により
得られた推定結果に対して、総合判断手段により、過去
の経験に基づくルール（条件と重みから構成される）を
適用して重み付け加算し、最終的な故障・欠陥総数の推
定結果を得、また、テストケースの良さの推定手段によ
り、前記テストケース能力推定手段により得たテストケ
ース能力の推定結果を、過去の経験に基づくルールを適
用して、テストケースの良さの度合いを推定すると云う
ものである。As described above, according to the present invention, a test run is performed by the execution means for executing the software to be evaluated according to various conditions prepared for the test, and the test coverage and the number of test cases and the number of detected failures / defects are thereby determined. It is obtained as time-series information, and the capability of the test case is estimated by the test case capability estimation means using the information on the test coverage, the number of test cases, and the number of detected faults / defects. An estimated value of the capability of the used test case is obtained based on the detected failure / defect number and time-series information of the test coverage, and the above-mentioned test coverage and test case number are obtained by the first failure / defect total estimation means. And the number of detected faults / defects, the The fault-defects Total number possessed by preparative software, test coverage and and detection failure of the number of test cases used until the information acquisition point and up to the point,
Obtained as an estimated value based on the number of defects, and
From the total number of test cases and the number of detected faults / defects by the total number of defects estimation means, the total number of faults / defects possessed by the software under test using the hypergeometric distribution model is obtained as an estimated value, and the total number of each fault / defect is calculated. The total judgment means applies a rule (consisting of conditions and weights) based on past experience to the estimation results obtained by the estimation means, adds the weights, and finally estimates the total number of failures and defects. The estimation result of the test case ability is estimated by the estimation method of the goodness of the test case, and the degree of the goodness of the test case is estimated by applying the rule based on the past experience to the estimation result of the test case ability. That is why.
【００９２】そして、２つの故障・欠陥総数推定手段に
より得られた推定結果は超幾何分布モデルをソフトウェ
ア信頼度成長モデルとして使用し、一つはテストケース
数と検出バグ総数とによる一般的手法によるものとし
て、もう一つはこれにさらにテストカバレッジを加味し
た手法によるものとして得ており、これらを熟練したソ
フトウェア開発技術者の経験と勘に基づくルールに当て
嵌めて重み付け加算して最終的な故障・欠陥の総数（バ
グ総数）の推定値を得るから、推定結果はより現実味を
帯びた精度の高いものとなり、しかも、こうして得た故
障・欠陥総数の推定結果およびその時点までに使用した
テストケースの良さに関する情報を算出して合わせて提
供するものであるから、現在のバグ総数の推定値をもと
に、被テストソフトウェアの抱える処置しなければなら
ないバグ数が掴めることになり、従って、被テストソフ
トウェアを製品としてリリース可能となるに要する開発
期間の予測が立つようになって、開発スケジュールをた
てることができるようになる他、テストケースの良さの
指標を出力できるので、現在使用しているテストケース
の適不適が途中段階でわかり、従って、不適の場合には
テストケースの変更を早目に行うことができて、その
分、無駄なテストを行わずにすむようになり、開発コス
トの低減を図ることができるようになるなど、ソフトウ
ェアの開発現場で十分に役に立つ品質評価システムが得
られる。The estimation results obtained by the two fault / defect total estimation means use the hypergeometric distribution model as a software reliability growth model, and the first one is a general method based on the number of test cases and the total number of detected bugs. The other one was obtained as a method that added test coverage to this, and these were applied to the rules based on the experience and intuition of experienced software development engineers, and weighted addition was performed to make the final failure.・ Because an estimate of the total number of defects (total number of bugs) is obtained, the estimation result becomes more realistic and highly accurate, and the estimation result of the total number of defects and defects obtained in this way and the test cases used up to that point Since the information about the goodness of the software is calculated and provided together, the software under test is based on the current estimated total number of bugs. The number of bugs that the software has to deal with can be grasped. Therefore, the development period required for the software under test to be released as a product can be predicted, and the development schedule can be set up. In addition to the above, the indicator of the goodness of the test case can be output, so that the suitability of the currently used test case can be known at an intermediate stage. Therefore, if it is not suitable, it is possible to change the test case early. By doing so, it is possible to avoid unnecessary tests, and it is possible to reduce the development cost. Therefore, it is possible to obtain a quality evaluation system that is sufficiently useful in software development sites.
【００９３】また、上述したように従来のソフトウェア
品質評価法に比べて実際の開発現場にいる人間の感覚や
経験を取り入れた形で、ソフトウェアの信頼性が算出さ
れるため、より現実的な値を提供することができ、そし
て、この推定結果を開発の進捗状況に合わせて開発チー
ムに提示してゆくことにができるので、後戻りなどによ
る開発コストを削減することが可能になると同時に、最
終的には一定以上の信頼性を保証されたソフトウェアを
開発することが可能になる。なお、本発明は上記し、且
つ、図面に示す実施例に限定することなく、その要旨を
変更しない範囲内で適宜変形して実施し得るものであ
る。Further, as described above, the reliability of the software is calculated in a form that incorporates the sense and experience of the human being in the actual development site, as compared with the conventional software quality evaluation method, so that a more realistic value is obtained. Since the estimated result can be provided to the development team according to the progress of development, it is possible to reduce the development cost due to backtracking etc. Makes it possible to develop software with a certain degree of reliability guaranteed. The present invention is not limited to the embodiments described above and shown in the drawings, but can be appropriately modified and carried out within the scope of the invention.
【００９４】[0094]
【発明の効果】以上、詳述したように、本発明によれ
ば、従来のソフトウェア信頼性推定方法に比べ、テスト
カバレッジや実際の開発現場にいる人々の感覚や経験を
取り入れてソフトウェア信頼性が算出されるため、より
現実的な値を提供することができる。また、テストケー
スの能力を推定することで、テストケースの能力が高く
なるようにテスト戦略を変更することができて、テスト
の効率化を支援することができるようになる。As described above in detail, according to the present invention, the software reliability is improved by incorporating the test coverage and the feeling and experience of people in the actual development site, as compared with the conventional software reliability estimation method. Since it is calculated, a more realistic value can be provided. In addition, by estimating the ability of the test case, it is possible to change the test strategy so that the ability of the test case becomes higher, and it becomes possible to support the efficiency of the test.
【００９５】そして、この推定結果を開発の進捗に合わ
せて開発チームに提示してゆくことによって、ソフトウ
ェアを出荷する以前に、ソフトウェアの信頼性を推定す
ることができるので、開発進捗、テスト進捗、修正進捗
を監視することができる。By presenting this estimation result to the development team according to the progress of development, the reliability of the software can be estimated before shipping the software. You can monitor the modification progress.
【００９６】このように、一定の信頼性を以て信頼性推
定を行うことができ、また、使用するテストケースの適
否をも判定することができて、無駄なテストを続けるこ
とも防止でき、従って、リリース時期やソフトウェア開
発の進捗状況なども適確に判断することができるように
したソフトウェア品質評価装置およびソフトウェア品質
評価方法を提供することができる。As described above, the reliability can be estimated with a certain reliability, the suitability of the test case to be used can be determined, and the unnecessary test can be prevented from being continued. It is possible to provide a software quality evaluation device and a software quality evaluation method capable of appropriately determining the release time and the progress of software development.
【図１】本発明の一実施例を示す全体構成のブロック
図。FIG. 1 is a block diagram of an overall configuration showing an embodiment of the present invention.
【図２】図１の部分拡大図。FIG. 2 is a partially enlarged view of FIG.
【図３】図１の部分拡大図。FIG. 3 is a partially enlarged view of FIG.
【図４】テストケースに基づいたＨＧＤＭ信頼性推定を
説明するための図。FIG. 4 is a diagram for explaining HGDM reliability estimation based on test cases.
【図５】使用したテストケース数の累積数とテストカバ
レッジの割合の推移を説明するための図。FIG. 5 is a diagram for explaining the transition of the cumulative number of used test cases and the ratio of test coverage.
【図６】使用したテストケース数の累積数と発見される
バグ件数の推移との関係の一例を説明するための図。FIG. 6 is a diagram for explaining an example of the relationship between the cumulative number of used test cases and the transition of the number of found bugs.
【図７】本発明装置の作用を説明するフローチャート。FIG. 7 is a flowchart explaining the operation of the device of the present invention.
【図８】本発明におけるカバレッジ情報収集の具体的例
を説明するためのサンプルプログラムを示す図。FIG. 8 is a diagram showing a sample program for explaining a specific example of coverage information collection according to the present invention.
【図９】図８の部分拡大図。9 is a partially enlarged view of FIG.
【図１０】図８の部分拡大図。10 is a partially enlarged view of FIG.
【図１１】図８の部分拡大図。11 is a partially enlarged view of FIG.
【図１２】カバレッジ情報収集の具体的例を説明するた
めのフローチャート。FIG. 12 is a flowchart for explaining a specific example of coverage information collection.
【図１３】カバレッジ情報収集の具体的例を説明するた
めの図。FIG. 13 is a diagram for explaining a specific example of coverage information collection.
【図１４】カバレッジ情報収集の具体的例を説明するた
めの図。FIG. 14 is a diagram for explaining a specific example of coverage information collection.
【図１５】カバレッジ情報収集の具体的例を説明するた
めの図。FIG. 15 is a diagram for explaining a specific example of coverage information collection.
【図１６】カバレッジ情報収集の具体的例を説明するた
めの図。FIG. 16 is a diagram for explaining a specific example of coverage information collection.
１…テストケース入力手段、２…被テストプログラムを
格納した記憶装置、３…テストケース処理部、４…構文
解析部、５…カバレッジ処理部、６…テスト結果期待値
保持部、７…バグ検出部、９…テストケースレジスタ、
１０…プログラム修正部、１１ａ，１１ｂ…データ記憶
部、１２ａ〜１２ｃ…推定部、１３…判断部、１４…知
識部、１５…第２の判断部、１６…判断結果抽出部。DESCRIPTION OF SYMBOLS 1 ... Test case input means, 2 ... Storage device in which the program under test is stored, 3 ... Test case processing part, 4 ... Parsing part, 5 ... Coverage processing part, 6 ... Test result expected value holding part, 7 ... Bug detection Part, 9 ... Test case register,
10 ... Program correction part, 11a, 11b ... Data storage part, 12a-12c ... Estimating part, 13 ... Judgment part, 14 ... Knowledge part, 15 ... Second judgment part, 16 ... Judgment result extraction part.
Claims (4)
あるテストケースに従って評価対象のソフトウェアを実
行させる実行手段と、 この実行手段による実行に使用したテストケース数の情
報と、前記実行手段により前記評価対象のソフトウェア
を実行させた際におけるこの評価対象のソフトウェアの
実行済み部分の割合を示すテストカバレッジ情報と、前
記実行により検出された故障・欠陥の数とをデータ収集
するテストデータ収集手段と、 この収集したデータをもとに、テストケースの有する前
記評価対象のソフトウェアに対する故障・欠陥発見能力
のパラメータであるテストケースの能力を推定するテス
トケース能力推定手段と、 この推定されたテストケースの能力について経験に基づ
く所定の規則に従って補正し、テストカバレッジの情報
を用いて処理することにより、テストケースの良さを算
出する手段と、 前記テストデータ収集手段の収集したデ−タをもとに、
ソフトウェア信頼性成長モデルに基づいて前記評価対象
ソフトウェアに潜在の故障・欠陥の総数推定値を得る第
１の推定手段と、 前記テストデータ収集手段の収集したデ−タのうち、テ
ストケース数の情報と検出故障・欠陥の数とを用い、ソ
フトウェア信頼性成長モデルに基づいて前記評価対象ソ
フトウェアに潜在の故障・欠陥の総数推定値を得る第２
の推定手段と、 これら第１および第２の推定手段により推定された各推
定値に対して、蓄積された経験に基づく所定の規則に従
って処理することにより、故障・欠陥の総数の推定結果
を得る総合判断手段とより構成したことを特徴とするソ
フトウェア品質評価装置。1. An executing means for executing software to be evaluated according to a test case, which is a group of various conditions prepared for testing, information on the number of test cases used for execution by the executing means, and the executing means. A test data collecting unit that collects data of test coverage information indicating a ratio of an executed portion of the evaluation target software when the evaluation target software is executed, and the number of failures / defects detected by the execution. , Based on the collected data, a test case capability estimating means for estimating the capability of the test case, which is a parameter of the fault / defect finding capability for the software to be evaluated included in the test case, and the estimated test case Test coverage is corrected according to prescribed rules based on experience Based on the data collected by the means for calculating the goodness of the test case by processing using the information of
First estimating means for obtaining a total estimated value of potential failures / defects in the evaluation target software based on a software reliability growth model, and information on the number of test cases among the data collected by the test data collecting means. And a number of detected failures / defects to obtain an estimated total number of potential failures / defects in the evaluation target software based on a software reliability growth model.
And the respective estimation values estimated by the first and second estimation means are processed according to a predetermined rule based on accumulated experience to obtain an estimation result of the total number of failures / defects. A software quality evaluation device comprising a comprehensive judgment means.
分布モデルであることを特徴とする請求項１記載のソフ
トウェア品質評価装置。2. The software quality evaluation apparatus according to claim 1, wherein the software reliability growth model is a hypergeometric distribution model.
あるテストケースに従って評価対象のソフトウェアを実
行させる実行ステップと、 この実行ステップでの実行に使用したテストケース数の
情報と、実行ステップでの前記評価対象のソフトウェア
を実行させた際におけるこの評価対象のソフトウェアの
実行済み部分の割合を示すテストカバレッジ情報と、前
記実行により検出された故障・欠陥の数とをデータ収集
するテストデータ収集ステップと、 この収集したデータをもとに、テストケースの有する前
記評価対象のソフトウェアに対する故障・欠陥発見能力
のパラメータであるテストケースの能力を推定するテス
トケース能力推定ステップと、 この推定されたテストケースの能力について経験に基づ
く所定の規則に従って補正し、テストカバレッジの情報
を用いて処理することにより、テストケースの良さを算
出する算定ステップと、 前記テストデータ収集ステップでの収集デ−タをもと
に、ソフトウェア信頼性成長モデルに基づいて前記評価
対象ソフトウェアに潜在の故障・欠陥の総数推定値を得
る第１の推定ステップと、 前記テストデータ収集ステップでの収集デ−タのうち、
テストケース数の情報と検出故障・欠陥の数とを用い、
ソフトウェア信頼性成長モデルに基づいて前記評価対象
ソフトウェアに潜在の故障・欠陥の総数推定値を得る第
２の推定ステップと、 これら第１および第２の推定ステップにより推定された
各推定値に対して、蓄積された経験に基づく所定の規則
に従って処理することにより、故障・欠陥の総数の推定
結果を得る総合判断ステップとより構成したことを特徴
とするソフトウェア品質評価方法。3. An execution step for executing software to be evaluated according to a test case, which is a group of various conditions prepared for testing, information on the number of test cases used for execution in this execution step, and an execution step A test data collecting step of collecting data of test coverage information indicating a ratio of an executed portion of the evaluation target software when the evaluation target software is executed, and the number of failures / defects detected by the execution. And a test case capability estimation step for estimating the capability of the test case, which is a parameter of the failure / defect finding capability of the evaluation target software of the test case, based on the collected data, and the estimated test case The ability of the Based on the software reliability growth model based on the calculation step of calculating the goodness of the test case by processing using the information of the test coverage and the collected data in the test data collecting step. A first estimating step of obtaining a total estimated value of latent failures / defects in software, and collecting data in the test data collecting step,
Using information on the number of test cases and the number of detected failures / defects,
For a second estimation step of obtaining a total estimation value of potential failures / defects in the evaluation target software based on the software reliability growth model, and for each estimation value estimated by the first and second estimation steps. A software quality evaluation method comprising: a comprehensive judgment step for obtaining an estimation result of the total number of failures / defects by processing according to a predetermined rule based on accumulated experience.
分布モデルであることを特徴とする請求項３記載のソフ
トウェア品質評価方法。4. The software quality evaluation method according to claim 3, wherein the software reliability growth model is a hypergeometric distribution model.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP4122233A JPH05324309A (en) | 1992-05-14 | 1992-05-14 | Device and method for evaluating software quality |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP4122233A JPH05324309A (en) | 1992-05-14 | 1992-05-14 | Device and method for evaluating software quality |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH05324309A true JPH05324309A (en) | 1993-12-07 |
Family
ID=14830871
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP4122233A Pending JPH05324309A (en) | 1992-05-14 | 1992-05-14 | Device and method for evaluating software quality |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH05324309A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008165491A (en) * | 2006-12-28 | 2008-07-17 | Hitachi Ltd | Software quality evaluation device and method |
| JP2010072883A (en) * | 2008-09-17 | 2010-04-02 | Nec Corp | Program verification apparatus, program verification method, and program |
| US10948900B2 (en) | 2009-11-03 | 2021-03-16 | Applied Materials, Inc. | Display of spectra contour plots versus time for semiconductor processing system control |
| CN112988577A (en) * | 2021-03-08 | 2021-06-18 | 中国地震局第二监测中心 | Rapid software evaluation execution method |
-
1992
- 1992-05-14 JP JP4122233A patent/JPH05324309A/en active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008165491A (en) * | 2006-12-28 | 2008-07-17 | Hitachi Ltd | Software quality evaluation device and method |
| JP2010072883A (en) * | 2008-09-17 | 2010-04-02 | Nec Corp | Program verification apparatus, program verification method, and program |
| US10948900B2 (en) | 2009-11-03 | 2021-03-16 | Applied Materials, Inc. | Display of spectra contour plots versus time for semiconductor processing system control |
| CN112988577A (en) * | 2021-03-08 | 2021-06-18 | 中国地震局第二监测中心 | Rapid software evaluation execution method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9052980B2 (en) | Exception based quality assessment | |
| US20090007078A1 (en) | Computer-Implemented Systems And Methods For Software Application Testing | |
| CN102722434B (en) | Performance test method and tool aiming at Linux process scheduling | |
| US20100005341A1 (en) | Automatic detection and notification of test regression with automatic on-demand capture of profiles for regression analysis | |
| JP4996624B2 (en) | Detection apparatus, system, program, and detection method | |
| CN107562621A (en) | The method and apparatus for determining manual test use-case and tested code incidence relation | |
| JPH05324309A (en) | Device and method for evaluating software quality | |
| JP3883449B2 (en) | Software system test plan creation support method and test plan creation support program | |
| US20100241908A1 (en) | Systems And Methods For Automated Determination Of Out Of Memory Handling | |
| KR102066868B1 (en) | Method and apparatus for simulating safety of automotive software to obtain a goal reliability index | |
| JP6416588B2 (en) | Source code verification system | |
| CN109858632A (en) | A kind of method and device of threshold value | |
| JPH05313881A (en) | Method and device for evaluation of software quality | |
| KR101403685B1 (en) | System and method for relating between failed component and performance criteria of manintenance rule by using component database of functional importance determination of nuclear power plant | |
| KR20170123389A (en) | System and method for human error probability calculation of nuclear generating station | |
| CN111967774B (en) | Software quality risk prediction method and device | |
| JP2003029970A (en) | Program quality management supporting device, program quality management supporting method, computer readable recording medium having program for making computer perform program quality management supporting method recorded thereon and program for making computer perform program quality management supporting method | |
| Mukherjee et al. | Introducing a fuzzy model for cost cognizant software test case prioritization | |
| JPH0619699A (en) | Software release time estimating device and method | |
| US8516445B2 (en) | Multi-dimension code coverage | |
| JPH04169849A (en) | Threshold setting method for discriminating data | |
| Khatun et al. | An automatic test suite regeneration technique ensuring state model coverage using UML diagrams and source syntax | |
| CN110532116B (en) | System reliability modeling method and device | |
| CN117215918A (en) | Defect detection and repair method and device for source code | |
| JP3923773B2 (en) | Plant abnormal event diagnosis apparatus, diagnosis method therefor, and recording medium |