戻る

テストファース

Revised: 2004-12-12

障害対応の最善策は、障害を未然防止することです。また、開発実施中は、バグを後工程に持ち込まないことです。そのため、システム開発ではテストが極めて重要です。

テストの基本

従来型のウォーターフォール型開発では、V字モデルでテストを実施していました（図）。要求分析、要件定義が運用テスト、システムテストを決め、外部設計、内部設計が結合テスト、プログラム設計が単体テストを決定します。

図：V字モデル

オブジェクト指向で推奨される反復型（ラウンド・トリップ型）の場合も、基本的にはウォーターフォール型のV字モデルに従います。しかし、反復（イタレーション）ごとに、追加された（インクリメンタル）機能に対する回帰テスト（リグレッションテスト）が必須になります。リグレッションテストは、追加／変更された機能が、既存機能に対して副作用（サイド・エフェクト）を持たないかどうかを確認するためのテストです。

システム開発は、アプリ開発と基盤開発の二つに分けられます。H/W, OS, ミドルウェアといったインフラ部分の開発が先行し、その上でアプリが開発され、テストされます。単体テスト (UT) 後、ITa の早い段階で基盤にアプリを乗せて基盤環境の連携テスト（フックアップ）を実施し、その後で、ITa, ITb1, ITb2 と進んでいきます。

インフラ開発では、開発環境、テスト環境（準本環境）、本番環境を開発し、そのほか、モニター環境、ライブラリ配布環境、コードレベル管理環境なども開発する必要があります。

オブジェクト指向の考慮点

オブジェクト指向型言語の特性としても従来型テストとは異なる考慮点があります。オブジェクト指向のカプセル化が内部構造を隠蔽するため、従来のように単体テスト時の「単体」の切り分けが困難になっていることです。

継承や集約によって複数のコードがクラスレベルでもオブジェクトレベルでも相関し合い、一つのクラス内のメソッドが修正されると、それが変更するフィールドを通して、関連を持つ全てのコードに副作用の懸念が生まれます。従って、単体テストのフェーズでも、コードのメソッドのホワイトボックス・テストと合わせて、コンポーネント単位の回帰テストをブラックボックス・テストで実施する必要が生まれます。

統合テスト時には、従来型の関係を持つ場合の末端クラスからの統合テストも実施しますが、継承関係があれば、スーパークラスからサブクラスに向かって結合していきます。また、複数のスレッドが連携する場合は、スレッド単位に統合していきます。

テストファースト

オブジェクト指向のアジャイル型開発XPでは、テストファーストを推奨しています。テストファーストでは、開発実施前に設計に応じたテストケースとテストコードを作り込みます。

テストファーストの手法は、幾つかの種類がありますが、多くの場合は、テストケースに従ってテストクラスを作り、それが期待通りに動作するようにクラス／コンポーネントを開発して、テストが通ったコードにリファクタリング／チューニングを施して回帰テストを実施します。

メリットとしてあげられることは、事前にテストケースを作り込むことで設計に検証が加えられる、開発実施時には、テストコードから実行可能な形として外部インタフェースが確定している、テストコードから実行可能なコードとして作成できる、回帰テストを含む単体テストを繰り返すので全体の品質が向上する、後工程にバグを持ち込まないので手戻り負荷が減少するなどです。

また、同じく開発プロセスであるRUPでは、テストのツールの利用を推奨しています。フリーのJUnit, Jakarta Maven, Jakarta Cactusや、商用製品のIBM Rationalツール群など多くのものが利用可能であり、それらが単体テスト、統合テスト、回帰テスト、負荷テスト、テスト・カバレージ管理、構成管理、要求／変更管理などを受け持ちます。

要求品質の向上とプロジェクト期間の短期化、環境の分散化やオープン仕様準拠などにより、テストツールによるテストの自動化は必要不可欠なものになっています。プロジェクトの開発フェーズでの作業負荷は、初期の要件定義／設計段階で作りこまれたバグの除去活動が大半だといわれています。また、上に書いたとおり、本番稼動システムで障害が発生したときの対応に掛かる労力は莫大になります。テストファーストやテストツールによる自動化と言う流れは、それらの自然な帰結です。

戻る