開発の初めから順番に書いていってみる その７６：単体テスト（１）単体テスト項目

　シリーズ「開発の初めから順番に書いていってみる」の続きです。

　設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
　前回までで、プログラミングがおわりました
　（バックナンバーは、ここ　http://www.geocities.jp/xmldtp/index_kaihatsu.htm）。

　今、テストについてやっています。前回までで、テストの概要の話をして、今回から、各テストについてです。今日は、単体テストについてです。

---

■単体テストの概要

単体テストで必要なものと成果物（入出力、事前条件と事後条件？）は、

必要なもの：プログラム、ソースコードまたは詳細設計書
成果物：単体テスト仕様書・結果報告書、エビデンス

となります。

で、その手順は

１．単体テスト仕様書の作成

２．テスト環境の作成

３．ドライバ、スタブ、テストデータの作成

４．実際にテストする

５．テストOKなら、いいんだけど、
　　NGだったら、バグ修正して再テスト

というかんじになります。

---

■仕様書でとりあげるテスト内容

　で、仕様書で取り上げるテスト項目についてですが、
　ホワイトボックステストと、ブラックボックステストが考えられます。

　ホワイトボックステストは、ソースをみて（まあ、詳細設計書でも、
　細かく書いてあればありなんだろうけど）、以下の基準で、項目を挙げます。

・命令を全部通るようにテスト項目をあげる（命令網羅C0)
　すべての命令を通過（もちろん、一回にじゃなくって、何回かに分けて
　やった結果、すべての命令を通過すればOK)するように、テスト項目を挙げる

・条件分岐文の、分岐をすべて通るようにテストする（分岐網羅C1)
　IF文の真と偽、switch(VBな人はselect case)文の全ケースを１度はとおる
　ようにテスト項目を挙げる

・条件分岐文の、分岐をすべて通るようにテストする（条件網羅C2)
　条件の組み合わせ全部を通るようにする。

ここ　http://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/zu2.html?ST=system

で取り上げられている例の場合、

１．命令が２つあるので、命令網羅の場合、命令１と命令２が通ればテストOK

２．分岐の場合、分岐１、分岐２、分岐３、分岐４が通ればOK
　　なので、その例では、
　　　　分岐１と分岐３、
　　　　分岐２と分岐４
　　っていう組み合わせで、２とおりとしているけど、

　　もちろん
　　　　分岐１と分岐４
　　　　分岐２と分岐３
　　っていう組み合わせでも（そういうテストデータが作成可能なら）OK

３．分岐の組み合わせ全部。
　　なので、
　　　　分岐１と分岐３、
　　　　分岐２と分岐４
　　　　分岐１と分岐４
　　　　分岐２と分岐３
　　の全組み合わせ（４とおり）をやらないとだめ

というかんじ。

で、ここで困るのが、例外処理なのですが、そのやり方は、またべつの機会でかきます。結局条件網羅しないとバグはでるんだよねえ。。

---

■ブラックボックスによるテスト項目

　そのほかにブラックボックスによるテスト項目の挙げ方があります。

　これは、あるメソッドに対して、引数やデータベースなどの入力値をさまざまに変えて、出力結果から、妥当なものかどうか調べることになります。

　このとき、入力値を、おなじ動作をする値の組（同値）にわけます。
　そして、それごとに入力するのですが、同値の境目となる境界値でもしらべるのが、ふつうです。

　たとえば、
　boolean nenrei_check(int nen);
　とあったとき、nenが
　　　19ならFalse,
　　　20以上ならTrue
　がかえってくるとき、19以下と20以上が同値となるのですが、
　境界値の２０前後の、19,20,21の３パターンを調べるなんていうものです。

---

さて、これらで、テスト項目が挙がったら、次は、テスト環境の作成なわけです。