LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託

要件定義書やテスト計画書を読んでいると、「ホワイトボックステストで網羅率を確認します」「ブラックボックステストで仕様どおりの動作を確認します」といった記載を目にすることがあります。どちらも「テスト」という言葉が付いていますが、実際には何を根拠に、何を確認する手法なのかという視点がまったく異なるものです。この違いを曖昧にしたまま進めてしまうと、コードの内部はくまなく確認できていても仕様どおりに動作していない、逆に仕様は満たしていても内部に未確認の処理経路が残ったまま、といったすれ違いが起こりやすくなります。

本記事では、ソフトウェアテストの二つの代表的な視点であるホワイトボックステスト（内部構造・コードを見て網羅性を検証する手法）とブラックボックステスト（仕様に基づき入出力の関係で検証する手法）について、意味と代表的な技法、開発工程における位置づけの違いを整理します。特定の自動化ツールや実装手順には深入りせず、発注担当者・PM・品質担当が押さえておきたい「二つの視点の使い分け」に焦点を当てて解説します。

ソフトウェアテストの二つの視点

ソフトウェアのテストには、大きく分けて「何を根拠に検証するか」という観点で二つの視点があります。一方はプログラムの内部構造やソースコードそのものを根拠にする視点、もう一方は外部から見える仕様や振る舞いを根拠にする視点です。

内部構造を見る視点と、仕様を見る視点

ホワイトボックステストは、プログラムの内部――条件分岐やループ、処理の経路――がどの程度実行され確認されたかに着目します。テストを設計する担当者はソースコードを読み、どの命令や分岐を通過させるかを考えながらテストケースを組み立てるものです。一方のブラックボックステストは、内部の作りには立ち入らず、仕様書に定められた入力と出力の対応関係だけを根拠にテストケースを設計する手法です。プログラムを「中身の見えない箱」として扱い、入力を与えたときに期待どおりの出力が返るかどうかを確認します。

なぜ二つの視点が必要になるのか

どちらか一方だけでは、確認できる範囲に偏りが生じやすくなります。内部構造だけを丹念に確認しても、そもそも仕様の解釈が誤っていれば見つけられない不具合が残るでしょう。逆に仕様どおりの動作だけを確認しても、実装した本人しか気づいていない未実行の処理経路が見過ごされることがあります。二つの視点を組み合わせることで、品質を確認する網の目を互いに補い合う関係になるものです。

ホワイトボックステストとは（代表技法）

ホワイトボックステストは、ソースコードの構造そのものを根拠に、どの程度の範囲を実行して確認できたかを測るテスト手法です。「構造テスト」「ロジックテスト」と呼ばれることもあります。

代表的な技法（1）命令網羅

命令網羅（ステートメントカバレッジ）は、プログラム中のすべての命令行が少なくとも一度は実行されることを目指す技法です。もっとも基本的な網羅基準であり、テスト設計の出発点として扱われることが多いといえます。ただし、条件分岐の片方しか通っていなくても命令網羅の基準自体は満たせてしまう場合がある点には注意が必要でしょう。

代表的な技法（2）分岐網羅

分岐網羅（ブランチカバレッジ、判定条件網羅）は、if文やswitch文などの分岐について、真と偽の両方の経路が少なくとも一度は実行されることを目指す技法です。命令網羅よりも確認する範囲が広く、分岐の片側だけが実行されて反対側が見過ごされる状況を防ぎやすくなります。

代表的な技法（3）条件網羅と経路網羅

条件網羅は、分岐を構成する個々の条件式（AND・ORで結ばれた各要素）それぞれについて真偽の両方を確認する、より細かい技法です。さらに複数条件の組み合わせすべてを確認する経路網羅（パスカバレッジ）まで踏み込むと確認できる範囲は広がりますが、組み合わせ数が急増し現実的な工数に収まらなくなることもあります。実務では、対象の重要度やリスクに応じて、どの網羅基準まで確認するかを見極める判断が求められるでしょう。

ブラックボックステストとは（代表技法）

ブラックボックステストは、内部の実装には立ち入らず、仕様書や要件定義書に記された入力と出力の関係を根拠にテストケースを設計する手法です。「仕様ベーステスト」と呼ばれることもあります。

代表的な技法（1）同値分割

同値分割は、入力値を「同じ結果が期待できるグループ」に分け、各グループから代表値を選んでテストする技法です。例えば年齢を入力する項目であれば、「0歳未満（無効）」「0〜17歳（未成年）」「18歳以上（成人）」といったグループに分け、それぞれから1件ずつ確認すれば、すべての値を試さなくても効率よく検証できるという考え方になります。

代表的な技法（2）境界値分析

境界値分析は、同値分割で区切ったグループの境目（例えば17歳と18歳の境目）に不具合が潜みやすいという経験則に基づき、境界の値とその前後を重点的に確認する技法です。「以上」と「より大きい」の取り違えといった条件式のわずかな誤りは境界付近で表面化しやすく、比較的少ない件数で発見効率を高めやすい技法として知られています。

代表的な技法（3）デシジョンテーブルとその他の技法

