コードカバレッジのまとめ

単体テストレベルでは、「コードカバレッジ」を意識しながら（基準にしながら）テスト設計やテストケース作成を行う機会が多い。でも、この「コードカバレッジ」って用語がばらばらであったり、どのカバレッジ基準がどういうことを確認するものなのか、どういう不具合を見つけられるのか、見つけられないのか、といったことが自分の中でしっかりまとまっていなかったので、いろいろ調べてまとめようと思います。

2008/03/12更新
　　サンプルプログラムで解説を追加
　　サンプルプログラムは、以前例題として作成したテニスのスコアボードについて
　　[例題]テニスのスコアボード

ステートメントカバレッジ

命令網羅。テスト対象となるプログラム中のステートメント（命令文）をどれくらい実施したかどうかをあらわす基準。すべてのステートメントを最低1回実施した場合に、ステートメントカバレッジ100%という。もっとも基本的なカバレッジ基準であるが、もっとも強度の弱い基準といってもよい。プログラムをフローグラフ（処理ブロック、判定、合流の3種類で表現したグラフ）に変換した場合、すべてのノードを通過することと同値であるので、ノードカバレッジとも呼ばれる。

• 強みポイント

すべてのステートメントが到達可能だということがテスト実施によって証明される。つまり、実装したが到達不可能なコードを見つけることができる。「最低限」ではあるが、もっとも低コストで網羅が可能な基準といえる。
• 弱みポイント

テスト対象となるプログラム構造について検証するという目的では、あまり効果がない。分岐の妥当性（分岐条件が正しいかどうか、分岐がすべて網羅されているか等）について保証するためにはより強度の高い基準が必要となる。
• 100%カバレッジのテストケース例




1. リセットボタンを押す


2. 電源ボタンを押す


3. ゲームポイントではない状態で、ポイントボタンを押す


4. ゲームポイントだが、セットポイントではない状態で、ポイントボタンを押す


5. セットポイントだが、マッチポイントではない状態で、ポイントボタンを押す

ブランチカバレッジ

分岐網羅。テスト対象となるプログラム中のブランチ（分岐）をどれくらい実施したかどうかをあらわす基準。ブランチとはフローグラフでは、2方向以上のリンクを持つノードを意味し、すべてのブランチにおいて、すべての方向を最低1回実施した場合に、ブランチカバレッジ100%という。フローグラフに変換した場合、すべての判定ノードの決定結果をすべて通過することと同値であるので、デシジョンカバレッジとも呼ばれる。

• 強みポイント

自明であるが、ステートメントカバレッジよりも強度の強い基準である。また、実装された分岐ノードでの判定が正しいかどうかをテスト実施によって確認できる。つまり、分岐での条件間違いを検出することができる。
• 弱みポイント

テスト対象となるプログラムや実装言語によっては、分岐条件が論理和（OR）/論理積（AND）であったり、分岐ノードですべての条件について判定しない場合がある。フローチャートをフローグラフに変換することである意味、検出可能なバグが隠蔽されてしまう可能性がある。
• 100%カバレッジのテストケース例




1. リセットボタンを押す


2. 電源ボタンを押す


3. ゲームポイントではない状態で、ポイントボタンを押す


4. ゲームポイントだが、セットポイントではない状態で、ポイントボタンを押す


5. セットポイントだが、マッチポイントではない状態で、ポイントボタンを押す


6. マッチポイントの状態で、ポイントボタンを押す

コンディションカバレッジ

条件網羅。テスト対象となるプログラム中のブランチが論理和（OR）/論理積（AND）を含む場合、各々条件をどれくらい実施したかどうかをあらわす基準。フローグラフでは無視されてしまう各ブランチでの判定条件を分解して、すべての判定条件を最低1回実施した場合に、コンディションカバレッジ100%という。

• 強みポイント

自明であるが、ブランチカバレッジよりも強度の強い基準である。また、フローグラフでは省略されてしまう、各ブランチでの詳細条件にも着目してテスト設計されるため、ブランチカバレッジでは検出不可能な、より細かい条件間違いを検出することができる。たとえば、論理演算子の順序や記述ミスなどが検出できたり、エラー処理の分岐が足りないなどのバグも検出できる。
• 弱みポイント

