最近なのですが、仕事で後輩の子からテスト技法に関する事を聞かれたりする時がちょこちょこあったりします。
その際に少しでも答えられないのは良くないなーと思い、メモも兼ねてソフトウェアテストに関する事を記事に書いていく事にしました。
今回はテスト技法のホワイトボックステストとブラックボックステストの事について簡単に書いておこうと思います。
ブラックボックステストとは？
ブラックボックスは日常でもちょこちょこ出てきたりしますが、意味としては「内部の原理や構造を知らなくても、外部から見た機能や使い方を知っていれば利用する事ができるモノ」となります。
コンピュータや家電など、中でどう動いてるかは不明ですが一目見て使い方が分かるというのは世の中結構ありますよね。
転じてブラックボックステストは内部の構造を考慮せずに、想定されている機能が仕様通りに利用できるかをどうかを確認するテストとなります。
例として図書館の本の検索システムにブラックボックステストを行う場合、本の名前や作者を入力し、それに紐づく検索結果が出力されるかを確認します。
その際にこのシステムの内部で何がどの様に処理されているのかは基本的に考慮しません。
ブラックボックステストの長所ですが、ユーザーと同じようにシステムを利用する立場に立った検証を行うので、顧客やユーザーの要望に応えられているかを確認しやすいです。
また、単独で作ったシステムの機能を連携させた際に時に起こる不具合等も見つけやすく、設計者の想定漏れを補いやすいという所も挙げられます。
一方の短所ですが、内部で間違った処理が行われていても、結果が正しければ問題になる事はありません。
その為ブラックボックステストでは処理上の不具合等を見つける事が難しいです。
ブラックボックステストで用いる技法には同値分割法、境界値分析、デシジョンテーブルテスト、状態遷移テスト等があります。
ホワイトボックステストとは？
ブラックボックステストが外部から見た機能や使い方に着目したテストだったのに対し、ホワイトボックステストはシステムの内部構造に着目したテストになります。
ソースコードの命令文や判定条件が正しく動作しているかといった内部構造を網羅する様なテストケースを作成し、そのテストケースでプログラムをどのくらい実行できたかをテスト品質の指標「カバレッジ（網羅率）」として計測します。
内部構造を理解している事が必要なのでプログラミングに関する知識が不可欠であり、主にクラスや関数を確認する単体テストで使われます。それもあり開発者がプログラム作成後にテストをする事も多いです。
長所としてソースコードに紛れ込んだバグを見つけられる事ができ、開発者向けのテストなので様々な状況・設定値でテストできる事が挙げられます。
短所としては内部構造の正確さのみを確認しているので、設計書・仕様書自体がユーザーの求める仕様に合わなかったり、設計自体に漏れ抜けが存在していた場合には対応できない点が挙げられます。
実際ゲームとかでも、バグが無くてもユーザーが求めていた物・仕様ではないというのはよくありますよね。。。
ホワイトボックステストで用いる技法としては制御フローテスト、データフローテスト等があります。
おまけ：グレーボックステスト
因みにブラックボックステストとホワイトボックステストの他に、グレーボックステストというのもあったりします。
グレーボックステストは上二つの特性を合わせ持っていて、「システムの内部構造を理解している上で外部からの機能や仕様を確認するテスト」になります。
テストの観点はブラックボックステストと同じですが、システムの内部構造を理解している事がポイントです。
これにより「プログラムでこう記載しているので、こういったテストを行う事が必要」と、詳細なテストケースを作成する事ができます。
一方でシステムの内部構造を理解していないといけないので、ブラックボックステストよりも実施の難易度が高いのがデメリットです。
以上、ブラックボックステストとホワイトボックステスト（おまけでグレーボックステスト）に関する簡単な記事でした。
今後機会があれば更に細かいテスト技法に関しても書いていきたいと思います。
