JP6747161B2 - Software quality judgment method - Google Patents
Software quality judgment method Download PDFInfo
- Publication number
- JP6747161B2 JP6747161B2 JP2016158792A JP2016158792A JP6747161B2 JP 6747161 B2 JP6747161 B2 JP 6747161B2 JP 2016158792 A JP2016158792 A JP 2016158792A JP 2016158792 A JP2016158792 A JP 2016158792A JP 6747161 B2 JP6747161 B2 JP 6747161B2
- Authority
- JP
- Japan
- Prior art keywords
- test
- viewpoint
- amount
- execution
- bug
- 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.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims description 24
- 238000012360 testing method Methods 0.000 claims description 213
- 238000011161 development Methods 0.000 claims description 21
- 238000004364 calculation method Methods 0.000 description 23
- 230000018109 developmental process Effects 0.000 description 20
- 238000012545 processing Methods 0.000 description 7
- 238000012552 review Methods 0.000 description 5
- 230000033772 system development Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000000528 statistical test Methods 0.000 description 1
Images
Landscapes
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Description
本発明は、システムの品質を判定するソフトウェア品質判定方法に関する。 The present invention relates to a software quality judgment method for judging the quality of a system.
バグ発生実績データからシステムに将来発生するバグ件数を予測し、予測したバグ件数と設定した品質指標とに基づいて、バグの発生が収束する収束時期を予測するソフトウェア品質判定方法が知られている（特許文献１参照）。 There is a known software quality judgment method that predicts the number of future bugs in the system from the bug occurrence data and predicts the convergence time when the occurrence of bugs will converge based on the predicted number of bugs and the set quality index. (See Patent Document 1).
上記ソフトウェア品質判定方法においては、バグの発生が収束したとしても、システムの開発規模（ソースコード規模、ソースコード複雑度、ＦＰ（Function Point）、など）に基づいてテストが十分に実施されていない場合や、テストする際のテスト観点が不足してる場合、がある。この場合、バグの収束を誤判定する虞がある。 In the above software quality judging method, even if the occurrence of a bug is converged, the test is not sufficiently carried out based on the system development scale (source code scale, source code complexity, FP (Function Point), etc.). In some cases, there is a lack of testing perspective when testing. In this case, the convergence of the bug may be erroneously determined.
本発明は、このような問題点を解決するためになされたものであり、必要なテスト観点毎に、システムの開発規模に応じた適切な量のテストを実施して、バグの収束を判定することで、バグの収束の誤判定を抑制できるソフトウェア品質判定方法を提供することを主たる目的とする。 The present invention has been made to solve such a problem, and determines the convergence of a bug by performing an appropriate amount of tests according to the development scale of the system for each required test viewpoint. Therefore, it is a main object to provide a software quality judgment method capable of suppressing erroneous judgment of bug convergence.
上記目的を達成するための本発明の一態様は、
システムに発生するバグの収束を判定するソフトウェア品質判定方法であって、
前記システムをテストする際の観点であるテスト観点毎の該テストの実施量を取得するステップと、
前記システムの開発規模を示す指標値に基づいて、前記テスト観点毎のテストの実施量の基準となる実施基準量を算出するステップと、
前記取得したテスト観点毎のテストの実施量と、前記算出した対応するテスト観点毎の実施基準量と、を夫々比較した後、テストの観点毎にバグの収束を判定するステップと、
を含む、ことを特徴とするソフトウェア品質判定方法
である。
One aspect of the present invention for achieving the above object is
A software quality determination method for determining the convergence of bugs that occur in the system,
Acquiring a test execution amount for each test viewpoint, which is a viewpoint when testing the system,
A step of calculating an execution reference amount which is a reference of an execution amount of a test for each of the test viewpoints, based on an index value indicating a development scale of the system,
After comparing the execution amount of the test for each acquired test viewpoint and the execution reference amount for each of the calculated corresponding test viewpoints, determining the convergence of the bug for each test viewpoint,
A software quality determination method characterized by including the following.
本発明によれば、必要なテスト観点毎に、システムの開発規模に応じた適切な量のテストを実施して、バグの収束を判定することで、バグの収束の誤判定を抑制できるソフトウェア品質判定方法を提供することができる。 According to the present invention, a software quality capable of suppressing erroneous determination of bug convergence by performing an appropriate amount of tests according to the development scale of the system for each required test viewpoint and determining the convergence of the bug. A determination method can be provided.
以下、図面を参照して本発明の実施形態について説明する。図１は、本発明の一実施形態に係るソフトウェア品質判定装置の概略的なシステム構成を示すブロック図である。本実施形態に係るソフトウェア品質判定装置１は、例えば、複数のプログラムで構成されてるシステムに発生するバグの収束を判定するものである。ここで、バグの収束判定を行う前に、必要なテスト観点を網羅し、かつ、該テスト観点毎に、システムの開発規模に応じた適切な量のテストを実施することが重要となる。本実施形態に係るソフトウェア品質判定装置１は、バグ収束判定を開始する前に、上記のような、必要なテスト観点を網羅し、かつ、該テスト観点毎の、システムの開発規模に応じた適切な量のテストを実施する。 Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram showing a schematic system configuration of a software quality determination device according to an embodiment of the present invention. The software quality determination device 1 according to the present embodiment determines, for example, the convergence of a bug that occurs in a system including a plurality of programs. Here, it is important to cover necessary test viewpoints and perform an appropriate amount of tests according to the development scale of the system for each test viewpoint before performing the convergence determination of the bug. The software quality determination apparatus 1 according to the present embodiment covers necessary test viewpoints as described above before starting the bug convergence determination, and is appropriate for each test viewpoint according to the system development scale. Perform a sufficient amount of testing.
ソフトウェア品質判定装置１は、例えば、演算処理等と行うＣＰＵ（Central Processing Unit）、ＣＰＵによって実行される演算プログラム、各種のデータを記憶するＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）からなるメモリ、外部と信号の入出力を行うインターフェイス部（Ｉ／Ｆ）、などからなるマイクロコンピュータを中心にして、ハードウェア構成されている。ＣＰＵ、メモリ及びインターフェイス部は、データバスなどを介して相互に接続されている。 The software quality determination device 1 includes, for example, a CPU (Central Processing Unit) that performs arithmetic processing and the like, an arithmetic program executed by the CPU, and a ROM (Read Only Memory) and a RAM (Random Access Memory) that store various data. The hardware configuration is centered on a microcomputer including a memory and an interface unit (I/F) that inputs and outputs signals to and from the outside. The CPU, memory, and interface unit are connected to each other via a data bus or the like.
本実施形態に係るソフトウェア品質判定装置１は、入力部２と、システムをテストする際のテスト観点毎のテストの実施量を取得する実施量取得部３と、テスト観点毎のテストの実施量の基準となる実施基準量と算出する実施基準算出部４と、システムのバグの収束を判定するバグ収束判定部５と、を備えている。
The software quality determination device 1 according to the present embodiment includes an
入力部２は、例えば、ユーザが任意の数値（後述のテスト実施量や開発規模指標値など）をソフトウェア品質判定装置１に入力し設定するための装置である。入力部２は、例えば、キーボート、マウス、タッチスクリーン、無線携帯端末（スマートフォンやタブレットなど）等の任意の入力装置である。
The
実施量取得部３は、入力部２などを介して、システムをテストする際の観点であるテスト観点毎のテストの実施量（以下、テスト実施量）を取得する。テスト実施量は、例えば、プログラムに対してテストを実施する際に必要なテスト工数やテスト件数である。なお、実施量取得部３は、開発規模指標値に基づいて、テスト観点毎のテスト実施量を自動的に算出してもよい。
実施基準算出部４は、システムの開発規模を示す指標値（以下、開発規模指標値）に基づいて、テスト観点毎のテスト実施量の基準となる実施基準量（以下、テスト実施基準量）と算出する。このテスト実施基準量は、各テスト観点毎に算出され、例えば、各テスト観点において、システム開発規模に応じて必要なテスト実施量である。
Through the
The implementation
開発規模指標値とは、例えば、そのシステムのプログラムのソースコード規模（実行コード行数など）、ソースコードの複雑さを示すソースコード複雑度、ＦＰ（Function Point）、などである。例えば、開発規模指標値は、上記メモリなどに予め設定されており、実施基準算出部４は、メモリから開発規模指標値を読み込む。
The development scale index value is, for example, the source code scale (number of execution code lines, etc.) of the program of the system, source code complexity indicating the complexity of the source code, FP (Function Point), and the like. For example, the development scale index value is preset in the memory or the like, and the implementation
テスト観点とは、例えば、プログラムが正常に動作するか否かを確認するための、テスト項目、着眼点、発想方法といった、テストを行う上での「切り口」であり、テストを実施するときの操作や手順の着眼点である。このテスト観点を適切に設定することで、プログラムのバグを十分に補足できる。例えば、テスト項目などのテスト観点は、上記メモリなどに予め設定されており、実施基準算出部４は、メモリから設定されたテスト観点を読み込む。メモリに設定されたテスト観点は、例えば、入力部２を介してユーザが自由に設定変更できる。これにより、ユーザは、任意の処理過程において、必要なテスト観点を適宜追加及び変更できるため、必要なテスト観点を網羅できる。
また、実施基準算出部４は、例えば、ＯＤＣ(Orthogonal Defect Classification)分析（例えば、http://www.researcher.watson.ibm.com/researcher/files/us-pasanth/ODC-5-2-Extensions.pdfを参照）のバグを発見する観点や後述のＩＳＯ（International Organization for Standardization）９１２６の品質特性に基づいて、テスト観点を設定してもよい。
The test point of view is, for example, a “cut point” in performing a test, such as test items, points of interest, and an idea method for confirming whether the program operates normally. This is the focus of operations and procedures. By properly setting this test viewpoint, it is possible to sufficiently catch bugs in the program. For example, a test viewpoint such as a test item is preset in the memory or the like, and the implementation
In addition, the implementation
実施基準算出部４は、例えば、過去の開発規模指標値に基づいて、統計的にテスト実施基準量を算出してもよい。より具体的には、テスト観点毎にテストを実施し、バグが収束したときのテスト工数（テスト件数を含む）が過去実績としてメモリなどに保持され、累積される。実施基準算出部４は、図２に示す如く、メモリに保持された、テスト観点毎のバグが収束したときのテスト工数に基づいて、統計的にテスト実施基準量を算出する。実施基準算出部４は、テスト観点毎に、例えば、テスト実施基準量の平均値（テスト工数／ＫＬＯＣ）及びその分散を算出する。実施基準算出部４は、このテスト観点毎のテスト実施基準量の平均値（テスト工数／ＫＬＯＣ）と、開発規模指標値と、に基づいて、テスト観点毎のテスト実施基準量を算出する。なお、テスト観点は、図３に示す如くＩＳＯ９１２６のテスト観点であり、例えば、機能性、効率性、信頼性、使用性、保守性、可搬性となっている。テスト観点毎のテスト実施基準量は、２．１、０．１、０．８、３．２、０．６、０、７となっている（図２）。
The implementation
また、実施基準算出部４は、テスト期間中のテスト工数とバグの発生状況とに基づいて、テスト観点毎のテスト実施基準量を算出してもよい。例えば、実施基準算出部４は、特許文献１に示す技術を用いて、横軸をテスト工数、縦軸をバグ総数とした、テスト観点毎のバグ曲線を生成する。
Further, the implementation
バグ曲線は、テスト観点毎に生成される。図４は、テスト観点が機能性である場合のバグ曲線の一例を示す図である。実施基準算出部４は、生成したバグ曲線に基づいて、バグ収束時のテスト工数を算出し、算出したテスト工数をテスト実施基準量とする。さらに、実施基準算出部４は、算出したテスト実施基準量を累積し、統計的なテスト実施基準量を算出してもよい。
The bug curve is generated for each test viewpoint. FIG. 4 is a diagram illustrating an example of a bug curve when the test viewpoint is functionality. The implementation
ところで、従来のソフトウェア品質判定方法においては、バグの発生が収束したとしても、システムの開発規模に基づいてバグテストが十分に実施されていない場合や、バグテストする際のテスト観点が不足してる場合、がある。この場合、バグの収束を誤判定する虞がある。 By the way, in the conventional software quality judgment method, even if the occurrence of a bug is converged, the bug test is not sufficiently performed based on the development scale of the system, or the testing viewpoint when performing the bug test is insufficient. If there is. In this case, the convergence of the bug may be erroneously determined.
これに対し、本実施形態においては、開発規模指標値に基づいて、テスト観点毎のテスト実施基準量を算出し、取得したテスト観点毎のテスト実施量と、算出した対応するテスト実施基準量と、を夫々比較した後、テストの観点毎にバグの収束を判定する。これにより、テスト観点毎に開発規模指標値に応じた適切な量のテストを実施した後に、より高精度なバグの収束の判定できる。すなわち、必要なテスト観点毎に、システムの開発規模に応じた適切な量のテストを実施して、テスト観点毎にバグの収束を判定することで、バグの収束の誤判定を抑制できる。 On the other hand, in the present embodiment, the test execution reference amount for each test viewpoint is calculated based on the development scale index value, and the acquired test execution amount for each test viewpoint and the calculated corresponding test execution reference amount are calculated. , Respectively, and then the convergence of the bug is determined for each viewpoint of the test. As a result, after performing an appropriate amount of tests according to the development scale index value for each test viewpoint, it is possible to determine the convergence of bugs with higher accuracy. That is, by performing an appropriate amount of tests according to the development scale of the system for each required test viewpoint and determining the convergence of the bug for each testing viewpoint, it is possible to suppress the erroneous determination of the convergence of the bug.
バグ収束判定部５は、実施量取得部３により取得されたテスト観点毎のテスト実施量と、実施基準算出部４により算出された対応するテスト実施基準量と、を比較した後、テスト観点毎にバグの収束を判定する。バグ収束判定部５は、例えば、実施量取得部３により算出された全テスト観点のテスト実施量が、実施基準算出部４により算出された対応するテスト実施基準量を夫々超えると、テスト観点毎のバグ収束判定を開始する。
The bug
バグ収束判定部５は、上述の如く、テスト観点毎のテスト実施量と、対応するテスト実施基準量と、を個別に比較する。これにより、テスト観点毎に実施したテスト量をテスト観点毎に容易に把握でき、どのテスト観点をもっとテストすべきかが容易に把握できる。
As described above, the bug
そして、バグ収束判定部５は、上述の如く、全テスト観点のテスト実施量が対応するテスト実施基準量を夫々超えると、テスト観点毎のバグ収束判定を開始する。これにより、必要な全テスト観点について、必要なテスト量のテストが実施された（テスト実施量＞テスト実施基準量）ことを判断した後、バグ収束判定を開始する。したがって、必要なテスト観点が抜けている、あるテスト観点についてテスト量不足である、といった問題が確実に解消できるため、その後のバグ収束判定をより確実に実行できる。なお、バグ収束判定部５は、一部のテスト観点のテスト実施量が対応するテスト実施基準量を超えると、逐次、そのテスト観点のバグ収束判定を開始してもよい。これにより、処理の高速化を図ることができる。
なお、バグ収束判定部５は、一定数以上のテスト観点のテスト実施量が対応するテスト実施基準量を夫々超えると、テスト観点毎のバグ収束判定を開始してもよい。
Then, as described above, the bug
The bug
バグ収束判定部５は、例えば、図４に示す如く、実施量取得部３により取得されたテスト観点（機能性）のテスト実施量（テスト工数）が実施基準算出部４により算出されたテスト実施基準量を超えると、そのテスト観点（機能性）のバグ収束開始判定を合格とする。バグ収束判定部５は、この機能性と同様の判定を他のテスト観点についても行い、全テスト観点のバグ収束開始判定が合格となった場合に、テスト観点毎のバグ収束判定を開始する。このように、バグ収束判定部５は、テスト観点毎にテスト実施量とテスト実施基準量とを比較することで、バグ曲線の品質判定を行う。その後、バグ収束判定部５は、バグ収束判定を開始する。
For example, as shown in FIG. 4, the bug
なお、バグ収束判定部５は、実施量取得部３により取得された全テスト観点のテスト実施量が、実施基準算出部４により算出された対応するテスト実施基準量を夫々超えると、テスト観点毎のバグ収束判定を開始する。しかし、実際には、テスト実施基準量は、例えば、信頼区間９０％でＡ〜Ｂと言った幅を有する数値となる。すなわち、実施基準算出部４は、上記信頼区間を考慮してテスト実施基準量を算出する。このように、テスト実施基準量は平均値ではなく、信頼区間を考慮した値となる。このため、バグ収束判定部５は、テスト実施量がその信頼区間内に入っていれば、そのテスト実施基準量を満たしているを判定してもよい。
It should be noted that the bug
図５は、本実施形態に係るソフトウェア品質判定方法の処理フローの一例を示すフローチャートである。 FIG. 5 is a flowchart showing an example of the processing flow of the software quality determination method according to this embodiment.
実施基準算出部４は、メモリの開発規模指標値に基づいて、テスト観点毎のテスト実施基準量を算出する（ステップＳ１０１）。
実施量取得部３は、テスト実施量を取得する（ステップＳ１０２）。
The execution
The implementation amount acquisition unit 3 acquires the test implementation amount (step S102).
バグ収束判定部５は、実施量取得部３により取得された全テスト観点のテスト実施量が、実施基準算出部４により算出された対応するテスト実施基準量を夫々超えているか否かを判定する（ステップＳ１０３）。バグ収束判定部５は、全テスト観点のテスト実施量が対応するテスト実施基準量を夫々超えていると判定したとき（ステップＳ１０３のＹＥＳ）、テスト観点毎のバグ収束判定を開始する（ステップＳ１０４）。一方、バグ収束判定部５は、全テスト観点のテスト実施量が対応するテスト実施基準量を夫々超えていないと判定したとき（ステップＳ１０３のＮＯ）、上記（ステップＳ１０２）に戻る。
The bug
以上、本実施形態に係るソフトウェア品質判定装置１において、実施量取得部３は、テスト観点毎のテスト実施量を取得する。実施基準算出部４は、開発規模指標値に基づいて、テスト観点毎のテスト実施基準量を算出する。バグ収束判定部５は、実施量取得部３により取得されたテスト観点毎のテスト実施量と、実施基準算出部４により算出された対応するテスト実施基準量と、を夫々比較した後、テストの観点毎にバグの収束を判定する。これにより、必要なテスト観点毎に、システムの開発規模に応じた適切な量のテストを実施して、テスト観点毎にバグの収束を判定することで、バグの収束の誤判定を抑制できる。
As described above, in the software quality determination device 1 according to the present embodiment, the implementation amount acquisition unit 3 acquires the test implementation amount for each test viewpoint. The implementation
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。 The present invention is not limited to the above-mentioned embodiments, but can be modified as appropriate without departing from the spirit of the present invention.
例えば、上記実施形態において、バグ収束判定部５は、全テスト観点のテスト実施量が対応するテスト実施基準量を夫々超えていないと判定したとき（ステップＳ１０３のＮＯ）、テスト観点毎の合否結果とそのバグ曲線を表示装置を用いてユーザに表示した（ステップＳ１０５）後、上記（ステップＳ１０２）に戻ってもよい（図６）。表示装置は、例えば、液晶ディスプレイ、有機ＥＬディスプレイなどである。表示装置は、例えば、図７に示すような、テスト観点毎の合否結果、そのバグ曲線、及びテスト実施基準量を表示する。これにより、テスト工数をテスト観点毎に容易に把握でき、どのテスト観点をもっとテストすべきかが明確に把握できる。
For example, in the above embodiment, when the bug
上記実施形態において、ソフトウェア品質判定装置１は、システムのテスト工程に適用されているが、これに限定されない。ソフトウェア品質判定装置１は、例えば、設計及び実装のレビュー工程に適用されてもよい。この場合、テスト実施量をレビュー工数、開発規模指標値をドキュメントのボリューム（行数、頁数、文字数など）、テスト観点をレビュー観点に置き換えて適用できる。なお、レビュー観点は、例えば、組織が有する観点表を用いてもよく、ＯＤＣ分析のレビュー工程のバグを発見する観点を用いてもよい。 In the above embodiment, the software quality determination device 1 is applied to the test process of the system, but is not limited to this. The software quality determination device 1 may be applied to, for example, a design and implementation review process. In this case, the test execution amount may be replaced with the review man-hour, the development scale index value may be replaced with the document volume (the number of lines, the number of pages, the number of characters, etc.), and the test viewpoint may be replaced with the review viewpoint. As the review viewpoint, for example, a viewpoint table included in the organization may be used, or a viewpoint of finding a bug in the review process of the ODC analysis may be used.
本発明は、例えば、図５に示す処理を、ＣＰＵ又はＧＰＵ（Graphics Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。 The present invention can also be realized, for example, by causing a CPU or a GPU (Graphics Processing Unit) to execute a computer program for the processing shown in FIG.
プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（random access memory））を含む。 The program can be stored using various types of non-transitory computer readable media, and can be supplied to a computer. Non-transitory computer readable media include various types of tangible storage media. Examples of the non-transitory computer readable medium include a magnetic recording medium (for example, flexible disk, magnetic tape, hard disk drive), magneto-optical recording medium (for example, magneto-optical disk), CD-ROM (Read Only Memory), CD-R, It includes a CD-R/W and a semiconductor memory (for example, mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (random access memory)).
プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。 The program may be supplied to the computer by various types of transitory computer readable media. Examples of transitory computer-readable media include electrical signals, optical signals, and electromagnetic waves. The transitory computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.
１ ソフトウェア品質判定装置、２ 入力部、３ 実施量取得部、４ 実施基準算出部、５ バグ収束判定部 1 software quality determination device, 2 input unit, 3 implementation amount acquisition unit, 4 implementation reference calculation unit, 5 bug convergence determination unit
Claims (1)
前記システムをテストする際の観点であるテスト観点毎の該テストの実施量を取得するステップと、
前記システムの開発規模を示す指標値に基づいて、前記テスト観点毎のテストの実施量の基準となる実施基準量を算出するステップと、
前記取得したテスト観点毎のテストの実施量が、前記算出した対応するテスト観点毎の実施基準量を超えると又は該実施基準量の信頼区間内に入ると、テストの観点毎にバグの収束を判定するステップと、
を含み、
前記テスト観点は、システムが正常に動作するか否かを確認するための、テスト項目、着眼点、又は発想方法であり、前記テストを行う上での切り口であり、
前記取得したテスト観点毎のテストの実施量が、前記算出した対応するテスト観点毎の実施基準量を超えていない又は該実施基準量の信頼区間内に入っていないと判定したとき、テスト観点毎の、判定結果と、テスト工数及びバグ総数の関係を示すバグ曲線と、前記実施基準量と、をユーザに表示する、
ことを特徴とするソフトウェア品質判定方法。 A software quality determination method for determining the convergence of bugs that occur in the system,
Acquiring a test execution amount for each test viewpoint, which is a viewpoint when testing the system,
A step of calculating an execution reference amount which is a reference of an execution amount of a test for each of the test viewpoints, based on an index value indicating a development scale of the system,
When the amount of test execution for each of the acquired test viewpoints exceeds the calculated execution reference amount for each corresponding test viewpoint or falls within the confidence interval of the execution reference amount, convergence of bugs for each test viewpoint A determining step,
Including,
The test viewpoint, the system for checking whether or not operating properly, a test item, Viewpoints, or thinking process, Ri Oh in cut in performing the test,
When it is determined that the obtained test execution amount for each test viewpoint does not exceed the calculated execution reference amount for each corresponding test viewpoint or is not within the confidence interval of the execution reference amount, for each test viewpoint Of the judgment result, a bug curve showing the relationship between the test man-hour and the total number of bugs, and the implementation reference amount, are displayed to the user,
A software quality judgment method characterized by the above.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2016158792A JP6747161B2 (en) | 2016-08-12 | 2016-08-12 | Software quality judgment method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2016158792A JP6747161B2 (en) | 2016-08-12 | 2016-08-12 | Software quality judgment method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2018026056A JP2018026056A (en) | 2018-02-15 |
| JP6747161B2 true JP6747161B2 (en) | 2020-08-26 |
Family
ID=61195264
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016158792A Expired - Fee Related JP6747161B2 (en) | 2016-08-12 | 2016-08-12 | Software quality judgment method |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6747161B2 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6897524B2 (en) | 2017-11-29 | 2021-06-30 | トヨタ自動車株式会社 | Software quality judgment device, software quality judgment method, and software quality judgment program |
| JP6891780B2 (en) | 2017-11-29 | 2021-06-18 | トヨタ自動車株式会社 | Software quality judgment device, software quality judgment method, and software quality judgment program |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05216651A (en) * | 1992-02-05 | 1993-08-27 | Hitachi Ltd | Program quality evaluation system |
| JP2008033662A (en) * | 2006-07-28 | 2008-02-14 | Nec Corp | Software test completion determination method, information processor, program and recording medium |
| JP6161367B2 (en) * | 2013-04-01 | 2017-07-12 | 三菱電機株式会社 | Information processing apparatus, information processing method, and program |
-
2016
- 2016-08-12 JP JP2016158792A patent/JP6747161B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2018026056A (en) | 2018-02-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108388514B (en) | Interface automation test method, device, equipment and computer readable storage medium | |
| US9256517B1 (en) | Display of aggregated stack traces in a source code viewer | |
| US9329981B2 (en) | Testing program, testing method, and testing device | |
| US20110131551A1 (en) | Graphical user interface input element identification | |
| US11068379B2 (en) | Software quality determination apparatus, software quality determination method, and software quality determination program | |
| KR20140038381A (en) | Systems and methods for testing content of mobile communication devices | |
| US8291388B2 (en) | System, method and program for executing a debugger | |
| US10783067B2 (en) | Software quality determination apparatus, software quality determination method, and software quality determination program | |
| US9690682B2 (en) | Program information generating system, method, and computer program product | |
| CN107223257B (en) | Test method, test server and test system | |
| CN116245074A (en) | Chip verification method, device and storage medium | |
| JP6747161B2 (en) | Software quality judgment method | |
| CN114996103A (en) | Page abnormity detection method and device, electronic equipment and storage medium | |
| CN111190791A (en) | Application exception reporting method and device and electronic equipment | |
| US20150355616A1 (en) | Programmable controller, programmable controller system, and method of creating execution error information | |
| US9348733B1 (en) | Method and system for coverage determination | |
| US9239770B2 (en) | Apparatus and method for extracting restriction condition | |
| CN114328158A (en) | Abnormity monitoring method and device, electronic equipment and storage medium | |
| CN111625835B (en) | Program vulnerability path tracking method, device, computer equipment and storage medium | |
| US9792202B2 (en) | Identifying a configuration element value as a potential cause of a testing operation failure | |
| CN110866492B (en) | Baseline branch identification method and device and computer system | |
| CN110633183B (en) | Method and related device for monitoring execution progress of software product | |
| JP6974707B2 (en) | Test program, test equipment and test method | |
| JP2016146032A (en) | Software covering testing device and method | |
| CN115237762A (en) | Software performance testing method and device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180921 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20190730 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190806 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20191004 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20200218 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20200518 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20200528 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20200707 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20200720 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 6747161 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| LAPS | Cancellation because of no payment of annual fees |