ホワイトボックステストの網羅率100％で本当に大丈夫？新人エンジニア必見の徹底解説

2025年2月19日 2025年2月19日山崎講師

山崎講師

こんにちは。ゆうせいです。

ホワイトボックステストの網羅率100％で本当に大丈夫？新人エンジニア必見の徹底解説

こんにちは。ゆうせいです。今回はソフトウェアテストの世界でよく聞かれる「ホワイトボックステストの網羅率が100％ならバグはないのか？」という疑問についてお話しします。新人エンジニアの方々は、テストの網羅率を見ると安心してしまいがちですが、テストの品質はそれだけでは語れません。どうしてだと思いますか？一緒に探究しましょう！

ホワイトボックステストとは？

ホワイトボックステストは、ソフトウェア内部のコードやロジックを把握した上で実施するテストです。プログラムの制御構造や条件分岐を意識してテストケースを作成します。ブラックボックステストが外部仕様（入力と出力）に基づくのに対して、ホワイトボックステストはソースコードそのものに注目する点が特徴です。

なぜホワイトボックステストが必要？

ロジックの抜け漏れを発見しやすい
内部構造を直接確認しながらテストを組み立てるため、複雑な条件分岐やループなどの不具合を見つけやすくなります。
コーディングの理解が深まる
実際にどのような流れで処理が行われているのかを理解するうえで、とても役立ちます。

網羅率（カバレッジ）とは？

ホワイトボックステストでは「網羅率（カバレッジ）」という指標が登場します。テストでコードのどれくらいを実行できているかを数値化したものです。代表的な測定項目として、以下のようなタイプがあります。

ステートメントカバレッジ（Statement Coverage）
実行可能な全ての文（ステートメント）が少なくとも1回実行されたかを測定します。
ブランチカバレッジ（Branch Coverage）
条件分岐の中のif文やswitch文などがtrue/false（各ケース）で最低1回ずつ実行されたかを測定します。
パスカバレッジ（Path Coverage）
分岐から派生するあらゆる通り道（パス）を少なくとも1回ずつ実行するかを測定します。

網羅率の算出は、下記のような数式を用いて考えられます。例としてステートメントカバレッジの場合を挙げてみましょう。

カバレッジ率 = ( テストで実行されたステートメント数 / ステートメント総数 ) × 100
Coverage(%) = ( Number_of_Executed_Statements / Total_Number_of_Statements ) × 100

値が100％なら「全ての行を一度は通った」という意味になります。ただし、この数値が高ければ高いほどテストが完璧なのかというと、必ずしもそうではありません。

網羅率100%でも安心できない理由

1. テストの深さが不十分な可能性

1回実行しただけでエッジケース（極端な入力値など）を十分に検証できているとは限りません。たとえば数値の境界付近でしか発生しないバグなどは、網羅率が高くても取りこぼしてしまうことがあります。

2. 想定外の連携・環境依存の問題

外部APIとの通信やOS、データベースなど、コードだけでは把握しきれない要素の不具合は、ホワイトボックステストの網羅率に反映されません。アプリケーションの実行環境が変わると症状が出るような不具合には別の視点のテストが必要です。

3. ロジックの誤りを発見できない場合

意図通りに全行実行しているとしても、そもそものロジックが間違っていれば正しい挙動はしません。網羅率で測れるのはあくまで「行数や分岐がテストによって通っているか」であり、ビジネスルールや仕様理解が間違っている場合には気づかないままになることがあります。

例：単純なif文で考える

以下のコードを考えてみてください。

if (score > 80) {
    System.out.println("合格");
} else {
    System.out.println("不合格");
}

スコアが81点のときと79点のときでテストすれば、ステートメントカバレッジは100%になり、ブランチカバレッジも100%になるはずです。ところが、境界値（80点ちょうど）のときのメッセージを確認していないと、思わぬ動きを見落とす可能性があります。

もう少し複雑な例を考えてみると、「実行される行数」は全て網羅できていても、「分岐先のロジックが本来の業務仕様と合っているのか」までは網羅率だけでは判断できません。

図で見るカバレッジのイメージ

下図のように、プログラム上には多くの通り道（分岐パス）が存在します。網羅率が100％になっていても、実は様々な入力パターンや状態遷移が存在し、単に全行を一度ずつ通っただけでは検証しきれない部分があるとイメージできます。

 +-----+   yes    +-----+
 |判断1|--------->|処理A|
 +-----+          +-----+
    | no
    v
 +-----+   yes    +-----+
 |判断2|--------->|処理B|
 +-----+          +-----+
    | no
    v
  (他の処理)

他のテスト手法との組み合わせ

ブラックボックステストや探索的テスト（仕様や使用状況をもとに自由度高く実施するテスト）と併用すると、さらに安心できます。機能の観点やユーザー視点の観点で「何が正しい動きなのか」を確認しない限り、どうしても漏れが発生しやすくなります。

ブラックボックステスト（Black Box Testing）
外部仕様や要求仕様を軸にして、入力と出力だけを確認するテスト。
探索的テスト（Exploratory Testing）
テスト担当者の知識や経験を活かし、自由度の高い手動テストを行う手法。

メリットとデメリット

	メリット	デメリット
ホワイトボックステスト	内部のロジックを詳細にチェック可能	コードを把握する時間とコストがかかる
ブラックボックステスト	ユーザー視点の欠陥を発見しやすい	内部のミスロジックを見落とす恐れ

いずれも併用することが重要になります。

まとめと今後の学習の指針

ホワイトボックステストの網羅率が100％になっていても、バグが完全に存在しないわけではありません。網羅率はあくまで「テストがどの程度コードを通過したか」を示す指標であって、仕様的な間違いや境界値などの問題を十分にカバーできるとは限らないからです。テストを設計する際は、以下を意識するとよいでしょう！

ホワイトボックステストとブラックボックステストの併用
コード内部と外部仕様の両面から確認する姿勢が欠かせません。
境界値分析や探索的テストの追加
一見通るように見えても境界値付近や想定外のシナリオで動作確認を行うと、不具合の発見につながりやすくなります。
業務ロジックの理解を深める
ソフトウェアが本当に解決しようとしている課題や要件をよく理解し、テストに反映させることが大切です。

ホワイトボックステストの知識を身につけたなら、次はテストの自動化ツールや継続的インテグレーション（CI）との連携にも挑戦してみてください。テストカバレッジレポートを自動生成し、チームで数値を見ながら議論できる環境を整えると学習効率が高まります。学びを深めながら、より品質の高いシステムを目指していきましょう！

セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク

投稿者プロフィール

山崎講師代表取締役

セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。