業務システムの開発ドキュメント標準化 第７回：結合テストと総合テスト

セス

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

---

図1：テストの4つのプロセス

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

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

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

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

結合テストの設計

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

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

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

図2：テスト設計書の作成手順

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

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

テストシナリオ

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

図3：結合テスト仕様書のテストシナリオ
（画像をクリックするとExcelファイルをダウンロードできます。57.0/KB）

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

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

 

試験内容（テストパターン）
   図4は、テストシナリオに対する詳細の試験内容を定義したものです。

---

図4：結合テスト仕様書のテストパターン
（画像をクリックすると別ウィンドウに拡大図を表示します）

   まず試験準備として、どのようなテストデータを用意するかを定義します。そしてテストシナリオにそって、どのようなテストを行い（試験実施方法欄）、どのようなことを確認するか（確認する内容欄）の詳細を定義します。

   そして、これらのテストパターンを実施した結果を図4の右端の確認欄に記述します。
テストデータ
   図5は、先ほど解説した試験準備でセットしておくべきテストデータの定義フォームです。

図5：結合テスト仕様書のテストデータ
（画像をクリックすると別ウィンドウに拡大図を表示します）

   あらかじめ部門マスタや社員マスタなどテストに関連するマスタデータをいくつかのパターンで用意しておくことにより、実際のテスト作業の効率があがります。

   規模の大きなシステムでは、マスタデータの全情報を記載するのは大変なので、ここではテストパターンに影響のありそうな項目のみを抜き出して記述しています。

   また必要に応じて、テストの中で入力するトランザクションデータも定義しておきます。この例では、受注入力で入力すべきトランザクションデータをパターン化して定義しています。
テスト結果データ
   バッチ処理など、テストデータ（INPUT）とテスト結果データ（OUTPUT）が定義しやすい場合は、テスト結果データも定義します。

図6：テストデータとテスト結果データ

テスト工数と品質のトレードオフ

   一般に、範囲が限定できるモジュールや機能の単体テストは網羅型テストが可能です。しかし、複数の機能を組み合わせた結合テストとなると、条件の組み合せが乗算で膨れあがり、その全パターンを網羅的にテストするのが困難になってきます。

   そのときに大切なのがシナリオの設定です。基本的に業務想定にあるシナリオは、すべてのパターンを確認する必要があるのですが、ほかのパターンですでに実証されてテスト内容が重複するような部分は省略します。

   同じようなテスト工数と品質のトレードオフは、テスト仕様書の作成においてもいえます。

   例えば複雑な業務パターンがいくつもあるケースにおいて、テストデータやテスト結果データをすべて書きだすのは、膨大な工数がかかり現実的ではありません。品質のトレードオフというと「だからソフト業界は」などと目くじらを立てる人がいますが、必要な品質をあきらめるというわけではありません。いたずらに網羅性、綿密性を追求するのではなく、ここまでやれば十分というゴールを定めてテストする姿勢が大切なのです。
総合テストの手順
   総合テストは、一般にシステムテストとも呼ばれています。業務アプリケーションにおいては、実際に業務で使うデータを使って、業務を運用するテストを意味します。既存のシステムがある場合は、現行業務と平行して同じデータを使って比較確認する平行本番テストということになります。

   総合テストを行う際は、図7のような手順になります。

図7：総合テストの手順

環境構築
   結合テストまでは、開発マシンもしくはテスト用マシン上での確認試験となりますが、総合テストは原則として本番マシン上でのテストとなります。アプリケーションのテストだけでなく、ハードウェアやOS、ミドルウェアなどのシステム全体が正常に動作することを確認します。Webサーバや開発言語、DBMSなどのバージョンの組み合せによるトラブルや個別の障害なども少なくありませんので、本番とまったく同じ環境を構築してテストを行う必要があります。
データ移行
   総合テストは、原則として本番と同じデータを使います。本番データを使うことにより、想定外のデータが存在していることが発覚したり、思うようにパフォーマンスがでないという問題が明らかになります。

   そのために、マスタデータおよび残データ、そしてトランザクションデータの移行を行う必要があります。これらの移行は、総合テストが終了した本番直前にも行うことになりますので、できる限り移行プログラミングを作成して何度でも移行できるようにします。

   過去データを照会および分析用に移行したいケースもありますので、トランザクションデータに関しても、どのデータをいつからの分まで移行するかを事前によく検討し、必要なデータの移行プログラムを用意しておきます。
ユーザ教育
   総合テストの主役はエンドユーザです。エンドユーザに業務を行ってもらうことにより、開発サイドでは気づかなかったような問題点が指摘されます。そのために、操作マニュアルや運用マニュアルを用意して、ユーザに対して何回か教育を行う必要があります。
テストシナリオ実施
   総合テストのシナリオは、基本的に結合テストのシナリオと一緒です。結合テストが開発環境において行うのに対し、総合テストは本番環境で実施するという違いになります。

   テスト仕様書も結合テストのものをコピー利用することになりますが、それに加えてパフォーマンステストやハードやネットワーク障害対応（イレギュラーテスト）、データのバックアップと復元など、運用面のシナリオも追加します（もちろん、これらのテストも結合テスト段階で実施している方が望ましいです）。
結果の照合・判定
   平行本番テストの場合は、現行業務と同じデータを平行して入力し、その結果を照合して差異のないことを確認します。それに加えて、操作性や運用の容易さ、パフォーマンスなどの総合的な評価を得て、ユーザの合格をもらいます。不具合があれば、タイムリーに修正して再テストします。修正に時間のかかるものは、とりあえずできるシナリオから先にテストを進めることになります。

   予定のシナリオがすべて終了し、発生した障害も対応して業務に支障がないことが確認できた段階で、ユーザ検収となりテスト終了です。ただし、月次処理や年次処理など、1ヶ月から数ヶ月後でなければ運用確認ができないような機能に関しては、擬似的に処理してその結果を確認したら検収をもらうことになります。
まとめ
   今回は、結合テストのテスト計画プロセスにおけるドキュメントとして「結合テスト仕様書」のテンプレートを紹介しました。テストのシナリオとテストケース、テストデータの定義パターンについて理解できたと思います。

   また、最終のテストとなる総合テストについては、手順や作業内容を簡単に説明しました。あくまでも業務アプリケーションをテスト対象としていますので、組み込み系ソフトウェアなどの場合は、少し内容が異なるということをご了承ください。