ER図でデータフローを分析
単体テストが終了すれば，次に結合テストのフェーズとなる。結合テストは，機能や処理に対するまとめ的なテストである。
事例システムの場合，単体テストでプログラムのロジックの観点から制御パス・テストを実施したので，結合テストではデータの流れに基づいたデータフローパス・テスト手法を用いることにする。
事例システムのようなデータベースを用いたシステムでは，システム設計時にER図（Entity Relationship Diagram）を作成することが多い。このER図を用いると，データフローを分析しやすい。このため，データフローパス・テスト手法は，結合テストでよく利用される手法だ。
このほか，トランザクションの生成から完了までの一連の流れに着目し，トランザクションの動作結果を確認する「トランザクションフロー・テスト」や，処理結果の種類に対応する入力条件（原因）を特定し，その原因を与えて動作を確認する「CFD（Case Flow Diagram）テスト」も，結合テストでよく利用される。
以下，事例システムの基本機能の1つである「会員登録」処理を対象にしたデータフロー・パステストの設計手順とフェーズの終了判定，進ちょく管理について述べる。
テスト対象パスを洗い出す
事例システムでユーザーが会員登録する場合，最初に，あるURL（URL(1)）から「仮登録」し，その後返信されたメールで指示されたURL（URL(2)）にアクセスする。また「仮登録」は日次のバッチ処理により2日間で自動消去されることも決まっている。まず，これらの情報とER図を参照しながら，データフローを明確にする。その後，データフローに基づいてテスト対象パスを考える。
事例システムでは，正常系のパスとしては「URL(1)→仮登録→URL(2)→会員」と「URL(1)→仮登録→消去」の2つのパスが，異常系のパスとしては「URL(1)→仮登録→消去→URL(2)」，「URL(1)→仮登録→URL(1)」，「URL(1)→エラー」，「URL(1)→仮登録→URL(2)→エラー」という4つのパスが考えられる。
これらのパスは，様々な「原因」によって引き起こされる。例えば，「URL(1)→仮登録→消去」というパスは，仮登録後48時間を経過したために消去されるケースや，メールの送信エラーによって，ユーザーがURL(2)を受け取れずに48時間を経過してしまうケースがある。
表1[拡大表示]では，洗い出した各パスと，これを発生させる原因を組み合わせた「組み合わせ表」としてテスト項目を定義している。各テスト項目に対する期待結果も明確にしているのがお分かりいただけるだろう。
最後に，各テスト項目に必要なテストデータを定義し，テストケースをまとめる。テストデータの定義は，実施時にテスト担当者に一任することもあるが，担当者ごとのスキルの差によりテスト水準にバラツキが生じる可能性がある。このため可能な限りテスト実施前に定義しておくべきだ。事例システムの場合は，URLから入力するデータについて正常系，異常系ともに定義しておく。
網羅率の管理が重要
結合テストは，先述したように機能や処理に関する「まとめ」のテスト・フェーズとなる。このため終了基準には，バグ発生率（バグ件数／ステップ数），バグ検出率（バグ件数／テスト項目数），バグ収束率（総バグ件数／バグ予測件数）といった不具合の発生・解決状況だけでなく，テストの網羅率（達成したテスト項目の割合）注1）も含めることが多い。事例システムでは，正常系パスの網羅率の終了基準を80％以上，異常系パスの網羅率の終了基準を100％としている（表2[拡大表示]）。
結合テストの進ちょく管理では，このテスト終了基準の達成状況を，テスト実施状況と合わせて管理する。特に，網羅率の達成状況を随時数値化して管理することは重要である。この際，図3[拡大表示]に示すような進ちょく管理グラフを用いるとよい。こうしたグラフを見ながら，テストケースの実施順や問題解決の優先度を調整していく。
石川 和則／エス・キュー・シー 取締役東海大学海洋学部卒業。1984年にCSK入社。OS/2関連のテスト・プロジェクトなどに参加。その後，エー・アンド・アイシステムでアプリケーション開発などに従事した後，1995年よりエス・キュー・シー取締役に就任。現在は上海の現地法人である索科思軟件測試の副董事長も兼務 |
