ホワイトボックステストとは。種類やブラックボックステストとの違い

ソフトウェアの内部構造をブラックボックスと見立てて、ソフトウェア（つまりプログラム）に実装されるコードの動きを意識することなく、設計仕様に基づいてソフトウェアが動作するかを確認するテストが、ブラックボックステストです。

では、ブラックボックスに対して、ホワイトボックステストは何を確認するためのテストでしょうか？

ホワイトボックステストの目的

ISTQBの用語集によると、ホワイトボックステストは以下のように定義されています。

コンポーネントまたはシステムの内部構造の分析に基づいたテスト

コンポーネント（Component）を訳すと、構成要素や部品となりますが、ソフトウェアであるならば、最小の構成単位となる、1つのプログラムやモジュールなどを指します。（ただし、プログラミング言語によって関数やクラスなど、その対象や粒度は異なります）

テストレベルとしては、主にコンポーネントテスト（単体テストやユニットテストとも呼ばれます）やコンポーネント統合テストでホワイトボックステストが用いられます。

では、何のために内部構造に基づいたテストを行うのか考えてみましょう。

筆者の理解でホワイトボックステストの目的を簡単に言うならば「どのようなパターンでテスト対象となるコンポーネントまたはシステムを動作させたかを証明すること」です。

ただし、どのようなパターンでというのが案外やっかいなのです。

それは、アルゴリズムによってパターンがいくらでも増えるからです。

ホワイトボックステストの観点

下の図表1を見てください。

一見、そんなに難しい処理には見えません。たった1つの繰り返しと、１つの繰り返し中に3つの分岐をたどるだけというシンプルな処理です。しかし、考えられる全ての処理フローを通すテストを実施するとなると、天文学的な時間が必要となります。20回繰り返すこのプログラムの全パターンのテストを実施するとなると、次のループに引き継がれるパスが5つあるため、その組み合わせは次のような計算で求められます。

5²⁰＋5¹⁹＋5¹⁸＋……＋5=10¹⁴

つまり、100兆通りもあります。もし1つのテストケースの設計、実装、実行に5分かかるとすると、10億年必要となり、とても現実的だとは言えません。たとえテストを自動化して、1テストケース当たり1ミリ秒に短縮できたとしても、3170年かかってしまいます。

ですから、テストの観点という意味では、「内部構造の分析に基づいてテストを行うこと」であったとしても、全ての処理フローをテストしきることが簡単ではないケースがほとんどであるといわれているのです。このため、全て実施できないのであればホワイトボックステストを頑張って実施しても意味がないと思われるかもしれません。そのことについては、メリット・デメリットとして後述します。

ISTQBのFoundation Levelのシラバスでは、ホワイトボックステストの技法（種類）として、ステートメントテストとブランチテストの2つが取り上げられています。

ステートメントテスト

ステートメントテストは命令網羅やC0（シーゼロ）と呼ばれ、コード内の全てのステートメントを少なくとも1回は実行します。

ブランチテスト

ブランチテストは分岐網羅やC1（シーワン）と呼ばれ、コード内の全てのブランチを少なくとも1回は実行します。

ステートメントテスト（C0）とブランチテスト（C1）の違いを簡単に絵に表すと図表2のようになります。

別名に「網羅」と付いているように、コードに対してどれくらいの粒度（命令か条件かなど）に対する処理フローにおいて「どの程度テストを実施したか」というテストの網羅度を表します。カバレッジとも呼ばれますが、ホワイトボックステストでどれくらいの網を掛けるか（網羅性を確保するか）を表すための尺度とも言えます。

このため、網羅率はパーセント(％)で表します。図表2でC1を尺度とした場合、2通りのパスをテストすれば網羅率は100%、片方だけだと網羅率は50％となります。

なお、ISTQBのAdvanced Levelシラバス　テクニカルテストアナリストには、ここで説明した2つの技法以外に加えて、改良条件判定テスト(MC/DC)や複合条件テストの説明があります。ご興味がある方はJSTQBのサイトからシラバスをダウンロードして確認してみてください。

ホワイトボックステストを実施することのメリットとデメリットを整理します。

メリット

ホワイトボックステストを実施することで、定量的に「どれだけテストを実行したか」を証明できることがメリットとなります。

