コードカバレッジ 7つの種類とコード例を紹介！知っておくべき落とし穴

カバレッジ(網羅率)とは、対象のプログラムがどこまでテスト実施されたのかの割合のことです。

カバレッジ基準は、カバレッジの値を導き出すときに使う算定対象と算定規則を決めた基準のことで、ソフトウェアテストでは、目的や用途に合わせた複数の種類が存在します。

カバレッジ基準(特にコードカバレッジ)は、システムの品質を考える上では知っておくべき考え方ですが、カバレッジに固執しすぎると起こりうる弊害もあります。

今回の記事では、カバレッジ基準を一挙にご紹介するとともに、コードカバレッジを考えていくにあたって気をつけたい「カバレッジの罠」とも言える事例を紹介いたします。

もくじ

1. コードカバレッジ大全集
   
   • ステートメント・カバレッジ（C0）
   • デシジョンカバレッジ（C1）
   • コンディションカバレッジ
   • コンディション／デシジョン・カバレッジ
   • MC/DC
   • 複合条件カバレッジ（C2）
   • パス・カバレッジ
2. 過信は禁物！コードカバレッジの「落とし穴」
3. おわりに

１．コードカバレッジ大全集

コードカバレッジに焦点を絞り、具体的なコードを明示しながらカバレッジの特徴を解説します。今回ご紹介するのは、下記の代表的な7種類のカバレッジです。

1. ステートメント・カバレッジ（C0）
2. デシジョンカバレッジ（C1）
3. コンディションカバレッジ
4. コンディション／デシジョンカバレッジ
5. MC/DC
6. 複合条件カバレッジ（C2）
7. パスカバレッジ

1‐1　ステートメント・カバレッジ（C0）

ステートメント・カバレッジ（C0）は、命令網羅とも言われます。プログラム上の全ての命令文を実行することがカバレッジを向上させることに直結するという考え方です。

コード例１

commandA();
 　if (x == 0) {   // 変数xの値が0のとき、{}の中を実行
　　　 commandB();
　}
commandC();

ステートメント・カバレッジを100%にする方法

変数x=0のテストケースを実行すれば、全ての命令文（CommandA,B,C）が実行されます。この考え方に則れば、テストケースは1パターンで良いことになります。

1‐2　デシジョンカバレッジ（C1）

デシジョンカバレッジ（C1）は判断網羅、またはブランチカバレッジとも言われます。プログラム上の全ての判断文について、その判断結果すべてを網羅するように実行する考え方です。

コード例２

commandA();
 if (x == 0) {   // 変数xの値が0のとき、{}の中を実行
   commandB();
 }
commandC();

デシジョンカバレッジを100%にする方法

変数xが「0の場合」「0以外の場合」の2種類のテストケースを実行すれば、if文の条件のTRUE/FALSEの両方を網羅できます。この考え方に則れば、テストケースは2パターンで良いことになります。

1‐3　コンディションカバレッジ

コンディションカバレッジは、条件網羅とも言われます。プログラム上の全ての判断文について、判断文内の条件式ひとつひとつを網羅しすべてのパターンを実行する考え方です。

コード例３

commandA();
  if (x == 0 || y <= 10) {??? // ||は「または」の意味
    commandB();
  }
commandC();

コンデションカバレッジを100%にする方法

この場合、判断式は「x == 0」と「y <= 10」のそれぞれ2種類です。

コンデションカバレッジの考え方では、各条件式について、真偽の判定を網羅できればOKです。

つまり、

「x = 0, y = 100」...　「パターン(a)：TRUE」かつ「パターン(d)：FALSE」
「x = 1, y = 0」　...　「パターン(b)：FALSE」かつ「パターン(c)：TRUE」

の2種類のテストケースを実行すれば、コンディションカバレッジは100%になります。

1‐4　コンディション／デシジョンカバレッジ

コンディション／デシジョンカバレッジは、「条件判断網羅」、「デシジョン／コンディション・カバレッジ」、「判断条件網羅」とも言われます。

これは、デシジョンカバレッジ、コンディションカバレッジの両方をカバーする考え方です。

つまり、コンディション・デシジョンのどちらか一方を網羅したとしてももう一方を網羅できるとは限らない、といった難点をカバーできます。コンディションとディシジョンの両方のカバレッジを向上させるために重要な考え方です。

コード例4

commandA();
  if (x == 0 || y <= 10) {??? // ||は「または」の意味
     commandB();
  }
commandC();

コンディション／デシジョンカバレッジを100%にする方法

この考え方では、各条件式について、真偽の判定と判断式の結果を網羅する必要があります。

つまり、上記に加えて下記を考慮する必要があります。

したがって、

「x = 0, y = 0」　...　「パターン(a)：TRUE」かつ「パターン(c)：TRUE」→TRUE(A)
「x = 1, y = 100」...　「パターン(b)：FALSE」かつ「パターン(d)：FALSE」→FALSE(D)

の2種類のテストケースを実行すれば、コンディション／デシジョンカバレッジは100%になります。

1‐5　MC/DC（改良条件判断網羅）

MC/DCは、Modified Condition/Decision Coverage の略です。改良条件判断網羅と訳されます。

前述したコンディション／デシジョン・カバレッジを利用した場合でもデシジョン・カバレッジと同程度のカバレッジとなってしまうので、より詳細で綿密なカバレッジ網羅を行う必要がある場合に、MC/DCを使用します。

