結合テストにおけるパターンの考え方

ソフトウェア開発において、実装したプログラムをテストする上でとても重要なのが

　パターン（およびその組み合わせ）

です。

中でもデータ(入力値や出力値)のパターンに関しては、プログラムが引数だったりメモリだったり、ＤＢやファイルなどから、処理するために必要な入力値を取得した際、必ずと言っていいほど行われる"入力チェック"仕様と
ほぼ同一の組合せを求めることになります。

この観点は、機能仕様を検証する上で、ほぼすべての品質を確認できる観点となります。それらの組合せ一つひとつにおいて、

　正しい値／組み合わせパターンであれば、正しい動作をすること
　誤った値／組み合わせパターンであれば、異常検出時の動作をすること

を確認する必要があるからです。プログラムにおいて異常検出のロジックが必要なのは、その後の「値が正しいことを前提とした処理群」で想定外の結果となって欲しくないためです。

私たちが、食べ物を口にして「痛い」「マズい」「辛い」などを感じ取るのは、そのまま身体の中に含んでしまうと、内蔵処理が異常な活動を起こしてしまい、システムエラーによる異常動作（病気）や活動停止（死）になりかねないためのチェック処理のようなものです。

リアルの世界で、人間が得られる外部入力値と言うモノはとても種類が多すぎて、一つひとつの種類やサイズごとにチェック処理を設けるのは至難です。

しかし、プログラムの世界ではその組み合わせは数えられる範囲でしかありません。たとえば、もっとも有名なプログラム言語の１つ「Ｃ言語」の変数型を見てみましょう。

たったこれだけです。

これだけであれば、一つひとつの変数ごとのチェック観点を網羅することは容易いはずです。結合テストになってくると、データパターンの正常系/異常系網羅が中心となって機能仕様の検証を行うことになりますが、確認する本質的自体は単体テストレベルのそれと変わりありません。

　単体テスト：処理レベル（または、"単体"と認めた最小レベル）
　結合テスト：機能レベル
　総合テスト：仕様レベル（大抵の場合は、実運用レベル）

と言うスコープでテストすることになりますが、異なるのはスコープや、テストの種類、評価方法に差があるだけで、少なくともプログラムの妥当性検証を行う場合は、どの層のテストでも本質は変わらず

　求められるパターンの網羅

です。

　単体テストであれば、処理の分岐パターン網羅
　結合テストであれば、動作する機能が求める動作パターン網羅
　総合テストであれば、業務/運用上のシチュエーションパターン網羅

となります。

先日、記載した記事で条件分岐網羅については、ほぼほぼ明確にしたと思います。いずれ、繰り返し網羅についても説明しますが、一旦それは置いておくとしましょう。