統合テストとテスト設計

要点と定義

統合テストでは、組み合わせたモジュールや構成品目が、設計で定めた仕様に沿って連携するかを確かめます。ソフトウェア統合テストはソフトウェア設計のテスト仕様に基づき、ソフトウェア検証テストはソフトウェア要件に基づいて、要件どおりに実現されているかを確かめます。システム統合テストでは、ソフトウェアやハードウェア、手作業などを合わせたシステムの動作を確認します。テストの目的に応じて、対象と照らし合わせる仕様の段階が異なります。

テストケースは、入力や前提条件、実行する処理、期待する結果を組み合わせた確認単位です。テスト実施後は結果を記録・分析し、必要に応じて修正や文書更新を行います。仕様とテスト、結果の対応を追えるようにしておけば、要件の確認漏れや変更の影響を把握しやすくなります。

ホワイトボックステストはプログラムの内部構造に着目し、命令や分岐、条件の実行状況を確認します。ブラックボックステストは内部構造を前提にせず、仕様に基づく入力に対して期待どおりの出力になるかを確認します。処理手順の分岐を通したかを見るテストと、入力に対する結果が仕様どおりかを見るテストは、目的が異なります。

テストデータの選び方も目的に合わせます。ブラックボックステストでは、仕様上同じ振る舞いになる入力を同値クラスに分け、その代表値を選んだり、境界値とその前後を選んだりします。例えば「在庫数が1以上なら注文可能」という仕様なら、0、1、2を試すと境界付近の誤りを見つけやすくなります。実データを無作為に取るだけでは、仕様上の境界や例外を十分に確かめられるとは限りません。

決定表は、複数の条件と、それぞれの組合せで行う動作を表にしたものです。条件の組合せごとに結果を整理することで、条件の見落としや出力先の取り違えを確認しやすくなります。例えば「申請が有効」「期限内」の二条件なら、真偽の組合せごとに受理または保留などの動作を定めます。

網羅基準は、どこまで確認したかを測る尺度です。判定条件網羅は判定結果の真と偽を確認します。複数条件網羅は、判定を構成する各条件の真偽の組合せを確認します。条件が二つなら、真真・真偽・偽真・偽偽の四通りが対象です。判定結果が一度ずつ真と偽になっても、内部条件の組合せまでは網羅できないことがあります。

ブラックボックステストは外から観察できる振る舞いを仕様と照合します。そのため、冗長なコードが内部に存在すること自体は、出力が同じなら検出できません。内部構造やコードの品質を調べるには、別の確認手段が必要です。

テスト対象の前後にあるモジュールが未完成の場合、代替部品を用いて統合前のテストを進められます。ドライバはテスト対象を呼び出す側を代替し、引数を渡して実行します。スタブはテスト対象から呼び出される側を代替し、必要な応答を返します。呼び出し方向で役割を区別します。

エラー埋込法は、既知のエラーを意図的に埋め込み、その発見状況から潜在エラー数を推定する考え方です。埋め込んだエラー数を S、そのうち発見した数を m、テスト開始前から潜在していたエラー数を T、発見総数を n とし、両者の発見率が同程度と仮定すると、m/S=(n−m)/T となります。総発見数 n から既知の発見数 m を引くのは、自然に潜在していたエラーの発見数を求めるためです。この推定は発見率が同程度という仮定に依存します。

適用条件と例

テストの設計では、仕様に書かれた条件、境界、組合せ、期待結果を読み取り、目的に合うケースを選びます。例えば、注文情報をページごとに最大五件格納する処理なら、同じグループの情報が四件の場合と五件の場合を用意すると、上限に達したときの分岐を確かめられます。グループが切り替わる入力も加えれば、ページ件数の上限とは別の条件を確認できます。過年度の午後問題で扱われた流れ図の追跡やテストデータ設計は、現在の試験形式を示すものではありませんが、条件と処理を対応させる基礎として有用です。