テストをしていて一番悩むのが、どこまでテストすればよいのだろうか、という点です。勘と経験と度胸で終了判定を行っている組織もあれば、独自の方法を編み出している組織もあるようです。また信頼度成長曲線（Software Reliability Growth Model: SRGM）を始め、昔から研究テーマとしてもよく取り上げられます。しかし、これを考えれば万事オッケーというような、万能の判定基準はありません。信頼性を判定する指標も同様です。テスト対象やテストそのものの様々な側面を総合的に把握する必要があります。

その一つの側面が「カバレッジ（coverage）」です。どれくらい網羅したテストなのか、という指標を意味しています。最も有名なのはコードカバレッジでしょう。C0、C1などという用語を聞いたことはありませんか。もしくは命令網羅や分岐網羅、ノード網羅やリンク網羅という呼び方かもしれません。基本情報技術者試験の範囲にも入っているようですね。

コードカバレッジというのは、プログラム内部のロジック（制御パスと呼びます）をどのくらい網羅したテストなのか、という指標です。例えば、命令網羅というのはコードカバレッジの一種になります。デバッガでステップ実行をして全ての行（命令）を実行するのは、命令網羅と同等になります。

カバレッジは、コードカバレッジだけではありません。ランダムテストやアドホックテストを除くと、全てのテストでカバレッジを考えることができます。仕様書の要件をどれだけテストしたか、という指標は、仕様カバレッジや要件カバレッジと呼ばれます。ユースケースを網羅する場合はユースケース網羅ですし、機能を網羅する場合は機能カバレッジです。機能の組み合わせを網羅するテストをしたいのであれば、機能組み合わせカバレッジを考える必要があるでしょう。カバレッジは、テスト設計の種類に対応して存在すると考えることができます。

カバレッジのもう一つ別の側面は、「設計カバレッジ」と「実施カバレッジ」です。例として、機能カバレッジが90%でテストを終了したためにテスト漏れが起こってしまった、すなわち市場不具合が発生したという状況を考えてみましょう。再発防止のために、原因を分析して対策を打つ必要があります。もしかしたらプロセスの成熟度が低いために仕様書が無く、テスト項目が存在しないことが原因かもしれません。この場合は、要求分析プロセスの質を向上して仕様書を作成し、テスト設計時に機能が網羅できているかどうかを簡単に確認できるチェックシートを作る、などの対策を挙げることができます。しかし見積もりが甘かったり開発が遅れたりしてテスト工数が足りないために、テスト項目を実行できないことが原因であれば、対策は異なります。このようにテストの質を上げるためには、設計カバレッジと実施カバレッジを分けて検討することが重要なのです。

さてカバレッジを出荷判定や信頼性評価の指標の一つに使う際には、2つの概念を整理して検討する必要があります。それが「カバレッジ基準」と「カバレッジ率」です。

例えば、ちょっと体調が悪いなと思って病院で検査を受けることを考えてみましょう。忙しいために１時間で終わる簡単な検査で済ます場合もあれば、2日かけて泊まり込みで人間ドックに入る場合もありますね。1時間コースの方が安く済むでしょうが、病気を見落とすかもしれません。2日コースの方がたくさん検査をする分だけ安心ですが、その分手間や費用がかかります。どちらを選ぶかは、必要とする安心度と費用のトレードオフです。

一方、2日コースできちんと2日受診する場合もあれば、忙しくて1時間で帰ってきてしまう場合もあります。同じ1時間の検査であっても、１時間コースを全て受診した場合と、2日コースなのに1時間しか受診しない場合とでは、ずいぶん異なるかもしれませんね。1時間コースを全て受診した場合は、精度は低いものの、身体全体を検査してくれるでしょう。しかし2日コースで1時間しか受診しない場合は、精度は高いかもしれませんが、身体の一部しか検査されていないかもしれません。

もうお分かりでしょう。カバレッジ基準とは、どれくらいテストをすべきか、という概念です。検査であれば、1時間なのか2日なのかという受けるべき検査の量（日数）にあたります。カバレッジ率とは、テストすべきカバレッジ基準をどれくらい達成したか、という概念です。検査であれば、1時間や2日といったそれぞれのコースを全て受診したのか、半分で帰ってしまったのか、にあたります。

命令網羅（C0網羅）や分岐網羅（C1網羅）というのは、カバレッジ基準です。基準が厳しいほど、見つけられる不具合の種類が多くなりますが、必要なテスト項目は同じか増加します。C1基準の場合、C0基準で見つからない飛び先誤りという不具合を見つけることができるようになりますが、飛び越しやループの数だけテスト項目数が増えていきます。一方、命令網羅で10本のテストパスが必要となった場合、5本しか実施しなければ、カバレッジ率は5本÷10本＝50%となります。

テスト項目の数を減らしたい場合は、2つの選択肢があります。一つはカバレッジ基準を緩めることであり、もう一つはカバレッジ率を下げることです。大差ないように感じますが、カバレッジ率を下げることはリスクを伴います。病院の検査の例から分かるように、カバレッジ率が低い場合は全体をテストできず、丸ごと抜けてしまう部分が発生してしまうのですね。しかも多くの場合はカバレッジ率の数値が一人歩きするため、どこが抜けてしまったのかを検討しないまま、市場に不具合が流出してしまうことになります。しかしカバレッジ基準を緩めるのであれば、その際にどんな不具合を見逃すのかをきちんと検討しておけば、レビューの結果などを併用することでリスクを抑えることができます。私見ですが、カバレッジ率は常に100%を達成すべきでしょう。C0基準で70%程度という基準の組織もあるようですが、実行できないパスが異常系で実行確率が低く、テストで実行するにはコストがかかりすぎ、かつレビューなどで不具合が無いことを十分検討しておいた場合にのみ有効だと思います。

カバレッジの検討は、出荷判定や信頼性評価だけでなく、自分たちのテストの質の把握にも使うことができます。皆さんの組織では、どのようなカバレッジ基準を採用していますか？カバレッジ基準を定められるようなテスト設計を行っていますか？カバレッジ基準の策定には、どのような検討を行いましたか？自分たちが採用しているカバレッジ基準では、どのような不具合を見逃すリスクがありますか？開発側のテスト（単体テストや結合テスト）でのカバレッジ率はどの程度ですか？出荷時のカバレッジ率はどの程度ですか？なぜ100%にならないのですか？100%に満たないテスト項目はレビューで押さえていますか？見逃した不具合は、カバレッジ基準を定めたテスト項目で見つけられるものでしたか？不具合を見逃したのは、設計カバレッジが低いからですか、実施カバレッジが低いからですか？・・・まずは自分たちがどんなテストをしているのかをカバレッジで把握して、テスト改善のきっかけにしてみましょう。