システム開発におけるテストは、システムの品質を担保するためにも重要な工程です。
テスト手法には様々な種類があり、その中の一つにホワイトボックステストという手法が存在します。
今回は、ホワイトボックステストについての説明とその中で使われる技法、また対照的な手法であるブラックボックステストとの違いについても触れていきます。
ホワイトボックステストとは？
ホワイトボックステストとは、テスト対象のソフトウェアの処理の流れやロジックが正しいかどうかを検証するテスト手法です。
処理の中身を検証するため、ソフトウェアの内部構造を理解した上で使われる手法になります。
その性質上、プログラムの構造を熟知した者が行う必要があるため、開発者がホワイトボックステストを担当することが一般的です。
ホワイトボックステストは主に、モジュールそれぞれを対象とした単体テストで用いられることが多いです。
テストケースについては、プログラム内部の仕様について記載している詳細設計書をベースに作成されます。
ブラックボックステストとの違いは？
ブラックボックステストは、ホワイトボックステストとは対照的で、ソフトウェアの内部構造を考慮せずに実施するテスト手法です。
処理の流れやロジック、ソースコードがどのように構築されているかは考慮しない状態で、入力値とそれに伴う出力結果のみを確認します。
例えば、ある値を入力するとそれに応じてデータベース内を検索して結果を出力する処理をテストする場合は、検索処理のロジックの中身については考慮せず、入力値とそれに対応する正しい出力結果が返ってきたかどうかだけを確認します。
ブラックボックステストは、その性質上、内部のプログラムに対する知識は必要ないため、開発者以外の第三者でも実行出来るテストです。単体テストを終えたモジュール同士を結合させた結合テストの段階で用いられることが多いです、
ブラックボックステストについては、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
ホワイトボックステストで使用される技法
ホワイトボックステストでは網羅性の高いテストケースを効率よく作成するために、「制御フローテスト」と「データフローテスト」という2つの技法が主に用いられます。
それぞれの技法について詳しくご紹介します。
制御フローテスト
制御フローとは、プログラムの動作を処理に沿って簡単にまとめた以下のような図です。
制御フローテストとは、この制御フローの流れに沿って処理が正しく動作するかを確認するテストのことを指します。
プログラムの規模次第では制御フローも膨大な量となり、全ての制御フローをテストするには膨大な時間を要する可能性があります。
そのため、制御フローテストには網羅する基準(カバレッジ基準)がいくつか設けられており、その基準に沿ってさらに以下の様な技法に分けられます。
命令網羅
命令網羅(ステートメントカバレッジ)は、プログラム全体の処理を少なくとも1回ずつは実行する技法です。
カバレッジ基準の中では最も少ないテストケースでテストを実施することが出来ますが、テストが出来ずに見逃される処理も多くあるため、十分なレベルのテストとは言えません。
分岐網羅
分岐網羅(ブランチカバレッジ)は、プログラム内の全ての分岐処理を少なくとも1回ずつは実行する技法です。
命令網羅とは違い、各分岐処理のtrueとfalseをそれぞれ1回ずつ検証していきます。分岐処理の結果を真偽両方とも検証出来るため、命令網羅と比べるとテストの精度は高いと言えます。
しかし、ANDやORの複合条件の組み合わせについては考慮されていないため、全ての条件の組み合わせを検証出来ているとはまだ言えません。
条件分岐
条件分岐(ディシジョンカバレッジ)は、プログラム内の全ての分岐処理において判定条件が複数ある場合に、それぞれの条件が真・偽の場合を組み合わせて検証する技法です。(判定条件網羅とも言われます)
ANDやOR条件等、分岐の判定に影響を与える条件は全て網羅したテストケースを作成します。命令網羅や分岐網羅と比べてテストケースの数は多くなりますが網羅性は高く、テストの精度も高いです。
その分、作業工数も大幅に掛かってしまうため、スケジュールに余裕を持たせて取り組むことが重要です。
データフローテスト
データがどこに渡されたのか等、データの変化の流れをデータフローと言います。
データの状態である定義・使用・消滅の3つの変化を確認するテストがデータフローテストです。
例えば、プログラム内のある変数が、使用される前に消滅していたり、定義をしているはずなのに正しく使用されていない場合等は不具合と見做します。
データの流れを追っていき、仕様通りの動きをしているかを確認していきます。
ホワイトボックステストでは検出できないバグ・不具合はある？
ホワイトボックステストはテストの網羅性も高く、バグ・不具合も効率よく検出することは出来ますが、中には検出出来ないバグ・不具合もいくつかあります。
仕様によって発生する不具合
設計した仕様に対しての不具合や、ユーザーが求めている仕様の認識と齟齬があった場合等の問題は解決出来ません。
これはテスト全般に言えることですが、テスト作業は完成したプログラムが仕様通りとなっているかを確認することしか出来ないため、上流工程で生じる不具合を検出することは出来ません。
場合によっては、設計を根本的にやり直す必要もあります。
後戻りを引き起こさないためにも、要件定義は綿密に行う必要があります。
設計書の抜け漏れによって発生する不具合
ホワイトボックステストはプログラムの詳細について記載する詳細設計書をもとに作られるため、設計書に抜け漏れがあった場合は、その箇所をテストすることが出来ません。
重大な箇所が抜けている場合は、コーディングの段階で気づいてその段階で設計書を修正出来ますが、細かい処理で抜け漏れがあった場合はコーディング時に見落としてしまい、テスト自体を実施出来ません。
データによって発生する不具合
データによって発生する不具合についても、解決は出来ません。
例えば、データベース内の特定のデータを取り出す処理を検証する場合、データベースに登録したデータに誤りがあった場合は処理が正しく動きませんが、プログラム側の不具合ではないため、検出することは出来ません。
テストする際は、プログラムだけでなく、データベース等、周囲の状況にも注意する必要があります。
データによって発生する不具合は、入出力結果のみを確認するブラックボックステストで発見することが出来ます。
プログラムを複数組み合わせた場合に発生する不具合
基本的に、ホワイトボックステストは単体テスト時に使用される技法です。
そのため、複数のプログラムを組み合わせて処理の流れを確認する結合テスト時に、単体テスト時には起こらなかった予期しない不具合が起こる可能性があります。
単体テスト時の検出漏れであったのか、複数プログラムを組み合わせたことによって発生した不具合なのか判別をつけるのが難しいため、ホワイトボックステストで検出出来るとは言えません。
【まとめ】ホワイトボックステストの基本理解を
ホワイトボックステストは正しく行えば、網羅性が高く不具合の発見率も上がるため、システムの品質を担保するのに効率的な手法と言えます。
複数のカバレッジ基準があるため、内部構造を理解した者でなければ難しいテスト手法ではありますが、基本を理解して、制御フローテストとデータフローテストの技法を身につければ精度の高いテストが可能です。
ホワイトボックステストでの検証が難しい箇所については、ブラックボックステスト等、他の手法を用いて臨機応変に対応していきましょう。
