キャリア

【新人必見】「ホワイトボックステスト」でつまずかない！カバレッジ(C0/C1)達成のためのテストケース作成完全ガイド

ENGINEER.CLUB編集部

• 最終更新日:2026/1/27

「ホワイトボックステスト」という言葉を聞いて、
「コードの中身を見て、一体どこまでテストすればいいんだろう？」

「C0とかC1とか、カバレッジの基準が曖昧で不安だ…」と感じていませんか？

ソフトウェア開発の現場で単体テストや結合テストを担当する際、必ず直面するのが、この「内部構造の網羅性」を問われる課題です。
特に新人や、テスト業務に不慣れなエンジニアにとって、複雑な処理フローを追いかけ、すべての分岐を網羅するテストケースを設計するのは、大きな壁となります。

安心してください。

本記事は、ホワイトボックステストの基礎知識から、実務で必須となる「カバレッジ(網羅率)」を確実に達成するための具体的なテストケース作成手順までを、図解とコード例を用いて徹底的に解説します。

難しい理論は抜きにして、この記事を読み終える頃には、あなたはホワイトボックステストの目的を明確に理解し、「このテスト設計で網羅性はバッチリだ！」と自信を持って業務に取り組めるようになっているでしょう。

さあ、テスト設計の不安を解消し、品質の高いコード開発への一歩を踏み出しましょう。

セクション1：そもそも「ホワイトボックステスト」とは？

ホワイトボックステスト (White-Box Testing)とは、プログラムの内部構造や論理構造を理解した上で、その構造が設計通りに動作することを検証するテスト手法です。
まるでコードという「白い箱（White-Box）」の中身を覗き込むようにテストすることから名付けられました。

１ｰ１．テストの目的：なぜコードの「中身」を見る必要があるのか

テストの主な目的は以下の2点です。

1. 内部ロジックの検証
   if文、forループ、例外処理など、すべての処理パス（経路）が意図した通りに実行されるかを確認する。
2. 網羅性の確保
   実行可能なコード行や分岐が漏れなくテストされているかを数値（カバレッジ）で確認し、品質の基盤を築く。

１ｰ２．ブラックボックステストとの決定的な違い(役割と適用フェーズ)

ホワイトボックステストを理解する上で、対極にあるブラックボックステストとの違いを明確にすることが重要です。

ブラックボックステストは、ユーザーの視点から「ボタンを押したらどうなるか」を確認します。
一方、ホワイトボックステストは、開発者の視点から「このif文のelse側は実行されたか」を確認するのです。

１-３．ホワイトボックステストの主な適用場面(単体テスト、結合テストでの役割)

• 単体テスト (Unit Testing)
  役割： 最も主要な適用場面です。関数やメソッドといった最小単位のコードが、すべてのロジックを正しく処理しているかを確認します。カバレッジ計測はこのフェーズで最も重要視されます。
• 結合テスト (Integration Testing)
  役割： モジュール間のインターフェース（データの受け渡し部分）のロジックが正しいかを、内部構造を参照しながら確認するために使われることがあります。ただし、メインの目的はインターフェースの検証であり、カバレッジ計測は単体テストほど厳密には求められないことが多いです。

セクション2：ホワイトボックステストの実務で必須！カバレッジ(網羅率)の基礎知識

ホワイトボックステストは、コードの内部構造に着目し、そのロジックが意図通りに動作するかを検証するテスト手法です。
このテストの品質、すなわち「本当に必要な部分をテストできているか」を客観的に評価し、漏れなくテストを完了させるために、カバレッジ（網羅率）の理解は不可欠です。

本セクションでは、ホワイトボックステストの品質保証に直結するカバレッジの基本的な概念、そしてテストの実務でよく利用される代表的なカバレッジの種類について学びます。
この知識は、テストの計画・実行・完了基準の設定において、技術者としての説得力と信頼性を高める土台となります。

２-１．カバレッジとは何か？(テストの「抜け漏れ」を防ぐ指標)

カバレッジ (Coverage)、または網羅率とは、作成したテストケースによって、プログラムのどの部分がどれだけ実行されたかを示す指標です。

この要素とは、「コードの行」「処理の分岐」「条件式」などを指し、どの要素を対象とするかによって、C0、C1などの網羅基準が変わってきます。

２-２．最も基本となる基準：C0(命令網羅)の考え方

C0 (Command Coverage / 命令網羅)は、プログラム中のすべての実行可能な命令（ステートメント）を少なくとも一度は実行するようテストする基準です。

