テストカバレッジとは。C0とC1の違いや正しく選ぶことの重要性を解説

テストカバレッジ(Test Coverage)は、ソフトウェアテストにおいて、テストの網羅度を測定するために用いられる指標値のことで、網羅率とも呼ばれます。その名の通りパーセントで表します。テスト対象やテストアイテムに対してテストすべき事柄をどれくらいテスト実行しているかを表す割合、ということができます。

一般的にテストカバレッジというと、コードカバレッジ（C0、C1、C2）が浮かびます。しかし、これ以外にもさまざまなテストカバレッジがあり、テストレベルごとに異なるものが用いられます。

本記事では、これらのカバレッジの説明と共に、それぞれどのように用いられるかを解説します。

以下にユニットテストで用いられるカバレッジを紹介します。

C0、C1、C2は、コードカバレッジ、あるいは構造カバレッジと呼ばれ、ホワイトボックステストで用いられるカバレッジです。コードに対するテストケースでの実行の割合を表します。

C0 ステートメントカバレッジ（Statement Coverage）

命令網羅と呼ばれます。テスト対象のコード中の命令文に対する網羅率です。このカバレッジが100％になると、コード中の全ての命令文が少なくとも1回実行されたことになります。コードカバレッジの中で最も簡単に達成できるカバレッジです。

C1 デシジョンカバレッジ（Decision Coverage）

分岐網羅と呼ばれます。コード中の分岐に対しての網羅率を表します。このカバレッジを達成するには真と偽の両方が実行される必要があります。

C2　コンディションカバレッジ（Condition Coverage）

条件網羅と呼ばれます。複合条件式に含まれる条件式それぞれが、真と偽の両方の結果が実行されている必要があります。これは複数の組み合わせが発生し、デシジョンカバレッジに比べ、多くのテストケースが必要になります。

コードカバレッジのC0、C1、C2には、それぞれメリットとデメリットがあります。C0はテストケース数が最も少なく済むため、低コストで実行できます。しかし、分岐条件や例外的な処理など、テストで網羅されない処理が多いため、バグを見逃すリスクがあります。C2は逆に、メリットとしてバグを検出できる可能性が最も高くなりますが、多くのテストケースが必要になり、コストは高くなります。

どれを用いるべきかは、テスト対象の条件（プロダクトによっては国際標準や法規）やプロジェクトの条件などにより決めます（図表1）。

図表1：コードカバレッジの特徴

その他のコードカバレッジ

C0、C1、C2以外にも以下のカバレッジが用いられることがあります。

MC/DC（Modified Condition/Decision Coverage）

安全が重視される分野で用いられ、DO-178C（民間航空機ソフトウェア認証基準）やISO 26262（自動車機能安全規格）などの国際標準において高い信頼性や安全性が求められるプロダクトに対する基準の一つとなっています。

複合条件カバレッジ（Multiple Condition Coverage）

複合条件式に含まれる真と偽の全ての組み合わせを網羅します。網羅性の高いカバレッジですが、条件の数が増えると指数関数的にテストケース数が膨大になります。

パスカバレッジ（Path Coverage）

対象のコードの、開始から終了までの全てのパスに対して実行されたテストケースの割合です。コード中の分岐を通って終了に至る一連の処理をテスト実行します。

ここまでで紹介したコードカバレッジは、主にユニットテストで用いられます。それでは、他のテストレベルではどのようなカバレッジが用いられるのでしょうか。それぞれのテストレベルで用いられるカバレッジを見てみましょう。

以下に統合テストで用いられるカバレッジを紹介します。

インターフェースカバレッジ

複数のコンポーネントがやり取りする、インターフェースの網羅率の指標です。API、関数の呼び出し、通信路、データ形式などに着目します。定義されたインターフェースが最低一度呼び出されることが条件となります。

データカバレッジ

入力データ、システム内部データの網羅率の指標です。入力値のバリエーション、内部状態やフラグの網羅性、データ構造・組み合わせ網羅といった観点があります。主な観点は図表2のとおりです。

図表2：データカバレッジの観点

構造カバレッジ 

統合テストレベルにおける構造カバレッジでの網羅に対する考え方はコードカバレッジと同様ですが、複数のモジュール、クラス、サービス間のインターフェースを対象とし、実際に連携して動作した時に、コードのどの部分が実行されたかを測定します（図表3、図表4）。

