この成果物は、テストの設計仕様を実現し、その実行を可能にするステップ形式の指示書です。
役割: 実装担当者 
オプション性/オカレンス: 開発者テストの対象範囲と詳細度によって異なります。サブシステムのテストに関しては、適切なカバレッジを実現するために必要な分だけの指示書を作成します。比較的小さなコンポーネントの場合、通常は重要な側面だけがテストされます。
テンプレートとレポート:
     
例:
     
UML の表現: なし
詳細情報:  
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

開発者テストの目的は、必要なテストのサブセットの実装を、効率的かつ実効的な形式で提供することです。

概要 ページの先頭へ

各開発者テストでは、以下を含めたさまざまな側面を考慮するようにします。

  • 基本的なコンピューター・ハードウェア要件。プロセッサー、メモリー容量、ハード・ディスク容量、入出力インターフェース・デバイスなど。
  • 動作基盤の基本ソフトウェア環境。オペレーティング・システムや、電子メール、カレンダー・システムなどの基本的な生産性ツールなど。
  • 補足的に仕様化される入出力周辺ハードウェア。バーコード・スキャナー、レシート・プリンター、ATM、センサー・デバイスなど。
  • 特殊な目的の入出力周辺ハードウェアに必要なソフトウェア。ドライバー、インターフェース、ゲートウェイの各ソフトウェアなど。
  • 作業のテスト、評価、診断を実施するために必要なソフトウェア・ツールの最小限のセット。これにはメモリー診断や、テストの自動実行のためのソフトウェアが含まれます。 
  • ハードウェアとソフトウェア両方のオプションの必要な構成設定。ビデオ・ディスプレイ解像度、リソース割り当て、環境変数など。
  • 必要な「既存の」消耗品。データの入ったデータ・セット、レシート・プリンターの明細書など。

プロパティー ページの先頭へ

これらのプロパティーの UML 表現はありません。開発者テストの形式性のレベルは可変であり、以下の情報の一部については、実装から省かれる場合もあれば実装に組み込まれる場合もあります。一般に、テスト対象コンポーネントの規模が大きいほど、また重要度が高いほど、開発者テストの保守に割く必要のある作業量は増えます。

プロパティー名 概要
Name  この開発者テストを識別するために使用される固有の名前。 
Description  開発者テストの簡単な説明。通常は、複雑度または対象範囲を概略レベルで示します。 
Purpose  この開発者テストが何を表すかについての説明と、テストが重要である理由。 
Dependent Test and Evaluation Items  参照する必要のある特定の要素 (個別の要求定義書など) への、何らかの形式の追跡可能性または依存関係マッピング。 
Preconditions  開発者テストの実行の前提条件となる開始状態。 
Instructions  手動でのテストを実行するための手順説明、またはコンピューターが解釈可能な命令の羅列。これらは実行されると、適切なアクター (人間またはその他のもの) によって行われるアクションと同等の作用をソフトウェアに与えます。 
Observation Points  開発者テストの指示書中の 1 つ以上の位置。これは、システム状態の何らかの側面が観測される位置であり、通常は、観測結果と予測される結果との間で比較が行われます。 
Control Points  開発者テストの指示書中の 1 つ以上の位置。これは、システムにおける何らかの条件またはイベントが発生し、次にどの指示に従うべきかの決定に際して考慮される必要がある位置のことです。 
Log Points  開発者テストの指示書中の 1 つ以上の位置。これは、実行中のテスト・スクリプトの状態の何らかの側面が、将来の参照目的で記録される位置のことです。 
Postconditions  開発者テストの実行後にシステムが到達していなければならない最終的な状態。 

 

タイミング ページの先頭へ

開発者テストの大半は、テストされる必要のあるソフトウェア・コンポーネントと同じ時間的枠組みの中で作成されます。変更依頼を発端とするテストは、コンポーネントが開発された後から作成されます。それらのテストの目標が単に、より制御可能な環境内で障害を再発させることである場合、ほとんどのテストは短期間しか使用されません。

責務 ページの先頭へ

この成果物に対する責任を持つのは、主に実装担当者 の役割を担当するユーザーです。具体的には、次の処理について責任を持ちます。

  • 設計仕様に従って、効率的かつ実効的な形式でテストを作成すること
  • 定義済みのガイドラインに従い、テストの保守性とほかのテストとの互換性を確保すること
  • 変更を管理すること
  • 保守する必要があるテストを識別し、目的と使用期間が限定的なテストをクリーンアップまたはマークすること
  • 再利用と簡素化のための機会を識別すること

カスタマイズ ページの先頭へ

全体的な目標は、シンプルで効率的な開発者テストのフレームワークを実装することです。「一回かぎり」のテストについては、ほとんどの文書化作業は回避するほうが適切です。サブシステムや、比較的「変動しやすい」コンポーネントを対象とした回帰テストとして使用されるテストには、文書化、保守容易性、効率性、堅牢性という点から特別な注意を払う必要があります。



Rational Unified Process   2003.06.15