 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||||||
|
||||||||||||||||||||
| 試験内容（テストパターン） | ||||||||||||||||||||
|
図4は、テストシナリオに対する詳細の試験内容を定義したものです。  図4：結合テスト仕様書のテストパターン （画像をクリックすると別ウィンドウに拡大図を表示します） そして、これらのテストパターンを実施した結果を図4の右端の確認欄に記述します。 |
||||||||||||||||||||
| テストデータ | ||||||||||||||||||||
|
図5は、先ほど解説した試験準備でセットしておくべきテストデータの定義フォームです。  図5：結合テスト仕様書のテストデータ （画像をクリックすると別ウィンドウに拡大図を表示します） 規模の大きなシステムでは、マスタデータの全情報を記載するのは大変なので、ここではテストパターンに影響のありそうな項目のみを抜き出して記述しています。 また必要に応じて、テストの中で入力するトランザクションデータも定義しておきます。この例では、受注入力で入力すべきトランザクションデータをパターン化して定義しています。 |
||||||||||||||||||||
| テスト結果データ | ||||||||||||||||||||
|
バッチ処理など、テストデータ（INPUT）とテスト結果データ（OUTPUT）が定義しやすい場合は、テスト結果データも定義します。  図6：テストデータとテスト結果データ |
||||||||||||||||||||
 |
||||||||||||||||||||
|
テスト工数と品質のトレードオフ 一般に、範囲が限定できるモジュールや機能の単体テストは網羅型テストが可能です。しかし、複数の機能を組み合わせた結合テストとなると、条件の組み合せが乗算で膨れあがり、その全パターンを網羅的にテストするのが困難になってきます。 そのときに大切なのがシナリオの設定です。基本的に業務想定にあるシナリオは、すべてのパターンを確認する必要があるのですが、ほかのパターンですでに実証されてテスト内容が重複するような部分は省略します。 同じようなテスト工数と品質のトレードオフは、テスト仕様書の作成においてもいえます。 例えば複雑な業務パターンがいくつもあるケースにおいて、テストデータやテスト結果データをすべて書きだすのは、膨大な工数がかかり現実的ではありません。品質のトレードオフというと「だからソフト業界は」などと目くじらを立てる人がいますが、必要な品質をあきらめるというわけではありません。いたずらに網羅性、綿密性を追求するのではなく、ここまでやれば十分というゴールを定めてテストする姿勢が大切なのです。 |
||||||||||||||||||||
|
||||||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
