(cache) [ThinkIT] 第7回：結合テストと総合テスト (1/3)

TOP＞プロジェクト管理＞テストのプロセス

	<AHREF="http://ngs.impress.co.jp/click.ng/Params.richmedia=yes&site=TI&size=text&sp=ti_text_link1"target="_blank"> <IMGSRC="/contents/026/141/677.mime7"BORDER=0> </A>

	<AHREF="http://ngs.impress.co.jp/click.ng/Params.richmedia=yes&site=TI&size=text&sp=ti_text_link2"target="_blank"> <IMGSRC="/contents/026/141/687.mime7"BORDER=0> </A>

即活用！業務システムの開発ドキュメント標準化

第７回：結合テストと総合テスト
著者：システムインテグレータ梅田弘之 2005/10/7

1 2 3 次のページ

テストのプロセス

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

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

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

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

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

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

結合テストの設計

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

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

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

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

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

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

テストシナリオ

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

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

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

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

1 2 3 次のページ

著者プロフィール
株式会社システムインテグレータ梅田弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。

この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。
ご意見、ご要望にお応えします！インプレスIT INSIDE

INDEX
第7回：結合テストと総合テスト
	テストのプロセス
	試験内容（テストパターン）
	総合テストの手順

即活用！業務システムの開発ドキュメント標準化
第1回	開発ドキュメント体系と業務フロー
第2回	機能一覧表とI/O関連図
第3回	基本設計書
第4回	詳細設計書（前半）
第5回	詳細設計書（後半）
第6回	単体テスト仕様書＆報告書
第7回	結合テストと総合テスト
第8回	要求仕様書の標準化プロセス

関連記事：即活用！企業システムにおけるプロジェクト管理
第1回	プロジェクト管理力を強化するための具体的プラン
第2回	PMBOKをベースにしたプロジェクト管理の管理
第3回	スコープ管理とスケジュール管理
第4回	コスト管理の構造と見積手法
第5回	品質管理
第6回	組織管理
第7回	コミュニケーション管理
第8回	リスク管理
第9回	調達管理（外注管理）

関連記事：即活用！ツールを活用したデータモデリング
第1回	ソフトウェア産業に産業革命を起こすデータモデリング
第2回	ERの基礎知識とツールの活用法
第3回	日本語名の是非とデータ型採用方針
第4回	制約の使い方、Unicode使用可否、明細テーブルの設計
第5回	教科書的ではなく、現場にあったデータベース設計のコツ