はじめに
皆さんは、ブラックボックテストとホワイトボックステストについて
知っていますか?
自分は前職に就いている間は、特に意識しておりませんでした。
レビューを頂いた際に、「自分が書いているのが、ブラックボックステストを書いているのかホワイトボックステストを書いているのかを考慮した方が良い」というアドバイスを受けて恥ずかしながら初めて知りました😢
今回は教えて頂いたことと、調べたことを自分の備忘録的意味もかねてまとめさせていただきます。
ブラックボックステスト
初めて名前を聞いたとき、テストのアンチパターンの一つか!? と思いましたが、そういうことではありません。
テスト対象の「仕様」に基づいたテストケースの作成技法を 「ブラックボックステスト」 と呼びます。
簡単にいうと、利用者側の目線に立ったテストのことを指します。
テスト対象のことを「中の見えない箱」と例えて、ブラックボックステスト と命名されています。
利用者からしたら、システムの内部構造は分からないですよね? そういうことです!
メリットとして、内部構造が分からない第三者でもテストしやすいといった利点がありますが、
デメリットとして、仕様が間違っていたり、抜け漏れや矛盾が含まれると適切なテストが行えないといった点があります。
ホワイトボックステスト
テスト対象の「内部構造」に着目してテストケースを作成する手法が 「ホワイトボックステスト」 と呼びます。
簡単にいうと、実装者側の目線に立ったテストのことを指します。
単体テストであれば、メソッドの実装、条件分岐等を意識してテストケースを作成していくイメージです。
テスト対象のことを「中身が分かる箱」と例えて、ホワイトボックステスト と命名されています。
そして、ホワイトボックスのテストケースはどれくらい処理経路を網羅しているかを評価することが重要になります。
処理経路の網羅度合いをカバレッジといい、目標するカバレッジを満たすようなテストケースを設計していきます。
上記によって潜在的な不具合を見つけやすくなります。
最後に
いかがでしたでしょうか。
ブラックボックステストとホワイトボックステストどちらかが優れているわけではありません。
プロジェクトの性質や目的に応じて適切なテストアプローチを選択することが重要になります。
(単体テストはホワイトボックステストで統合テストはブラックボックステストで対応するなど)
今回の記事が多くの方に参考になったら幸いです。
参考文献