テストの基本的な知識は、あまねくITエンジニアが持つべきだ。しかし実際には、本当に基本的な知識でさえ浸透していないのが現状である。そこでこの記事では、ITエンジニアが最低限知っておくべきテストの基本知識と、その活用方法を解説する。
社会的なインフラとして構築された大規模システムで，大きな障害が多発している。こうした問題を防ぐためにも，高品質なシステムを開発する必要性がますます高まっていることは言うまでもないだろう。
システムの品質を向上させるためには，しっかりと設計を行い，それに基づいて正しく実装する必要があるのはもちろんだが，最終的にはシステムを動作させてテストするしかない。
テストで品質を検証するためには，周到なテスト計画やソフトウエアの特性に合わせたテスト設計，効率的なテスト管理が必須となる。そのためには，品質管理の担当者だけではなく，プロジェクト・マネジャーやリーダー，SEにも，テストの基本的な知識は必要である。
そこで本稿では，システム開発に携わるすべてのITエンジニアを対象に，テストの基礎について解説する。ベテラン・エンジニアも，復習のつもりで読んで欲しい。
品質を段階的に検証する
最初に，システム開発におけるテストの位置付けを明確にしておこう。図1[拡大表示]は，品質保証の観点から見た有名な「V字モデル」である。システム開発における各フェーズを「品質の埋め込みプロセス」と「品質の検証プロセス」に分類し，それぞれを検証内容によって対応付けている。
このうち後者の品質の検証プロセスを「テスト・プロセス」と呼ぶ注1）。テスト・プロセスには，(1)モジュールをテストする単体テスト，(2)各モジュールを結合させた状態でテストを実施する結合テスト（囲み記事参照），(3)システム全体をテストするシステムテスト（統合テストと呼ぶこともある），(4)ユーザー企業による受け入れテストや本番環境でテストを実施する運用テスト—といったテスト・フェーズがある。
この中で，単体テストはプログラマが実施し，結合テスト以降はプロジェクトの中のテスト・チームが実施することになる。ただし，これらは一般的なテスト・フェーズであり，具体的にどんなテスト・フェーズを実施するのかはプロジェクトごとに異なる。
テストの目的は，大きく2つに分類できる。1つはバグ検出のためのテスト。もう1つはシステムの動作を保証するためのテストだ。
テストと言うと「バグを発見するもの」と考える読者が多いかもしれないが，必ずしもバグを発見することだけがテストの目的ではない。単体テストなどのテストの初期段階ではバグの検出が優先されるが，結合テスト以降では，システムの動作を保証することに，より重点が置かれる（表1[拡大表示]）。
ソフトウエアのテスト作業は，地雷撤去に似ている。ソフトウエアという広大な土地に埋められた複数の地雷（バグ）をテストで撤去していくわけだ。それだけに，テストは段階的かつ計画的に実施しなければならない。
2つに分類できるテスト手法
段階的にソフトウエアの品質を検証するには，各テスト・フェーズに合ったテスト手法を採用する必要がある。そこで，まずはテスト手法の基礎について解説しよう。
テスト手法には大きく分けて「ホワイトボックス・テスト」と「ブラックボックス・テスト」がある注2）。
ホワイトボックス・テストは，プログラムの内部構造を参照し，そのロジックや制御の流れを調べるテスト手法で，単体テストで使用される。
ホワイトボックス・テストは，さらにいくつかのテスト手法に分類できるが，最も一般的な手法は，制御パス・テストである（表2[拡大表示]）。
制御パス・テストは，プログラムの処理経路（開始から終了に至る命令の列）をテストする手法で，テストする処理経路の網羅の度合いに応じて，C0網羅（命令網羅），C1網羅（分岐網羅），C2網羅（条件網羅）などの網羅基準がある（図2[拡大表示]）。
C0網羅は，処理経路を構成するすべての命令を最低1回実行するテストで，処理経路の網羅の度合いは最も低い。単体テストでは最低限，このC0網羅は実施すべきだが，これだけでは十分ではない。C1網羅は，すべての条件分岐の真と偽の両方を最低1回テストする方法，C2網羅は条件分岐の真と偽のすべての組み合わせをテストする方法である。コストやテスト期間のバランスを考えれば，C1網羅が最も現実的である。なお，全処理経路数のうち，実際にテストした処理経路数の割合を「網羅率（カバレッジ）」と呼ぶ。例えば全命令数が100で，このうち50をテストした場合，C0網羅率は50％となる。
一方のブラックボックス・テストは，テスト対象の仕様や使い方に着目して，入力値と出力結果の対応関係から，関数やメソッドの振る舞いを調べるテストである。ブラックボックス・テストは，結合テスト以降のテスト後半で使用される。
ブラックボックス・テストも，「同値分割」や「境界値分析」，「原因結果グラフ・テスト」など様々な手法に分類される（表2参照）。例えば同値分割は，入力値を有効値の集合と無効値の集合に分け，各集合から代表値を選んでテストする手法。境界値分析は，有効値と無効値の境界値とその前後の値を選んでテストする手法である（図3[拡大表示]）。いずれも，無効値が入力されたときに限りエラーになることを確認するものだ。
ただし，ブラックボックス・テストでは検証できないこともある。具体的には，メモリーへの適正なアクセスやメモリー領域の確保・開放，プログラムの命令が実行されたのかどうかは，入力値と出力結果を見るだけでは検証できない。
このため，テスト対象プログラム内にチェック用のコード（プローブ）を埋め込んで命令の実行を確認したり，テスト実施中のメモリー状況を計測する，といった方法を採用することがある。この手法を「グレーボックス・テスト」と呼ぶ。グレーボックス・テストを実施するには，メモリー状況を計測したり，命令の呼び出しを計測するためのツールが必要になる。
結合テストの手法結合テストには「増加テスト（インクリメンタル・テスト）」と「一斉テスト（ビックバン・テスト）」という2つの基本的な進め方がある。 増加テストは，最初にテストしたモジュールに徐々に他のモジュールを結合しながらテストを進める方法。結合方法によって，(1)上位モジュールからテストを始めて，徐々に下位モジュールを結合していく「トップダウン・テスト」，(2)下位モジュールからテストを始めて徐々に上位モジュールを結合していく「ボトムアップ・テスト」，(3)中間のモジュールからテストを始めて上位，下位のモジュールを結合していく「サンドイッチ・テスト」の3種類に分類できる。 トップダウン・テストを実施する際には，下位モジュールをエミュレートするダミー・モジュールである「スタブ」を作成する必要がある。スタブは，上位モジュールから呼び出し可能な関数を持ち，ある値を受け取ると，なんらかの値を返す。 また，ボトムアップ・テストの場合は，上位モジュールをエミュレートする「ドライバー」を作成する必要がある。ドライバーは，下位モジュールを呼び出してテストデータを渡す機能を持つモジュールである。スタブやドライバーはなるべく単純な構造にしておき，何度も再利用することが重要である。 一方の一斉テストは，すべてのモジュールを結合してからテストを実施する方法で，段階を踏まない分，うまく進めれば最も効率よくテストを終了できる。だが，逆に問題が発生した際の手戻りや不具合の解析には時間がかかるため，開発の規模が大きかったり，システムが複雑な場合には，増加テストを採用する方が効率がよい。 |
石川 和則／エス・キュー・シー 取締役東海大学海洋学部卒業。1984年にCSK入社。OS/2関連のテスト・プロジェクトなどに参加。その後，エー・アンド・アイシステムでアプリケーション開発などに従事した後，1995年よりエス・キュー・シー取締役に就任。現在は上海の現地法人である索科思軟件測試の副董事長も兼務 |
