「上司の頭の中にあるテスト方法の考え方」シリーズ？の４回目、結合テストについてです。
結合テストの方法について、やはりIPAのCAIT(中央情報教育研究所）が出した、テキスト、
ただし今回は第一種共通テキスト（１５）応用システム開発技法から。
４８３ページから４８５ページまでをまとめます。
方法
（１）結合テスト仕様書を作成する
・結合順序：トップダウンでおこなうか、ボトムアップで行うか、
その中間でおこなうか（サンドイッチという）をきめる
・テストケースを考える
・テストケースを実現するデータを考える
・テスト結果について考える
・どこでテスト完とするかきめる
（２）結合テストを実現する環境を整え、テストデータを作成する
・テストツールを作成、入手し、動くようにする
・テストデータを作る
・テスト環境を整える（DB、Web環境などなど）
（３）テストを行う
・テストする
・エビデンスをあつめ、結果をかく
→バグがあったらバグ表をかく
・マネージャーがてきとーに終わりをきめる
→とは、テキストには書いてないが、ふつうそうだ
で、問題は、結合順序。
DBアクセス部分など、一番最底辺（資源より）の部分は、共通化されていて、その部分の開発は、たいてい共通ないし方式のチームがやることになる。ということは、ボトムアップだと、そのチームの開発がおわっていないといけない。
サンドイッチ、トップダウンだとしても、スタブがないと、リンクできず、実行できない。
でも、DBって、結構仕様（項目やテーブル）が動く。そこで、この部分は、自動化して、できるだけプログラムがすぐにできるように、それができない場合は、スタブがすぐにできるようにする。
じゃないと、リンクできなくなって、テストがとまってしまう。
そこで、この最底辺部分の自動生成というのは、よくやると思う。
で、この部分を簡単に自動生成させるには、ExcelファイルでVBAで動かすと、かんたんなのよね
なんで、仕様書、Excelファイルにしましょう。。。となりやすい。
まあ、これだけの理由じゃないんだけどね。仕様書を、Excelファイルにする理由は。。
ただ、現実問題、DBアクセス部分など、資源にアクセスする部分を手作業で作っていると、結合テスト段階で、間に合わなくなってくる。っていうのは、オブジェクト指向の場合、バグが出やすいのは、情報隠蔽とコミュニケーション不足（誤解）による意識の違いなので、結合でバグがでやすく、仕様変更もこの段階で多い。
そうすると、DBは、結合段階でばんばん動いてくる。がんがん作っていかないとまにあわなくなる。
そのわりに、テーブル数は結合段階では、５０なり１００なり、すごい数になっていて、かんりたいへん。。。
なんで、自動化してないと、たいへんなんだな！
でも現場で、こういう理解をしてくれる人は少なく、意識あわせの問題までも、「単体テストレベルのテストができてない」と、単体レベル、担当者レベルの責任にしてしまう。
したがって、どのように意識あわせをしたらいいかという、問題の本質は改善されず、だれかをスケープゴートにして、結局、意識あわせの部分は改善されない。っていうのが、現状かな。。。
アクセス
トータル
ランキング