各ブランチを構成する条件たち（因子たち）が非独立の場合に、単一の条件のみ（単因子のみ）に着目しているため、検出できない複合的なバグを見落とす可能性が残る。
• 100%カバレッジのテストケース例

今回のサンプルプログラムの場合、分岐B、分岐Cの条件が非常に複雑である。


P1：　第1セット～第4セットである（＝最終セットではない）

P2：　第1ゲーム～第12ゲームである

P3：　今回のポイントが4ポイント目以上である

P4：　今回のポイントが7ポイント目以上である

P5：　今回のポイントで2ポイント差

P6：　今回のゲーム勝利で6ゲーム目以上である

P7：　今回のゲーム勝利で2ゲーム差

P8：　今回のセット勝利で3セット目

分岐Bが真　⇔　P1 && (P2 && P3 && P5 || !P2 && P4 && P5) || !P1 && P3 && P5　が真

分岐Cが真　⇔　P1 && (P2 && P6 || !P2) || !P1 && P6 && P7

分岐Dが真　⇔　P8


すべての単独条件の真偽を網羅するためには、、、（作成中）

マルチコンディションカバレッジ

複数条件網羅。テスト対象となるプログラム中について、各ブランチの各々条件の組み合わせをどのくらい実施したかどうかをあらわす基準。すべての判定条件の組み合わせを最低1回実施した場合に、マルチコンディションカバレッジ100%という。

• 強みポイント

自明であるが、コンディションカバレッジよりも強度の強い基準である。また、各ブランチについていえば、すべての可能な条件を網羅しているため、コンディションカバレッジ基準で検出できなかったバグを検出する可能性がある。
• 弱みポイント

ステートメントカバレッジ、ブランチカバレッジ、コンディションカバレッジに比べて、テストケースが掛け算・指数関数的に膨大化しやすく、現実的ではない場合がある。コンディションカバレッジ基準では検出不可能なバグが見つかる可能性もあるが、本来はテスト対象の見直し・リファクタリングも考慮すべきである。
• 100%カバレッジのテストケース例

作成中

MC/DC

変更条件・分岐網羅、あるいは、モディファイドコンディション/デシジョンカバレッジ。テスト対象となるプログラム中において、各ブランチの各々条件が、分岐方向（結果）に影響を与えるような判定条件（原因）をどのくらい実施したかどうかをあらわす基準。すべての分岐方向を通過するような判定条件の組み合わせを最低1回実施した場合に、MC/DC100%という。また、原因結果グラフやデシジョンテーブルなどを利用したテスト設計は、このカバレッジ基準と同等といえる。

• 強みポイント

自明であるが、コンディションカバレッジよりも強度の高い基準である。また、マルチコンディションカバレッジよりも強度でいえば下回るが、より効率的にコードをカバーしているため、遜色のないバグ検出が可能である。
• 弱みポイント

他のカバレッジ基準に比べて、考え方が難しい点、解説資料が少ない点などがある。また、実装自体のリファクタリング、単純な実装などであれば、テスト設計のコストに見合った効果が期待できない場合がある。
• 100%カバレッジのテストケース例

作成中

パスカバレッジ

経路網羅。テスト対象となるプログラム中の考えうるすべての経路をどのくらい実施したかどうかをあらわす基準。すべての経路を最低1回実施した場合に、パスカバレッジ100%という。ただし、現実的には達成不可能の場合が多い。

• 強みポイント

理論上はすべての構造的なバグを検出可能である。
• 弱みポイント

現実的ではない場合が多い。パスカバレッジを達成するために、更なるコンポーネントの細分化が求められる。
• 100%カバレッジのテストケース例

現実的なテストケース数には落とし込めないので割愛。

参考：
Code Coverage Anaysis
Testing and Code Coverage
Part2 ホワイトボックス技法：ITpro
ソフトウェアテストの分類
A Practical Tutorial on Modified Condition/Decision Coverage(PDF)