コードカバレッジ

カバー範囲の基準はいくつかありますが、主なものは次のとおりです。^{[ 5 ]}

• 関数カバレッジ–プログラム内の各関数（またはサブルーチン）が呼び出されたかどうか？ 
• ステートメントのカバレッジ–プログラムに含まれる各ステートメントは実行されていますか？ 
• エッジカバレッジ–制御フローグラフ内のすべてのエッジが実行されたか？  
  • 分岐カバレッジ–各制御構造（ if文やcase文など）の各分岐（DDパスとも呼ばれる）が実行されたかどうか。例えば、if文の場合、 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。同時に、最初のケースではとなり、2番目のケースでは（ブール演算子の遅延評価のため）は(y>0)false評価されず、3番目のケースではとなります。(y>0)true

短絡評価を行わないプログラミング言語では、条件カバレッジは必ずしも分岐カバレッジを意味するものではありません。例えば、次のPascalコード断片を考えてみましょう。

aとbの場合

条件カバレッジは、次の2つのテストによって満たされる。

• a=true、b=false
• a=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 ]}

上記のカバレッジ基準の中には、相互に関連するものがあります。例えば、パスカバレッジは、決定カバレッジ、ステートメントカバレッジ、およびエントリー／エグジットカバレッジを意味します。決定カバレッジはステートメントカバレッジを意味します。なぜなら、すべてのステートメントは分岐の一部だからです。

上記のような完全なパスカバレッジは、通常、非現実的または不可能です。${\displaystyle n}$決定は最大で$2n$内部のパス。ループ構造は無限のパスを生み出す可能性がある。また、多くのパスは実行不可能である可能性があり、それはテスト対象プログラムにその特定のパスを実行させる入力がないことを意味する。しかし、実行不可能なパスを識別するための汎用アルゴリズムは不可能であることが証明されている（そのようなアルゴリズムは停止問題の解決に使用できる）。^{[ 14 ]}基本パステストは、たとえば、完全なパスカバレッジを達成せずに完全なブランチカバレッジを達成する方法である。^{[ 15 ]}

実用的なパスカバレッジテストの方法では、ループ実行回数のみが異なるコードパスのクラスを特定しようとし、「基本パス」カバレッジを達成するには、テスターはすべてのパスクラスを網羅する必要があります。^{[ 16 ]}