人間への安全性が求められるソフトウェアに対するテストの網羅度等の規定がある国際標準(IEC61508やISO26262など)では、コンポーネントテストや統合テストの網羅性を証明するために、カバレッジの記録を残すことが求められます。その場合は「メリット」ではなく規格からの「要求事項」であるため、必ずカバレッジを測らなければなりません。

一方、カバレッジを測ることで、どれくらいテストパターンに抜け・漏れが有るのか／無いのかが分かるため、実装した開発者自身がコンポーネントテストを行う上での重要な指標として活用されています。

デメリット

ホワイトボックステストで証明できることには限界があります。開発者の中には、コードカバレッジ（C0やC1の区別なく、こう言われることも多い）を取った上でコンポーネントテストをしておけば十分だと思われている方がいるかもしれません。

ただ、こう考えてブラックボックステストをおざなりにすると、それはデメリットにつながります。それは、カバレッジを測ることにより証明できることと、できないことが下図（図表3）のように分かれるからです。

それぞれの観点からの違いを説明します。

処理フローに対するパス・カバレッジの確保を主眼に置く場合、つまりコードを実装する立場や、システムとしてコンポーネント統合する視点でのテストはホワイトボックステストが担います。

ブラックボックステストでは、内部構造など問わず、第三者やユーザーの視点でテストします。

グレーボックステストは、両者の視点ではカバーしきれないシステム全体としての整合性や、機能／非機能要件の十分性の確認や評価する場合に用いることがあります。

関連記事：ブラックボックステストとは？種類やホワイトボックステストとの違いを解説

ホワイトボックステストでは、テスト設計・実装とテスト実行でテストツールを使用できます。

C0やC1といったカバレッジを網羅するためのテストケースやテストデータを、人間が作ることはできます。ただ、そういったことは「単なる作業」であり、人が実施するには生産性が低く、かつ「つまらない」作業だったりします。C0やC1（もしくはそれ以上のカバレッジ基準）を100%満たすためのテストの入力データを自動生成してくれるツールが存在します。オープンソース、商用ツールそれぞれにプログラミン言語への対応や網羅できるカバレッジは異なりますが、基本的にはソースコードを静的解析して、入力データを自動生成してくれます。

テスト実行では、テストツールがあらかじめコンパイル時にフックコードという計測用のコードをオブジェクトファイルに埋め込んだり、アセンブラレベルでのプログラミングの動作をトレースしたりすることにより、コードカバレッジを計測します。ツールによっては、コードのどの部分がカバレッジを満たしているか／いないか、テストケースごとにどのコードのカバレッジを満たしているかなどを可視化するものもあります。

注意点としては、ツールはあくまでテストケースの入力データを自動生成しますが、期待値となるテストで確認すべき出力値までは生成しないものがほとんどです。これは、論理的には自動生成できたとしても、仕様通りの期待値であるかどうかは、仕様ベースであるブラックボックステストで確認すべきことだからです。

具体的なホワイトボックステストで利用できるツールについては、参考資料に記載した「テストツールまるわかりガイド（ツール部）」にいくつか紹介があります。

本記事では、ホワイトボックステストの目的や、どのような観点で実施するテストであるかといったことを説明しました。

アジャイル開発におけるTDD(テスト駆動開発)でユニットテストを行うならば、コードを実装する流れでカバレッジを満たすテストケースを作成することになるでしょう。継続的インテグレーション環境として、CD／CTを実現するならば、おのずとホワイトボックステストも自動化することになります。

繰り返しになりますが、ホワイトボックステストは手動ではなく自動化することで、カバレッジを満たしつつも効率的なテストの実現を目指すようにしましょう。

■参考資料■ 

（※1）「ステップアップのためのソフトウエアテスト実践ガイド[改訂版]」大西建児著より引用 
「ソフトウェア・テストの技法」Glenford J.Myers 著、松尾正信 訳 
「ISTQBテスト技術者資格制度　Foundation LevelシラバスVersion 2023V4.0.J02」JSTQB編 
「ISTQBテスト技術者資格制度　Advanced Levelシラバス日本語版　テクニカルテストアナリスト　v4.0.J01」JSTQB編
テストツールまるわかりガイド(ガイド部)　Version 2.0.0　NPO法人ソフトウェアテスト技術振興協会