今回は「知っておきましょう」という知識の話です。
カバレッジ、ご存知ですか？
- テスト網羅率
- テスト設計の観点のひとつ
- 分岐をどこまでテストするか
カバレッジの種類
- C0：ステートメントカバレッジ（命令網羅）
- すべての行（命令文）を少なくとも1回は実行した割合
- 最も基本的だが、条件分岐の全ルートはチェックできないため、テストとしては不十分な場合が多い
- C1：ブランチカバレッジ（分岐網羅）
- すべての条件分岐（if文など）の真 (True) と偽 (False) を少なくとも1回は実行した割合
- 実務において、最低限クリアすべき基準としてよく設定される
- C2：コンディションカバレッジ（条件網羅）
- 分岐内の個々の条件式（複数の条件が結合している場合）が、真と偽の両方を取るように実行した割合
- 例：if (A && B) の場合、A単体、B単体の真偽をチェック（分岐全体の真偽とは異なる）
高度な網羅率
- MC/DC（修正条件判定網羅）
- 他の条件に影響されず、特定の1つの条件を変えるだけで全体の判定結果が変わるかを検証する高度な網羅基準
- 航空宇宙や自動車など、極めて高い安全性が求められるシステムの開発（ISO 26262など）で必須
イメージで理解する
if (a && b)
{
funcA();
}
else
{
funcB();
}
この分岐だと、C0とC1は同等。a あるいは b の境界値のみチェックする。
C2は、a と b の両方の境界値をチェックする。
実務では
- C0、C1では明らかに不足
- 経験的には
C2を漏らすことが多い気がする... - 実際にはここまで単純ではなく、全組み合わせを網羅するのは現実的ではない
- 早期リターンにより、以降の検査を行わなくてよくなる
- elseがないif/defaultがないswitch
実務では
全組み合わせは現実的でないので、実行可能でありながら致命的な結果が起きない手法を探す。
腕の見せ所！
- クリティカルな機能では網羅率を上げる
- 実装パターンを統一する
- テストが漏れても大けがしないようにしておく！
最後に
- カバレッジはテスト設計と切っても切り離せない
- テスト設計には様々な手法がある（そのうち情報共有します）
- お使いの言語でカバレッジ計測ツールを調べてみるのもいいでしょう