目的
  • 物理的な実行を通じて、個々のソフトウェア コンポーネントの検証を可能にするテストを実装する
  • 大規模なテスト環境の一部として、その他のテストと併せて実行できるテストを開発する
ステップ
入力とする成果物: 結果となる成果物:
頻度: 通常、実装要素を開発する作業ごとに 1 回
役割: 実装担当者
ツール メンター:
More Information: 

ワークフローの詳細:

範囲の洗練とテストの識別 ページの先頭へ

目的: テスト対象のコンポーネントを識別し、現在の反復で最も効果的な一連のテストを定義する

正式な環境では、開発する必要のあるコンポーネントとテストをテスト設計成果物で指定し、このステップをオプションにします。また、変更依頼、バグ修正、検証の必要な実装決定、設計モデルだけを入力として使用するサブシステムのテストが目的で開発者テストを行う場合もあります。これらの各ケースについて、以下の作業が必要です。

  • 目標の定義: サブシステム / コンポーネントのインターフェイスの検証、検証の実装、障害の再現
  • 範囲の定義: サブシステム、コンポーネント、コンポーネント グループ
  • テストの種類と詳細の定義: ブラック ボックス、ホワイト ボックス、事前条件、事後条件、不変条件、入力 / 出力と実行の条件、観測ポイント / 制御ポイント、クリーンアップ アクション
  • テストの寿命の決定: たとえば、障害修正に特化して作成されたテストは使い捨てになるかもしれませんが、外部インターフェイスをチェックするテストは、テスト対象のコンポーネントと同じライフサイクルを持ちます。

適切な実装手法の選択 ページの先頭へ

目的: テストを実装するための適切な手法を決定する

テストを実装するにはさまざまな手法を利用できますが、手動テストと自動テストの 2 つの一般的なカテゴリの観点から検討できます。ほとんどの開発者テストは、以下の自動化されたテスト手法を使用して実装されます。

  • テストのプログラム化: テスト対象のコンポーネントと同じソフトウェア プログラミングの手法と環境を使用するか、より単純なプログラミング言語とツール (tcl やシェル ベースのスクリプト言語など) を使用します。
  • テストの記録または取得: テスト対象のコンポーネントとシステムのその他の部分との間の相互作用を取得し、基本テストを生成するテスト自動化ツールを使用して作成します。
  • テストの生成: テストの一部の局面、つまりプロシージャやテストのデータは、より複雑なテスト自動化ツールを使用して自動的に生成できます。
GUI 関連のテストなどの場合に最も一般的な手法は「テストのプログラム化」ですが、より効率的にテストを実施する方法は手動で行うことです。手動によるテストでは、テキストで記述された一連の指示に従います。

テストの実装 ページの先頭へ

目的: 定義ステップ / 作業で識別したテストを実装する

最初のステップで定義したすべての要素を実装します。テスト環境の事前条件と、テスト対象のコンポーネントをテストできる状態にするためのステップを詳細化し、明確に指定します。環境を元の状態に戻すためのクリーンアップのステップを確認します。観測ポイント / 制御ポイントの実装に特に注意を払います。これらの局面は、テスト対象のコンポーネントで実装する必要のある特別なサポートが必要になる場合があります。

外部データ セットの確立 ページの先頭へ

目的: テストの外部に格納され、テスト実行中にテストによって使用されるデータを作成、維持する

多くの場合、テスト データをテストから分離することは、データを維持しやすくするための解決法です。テストの寿命が非常に短い場合は、データをテスト内に含めてハードコード化することがより効率的かもしれませんが、異なるデータ セットを使用する数多くのテスト実行サイクルが必要な場合、最も簡単な方法はデータを外部に格納することです。テスト データをテストから分離することには、以下の利点もあります。

  • 複数のテストで同じデータ セットを使用できる。
  • 変更や複製が簡単。
  • テスト内の条件分岐ロジックを制御するのに使用できる。

テスト実装の検証 ページの先頭へ

目的: テストの正しい動作を検証する

テストをテストします。環境のセットアップとクリーンアップの手順をチェックします。テストを実行し、その動作を観察し、障害を修正します。寿命の長いテストの場合は、内部知識の少ない人にテストの実行を依頼し、十分なサポート情報が備わっているかどうかをチェックします。開発チーム内のその他のメンバーや、その他の関係者と一緒にテストをレビューします。

追跡可能性関係の維持 ページの先頭へ

目的: 追跡アイテムに対して実行する影響分析と評価レポートを有効にする

実装される形式性の度合いによって異なります。


Rational Unified Process   2003.06.15