単体テスト仕様書＆報告書

設計＆テストのＶ字モデル

   一般にウォーターフォール型開発におけるテストは、図1のようなV字モデルで表されます。DUNGEONは、このV字モデルにのっとった設計＆テスト体系を採っています。

   つまり、次のように要求分析と総合テスト、基本設計と結合テスト、詳細設計と単体テストを対比させ、各テストでは対応する設計書の内容を満たすことを確認するのです。

   ここで各設計工程における定義内容を整理しておきましょう。

要求分析と総合テスト

   要求分析では、ユーザの業務要件を定義します。例えば受注業務であれば、次のような業務の流れが業務要件となります。

   DUNGEONでは、このような業務要件を本連載の第1回で説明した「業務フロー」というドキュメントに記載します。全体を通した業務の流れ、部署ごとの業務の役割、業務に使う画面や帳票などの種類を業務フローに図示し、上記のような業務要件を説明欄に記載するのです。

   総合テストでは、実運用に近い状態でシステムが有効に機能することを確認します。本番同様のデータを使い、要求分析で定めた業務の手順にそってシステムを使って業務をまわします。うまく運用がまわるか、不都合はないかということをシステムおよび運用の両面に渡って確認するのです。

基本設計と結合テスト

   基本設計ではユーザの機能要件が定義されています。例えば、受注入力画面という機能であれば、どのような項目を入力するか、どのような画面レイアウトになっているか、各項目の入力文字数や入力文字種類など、ユーザから見た場合の機能について定義されます。

   結合テストは、これらの機能を組み合わせた一連の流れをテストします。例えば受注処理では、「受注入力」機能で注文データを入力し、「受注伝票」を印刷する。その結果「在庫引当」が行われて有効在庫が減る。そういう一連の処理を「在庫照会」や「在庫一覧表」などの画面／帳票を使いながら確認するのです。


業務システムにおけるV字モデルとの不一致

   DUNGEONは、基本的に業務システムを構築するためのドキュメント標準ですが、いわゆるV字モデルとピッタリ合っていません。それは、基本設計で"機能"単位に設計書が作成されるのに対し、結合テストは"複数の機能"の組み合わせでテストするものと定義している点です。

   業務システムにおける結合テストは、例えば受注から出荷指示、出荷、売上など一連の業務を通してテストし、その流れの中で画面や帳票を出力してデータの整合性を確認することが主となります。つまり、本番直前の総合テストと同じようなテスト内容ではあるが、テスト用データを使って開発環境で行うという位置づけにしているのです。

   この不一致は、詳細設計や単体テストの対象単位を"モジュール"ではなく"機能"にしているから生じます。前回説明したビジネスロジックのようなモジュール単位に単体テストを行い、複数のモジュールを組み合わせた機能単位に結合テストを行うと定義すればV字モデルに合致するのですが、この用法は、業務システムには適さないと考えています。