結合テストの目的は，単体テストが完了したプログラムを「機能」や「サブシステム」単位で組み合わせ，基本設計書に定義された仕様を満たしているかどうかを確認すること。

　代表的な手法は，（1）機能単位にプログラムを結合してテスト対象とする「ブラックボックス・テスト」，（2）さらにサブシステム単位に機能をまとめてテスト対象とする「動作確認テスト」の2つがある。

　また，プログラムの結合はトップダウンで実施されるのが一般的だ。そのため，テストは結合された上位機能から順に実施され，呼び出される下位のプログラムの代わりには「スタブ」などを用いる＊13。

II-(1)：ブラックボックス・テスト

　このテストでは，テスト対象が「機能」となる。機能は，「複数のプログラムの集合体」であり，「データを入力すると，一意の出力データを得られる箱」と考えることができる。「ブラックボックス・テスト（機能テスト）」は，この中身の分からない箱（ブラックボックス）に対して，基本設計書に定義された入力と条件を与え，出力結果が定義通りであることを確認する。設計書からテスト・ケースを考える場合，下記の分析方法を用いる。

● 同値分析

　機能に与える入力と条件の組み合わせを，正常に処理できる範囲（有効値）と処理できない範囲（無効値）の2つの集合に分け，各集合の中から代表的な値を取り出してテストを行う。

　例えば，正の数しか処理できない機能の場合，有効値の代表は「1」，無効値の代表は「−1」となる。

● 境界値分析

　有効値と無効値の境界付近には特に多くの問題が存在する。そのため，各集合の境界値と，その前後を集中的にテストする。前出の例では，ゼロが境界値であり，「ゼロ」，「1」，「−1」を入力として与えてテストを行う。

● 原因結果分析

図6●入出力の関係は表にする
機能の入力データと出力データの関係を分析した結果を「デシジョン・テーブル」にまとめた。例えば，項目Aに「0以下」を入力した場合には，項目Bに「入力値が小さすぎます」を表示することを示している。表にまとめることで，テスト・ケースの漏れを防ぎやすくなる
[画像のクリックで拡大表示]

　機能の仕様に定義された入力条件（原因）と出力条件（結果）を分析して，関連結果をデシジョン・テーブルにまとめる（図6[拡大表示]）。このデシジョン・テーブルの1行を1つのテスト・ケースとして利用する。表にすることで漏れも防ぎやすい。

II-(2)：動作確認テスト

　ブラックボックス・テストにおける機能の確認は，入力と条件に対して結果出力が正しいことを確認する。一方，動作確認テストでは，機能をまとめた「サブシステム」や「システム」をテスト対象として，「システムと人間とのインタフェース」や「サブシステム間のインタフェース」などが正しく動作することを確認する。

　動作確認テストは，基本設計書に定義された，画面操作や表示，システム間のインタフェースなどを対象にして，下記のような観点で実施する＊14。

● 操作確認テスト

　利用者に何らかの操作画面を提供するシステムで実施される。画面のすべてが仕様通りに操作できるか，誤った画面操作をしても適切なエラー・メッセージが返されトラブルに至らないか，などを確認する。

　基本設計書中の画面操作仕様には暗黙の前提が多く，すべての操作に対する振る舞いが記載されているとは限らない。この不明確な部分が，本番稼働後に発覚したり，オペレーション・ミスを誘発することも多い。

● データ・バリエーション・テスト

　基本設計書のDFD（データフロー図）＊15などに定義された「各サブシステムへの入力データ」などに着目し，仕様から想定される様々な入力データを与えて，テスト対象の動作，出力結果を確認する。

　この時，入力データとして想定するのは，正常データだけではなく，異常データも含めておくことが重要だ。本来はあり得ないような入力に対するシステムの振る舞いも検査しておくと，システム障害時の原因分析や障害レベルの切り分けに有効だ。

　運用上発生する障害は，システムのバグのみに起因するわけではない。システムが訂正や補正のために許可した操作を，利用者が誤って実行した場合なども障害となる。例えば，元トランザクションが存在しないのに取り消しのトランザクションを発行した場合や，マイナス量の入荷や出荷を登録するトランザクションを発行した場合などだ。このような理論上誤ったトランザクションが発行された場合にも，システムが例外処理として正常にエラーを返せることを事前に確認しておくことで，運用後のトラブルを未然に防げる。

● インタフェース確認テスト

　サブシステム間や他システムとの間でやり取りされるデータや，共有リソースなどが規定通りかを確認する。

　通常，システム間のインタフェースは受け取る側が規定し，送る側が保証する。このため，テスト対象が送る側か，受ける側か，あるいは両方かで，テスト内容は異なる。少なくとも「規定外の情報を相手に与えないこと」，「規定外の情報を受け取っても正しい例外処理が行われること」を保証できるようにテストする。

● 業務シミュレーション・テスト

　業務系システムでは，個々のサブシステムが動作した後，業務の流れに沿ってデータが正しく扱われるか，期待した中間結果や処理結果が得られるか，入力したデータの取り消しや修正が可能かなど，基本設計書に沿って業務処理をシミュレートする。

　このテストは，結合テストとシステム・テストの中間的なテストであり，業務の流れに沿って動作することの保証取りと，基本設計書のバグ取りの両面を持つ。また，結合テストの終了可否の判定基準とされる場合が多い。

テストを自動化する

　結合テストでは，プログラム構造を意識せずにテストを実施する。そのため，検出したバグは，複数のプログラムにまたがることが多い。バグの修正も単体テスト・レベルの回帰テストのみで確認することは妥当ではない。結合テスト・レベルでの回帰テストが必要になる。


表3●動作確認テストを自動化する主なツール
[画像のクリックで拡大表示]

　結合テストでの回帰テストを効率化するには，テストの自動化が有効だ。自動化ツールは，GUI自動操作ツールやASQ（Automated System Quality）ツールと呼ばれる。画面上の操作を，人手やスクリプトであらかじめツールに記録しておき，任意に再現して回帰テストを実施できる（表3[拡大表示]）。操作シナリオを作成する言語は，独自スクリプト言語が多いが，最近ではVBScriptなど標準的なスクリプト言語を利用できるツールもある。また当然のことだが，そのテストを一度しか実施しない場合は，自動化のメリットはない＊16。


倉田 克徳
エス・キュー・シー 代表取締役
石川 和則
エス・キュー・シー 取締役 事業企画室長