結合テストと総合テスト

テストのプロセス

   ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます（図1）。

---

   テスト計画プロセスでは、テスト全体の指針や概要をまとめます。テストの目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、合格基準など、テスト全般に関わる方針を「テスト計画書」にまとめ、ユーザを含むプロジェクトメンバー全員で方向性を共有します。

   テスト設計プロセスでは、策定されたテスト計画に基づいて、実際のテスト作業内容を設計します。テストのシナリオやテスト内容、確認すべき項目などを「テスト仕様書」に具体的に定義します。

   テスト実施者は、このテスト仕様書に基づいてテストを実施します。障害を発見した際は、障害番号を採番し、障害管理票に記載して残管理します。これらの障害が片づいて、テストが正常に行われた場合は「テスト報告書」で報告します。

   弊社では、これらのテストプロセスに対応したドキュメントをプロジェクト管理手法（PYRAMID）と開発ドキュメント標準（DUNGEON）にて定義しています。前回は、この中から「単体テスト仕様書」について説明しました。今回は、「結合テスト仕様書」と「総合テスト仕様書」について説明します。

結合テストの設計

   DUNGEONでは、業務アプリケーションの結合テストを「複数の機能を組み合わせた一連の流れをテストすること」というように定義づけています。つまり、基本設計工程で作成した業務フローにそって、「受注入力」「受注伝票出力」「出荷依頼」「出荷」などの個々の"機能"を結合してテストし、データが正しくターンアラウンドされ、整合性が保たれることを確認することになります。

   テスト設計プロセスでは、このようなテストのシナリオを設定します。一連のシステムが業務要件を保つことを確認するためのシナリオを用意し、そのシナリオにそったテストケースを設定する作業ということになります。

   DUNGEONの結合テストの設計では、図2のようにテストシナリオとその具体的な試験内容となるテストケースを定義します。

   テストシナリオで全体のテストの流れ（機能確認の順番など）を想定し、テストケース定義で個々のテスト内容（どんなテストデータを入力して、どういうテスト結果を想定するかなど）を定義します。

   結合テストでは、何パターンかのテストシナリオを作成します。そして、シナリオごとに複数のテストケース定義し、どんなテストで何を確認するかを定義します。テストケース策定の際に必要となるマスタデータも、テストデータとして定義しておいた方がやりやすいでしょう。

テストシナリオ

   テストシナリオは、一連のテストの流れをパターン化したものです。図3は、DUNGEONのテストシナリオを表したものです。

   例えばシナリオ「J01-01 出荷依頼の取消＆受注変更」では、「受注新規 → 出荷依頼 → 出荷依頼取消 → 受注変更 → 出荷依頼 → 出荷確認 → 売上計上」という一連の業務の流れを想定し、各業務の概要を「1-1〜1-7」で説明しています。

   テストシナリオでは、どのようなテスト手順にすれば確認したいテスト内容をカバーできるかを考えます。この例は、すでに出荷依頼済みの受注伝票を変更するために、いったん出荷依頼を取り消してから受注変更を行った場合の動作を確認するシナリオです。