Loading article…
ソフトウェア工学において、コードカバレッジはテストカバレッジとも呼ばれ、特定のテストスイートが実行されたときにプログラムのソースコードが実行される度合いをパーセンテージで表したものです。コードカバレッジの高いプログラムはテスト中に実行されるソースコードが多く、コードカバレッジの低いプログラムに比べて検出されないソフトウェアバグが含まれる可能性が低いことを示しています。 [1] [2]テストカバレッジの計算には、さまざまな指標を使用できます。最も基本的な指標としては、プログラムサブルーチンの割合や、テストスイートの実行中に呼び出される プログラムステートメントの割合などがあります。
コードカバレッジは、体系的なソフトウェアテストのために発明された最初の方法の1つです。最初の文献は、1963年にミラーとマロニーによってCommunications of the ACMに掲載されました。 [3]
対象基準
テストスイートによって実行されたコードの割合を測定するために、1つ以上のカバレッジ基準が使用されます。これらは通常、テストスイートが満たさなければならないルールまたは要件として定義されます。[4]
基本的な補償基準
適用範囲の基準はいくつかあるが、主なものは以下のとおりである。[5]
- 関数カバレッジ–プログラム内の 各関数 (またはサブルーチン) が呼び出されていますか?
- ステートメント カバレッジ–プログラム内の 各ステートメントは実行されましたか?
- エッジ カバレッジ -制御フロー グラフ内のすべてのエッジが実行されましたか?
- 条件カバレッジ – 各ブール値サブ式は true と false の両方に評価されましたか? (述語カバレッジとも呼ばれます。)
たとえば、次のC関数を考えてみましょう。
int foo ( int x , int y ) { int z = 0 ; if (( x > 0 ) && ( y > 0 )) { z = x ; } return z ; }
この関数がより大きなプログラムの一部であり、このプログラムが何らかのテスト スイートを使用して実行されたと仮定します。
- この実行中に関数が
foo少なくとも 1 回呼び出された場合、関数カバレッジは満たされます。 - この関数のステートメント カバレッジは、たとえば として呼び出された場合に満たされます
foo(1,1)。これは、この場合、 を含む関数内のすべての行が実行されるためですz = x;。 - 分岐カバレッジは
foo(1,1)、 およびを呼び出すテストによって満たされます。foo(0,1)これは、最初のケースでは両方のif条件が満たされてz = x;が実行され、2 番目のケースでは最初の条件(x>0)が満たされず、 の実行が妨げられるためですz = x;。 - 条件カバレッジは
foo(1,0)、、、foo(0,1)およびを呼び出すテストで満たされますfoo(1,1)。これらは、最初のケースでは(x>0)が に評価されtrue、2 番目のケースでは に評価されるため必要ですfalse。同時に、最初のケースでは が作成され(y>0)false、2 番目のケースでは は評価されず(y>0)(ブール演算子の遅延評価のため)、3 番目のケースでは が作成されますtrue。
短絡評価を実行しないプログラミング言語では、条件カバレッジは必ずしも分岐カバレッジを意味するわけではありません。たとえば、次のPascalコード フラグメントを考えてみましょう。
aかつbならば
条件カバレッジは次の 2 つのテストによって満たされます。
a=true、b=falsea=false、b=true
ただし、どちらのケースも条件を満たさないため、このテスト セットは分岐カバレッジを満たしませんif。
テスト中に例外処理コードのすべての条件と分岐が適切にカバーされるよう にするには、フォールト インジェクションが必要になる場合があります。
修正された条件/決定範囲
関数カバレッジと分岐カバレッジの組み合わせは、決定カバレッジと呼ばれることもあります。この基準では、プログラム内のすべてのエントリポイントと終了ポイントが少なくとも1回呼び出され、プログラム内のすべての決定がすべての可能な結果を少なくとも1回とっている必要があります。このコンテキストでは、決定は条件と0個以上のブール演算子を含むブール式です。この定義は分岐カバレッジと同じではありませんが、[6]決定カバレッジという用語は分岐カバレッジの同義語として使用されることがあります。[7]
条件/決定カバレッジでは、決定カバレッジと条件カバレッジの両方が満たされる必要があります。ただし、安全性が重要なアプリケーション (航空電子工学ソフトウェアなど) では、修正条件/決定カバレッジ (MC/DC)が満たされる必要があることがよくあります。この基準は、各条件が決定結果に独立して影響を与えるという要件で条件/決定基準を拡張します。
たとえば、次のコードを考えてみます。
もし（aまたはb ）かつcならば
条件/決定基準は、次の一連のテストによって満たされます。
ただし、上記のテスト セットは、最初のテストでは 'b' の値、2 番目のテストでは 'c' の値が出力に影響しないため、変更された条件/決定カバレッジを満たしません。したがって、MC/DC を満たすには、次のテスト セットが必要です。
複数の条件をカバー
この基準では、各決定内の条件のすべての組み合わせをテストする必要があります。たとえば、前のセクションのコード フラグメントでは、次の 8 つのテストが必要になります。
パラメータ値の範囲
パラメータ値カバレッジ（PVC）では、パラメータを取るメソッドで、そのようなパラメータのすべての共通値を考慮する必要があります。その考え方は、パラメータの一般的な可能な値すべてをテストするというものです。[8]たとえば、文字列の一般的な値は次のとおりです。1) null、2) 空、3) 空白（スペース、タブ、改行）、4) 有効な文字列、5) 無効な文字列、6) シングルバイト文字列、7) ダブルバイト文字列。非常に長い文字列を使用することも適切な場合があります。考えられるパラメータ値をすべてテストしないと、バグが発生する可能性があります。これらのうちの 1 つだけをテストすると、各行がカバーされるため 100% のコード カバレッジになる可能性がありますが、7 つのオプションのうち 1 つだけがテストされるため、PVC は 14.2% しかありません。
その他の補償基準
他にもあまり使用されないカバレッジ基準がいくつかあります。
- 線形コードシーケンスとジャンプ（LCSAJ）カバレッジ、別名JJパスカバレッジ – すべてのLCSAJ/JJパスが実行されましたか？ [9]
- パス カバレッジ – コードの特定の部分を通過するすべての可能なルートが実行されましたか?
- エントリ/終了カバレッジ – 関数のすべての可能な呼び出しと戻りが実行されましたか?
- ループ カバレッジ – 考えられるすべてのループが 0 回、1 回、複数回実行されましたか?
- 状態カバレッジ–有限状態マシン の各状態に到達して調査されましたか?
- データフローカバレッジ – 各変数の定義とその使用法に到達し、調査しましたか? [10]
安全性が重要または信頼できるアプリケーションでは、何らかのテスト カバレッジを 100% 実証することが求められることがよくあります。たとえば、ECSS -E-ST-40C 標準では、4 つの異なるクリティカル レベルのうち 2 つについて、100% のステートメントおよび決定カバレッジが要求されます。その他のレベルについては、ターゲット カバレッジ値はサプライヤーと顧客の間で交渉されます。[11] ただし、特定のターゲット値 (特に 100%) を設定することは、さまざまな理由で実務者から批判されています (cf. [12] ) Martin Fowler は次のように書いています。「100% のような数値には疑問を感じます。カバレッジの数値を満足させるためにテストを書いているが、自分が何をしているのか考えていないという臭いがするからです」。[13]
上記のカバレッジ基準の一部は相互に関連しています。たとえば、パス カバレッジは、決定、ステートメント、およびエントリ/終了カバレッジを意味します。すべてのステートメントがブランチの一部であるため、決定カバレッジはステートメント カバレッジを意味します。
上で説明したタイプの完全なパスカバレッジは、通常、非現実的または不可能です。一連の決定を含むモジュールには、最大でパスを含めることができます。ループ構造は、無限の数のパスを生み出す可能性があります。また、多くのパスは、テスト対象のプログラムに特定のパスを実行させる入力がないため、実行不可能である可能性があります。ただし、実行不可能なパスを識別するための汎用アルゴリズムは不可能であることが証明されています（このようなアルゴリズムは、停止問題を解決するために使用できます）。[14]たとえば、基本パステストは、完全なパスカバレッジを達成せずに完全な分岐カバレッジを達成する方法です。[15]
実用的なパス カバレッジ テストの方法では、ループ実行回数のみが異なるコード パスのクラスを識別しようとします。また、「基本パス」カバレッジを達成するには、テスターがすべてのパス クラスをカバーする必要があります。[引用が必要] [説明が必要]
実際には
ターゲット ソフトウェアは、特別なオプションまたはライブラリを使用して構築され、制御された環境で実行され、実行されるすべての関数をソース コード内の関数ポイントにマッピングします。これにより、通常の状態ではほとんどアクセスされないかまったくアクセスされないターゲット ソフトウェアの部分をテストでき、最も重要な条件 (関数ポイント) がテストされたことを再確認するのに役立ちます。次に、結果の出力を分析して、実行されていないコード領域を確認し、必要に応じてこれらの領域を含むようにテストを更新します。他のテスト カバレッジ方法と組み合わせて、厳密でありながら管理しやすい回帰テスト セットを開発することが目的です。
ソフトウェア開発環境内でテスト カバレッジ ポリシーを実装する場合は、次の点を考慮する必要があります。
- 最終製品の認証のカバレッジ要件は何ですか。また、必要なテスト カバレッジのレベルはどの程度ですか。一般的な厳密さの進行レベルは次のとおりです。ステートメント、分岐/決定、修正条件/決定カバレッジ(MC/DC)、LCSAJ (線形コード シーケンスとジャンプ)
- カバレッジは、テスト対象システムに課せられた要件を検証するテストに対して測定されますか ( DO-178B )?
- 生成されたオブジェクトコードはソースコードステートメントに直接追跡可能ですか？特定の認証（DO-178BレベルAなど）では、そうでない場合はアセンブリレベルでのカバレッジが必要です。「その後、生成されたコードシーケンスの正確性を確立するために、オブジェクトコードに対して追加の検証を実行する必要があります」（DO-178B）パラグラフ6.4.4.2。[16]
ソフトウェア作成者は、テスト カバレッジの結果を確認して、重要な機能のカバレッジを増やすための追加のテストや入力または構成セットを考案できます。テスト カバレッジの一般的な 2 つの形式は、ステートメント (または行) カバレッジとブランチ (またはエッジ) カバレッジです。行カバレッジは、テストを完了するためにどのコード行が実行されたかという点で、テストの実行フットプリントを報告します。エッジ カバレッジは、テストを完了するためにどのブランチまたはコード決定ポイントが実行されたかを報告します。どちらも、パーセンテージで測定されたカバレッジ メトリックを報告します。この意味は、使用されたカバレッジの形式によって異なります。67% のブランチ カバレッジは、67% のステートメント カバレッジよりも包括的です。
一般的に、テスト カバレッジ ツールは実際のプログラムに加えて計算とログ記録も行うため、アプリケーションの速度が低下するため、通常、この分析は実稼働環境では実行されません。予想どおり、これらのカバレッジ テストを実際に実行できないソフトウェア クラスもありますが、直接テストするのではなく分析によって、ある程度のカバレッジ マッピングを概算できます。
このようなツールによって影響を受ける欠陥もいくつかあります。特に、一部の競合状態や同様のリアルタイム性に敏感な操作は、テスト環境で実行するとマスクされる可能性があります。ただし、逆に、テスト コードの追加オーバーヘッドの結果として、これらの欠陥の一部が見つけやすくなる場合があります。
プロのソフトウェア開発者の多くは、C1 カバレッジと C2 カバレッジを使用しています。C1 はステートメント カバレッジ、C2 は分岐または条件カバレッジの略です。C1 と C2 を組み合わせることで、コード ベース内のほとんどのステートメントをカバーできます。ステートメント カバレッジでは、エントリと終了、ループ、パス、状態フロー、制御フロー、データ フロー カバレッジを含む関数カバレッジもカバーされます。これらの方法を使用すると、ほとんどのソフトウェア プロジェクトでほぼ 100% のコード カバレッジを達成できます。[17]
注目すべきコードカバレッジツール
ハードウェアメーカー
ソフトウェア
業界での使用
試験範囲は、航空電子機器の安全認証における考慮事項の1つです。連邦航空局（FAA）による航空電子機器の認証ガイドラインは、 DO-178B [16]およびDO-178C [18]に文書化されています。
テスト範囲は自動車安全規格ISO 26262 道路車両-機能安全のパート6でも要件となっています。[19]
参照
- 循環的複雑性
- インテリジェントな検証
- 線形コードシーケンスとジャンプ
- 修正された条件/決定範囲
- 突然変異検査
- 回帰テスト
- ソフトウェアメトリック
- 静的プログラム解析
- ホワイトボックステスト
- Javaコードカバレッジツール
参考文献
- ^ Brader, Larry、Hilliker, Howie、Wills, Alan (2013 年 3 月 2 日)。「第 2 章 ユニット テスト: 内部のテスト」。Visual Studio 2012 を使用した継続的デリバリーのテスト。Microsoft。p. 30。ISBN 978-1621140184. 2016年6月16日閲覧。
- ^ Williams, Laurie ; Smith, Ben; Heckman, Sarah. 「Test Coverage with EclEmma」. Open Seminar Software Engineering . North Carolina State University. 2016年3月14日時点のオリジナルよりアーカイブ。 2016年6月16日閲覧。
- ^ Joan C. Miller、Clifford J. Maloney (1963 年 2 月)。「デジタル コンピュータ プログラムの体系的な誤り分析」。Communications of the ACM。6 ( 2)。ニューヨーク、NY、米国: ACM : 58–63。doi : 10.1145 /366246.366248。ISSN 0001-0782。
- ^ Paul Ammann、Jeff Offutt (2013)。ソフトウェアテスト入門。ケンブリッジ大学出版局。
- ^ Glenford J. Myers (2004).ソフトウェアテストの芸術、第2版。Wiley。ISBN 0-471-46912-2。
- ^ ポジションペーパー CAST-10 (2002 年 6 月)。修正条件/決定カバレッジ (MC/DC) および決定カバレッジ (DC) の適用における「決定」とは何ですか?
- ^ MathWorks.モデルカバレッジの種類。
- ^ 「パラメータ値カバレッジ (PVC) を使用したユニットテスト」。
- ^ MR Woodward、MA Hennell、「2 つの制御フロー カバレッジ基準の関係について: すべての JJ パスと MCDC」、情報およびソフトウェア技術 48 (2006) pp. 433-440
- ^ ティン・スー、ケ・ウー、ウェイカイ・ミャオ、ゲーグァン・プー、ジフェン・何、ユウティン・チェン、ジェンドン・スー。 「データフローテストに関する調査」。 ACM コンピューティング。生き残る。 50、1、第 5 条（2017 年 3 月）、35 ページ。
- ^ ECSS-E-ST-40C: 宇宙工学 - ソフトウェア。ECSS 事務局、ESA-ESTEC。2009 年 3 月
- ^ C. Prause、J. Werner、K. Hornig、S. Bosecker、M. Kuhrmann (2017): 100% のテスト カバレッジは妥当な要件か? 宇宙ソフトウェア プロジェクトから学んだ教訓。PROFES 2017。Springer。最終アクセス: 2017-11-17
- ^ Martin Fowler のブログ: TestCoverage。最終アクセス: 2017-11-17
- ^ Dorf, Richard C.: Computers, Software Engineering, and Digital Devices、第 12 章、15 ページ。CRC Press、2006 年。ISBN 0-8493-7340-9 、 ISBN 978-0-8493-7340-4。Googleブック検索経由
- ^ YN Srikant、Priti Shankar (2002)。コンパイラ設計ハンドブック: 最適化とマシンコード生成。CRC Press。p. 249。ISBN 978-1-4200-4057-9。
- ^ ab RTCA/ DO-178B、航空機搭載システムおよび機器認証におけるソフトウェアの考慮事項、航空無線技術委員会、 1992 年 12 月 1 日
- ^ Boris beizer (2009).ソフトウェアテストテクニック、第2版。Dreamtech press。ISBN 978-81-7722-260-9。
- ^ RTCA/ DO-178C、航空機搭載システムおよび機器認証におけるソフトウェアの考慮事項、航空無線技術委員会、 2012 年 1 月。
- ^ ISO 26262-6:2011(en) 道路車両 -- 機能安全 -- パート 6: ソフトウェア レベルでの製品開発。国際標準化機構。