Excelなんかで、試験仕様書（テスト仕様書）を書くことって、多いと思います。
で、Junitを使う人も多いと思います。
でも、やっぱ、この業界、流派ごとの争いがおおいんでしょーかねー、
このExcelなんかで書く、試験仕様書（テスト仕様書）が、Junitで、どうやって、落とし込むのかっていうことについて、書いてくれてないケースって、多くありませんかねー。
ウィリアムのいたずらの関係したプロジェクトだけが、不運にも、そうなのか？
（たしかに、「不幸学鑑定」をやったら、けっこう不幸な人です。で、その不幸の度合いは、ドラゴンボールで言うところのヤムチャ級と出た）。
っていうことで、今日は、その関係について、独断と偏見で書いてみたいと思います。
（つーことで、これと違う意見を言う人も、たぶん、いっぱいいると思う。
１つの考え方としてみてね）
■■ そもそも、試験仕様書に書く項目を考える
テスト仕様書（＝試験仕様書、以下同じ）に書く項目は、こんなかんじだと思います
・テストの表題部分（テストするシステム名などなど）
・テストの番号、分類（大分類・中分類・小分類などと、正常系か異常系かなど）
・テスト内容
ここが、２つないし、３つにわかれる場合もある
３つの場合は、テストの内容、テストを行う（前提）条件、予想される結果
２つの場合は、どれかをまとめる
１つの場合は、３つまとめて
あと、これは試験仕様書の範囲でなく、テスト結果の報告書の範囲になるんだけど
・エビデンスに関して（確認方法やどのエビデンスかをしめす）
・検査した人と検査日
・検査結果
もちろん、プロジェクトによっては、これ以上にいろんなことを書くテスト仕様書もあるし、書かないテスト仕様書もある。呼び方に関してはさまざま。（テスト内容じゃなくって、テスト項目とか、試験方法とか、いろいろ）
■■ Junitなんかのユニットテストの考え方について、考えてみる
次に、Junitなどの、ユニットテストでの考え方について、考える。
この基本は、契約による設計(DbC)だと思います。
で、契約による設計の場合
・事前条件
そのテストするユニット（メソッド）が実行するとき（直前）に満たすべき条件
メソッドの引数の値など
・事後条件
そのテストするユニット（メソッド）が実行すたとき（直後）にみたすべき条件
メソッドの返り値など
・不変条件
メソッドの引数、返り値などについては、上記で調べたが、実際には、メソッドに
影響を与える可能性のあるものというのは、他に、そのメソッドが属するクラス内
のメンバ変数（意味通じない人へ、そういう変数があるのだよ）などもある。
ってことで、
メソッドが属するクラスのオブジェクトが満たすべき条件
っていうのも、テストする必要がある。
（たとえば、ＤＢ使ってるとき、クラスの変数にコネクションがあったら、
メソッド実行時に、コネクションが接続されていて、正常終了の場合は、コネクションが
つながってることなど）
この、上記の条件のこと
で、これらの条件とJUNITの関係は、Junitの本やサイトに書かれている。
みたことない！っていうひとは、
こちらをどうぞ http://www.javaroad.jp/java_exception4.htm
ということは、上記の関係と、仕様書の関係を示せばいいよね
■■ 仕様書（内容３部構成）と、契約による設計の関係
で、ここで、内容についてなのですが、
・テスト内容
ここが、２つないし、３つにわかれる場合もある
３つの場合は、テストの内容、テストを行う（前提）条件、予想される結果
２つの場合は、どれかをまとめる
１つの場合は、３つまとめて
とありますが、まず、
３つの場合は、テストの内容、テストを行う（前提）条件、予想される結果
のケースについて、書きます。であとは、３つの場合と、２つ、１つの場合のまとめ方を書けばいい。
ここで、３つに分けた場合、
事後条件が、「予想される結果」であることは、想像つくし、ふつう、そうやってかく。
で、のこりについては、
不変条件（のうち、事前に満たしておくこと）を、テストを行う（前提）条件に、
事前条件を「テストの内容」（テスト項目）
として、わけてしまうと、あとでテストしやすいと思う。
で、そうすると、不変条件（のうち、事後にも満たしているはずのこと）が抜けてしまうけど、それは、「予想される結果」に、事後条件と一緒に書いておく。
ごめんなさい。このあと、すごーくながいんで、ここで、話をいったんきりますね。
つづきは、またこんど
アクセス
トータル
ランキング
