結合テスト(結合試験)とは、「複数のプログラム(モジュール)をつなげて動作確認するテスト」のことです。
IT(Integration Test)と呼ばれたり、SI(System Integrationt Test)と呼ばたりするけど、なんて呼ぶかはその時次第。
ひよこSE(@PiyoOct)が経験したプロジェクトでは、”SI”と呼んでいます(“IT”と呼ぶことの方が多いらしい)。
「モジュール」なんて難しい言葉が出るとビビりがちだけど、簡単に言えば「単体テストをくぐりぬけた部品(プログラム)を合体して動かしてみても、ちゃんと動くよね？」という疎通(そつう)確認をします。
一つ一つの部品(プログラム)を合体させて、「ホテル予約システム」なり「在庫管理システム」なり「会計システム」なり、誰かが使える「システム(製品)」が完成します。
言い換えると、実際に「システム(製品)」を試しに動かしてみて動くか？を見るのが結合テストです。
結合テストとは、複数のプログラム(モジュール)をつなげて動作確認するテスト
結合テストとは、複数のプログラム(モジュール)をつなげて動作確認するテストです。
その前に、「モジュールってなんだ？」ってなってる人向けに、簡単に説明します。
モジュールとは？
「単体テスト」の記事を見てくれている人は、「もういいよ」ってなると思うので適当に飛ばしてください。
モジュールとは、「プログラムの部品」のこと。
例えば、ドラクエ。
実際のドラクエの作りはわからないけど、冒険の書を作ってオープニングムービーが流れるまでに、
- 冒険の書を作るプログラム
- オープニングムービーを流すプログラム
の2つのプログラム(モジュール)があると仮定します。
「ドラクエ」というゲームをプレイするなら
冒険の書を作る→オープニングムービーを流す→・・・→魔王を倒してエンディング
みたいに、それぞれの部品(モジュール)を合体させて、ゲームとして動かないと意味がありません。
それぞれのモジュールが問題ない前提で、実際につなげて動くかが観点
ドラクエの例だと、「冒険の書を作る（勇者の名前を決める）」⇒「オープニングムービーを流す」ということを実際にやってみて正しく動作するか？を確認します。
「冒険の書をつくるプログラム」と「オープニングムービーを流すプログラム」は、単体テストが終わったので、問題ない前提です。
問題ないプログラム(モジュール)同士をつなげて、通しでテスト。
たとえば、こんなことをテストします(あくまでイメージです)。
- そもそも、フリーズせずに冒険の書を作ってムービーが正しく流れるか？
- はじめに決めた勇者の名前がムービー内で正しく表示されるか？
- プログラムの実行が終わったあとに、セーブデータは正しく保存されているか？
テストして不具合(バグ)が見つかれば、「冒険の書をつくるプログラム」と「オープニングムービーを流すプログラム」の仕様(考え方)がケンカをしています。
原因を特定。通しで動かしても問題ないように片方、あるいは両方の設計を修正します。
あれ、仕様がケンカしているとは限らないのでは？
結合テストでは、プログラム単体では悪さしない前提なので・・・
結合テストで片方のモジュールがない場合はスタブとドライバで代用
結合テストでは、どちらか片方のモジュールがない場合もあります。
結合テストは「試しに動かしてみる」イメージ
え？実際につなげて動かすのに矛盾していない？
冒頭で「『システム(製品)』を試しに動かしてみて動くか？を見る」と、わざと回りくどい書き方をしました。
結合テストの段階では、「試しに動かしてみる」だけであって、まだまだ「練習」の段階です。
スポーツの世界で例えるなら、単体試験が個別トレーニングで、結合テストが「紅白戦」。
どちらか片方のモジュールがない場合は、紅白戦の人数が足りないイメージ！
「夏の大会の本番に向けた仕上げの練習試合」は、さらに次の工程の、総合テストです。
開発中のモジュール(プログラム)があるなら、スタブとドライバで代用
というわけで、片方のモジュールがない可能性もあります(*´ω｀)。
システム開発の話に戻ると、例えば「オープニングムービーを流すプログラム」は、全くの別会社に外注してて製作中のときとか。
そんなときは、「ドライバ」あるいは、「スタブ」という仮のプログラムを作って代用します。
- 【ドライブ】別のモジュールを呼び出す仮のプログラム
- 【スタブ】呼び出される側の仮のプログラム
「冒険の書をつくるプログラム」⇒「オープニングムービーを流すプログラム」の例の場合。
ドライブは「冒険の書をつくるプログラム」で、スタブは「オープニングムービーを流すプログラム」です。
【余談】結合テストで単体テストレベルの不具合(バグ)が見つかるとめんどいよ
完全に余談だけど、結合テストで単体テストで見つかるべきレベルの不具合(バグ)が見つかるとめんどいです。だるいです。やるせないです。
早い話が、部品をつなげるうんぬん以前の問題で、1つのプログラム単体で自滅しちゃったってことなので(*´ω｀)。
最悪は(あまりに単体レベルのバグが多いと)・・・「テストのやり直し」みたいな話になります。
大人の事情なので、あまり具体的なことは書けないけど・・・。察してください(-_-;)。
まとめ
結合テスト(結合試験)ときたら、「複数のプログラム(モジュール)をつなげて動作確認するテスト」のことです。
IT(Integration Test)と呼ばれたり、SI(System Integrationt Test)と呼ばたりするけど、なんて呼ぶかはお仕事をする場所次第。
「単体テストをくぐりぬけた部品(プログラム)を合体して動かしてみても、ちゃんと動くよね？」という疎通(そつう)確認をするのが目的です。
合体して「うん。問題ないね」となれば、次の工程の「総合テスト」と呼ばれる、練習試合的な工程に進むと思ってくださいまし(-_-;)。
コメント