前回までは，テストの基本的な手法や管理方法について説明した。だが，現実のプロジェクトでは基本通りに進まないことが多々ある。そこで今回からは「応用編」として，BtoCのWebシステム開発を例に，具体的なテストの進め方について説明する。
例として取り上げるのは，コンテンツ・サービスのライセンス販売システムである。ユーザーがあるURLでIDの仮登録を行うと，メールで本登録用のURLが送付され，そのURLでIDを本登録。IDが登録されたら，1カ月，3カ月，半年，1年の各ライセンスをクレジットカードで購入できるシステムだ。プログラムは，(1)Webインタフェース部分，(2)データベースへのアクセス部分，(3)バッチ処理部分という3つのサブシステムで構成されるものとする。
特性を見極めて計画を作る
前回までで見たように，最初にシステムの「全体テスト計画」を立案する。ここで重要なのは，そのシステムの品質向上に自信を持って取り組めるよう創意工夫することだ。以前紹介した記載項目をマニュアル通りに記載すればいい，というものではない。
例えば，事例システムのWebインタフェース部分を，プロトタイピングを重視したスパイラル型で開発する場合，デバッグと単体テストを切り分けるのは難しい。このため，Webインタフェース部分は単体テスト・フェーズの対象外とし，結合テストからフェーズに組み入れた方が効果的だ。
ついつい杓子定規になりがちなテスト・フェーズの組み立てだが，効率の悪い作業は思い切って切り捨てることも，全体テスト計画の重要なポイントになる。
コストに余裕がある場合は，本番用環境とテスト用環境を別に準備し，サーバー環境の負荷テスト（レスポンスタイムを計測するテスト）は本番環境で，アプリケーションの負荷テストはテスト用環境で実施するシナリオも検討すべきである。負荷テストに合格済みのサーバー環境へアプリケーションを載せる方が，安定した稼働を実現しやすいし，ハードやOS，ミドルウエアなどの環境の問題とアプリケーションのボトルネックを早期に切り分けられるからだ。
アプリケーションを載せずにサーバー環境をテストするには，アプリケーション・サーバーやデータベース管理システムを利用する「ダミー・プログラム」を作成しておく。サン・マイクロシステムズや日本オラクルなどのベンダーが提供するパフォーマンス・チェック用ツールを使えば，あらかじめ用意されたダミー・プログラムを使って，サーバーやデータベースなどの個別製品のパフォーマンスをチェックできる。コスト面で，本番環境と実行環境を用意するのが難しい場合は，アプリケーションの負荷テストをなるべく早い段階から実施し，環境に起因しないボトルネックや負荷特性をあらかじめ確認できるようフェーズの組み立てを行うべきである。
内部構造を模式化する
次に，テスト・フェーズごとにテスト設計やテスト管理方法を見ていこう。まずは単体テストだ。
単体テストは最初のテスト・フェーズであり，通常はテスト・チームではなく，プログラマが実施する。しかし，テストとして実施する以上は，単体テストでもしっかりとしたテスト設計を行う必要がある。
単体テストでは，プログラムの内部構造に基づいたホワイトボックス・テストの手法が用いられる。以下では，ホワイトボックス・テストの代表例である制御パス・テストによるテスト設計の進め方を説明しよう。
制御パス・テストでは，最初にテスト対象モジュールの制御構造を分析して模式化する。模式化の方法にはいくつかの手法があるが，ここでは簡単なフローチャートを用いることにする（図1[拡大表示]）。
最近のプログラム設計ではフローチャートを利用することは少ない。特にJavaによる開発では，フローチャートよりもUML（Unified Modeling Language）を用いて設計することの方が多いだろう。しかし，UMLは制御構造を設計する場合には効果的だが，処理経路を洗い出すのに必要な情報がオブジェクト図，シーケンス図，コラボレーション図，ステートチャート図などの図に分散してしまうため，制御パス・テストの設計には向かない。このため，テスト設計ではフローチャートなどで簡易的にプログラム構造を模式化する方が効率がよい。
最近は単体テストの設計を自動的に行ってくれるツールも市販されている。ただし，ツールが利用できるかどうかは事前によく調査しておく必要はある。
バグ発生をリアルタイムに共有
フローチャートを作成したら，次にテスト項目を定義する。この際，達成すべき網羅基準を明確にすることが重要である。
制御パス・テストの網羅基準には，前回までで説明したようにC0網羅（命令網羅）やC1網羅（分岐網羅），C2網羅（条件網羅）があるが，事例システムの単体テストではC1基準を採用することとした（図1[拡大表示]参照）。図2[拡大表示]に，C1網羅に沿ったテスト項目を確認するための，実際のテストケースの例を示した。
単体テストの進ちょく管理については，テストケースの消化状況とバグの発生／修正状況を管理するのが一般的だ。ここでの注意点は，バグの発生や修正がリアルタイムにチーム全体に周知徹底されるようにする必要がある，ということである。単体テストで発生したバグを修正すると，必然的に他のモジュールに影響を及ぼすために，チーム全体で情報を共有していないと「デグレード」を引き起こす可能性が高いからだ。リアルタイムに情報を共有するためには，なるべく構成管理ツールなどを導入するべきだろう。
石川 和則／エス・キュー・シー 取締役東海大学海洋学部卒業。1984年にCSK入社。OS/2関連のテスト・プロジェクトなどに参加。その後，エー・アンド・アイシステムでアプリケーション開発などに従事した後，1995年よりエス・キュー・シー取締役に就任。現在は上海の現地法人である索科思軟件測試の副董事長も兼務 |