• 意味合い
  「すべての行が一度は実行された」ことを保証します。
• 実務上の位置付け
  最低限クリアすべき基準です。これが満たされないコードは、そもそもテストされていない行が存在することを意味します。

【コード例：C0網羅】Java

// 対象コード
int calculateValue(int a, int b) {
    int result = a + b; // (命令1)
    if (result > 10) {  // (命令2: 分岐の開始)
        return result * 2; // (命令3)
    }
    return result; // (命令4)
}

C0網羅に必要なテストケース
　a=5, b=6 → result=11。
　このケースで命令(1), (2), (3), (4)（ifの中と外両方）が実行され、100%達成となります。

【中堅エンジニアとしての助言】
　C0は簡単そうに見えますが、if文の中身の処理が実行されるかどうかは、条件次第です。
　C0を意識するということは、テストがすべての処理行を通過するように設計する、
　ということです。キストが入ります。

２-３．品質を確保する重要な基準：C1(分岐網羅／デシジョンカバレッジ)の考え方

C1 (Branch Coverage / 分岐網羅またはDecision Coverage / デシジョンカバレッジ)は、プログラム中のすべての分岐命令（if、while、caseなど）において、
真（True）と偽（False）の両方の経路を少なくとも一度は実行するようテストする基準です。

• 意味合い
  「すべてのif文でYESの場合とNOの場合の両方がテストされた」ことを保証します。
•  実務上の位置付け
  多くの現場で単体テストの必須基準とされている、最も重要なカバレッジ基準です。C1を達成すれば、必ずC0も達成されます。

【コード例：C1網羅】前述のコードをC1基準で考えます。Java

// 対象コード
int calculateValue(int a, int b) {
    int result = a + b;
    if (result > 10) { // ★分岐条件
        return result * 2;
    }
    return result;
}

• 分岐条件　 　： result > 10
• Trueの経路 　： result > 10となるケース（例：a=5, b=6 → result=11）
• Falseの経路　： result <= 10となるケース（例：a=3, b=4 → result=7）
• C1網羅に必要なテストケース： 1. True経路を通るケース: a=5, b=6 → 戻り値: 22 2. False経路を通るケース: a=3, b=4 → 戻り値: 7

この2つのテストケースで、C1カバレッジ100%が達成されます。

２-４．より厳しい品質を求めるなら：C2(条件網羅)とMC/DC(応用知識)

C1が分岐全体（if文全体）のTrue/Falseを網羅するのに対し、複合条件（例：if (A && B)）を持つ場合、より厳しい以下の基準が用いられます。

【中堅エンジニアとしての助言】
　新人のうちは、まずはC1（分岐網羅）100%を達成することを目標にしましょう。
　多くの一般的なビジネスアプリケーションでは、単体テストでC1達成が求められます。
　C2や　MC/DCは、プロジェクトの特性に応じて必要になった際に学習すれば十分です。

セクション3：明日から使える！カバレッジ達成のためのホワイトボックステスト実践手順

ここからは、実務でカバレッジを達成するための具体的なテストケース作成手順を解説します。

３-１．【STEP1】対象コードの把握とフローの可視化

まず、テスト対象の関数やメソッドのコードを読み込み、処理の流れを理解します。
複雑なロジックの場合は、制御フローグラフをイメージして可視化すると、分岐と経路が明確になります。

• 着目ポイント： if文、whileループ、switch/case文、例外処理（try-catch）など、制御が分かれる箇所を特定する。

３-２．【STEP2】網羅基準(C0 or C1)の設定

上司やプロジェクトの規約に従い、満たすべきカバレッジ基準を設定します。
特に指定がない限り、C1（分岐網羅）を目指すのが一般的です。

•  C0目標の場合： すべての処理行を通る最小限の経路を探す。
•  C1目標の場合： すべての分岐条件に対して、TrueとなるケースとFalseとなるケースのペアを特定する。

３-３．【STEP3】カバレッジを満たす最小限のテストケースの洗い出し(実例演習)

前のセクションのコードを例に、C1網羅のためのテストケースを具体的に洗い出します。

【対象コード】Python

def check_level(score, is_pro):
    if is_pro and score >= 90:  # 分岐A
        return "Expert"         # 経路A-True-B-True
    elif score >= 70:           # 分岐B (is_proがFalseかscore<90の場合に評価)
        return "Advanced"       # 経路A-False または 経路A-False-B-True
    else:
        return "Beginner"       # 経路A-False-B-False