デシジョンテーブル（決定表）は、複数の条件の組み合わせと、それぞれに対応する動作を表形式に整理し、条件の組み合わせに漏れがないかを確認する技法です。会員種別や在庫状況など、複数の要因が絡み合って動作が変わる仕様の確認に向いています。このほか、画面の遷移パターンを確認する状態遷移テストなど、仕様の性質に応じて使い分けられる技法がいくつか存在します。

両者の違い：対比表と図

ホワイトボックステストとブラックボックステストは、しばしば対になる概念として語られますが、着目している対象がそもそも異なります。主な観点を次の表に整理します。

対比表からも分かるとおり、ホワイトボックステストは「箱を開けて中身を見る」視点、ブラックボックステストは「箱を閉じたまま入出力だけを見る」視点だといえます。次の図は、この違いをイメージにしたものです。

開発工程での位置づけ

ホワイトボックステストとブラックボックステストは、どちらか一方だけを使う手法というより、開発工程の段階に応じて重みづけが変わる傾向があります。

単体テストは白箱寄り

関数やクラスといった小さな単位を対象にする単体テスト（ユニットテスト）では、実装したコードそのものを見ながら分岐や条件を網羅するホワイトボックステストが中心になりやすいといえます。開発者自身がコードを読める立場にあり、内部の処理経路を意識してテストケースを組み立てやすい段階だからです。

結合テスト・システムテストは黒箱寄り

複数のモジュールを連携させる結合テストや、システム全体の振る舞いを確認するシステムテストでは、内部の実装よりも「仕様どおりに動くか」という観点が重視され、ブラックボックステストの比重が高まりやすくなります。画面やAPIを通じて外部から入力を与え、期待どおりの出力や画面表示が得られるかを確認する形が中心になるものです。

受入テストは仕様準拠の確認が中心

発注者側が最終的に確認する受入テストは、内部構造には立ち入らず、要件定義書や仕様書に定めた内容が満たされているかを確認する、典型的なブラックボックステストの場面です。発注担当者にとっては、この段階でどのような観点から確認するかを事前に整理しておくことが、後工程での認識のずれを防ぐことにつながります。

両者を組み合わせる考え方

ホワイトボックステストとブラックボックステストは、優劣を比べる関係ではなく、見落としの傾向が異なる二つの視点として組み合わせて使うものと捉えるとよいでしょう。

片方だけでは見えない不具合がある

ホワイトボックステストだけを重ねても、仕様そのものの解釈が誤っていれば、その誤りには気づけません。逆にブラックボックステストだけを重ねても、仕様書には表れない例外的な処理経路や、エラー処理の抜け漏れは見過ごされることがあります。二つの視点を組み合わせることで、それぞれの弱点を補い合う形になるものです。

リスクに応じた配分の考え方

すべての機能に同じ密度でテストを行うことは、限られた工数の中では現実的ではありません。金額計算や権限判定など、誤りが業務影響につながりやすい機能には分岐網羅や境界値分析まで含めて手厚く確認し、影響が小さい機能では基本的な同値分割による確認にとどめるといった、リスクに応じたテスト配分の考え方が実務では採られています。

発注・受入テストでの確認点

システム開発を発注する際は、次のような観点を確認しておくと、テストの範囲や品質に関する認識のずれを防ぎやすくなります。

• 単体テストの段階で、どの程度の網羅基準（命令網羅・分岐網羅など）を目標としているか
• 結合テスト・システムテストで、どのような同値分割・境界値分析の観点が設計されているか
• 受入テストの項目が、要件定義書・仕様書の記載と対応づけて整理されているか
• テスト結果（消化件数・不具合件数・網羅率など）がどのような形式で報告されるか
• カバレッジの数値だけでなく、テストケースの内容そのものを確認できる体制になっているか

要件定義段階で確認観点を分けて整理する

「テストを実施します」とひとまとめに記載してしまうと、内部構造の網羅を指しているのか、仕様どおりの動作確認を指しているのかが曖昧になりがちです。要件定義やテスト計画の段階で、工程ごとにどちらの視点を主眼に置くのかを分けて整理しておくことが、後工程での手戻りを減らすことにつながるでしょう。

まとめ：二つの視点を分けて捉える

本記事では、ホワイトボックステスト（内部構造・コードを見て網羅性を検証する視点）とブラックボックステスト（仕様に基づき入出力の関係で検証する視点）という、ソフトウェアテストの二つの代表的な視点の違いを整理しました。単体テストは白箱寄り、結合・システムテストは黒箱寄りになりやすい傾向がありますが、どちらか一方だけで品質を確認しきれるものではありません。

見落としの傾向が異なる二つの視点を組み合わせ、リスクの大きさに応じてテストの密度を配分していくことが、無理のない品質確保につながります。要件定義や発注の段階から、二つの視点を分けて確認しておきたいポイントです。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（情報処理推進機構）基本情報技術者試験シラバスにおけるテスト技法（ホワイトボックステスト・ブラックボックステスト）に関する解説（https://www.ipa.go.jp/shiken/syllabus/index.html）

Tweet