ホワイトボックステストとは、プログラムの中身と内部構造に注目する試験です。
ブラックボックステストのように「テストデータを入力して、どんな出力結果になるか？」も大切ではあるけど、結果ができる過程・流れに注目。
プログラムの中身の細かいところまでしっかりと確認します。
「Aの場合は処理Bを実行する」といった、詳細設計書(プログラム設計書)に書かれている処理分岐を網羅することが肝心。
「処理分岐をどう網羅するか？」によって、必要なテストケースも変化。
ホワイトボックステストのテストパターンを網羅する方法まで理解できてれば、よきです。全部で考え方は4つあります。
ホワイトボックステストとは、プログラムの中身と内部構造に注目する試験
ホワイトボックステストとは？プログラムの中身と内部構造に注目する試験です。
例えば、「(1+3)×(2+3)×(1+4)=100を計算してくれるマシーンがあったとして。
計算結果は、100なのだけれども、「本当に100なの？」となったときに、途中式を確認。
(1+3)×(2+3)×(1+4)=4×5×5=20×5=100
ここまでていねいに書けば、「うんうん。ちゃんと計算されて100になったね」とわかります。
反対に、100という正しい結果が得られたとしても、途中式が
(1+3)×(2+3)×(1+4)=2×5×10=10×10=100
のようになってたら、きっとその計算マシーンはおかしいです。
「足し算だけじゃなくて、ひき算・かけ算・わり算や小数点や四捨五入、かっこのありなしも含めてテストするべきだ」みたいな感じで、プログラムの中身と内部構造に注目してテストするのが、ホワイトボックステストです。
ホワイトボックステストで求められる条件網羅と作るべきテストデータ
ホワイトボックステストで求められる条件網羅(いいかえると、テスト方法)は、下記のとおりです。
命令網羅
命令網羅は、特定の命令が実行されればOKとする考え方。
例えば、「CSV出力」ってボタンがあって押したら、CSV(「”ひよこSE”,”男”,”27歳”」のように、カンマで区切ったテキストファイルで、エクセルで開けるやつ)が出力される機能を作ったとします。
※これからの例は、計算マシーンの例だと苦しいので、別の例にします 笑
特に条件なしで、常に実行される命令(この例だと、無条件でCSVを出力する場合)に使われます。
判定条件網羅（分岐網羅）
判定条件網羅（分岐網羅）は、プログラムのすべての命令の分岐を1回は通す考え方です。
例えば、「CSV出力」ボタンがあって、ボタンを押したはいいけど、CSVにするデータがない場合。
「データがない場合は、CSVをそもそも作らない」／「データがあれば、CSVを作る」みたいに、命令が実行される／されないを網羅、つまりは判定条件を網羅するときに使われます。
条件網羅
条件網羅は、命令が実行される分岐のもとになる条件を網羅する考え方です。
「んん？」となっていると思いますが、いったん最後まで 汗。
たとえば「CSV出力ボタン」の横に、「0件でもCSVはつくる」というチェックを作ったとします。
すると、判定条件網羅にあった「データがない場合は、CSVをそもそも作らない」／「データがあれば、CSVを作る」という命令を実行するときに、さらに前提条件が追加。
- 【0件でもCSVはつくるにチェックがある場合】「CSVを作る」
- 【0件でもCSVはつくるにチェックがない場合】「データがない場合は、CSVをそもそも作らない」／「データがあれば、CSVを作る」
判定条件網羅では、CSVをつくる・つくらないという命令の分岐が網羅されていればOK。
条件網羅では、命令の分岐のもとになる条件である、「CSVが0件でない」という条件と「0件でもCSVはつくる」が、最低1回は正しく判定されるか？をテストします。
具体的に書くと、下記のようなテストができればいいです。
(CSVが0件でない,0件でもCSVはつくる)
={(真,真),(偽,偽)}
={(CSVができる),(CSVができない)}
複数条件網羅
複数条件網羅は、条件網羅のパワーアップバージョン。
「CSVが0件」／「0件でもCSVはつくる」の2つの条件が当てはまるか？の組み合わせ(真偽)は、
(CSVが0件でない,0件でもCSVはつくる)
={(真,真),(真,偽),(偽,真),(偽,偽)}
={(CSVができる),(CSVができる),(CSVができる),(CSVができない)}
の4つあります。この4つすべてをテストするのが、複数条件網羅。
ちなみに、1つ前の条件網羅についてもう一度書くと。
最低でも1回、真偽の判定が正しいか？が検証できればいいです。
(CSVが0件でない,0件でもCSVはつくる)
={(真,真),(偽,偽)}
={(CSVができる),(CSVができない)}
え？でも、条件網羅だけだと、なんだか不安。
複数条件網羅でテストするべきじゃないの？
その通りではあるのですが・・・。
複数条件網羅をやると、テストケースがかなり多く場合もあるので・・・。
おっと、ここらへんは、大人の事情ですね(*´ω｀)。
単体テストでは、ホワイトボックステストの比重が高くなる
単体テストでは、ホワイトボックステストの比重が高くなります。
判定条件網羅やら、条件網羅やら、細かいところをしっかりとみるのがホワイトボックステスト。
1つ1つのプログラムの作りが、詳細設計書通りに正しく作られていることを、単体テストで担保したうえで。
プログラム同士を合体して動かして、結合テストへと進んでいきます。
結合テストでは、ブラックボックステストがメインです。
まとめ
ホワイトボックステストきたら、プログラムの中身と内部構造に注目する試験のこと。
結果が正しいか？だけではなく、命令網羅やら判定条件網羅やら条件網羅やら複数条件網羅やらで、細かいプログラムの中身・分岐までしっかりと見てやります。
いろんなテストパターンを網羅して、テストが完了したら、プログラム単品の完成が近づく。
ホワイトボックステストは、プログラム(モジュール)単品を完成させるための作業と思ってくださいまし(-_-;)。
コメント