【C1網羅のためのテストケース設計】

ポイント： テストケース1で分岐AのTrue側、テストケース2で分岐AのFalse側（score >= 90がFalse）、テストケース3で分岐BのFalse側を網羅しています。
　　　　　この3つのケースで、すべての分岐のTrue/False経路が実行され、C1網羅率100%が達成されます。

３-４．【STEP4】テストケースの効率的な設計技法(制御パステストの導入)

上記の例のように、すべての分岐経路を網羅するために、より体系的な手法として制御パステストがあります。
これは、制御フローグラフ上で実行可能な独立した経路をすべて特定し、その経路を最低一度は通るようなテストケースを設計する技法です。

• 独立した経路（独立パス）
  過去に通過していない命令を少なくとも一つ含む経路のこと。
• 導出方法
  制御フローグラフを作成し、グラフのサイクロマティック複雑度（$V(G)$）を計算します。
  ・ V(G) = E – N + 2P （E:エッジ数, N:ノード数, P:連結グラフの数）
  ・ このV(G)の値が、C1網羅に必要な最小限の独立パスの数を示します。

【中堅エンジニアとしての助言】
　複雑度が低い（V(G)が小さい）ほど、コードはシンプルでテストしやすいと言えます。
　コードを書きながらこのV(G)が大きくなりすぎないように意識することも、可読性の高い
　コードを書くための重要なスキルです。入ります。

セクション4：新人エンジニアが陥りがちなホワイトボックステストの落とし穴と解決策

４-１．「網羅率100%＝バグゼロ」ではない！：カバレッジの限界を知る

C1カバレッジ100%を達成したからといって、「バグが一つもない」という意味ではありません。これは、「実装したロジックのすべてが実行された」ことを示すにすぎません

• カバレッジの限界

1. 仕様の漏れを見つけられない： そもそも実装されていない機能や仕様に関するバグは、カバレッジでは発見できません。
2. データの誤りを見つけられない： 境界値分析などのデータに着目したテスト技法を組み合わせないと、データの処理ミスは検出できません

解決策： ホワイトボックステスト（C1）でロジックの網羅性を担保しつつ、ブラックボックステストの技法（境界値分析、同値分割など）を組み合わせてデータの網羅性も確保しましょう。

４-２．テストケースのレビューで指摘を減らすためのチェックポイント

テスト設計書を上司に提出する前に、以下の点を確認しましょう。

• 網羅性の根拠が明確か？
  「このテストケースは、if文のFalse経路を網羅するために設計した」といった目的を設計書に明記する。
• 境界値が考慮されているか？
  条件式（例：score >= 90）の境界値（90や89）は必ずテストケースに含める。
• 異常系も網羅されているか？
  意図しない入力（null、ゼロ除算、負の値など）に対するエラー処理や例外処理もC1基準で網羅できているか確認する。

４-３．ツールを使ったカバレッジ計測の効率化

実務では、カバレッジを手動で数える必要はありません。
多くのプログラミング言語には、カバレッジ計測を自動で行う専用のツールが存在します。

これらのツールをCI/CD（継続的インテグレーション/継続的デリバリー）パイプラインに組み込むことで、コードの変更があるたびに自動でカバレッジを計測し、設定した基準（例：90%以上）を下回った場合に警告を出すなど、品質を自動で維持する仕組みを作ることができます。

まとめ：自信を持って単体テストを完了させましょう

本記事を通じて、あなたは以下の重要なスキルと知識を身につけました。

1. 概念の整理
   ホワイトボックステストは、単体テストフェーズで内部構造の網羅性を検証する開発者にとって必須のテスト手法であること。
2. カバレッジの理解
   実務で重要なのは、すべての分岐のTrue/FalseをテストするC1（分岐網羅）であること。
3. 実践スキル
   コードから分岐条件を特定し、C1を達成するための最小限かつ効果的なテストケースを設計する具体的な手順。

私が中堅エンジニアとして新人の方に伝えたいのは、テスト設計は「作業」ではなく「品質保証」の設計であるということです。単に動けばOKではなく、「このコードは私が保証した」と言える根拠がホワイトボックステストにあります。

この知識と自信を持って、今日からあなたの単体テスト設計書を、「網羅性100%の、抜け漏れのない設計」へとアップグレードしてください！

次に、あなたのプロジェクトの最も複雑な関数を一つ選び、C1網羅を目指してテストケースの洗い出しを始めてみませんか？