以下にシステムテストで用いられるカバレッジを紹介します。

機能カバレッジ

システムに定義されている機能に対するカバレッジです。全ての機能に対してテスト実行できた割合を評価します。

要求カバレッジ

要求定義書やユーザーストーリーに対するカバレッジです。これらが全てテストできているかを評価します。

ユースケースカバレッジ

ユーザーによるシステムの使われ方を想定したシナリオについて全てテストできているかを評価します。

以下に受け入れテストで用いられるカバレッジを紹介します。

要求カバレッジ

顧客・ユーザーの要求項目（要件定義・受け入れ基準）がテスト実行されたかを評価します。

業務シナリオカバレッジ

実際にシステムを利用するユーザーの、業務の流れやユースケース、ユーザーシナリオがテストされたかを評価します。

業務フローカバレッジ

システムや業務プロセス全体の流れを業務シナリオ化したものを基に、業務フローを用いて体系的に記述し、そのフローの分岐や経路がテストされたかを評価します（図表5）。

図表5：業務シナリオカバレッジと業務フローカバレッジの違い

機能カバレッジ 

システムに実装された機能についてテストされたかを評価します。ここでの機能は、コードレベルではなく、要求仕様に対してシステム化されたテスト対象がどのように振る舞うかを確認します。

カバレッジそのものは、それぞれが指し示すものに対してテストケースがどれくらいカバーできているかを表します。

今まで取り上げたカバレッジは、各テストレベルで必ず取り入れなければいけないわけではありませんし、そのカバレッジを100％にすれば無条件で品質が上がる、というものでもありません。プロダクトやプロジェクトの目的、品質目標、リスクを検討した上でテストによって何を達成したいのか、ステークホルダーに対して品質の指標として何を提示すべきかを考えて、どのカバレッジを採用するかを決定する必要があります。

テストレベルごとに明確な目的を設定し、テスト活動で何を保証するのかを検討してテスト計画を立案し、テスト戦略を作成します。組織としてのガイドライン（テスト方針や組織のテスト戦略）などの定義があれば、それに従ってテスト計画に盛り込みます（図表6）。

テスト計画とカバレッジ

テスト計画を策定する場合は、テスト戦略を具体的に実行可能な形に定義していきます。そしてテスト戦略で、カバレッジをどこまで満たすべきかを決定します。テストの終了基準として明確な形でカバレッジを定義します。

テスト設計とカバレッジ

テスト戦略で定めたカバレッジを、テスト計画で定めた水準まで満たせるようにテストを設計してきます。カバレッジはテストケース作成のための指針として機能します。

テスト実行とカバレッジ

テスト実行により、適用したカバレッジがどの程度達成できたかによって、テスト計画に対するテスト実行での達成度合いを確認または評価できます。

図表7：テストプロセスごとのテストカバレッジの役割

どのカバレッジをどのプロセスで、どれくらい達成するか、という基準を適切に設定すれば、各テストプロセスの指標として用いることができます（図表7）。また、テスト実行後、品質を推し測るためにカバレッジを用いることもできます。

テストをどれだけ網羅的に実行したかが数値として分かるため、その時点のテスト対象やテストアイテムの品質を評価できます。ただし、適切なカバレッジを用いていない場合、十分に不具合を検出できていない可能性があります。

また、適切なカバレッジが用いられていても、テストケースが妥当でない場合、十分なテストを行ったとは言えません。非機能特性のように、システムの振る舞いや特性を評価しなければならない場合、カバレッジでは測れないからです（図表8）。

図表8：カバレッジが担保できること・できないこと

このようにテストカバレッジは、どこをテストしたかを表すための指標です。適切なテスト戦略により、妥当な深さのテストが行われたかはカバレッジの数値だけでは判断できません。

テストカバレッジは、テスト対象に対してどれだけテストしたかを表す指標です。品質を向上させるために、このカバレッジを達成すべき目標として捉えず、テストの目的から導かれたテスト戦略に基づく指標として用いることにより、適切なテストを実行できるようにしましょう。

さらにカバレッジだけに頼らず、テストの妥当性や非機能特性を考慮したテスト技法を組み合わせることで、効果的に品質を向上させることを心掛けましょう。