システム開発においてテストは非常に大事です！
ソフトの詳細設計時に分割したモジュール（プログラム）ごとに、正しく動作するかテストしますが、これを単体テストと呼びます。
この単体テストには大きく二つに手法があります。
ホワイトボックステスト
ブラックボックステスト
文字の通り「白か黒か」、「見えるか、見えないか」の違いなのですが、「利用者側」目線のテストがブラックボックステスト、「作り手側」目線のテストがホワイトボックステストという表現をしているサイトもあります。
今回はこの二つのテスト手法の違いを調べてみました！
ブラックボックステスト
先ずブラックボックステストですが、 こちらはモジュールの内部構造は意識せず、入力に対して出力が正しく出るかを検証するテストです。
つまり、入力と出力だけを着目すれば（気にすれば）良いのです。
以下にテストのパターンを表にしてみました。
| 設計方法 | 説明 |
| 同値分割 | 入力と出力をシステムとして動作が同じと見なせる値の範囲に分類（同値クラス）して、各同値クラスを代表する値に対してテストを実施します |
| 限界値分析 | 同値クラスの両端の値（境界値）をテストする方法です。エラーは分岐の境界で起こりやすいので、そこを重点的にテストします |
| 決定表 | 考慮すべき条件と、その条件に対する結果のマトリクスを作成する方法です。主に、テスト項目を作成するために利用されます |
| 原因・結果グラフ | 入力と出力の関係を表すような図や表を作成して、テストを行う方法です |
ホワイトボックステスト
一方、ホワイトボックステストは、モジュールの内部構造が正しく作られているかを検証するテストです。モジュールの内部で行われている処理が正しいかを確認するテストなので、入力と出力結果だけでは無く、内部の構造をメインに着目する必要があります。
テストにおいて、どの程度のソースコードが網羅されたかをカバレッジ（網羅率）と呼び、この分析のことをテストカバレージ分析といいます。
テストする経路（手法）によって、次のような様々な網羅方法があります。
| 設計方法 | 説明 |
| 命令網羅 | 全ての命令を最低1回は実行します |
| 判定条件網羅 | 分岐の判定において、真と偽の分岐を少なくとも1回は実行します |
| 条件網羅 | 分岐の判定分が複数ある場合に、それぞれの条件が真と偽の場合の組み合わせを網羅します |
| 複数条件網羅 | 判定分の条件が取りうる全てのパターンを網羅します |
また、ホワイトボックステストを内部構造に着目、ブラックボックステストを外部の入力、出力に着目して分けた場合、「入力 ⇒ 内部構造 ⇒ 出力」の一連の流れを着目してテストすることをグレーボックステストなんて呼び方もするようですが、ホワイトボックステストでも入力、出力に着目しますから考え方はホワイトボックステストに近いですね。
二つのテストの使い分けは？
どちらもシステム開発においては利用しますが、単体テストのような部品の確認は、ホワイトボックステストが中心のようですね。
また、結合テストのようにモジュール間を繋げて、全体の流れを確認する段階になると、ブラックボックステストが多くなるようですね。
発注ラウンジさんのサイトには以下のような例えがあります。
一方、ブラックボックステストは、外部からの確認のみで済むため、理解するのに時間はかかりません。ただし、内部についての詳細な確認はできないため、潜在的なバグを検知しきれない可能性があります。
どちらか一方では無く、両方を上手く使い分けることが大事なのですね。
以下に各テストの違いを図にしてみました。
各テストの違い
まとめ
今回はホワイトボックステストとブラックボックステストを調べてみました。
両方ともシステム開発には必要不可欠なテストで、どちらか一方に偏ったテストでは、プログラム開発に必要な最低限の確認を網羅できません。
工数や工期などを考慮して、どちらのテストをどこまでやるかを検討することが良いようですね。
勿論、やり過ぎるとそれだけ工数やスケジュールが掛かってしまいますので、その辺も踏まえてのテスト計画ですね。
以上です！
参考URL）