ユースケースから、トレーサビリティを持った結合テストの書き方

　昨日、
画面定義→プログラム→JUnit等までのトレーサビリティを持った、単体テストの書き方
http://blog.goo.ne.jp/xmldtp/e/3f8181538e53fae2e9246cdf2f83be33
を書いたので、今日は、結合テストに行きたいと思います。

---

■単体テストと結合テストの違い

単体テストの場合は、試験単位は、モジュール単位、つまり、
　　　ＤＢアクセス部分のメソッド１つ１つとか
　　　１つの共通部品１メソッドとか
　　　１画面（１Ａｃｔｉｏｎのexecute()とか１service（）とか）
になるとおもうのですが、

結合の場合は、１画面のときもあるけど（１画面で何でもできるようにした場合）、
ふつうは、複数画面になります。

このとき、複数画面全部の組み合わせを行うと、莫大な量になるし、
　　そもそも、そんな遷移はできないということもあるので、
結局、
　　ユースケースシナリオに基づいた、考えられるケースに対してのテスト
ということになるとおもいます。

---

■結合テストの内容

ってことで、昨日と同じような構造を書くと

　各種業務
　　｜ 1
　　｜
　　｜ N
　ユースケース
　　｜ 1
　　｜
　　｜ N
　ユースケース上ポイントとなるチェック内容(試験観点）
　　｜ 1
　　｜
　　｜ N
　チェック内容に対応する具体的な試験項目（値）
　　｜ 1
　　｜
　　｜ 1
　テスト結果

となると思います。

たとえば受注業務の場合、そのお店は、
　　・コーヒーと
　　・中古パソコンと
　　・中古漫画
を販売していて、その他にまんが喫茶を経営していたとしたら
（つまり、まんが喫茶で、お店のものが古くなったら客に売りつけ、
　新しいものを仕入れているお店なんだな）

そのお店の、「中古パソコン販売」が業務で、「個人に売りつける場合」というのが、ユースケースとする。
このとき、「注文を受ける」「お金をもらう」「商品引渡し」といった、チェック内容があるが、
それだけでは、テストできないので、具体的に注文を受けるとき、どの画面にどのように値を入れるかというのをきめ、
その結果を書く。つまり、

例

　「中古パソコン販売」
　　｜ 1
　　｜
　　｜ N
　「個人に売りつける場合」
　　｜ 1
　　｜
　　｜ N
　「注文を受ける」「お金をもらう」「商品引渡し」
　　｜ 1
　　｜
　　｜ N
　「注文画面」「種別＝個人　パソコンＮＯ＝１２３４　販売日・・・・」
　　｜ 1
　　｜
　　｜ 1
　「受注ＤＢの中身・・・・」

ってなかんじ

---

■ユースケース、画面定義、各種テストツールの関係。
　各種業務、ユースケースは、ユースケースシナリオの見出しとかに書いてある。
　「ユースケース上ポイントとなるチェック内容」は、ユースケースの中身として、
　どの画面をどう操作してとか、書いてある。

　なのであとは、画面定義などを見ながら値を適当に決めて、
　その値を入れたときの結果を書いていく。

　この値と結果をもとに、各種テストツールを設定する。
　自動生成でも良い。

---

なかんじかしら・・・