特に、DO-178B(RTCA)といった、航空機器の安全基準などでこの考え方を用いるよう、設定されています。

DO-178Bの定義によると、MC/DCカバレッジを100%にするには、下記の条件を満たす必要があります。

1. 判断文がすべての結果を実行する
2. 条件式がすべてのパターンを実行する
3. 条件式の各条件が、単独で結果に影響する

1.と2.はコンディション／デシジョン・カバレッジと同等の基準ですが、この2つに3.を追加することによって、より詳細なカバレッジを実現することができます。

コード例５

commandA();
  if (x == 0 || y <= 10) {??? // ||は「または」の意味
    commandB();
  }
commandC();

MC/DCを100%にする方法

デシジョン／コンディションカバレッジと同様に、各条件式について真偽の判定と判断式の結果を網羅するという点は変わりません。

これに加え、条件式が単独で判断結果に影響するようなパターンを選択する必要があります。

したがって、

「x = 0, y = 100」...　「パターン(a)：TRUE」かつ「パターン(d)：FALSE」→TRUE(B)
「x = 1, y = 0」　...　「パターン(b)：FALSE」かつ「パターン(c)：TRUE」→TRUE(C)
「x = 1, y = 100」...　「パターン(b)：FALSE」かつ「パターン(d)：FALSE」→FALSE(D)

の3種類のテストケースを実行すれば、MC/DCは100%になります。

残った、「パターン(a)：TRUE」かつ「パターン(c)：TRUE」→TRUE(A)

については、条件式の真偽変更しても判断結果が変わらないため、MC/DCの3.の条件を満たしません。したがって、テストケースに含める必要はない、と判断できます。

1‐6　複合条件カバレッジ（C2）

複合条件カバレッジ（C2）は、マルチコンディション・カバレッジとも言います。すべての条件式の組合せを実行する考え方です。

単独の判断文に対するカバレッジの中ではもっとも網羅性の高い基準ですが、条件式が増えるほどテストケース数が極端に増えていくという欠点もあります。

コード例6

commandA();
   if (x == 0 || y <= 10) {??? // ||は「または」の意味
      commandB();
  }
commandC();

複合条件カバレッジ（C2）を100%にする方法

全ての条件式の組み合わせを網羅する必要があるため、上記表に表した4つのパターン全てを実行する必要があります。

1‐7　パス・カバレッジ

ここまで紹介してきた1～5のカバレッジは、単独の判断文に対するカバレッジ率を表現しています。
これに対して、プログラムの一定の範囲（関数やクラスなど）に対するすべての経路（パス）を網羅するかの基準がパス・カバレッジとなります。

そのため、プログラム内に判断文が増えれば増えるほど、テストケース数が極端に増えていってしまいます。

特に、for文・while文などのループを含むプログラムの場合は、実質的に100%網羅は困難となります。

2．過信は禁物！コードカバレッジの「落とし穴」

カバレッジには様々な種類があり、どのような観点で網羅性を高めるかによって達成できる品質や保証内容が異なることがわかりました。

カバレッジを100%に近づけることはテストケースの品質をあげるにあたって非常に大切な観点ですが、それだけでは不十分です。

なぜなら、カバレッジの向上を達成したとしても、実際にテストケースを振り返って保証できた内容を見てみると、システムに求める品質として不十分な場合があるからです。

例えば、下記のような命令文があるとします。

int a = b / c;

この例は、「b÷cの結果をaに代入する」という命令文です。

ですので、例えばbに10, cに5を設定するようなテストケースを実行すれば、カバレッジは100%となります。

ただし、cが0の場合、ゼロ除算のエラーが発生します。つまり、カバレッジが100%になっただけではエラーの考慮ができておらず、十分な品質保証ができないと言えます。

エラーが発生するのをcが0とならないことをどこかで担保する必要がありますが、カバレッジだけに着目していた場合は、この観点を確認できなくなる恐れがあります。

また、カバレッジの説明でこれまで例に挙げてきたコード例について考えてみてください。

commandA();
  if (x == 0 || y <= 10) {??? // ||は「または」の意味
    commandB();
  }
commandC();

プログラム言語や構造によっては、「x == 0」が真の場合には、「y <= 10」の部分を判断しないものもあります。このような仕組みを「遅延評価」と呼びます。

この場合はyの値を評価することなく、「x == 0」の部分だけでカバレッジを100%とすることができてしまうので、実際に実施するテストとしては不十分になることも考えられます。

このような「カバレッジの罠」にはまらないためにも、カバレッジの網羅性にばかり着目しすぎない方が良いこともあるでしょう。カバレッジの観点で作成したテストケースの内容が、システム全体として品質保証を十分にできているか、確認が必要です。

おわりに

今回の記事では、代表的なカバレッジの種類について具体的なコード例を挙げて解説した上で、カバレッジを扱うにあたって気をつけるべきポイントについて説明しました。

カバレッジ、特にコードカバレッジは、条件式とその判断結果を中心に網羅性をあげる、ホワイトボックステストを実施するにあたって非常に重要な観点です。

どの程度の網羅性を達成すべきかによってテストケースの選び方がそれぞれ変わりますので、それらの特徴を踏まえてカバレッジの手法を選択する必要があるでしょう。

ただし、カバレッジの考え方ではカバーしきれない観点は意外と多くあります。カバレッジを達成したテストケースがシステムの性質上保証すべき観点を押さえているか、毎回確認する必要があると言えるでしょう。

関連記事

システム内部構造をベースにテストする「構造テスト」