履修コース登録システム

アーキテクチャー・プロトタイプのテスト計画書

バージョン 1.0

 

改訂履歴

日付 バージョン 説明 作成者
1999 年 3 月 7 日 1.0 初期リリース - プロトタイプ・テスト計画 K. ストーン
 
 
 
 
 
 
 
 
 
 
 
 

 

 

目次

  1. 目標
  2. テストに関する要求
  3. テスト戦略
  4. リソース
  5. プロジェクトのマイルストーン
  6. ワーク・プロダクト
  7. プロジェクトのタスク

 

アーキテクチャー・プロトタイプ

テスト計画書

1. 目標

1.1 目的

本書では、C- 登録システムのアーキテクチャー・プロトタイプのテストに関する 計画について説明します。このテスト計画書は、次の目標をサポートします。

1.2 範囲

このテスト計画では、「Integration Build Plan for the Prototype」 (参考資料 [16]) で識別されるサブシステムとコンポーネントの統合に続いて、アーキテクチャー・プロトタイプで行われる統合とシステム・テストについて説明します。

ブラック・ボックス・テスト、ソース・コードの拡張カバレッジ、すべてのモジュール・インターフェースのテストによって、単体テストは既に行われているものとします。

アーキテクチャー・プロトタイプを組み立てる目的は、 選択したアーキテクチャーの実現可能性と性能をテストすることでした。 すべてのシステムとサブシステムのインターフェース、 そしてシステムの性能もこの初期の段階でテストすることは重要です。 システムの機能のテストは、プロトタイプでは行いません。

次のサブシステム間のインターフェースをテストします。

    1. 履修コース登録
    2. 財務システム
    3. コース・カタログ

次のデバイスとの外部インターフェースをテストします。

    1. ローカル・コンピューター
    2. リモート・コンピューター

テスト対象の最も重要な性能測定は、次のとおりです。

    1. 履修コース登録システムに対するリモート・ログインの応答時間
    2. 財務システムへのアクセスの応答時間
    3. コース・カタログ・サブシステムへのアクセスの応答時間
    4. 200 名の学生のログインによる負荷がシステムにかかった状態での、学生の応答時間
    5. コース・カタログ・データベースに 50 名が同時にアクセスした場合の学生の応答時間
1.3 参考資料

該当する参考資料は次のとおりです。

    1. 「Course Billing Interface Specification, WC93332」 1985 年、Wylie College Press
    2. 「コース・カタログ・データベース 仕様書、WC93422」 1985 年、Wylie College Press
    3. 「履修コース登録システム 開発構想書 WyIT387、バージョン 1.0」 1998 年、Wylie College IT
    4. 「履修コース登録システム 用語集 WyIT406、バージョン 2.0」 1999 年、Wylie College IT
    5. 「履修コース登録システム ユースケース仕様書 - 登録の終了、WyIT403、バージョン 2.0」 1999 年、Wylie College IT
    6. 「履修コース登録システム ユースケース仕様書 - ログイン、WyIT401、バージョン 2.0」 1999 年、Wylie College IT
    7. 「履修コース登録システム ユースケース仕様書 - 教授情報の管理、WyIT407、バージョン 2.0」 1999 年、Wylie College IT
    8. 「履修コース登録システム ユースケース仕様書 - コース登録、WyIT402、バージョン 2.0」 1999 年、Wylie College IT
    9. 「履修コース登録システム ユースケース仕様書 - 担当講座の選択、WyIT405、バージョン 2.0」 1999 年、Wylie College IT
    10. 「履修コース登録システム ユースケース仕様書 - 学生情報の管理、WyIT408、バージョン 2.0」 1999 年、Wylie College IT
    11. 「履修コース登録システム ユースケース仕様書 - 成績表の提出、WyIT409、バージョン 2.0」 1999 年、Wylie College IT
    12. 「履修コース登録システム ユースケース仕様書 - 成績表の表示、WyIT410、バージョン 2.0」 1999 年、Wylie College IT
    13. 「履修コース登録システム ソフトウェア開発計画書 WyIT418、バージョン 1.0」 1999 年、Wylie College IT
    14. 「履修コース登録システム 反復計画書、推敲反復 #E1 WyIT420、バージョン 1.0」 1999 年、Wylie College IT
    15. 「履修コース登録システム ソフトウェア・アーキテクチャー説明書 WyIT431、バージョン 1.0」 1999 年、Wylie College IT
    16. 「履修コース登録システム アーキテクチャー・プロトタイプの統合ビルド計画書 WyIT430、バージョン 1.0」 1999 年、Wylie College IT
    17. 「履修コース登録システム Requirements Attributes Guidelines WyIT404、バージョン 1.0」 1999 年、Wylie College IT
2.    テストに関する要求 

    次のリストは、テストの対象として指定された項目 (ユースケース、機能要求、 機能外要求) を洗い出したものです。 リストはテストの内容 を示しています。

    (メモ: このテスト計画の将来のリリースでは、Rational RequisitePro を使用してユースケース文書と補足仕様書の要求に直接リンクする予定です。)

    2.1 データとデータベースの整合性テスト

    コース・カタログ・データベースへのアクセスを検証します。

    レコード読み取りの同時アクセスを検証します。

    コース・カタログ更新中のロックアウトを検証します。

    データベース データの更新の正しい取得を検証します。

    2.2. 機能テスト

    「開発構想書」のセクション 12.2 を参照: システムは、既存のコース・カタログ・データベース・システムとインターフェースすること。C- 登録は、参考資料 [2] に定義されたデータ・フォーマットをサポートすること。

    「開発構想書」のセクション 12.2 を参照: システムは、既存の請求システムとインターフェースし、参考資料 [1] に定義されたデータ・フォーマットをサポートすること。

    「開発構想書」のセクション 12.2 を参照: システムのサーバー・コンポーネントは、カレッジのキャンパス・サーバーで稼働し、UNIX オペレーティング・システムで実行されること。

    「補足仕様書」のセクション 9.3 を参照: システムのサーバー・コンポーネントは、Wylie カレッジの UNIX サーバーで稼働すること。

    「開発構想書」のセクション 12.2 を参照: システムのクライアント・コンポーネントは、486 以上のマイクロプロセッサーを持つどのパーソナル・コンピューターでも稼働すること。

    「補足仕様書」のセクション 9.3 を参照: システムのクライアント・コンポーネントは、 486 以上のマイクロプロセッサーを持つどのパーソナル・コンピューターでも稼働すること。

    「補足仕様書」のセクション 9.1 を参照: システムは、カレッジの DEC VAX メインフレームで稼働する既存のレガシー・システム (コース・カタログ・データベース) と統合されること。

    「補足仕様書」のセクション 9.2 を参照: システムは、カレッジの DEC VAX メインフレームで稼働する既存のコース費用請求システムと統合されること。

    2.3 ビジネス・サイクルのテスト

    なし

    2.4 ユーザー・インターフェースのテスト

    画面のサンプル・セットを通じて、ナビゲーションのしやすさを検証します。

    サンプル画面が GUI 標準に適合していることを検証します。

    「開発構想書」のセクション 10 を参照: システムは使いやすく、通常のコンピューター操作ができる学生と教授を対象とする目標市場に適切であること。

    「開発構想書」のセクション 12.1 を参照: デスクトップのユーザー・インターフェースは、Windows 95/98 に準拠すること。

    「補足仕様書」のセクション 5.1 を参照: デスクトップのユーザー・インターフェースは、Windows 95/98 に準拠すること。

    「補足仕様書」のセクション 5.2 を参照: C- 登録システムのユーザー・インターフェースは、 使いやすく、通常のコンピューター操作ができるユーザーがシステムに関して追加のトレーニングをしないで使用できるよう設計されていること。

    2.5 パフォーマンス・テスト

    外部の財務システムへのアクセスの応答時間を検証します。

    外部のコース・カタログ・サブシステムへのアクセスの応答時間を検証します。

    リモート・ログインの応答時間を検証します。

    履修コース登録のリモート提出の応答時間を検証します。

    「開発構想書」のセクション 12.3 を参照: システムは、 10 秒以内の待ち時間で従来のコース・カタログ・データベースへのアクセスを提供すること。

    「補足仕様書」のセクション 7.2 を参照: システムは、 10 秒以内の待ち時間で従来のコース・カタログ・データベースへのアクセスを提供すること。

    2.6 負荷テスト

    200 名の学生のログインによる負荷がかかった状態で、システムの反応を検証します。

    50 名の学生がコース・カタログに同時にアクセスした際のシステムの反応を検証します。

    2.7 ストレス・テスト

    なし

    2.8 ボリューム・テスト

    なし

    2.9 セキュリティーとアクセス・コントロールのテスト

    ローカル・コンピューターからのログオンを検証します。

    リモート・コンピューターからのログオンを検証します。

    ユーザー名とパスワードのメカニズムを使用したログオン・セキュリティーを検証します。

    2.10 フェイルオーバー/回復のテスト

    なし

    2.11 構成テスト

    「開発構想書」のセクション 12.2 を参照: システムのクライアント・コンポーネントは、Windows 95、Windows 98、Microsoft Windows NT のすべてで稼働すること。

    「補足仕様書」のセクション 9.4 を参照: C- 登録システムの Web ベースのインターフェースは、Netscape 4.0.4 と Internet Explorer 4.0 のブラウザーで稼働すること。

    「補足仕様書」のセクション 9.5 を参照: Web ベースのインターフェースは、Java 1.1 VM ランタイム環境と互換性があること。

    2.12 インストール・テスト

    なし

3.    テスト戦略

    テスト戦略は、ソフトウェア・アプリケーションのテストに対する推奨アプローチを表します。 前のセクション「テスト要求」では何が テストされるかを説明しましたが、 ここでは、どのように テストされるかを説明します。

    テスト戦略の主な検討事項は、使用する技術と、テスト完了を判断する基準です。

    次に示す各テストの検討事項に加えて、テストは、安全な環境で、制御された既知のデータベースでのみ実行する必要があります。

    次のテスト戦略は一般的なもので、本書のセクション 4 でリストアップした要求に適用されます。

3.1 テスト・タイプ

3.1.1 データと データベースの整合性テスト

データベースとデータベース・プロセスは、別のシステムとして テストする必要があります。これらのシステムは、(データへの インターフェースとしての) アプリケーションなしでテストする必要があります。 次に説明するテストをサポートするために、DBMS への追加調査を行って、 存在するツール/技術を識別する必要があります。

 

テストの目標 データベースのアクセス・メソッドおよびプロセスが正しく機能し、データの破損がないことを確認する。
技法
  • 有効データおよび無効データ (またはデータ要求) でデータベースのアクセス・メソッドとプロセスをそれぞれシードして呼び出す。
  • データベースを検査し、データが意図したとおりに組み込まれ、すべてのデータベース・イベントが適切に発生していることを確認する。または、戻されたデータをレビューし、(適切な理由により) 正確なデータが取り出されたことを確認する。
完了基準 すべてのデータベースのアクセス・メソッドおよびプロセスが設計通りに機能し、データの破損がないこと。
特に注意すべき点:
  • テストには、データベースでデータを直接入力や修正するために、DBMS 開発環境やドライバーが必要な場合があります。
  • プロセスは、手動で起動しなければなりません
  • 小さいサイズの (レコード数を制限した) データベースを使用し、受け入れられないイベントの可視性を向上させる。

 

 

3.1.2 機能テスト

アプリケーションのテストは、 ユースケース (またはビジネス機能) とビジネス・ルールに 直接さかのぼることのできる要求を対象とする必要があります。 これらのテストの目的は、適切なデータの受容、処理、取得、 ビジネス・ルールの適切な実装を検証することです。 このタイプのテストは、ブラック・ボックス技術に基づいています。 つまり、GUI を通じてアプリケーションとやり取りすることによって、 アプリケーションと内部プロセスを検証し、アウトプット (結果) を分析します。 次に示すのは、各アプリケーションに推奨するテストの概要です。

 

テストの目標 アプリケーションのナビゲーション、データ・エントリー、処理、取得が適切であることを確認します。
技法
  • 有効データと無効データを使用して、各ユースケース、ユースケース・フロー、機能を実行し、次の点について検証する。
  • 有効データを使用したときに予想された結果が得られたかどうか
  • 無効なデータを使用した場合は、該当のエラー/警告メッセージが表示される。
  • 各ビジネス・ルールが適切に適用されたかどうか
完了基準
  • 計画したすべてのテストを実行済みであること。
  • 特定されたすべての障害が対処済みであること。
特に注意すべき点:
  • Wylie カレッジの UNIX サーバー、既存のコース・カタログ・システム、請求システムへのアクセスには、識別されたシステム・テストをプロトタイプでいくつか実行する必要があります。
 

3.1.3 ビジネス・サイクルのテスト

このセクションは、アーキテクチャー・プロトタイプのテストには該当しません。

3.1.4 ユーザー・インターフェースのテスト

ユーザー・インターフェースのテストでは、 ユーザーとソフトウェアの相互作用を検証します。 UI テストの目的は、ユーザー・インターフェースが、アプリケーションの機能を通じてユーザーに適切なアクセスとナビゲーションの提供を確認することです。また、UI テストによって、UI 内のオブジェクトが予想どおりに機能し、社内標準または業界標準に適合していることを確認します。

 

テストの目標 次の点について検証する。
  • ウィンドウからウィンドウ、フィールドからフィールド、アクセス方法 (タブ・キー、マウスの動作、アクセラレーター・キー) の使用を含め、アプリケーションを通じたナビゲーションが、ビジネス機能と要求を適切に反映していること。
  • メニュー、サイズ、位置、状態、フォーカスなどのウィンドウのオブジェクトと特性が、標準に適合していること。
技法
  • 各ウィンドウのテストを作成または修正して、各アプリケーションのウィンドウとオブジェクトに対してナビゲーションとオブジェクトの状態が適切であることを検証します。
完了基準 各ウィンドウが、ベンチマーク・バージョンと矛盾がなく、許容できる基準の範囲内であることを検証済みであること。
特に注意すべき点:
  • カスタム・オブジェクトやサード・パーティー・オブジェクトの、すべてのプロパティーにアクセスできるわけではありません。
 

3.1.5 性能の分析

パフォーマンス・テストでは、応答時間、トランザクション速度、その他の時間に関する要求を測定します。 パフォーマンス・テストの目的は、性能要求が達成されたことを検証することです。 パフォーマンス・テストは通常、何回か行われ、そのたびに異なる「バックグラウンド負荷」をシステムに使用します。最初のテストは、 対象のシステムで実行済みの (または予定している) 通常の負荷と同様に、「公称」負荷で行います。2 回目のパフォーマンス・テストは、ピーク負荷を使用して実行します。

さらに、パフォーマンス・テストを使用して、システムの性能を作業負荷やハードウェア構成などの条件による機能として分析し調整することができます。

メモ: 以下のトランザクションは、「論理ビジネス・トランザクション」を指しています。 これらのトランザクションは、システムのユーザーがアプリケーションを使用して行うと思われる特定の機能として定義されます。 例えば、契約の追加や修正などです。

 

テストの目標 指定されたトランザクションまたはビジネス機能に対するシステムの応答時間を、以下の 2 つの条件で評価します。

- 通常予測されるボリューム

- 予想される悪い状態でのボリューム

技法
  • ビジネス・モデル・テスト (システム・テスト) 用に開発されたテスト・スクリプトを使用します。
  • データ・ファイルを修正する (トランザクションの数を増やす) か、スクリプトを修正して各トランザクションが発生する反復の数を増やします。
  • スクリプトは 1 台のコンピューターで実行し (ベンチマークの最良のケースは、単一ユーザー、単一トランザクション)、 複数のクライアントで繰り返す必要があります (仮想的に、または実際に。下の「特に注意すべき点」を参照)。
完了基準
  • 単一トランザクション/単一ユーザー: テスト・スクリプトが、(トランザクション当たりの) 予測/必要割り当て時間内に障害なく完了した。
  • 複数トランザクション/複数ユーザー: テスト・スクリプトが、受容できる割り当て時間内に障害なく完了した。
特に注意すべき点:
  • 包括的なパフォーマンス・テストには、サーバーの「バックグラウンド」の負荷を考慮することも含む。次のものを含む複数のメソッドが、この実行に使用されます。
    • 通常 SQL コールの形式で、直接サーバーへ「トランザクションをドライブ」する。
    • 「仮想の」ユーザー負荷を作成して、多数のクライアント (通常は数百) をシミュレートします。 リモート端末エミュレーション・ツールを使用してこの負荷をかけます。 この技術は、ネットワークに「トラフィック」の負荷をかけるのにも使用できます。
    • 複数の実際のクライアントを使用して、それぞれテスト・スクリプトを実行し、システムに負荷を掛ける。
  • パフォーマンス・テストは、テスト専用のコンピューター上で、 またはテスト専用の時間帯に実行しなければなりません。 これにより、測定を完全に制御し、正確に実行することができます。
  • パフォーマンス・テストに使用するデータベースは、実際のサイズまたは均等に拡大したものとする。

 

3.1.6 負荷テスト

負荷テストでは、テスト対象のシステムに変化する作業負荷をかけて測定し、異なる作業負荷の下で適切に機能し続けるシステムの能力を評価します。 負荷テストの目的は、予測された最大作業負荷を超えてもシステムが適切に機能することを確認することです。 また、負荷テストでは、性能特性 (応答時間、トランザクション速度、およびその他の時間関連の問題) を評価します。

メモ: 以下のトランザクションは、「論理ビジネス・トランザクション」を指しています。 これらのトランザクションは、システムのユーザーがアプリケーションを使用して行うと思われる特定の機能として定義されます。 例えば、契約の追加や修正などです。

 

テストの目標 変化する作業負荷の条件下での、指定されたトランザクションまたはビジネス・ケースに対するシステムの応答時間を検証します。
技法
  • ビジネス・サイクル・テスト用に開発されたテストを使用します。
  • データ・ファイルを修正してトランザクションの数を増やすか、テストを修正して各トランザクションが発生する回数を増やす。
完了基準
  • 複数トランザクション/複数ユーザー: 受容できる割り当て時間内に障害なくテストが完了した。
特に注意すべき点:
  • 負荷テストは、テスト専用のコンピューター上、 またはテスト専用の時間帯に実行しなければなりません。 これにより、測定を完全に制御し、正確に実行することができます。
  • 負荷テストに使用するデータベースは、実際のサイズまたは均等に拡大したものとする。
 

3.1.7 ストレス・テスト

このセクションは、アーキテクチャー・プロトタイプのテストには該当しません。

3.1.8 ボリューム・テスト

このセクションは、アーキテクチャー・プロトタイプのテストには該当しません。

3.1.9 セキュリティーとアクセス・コントロールのテスト

セキュリティーとアクセス・コントロールのテストは、セキュリティーの 2 つの主要な領域を対象としています。

アプリケーションのセキュリティー。データやビジネス機能へのアクセスを含みます。
システム・セキュリティー: システムへのリモート・アクセスを含みます。

アプリケーション・セキュリティーにより、セキュリティーのレベルに基づいて、ユーザーが使用できる機能またはデータが制限されます。 例えば、データの入力や新しいアカウントの作成は誰でもできるが、 それを削除できるのは管理者に限られる場合があります。 データ・レベルのセキュリティーがある場合、例えば、「タイプ」 1 のユーザーは財政データを含むすべての顧客情報を見ることができるが、 「タイプ」 2 のユーザーは同じクライアントの統計データしか見られない、ということをテストによって確認できます。

システム・セキュリティーによって、システムへのアクセスが認められたユーザーだけが、適切なゲートウェイを通じてアプリケーションにアクセスできます。

 

テストの目標 機能/データ・セキュリティー: ユーザーが、自分のユーザー・タイプに与えられた権限内の機能やデータにのみ、アクセスできることを検証します。

システム・セキュリティー: システムとアプリケーションへのアクセス権を持つユーザーのみが、それらにアクセスできることを検証します。

技法
  • 機能/データ・セキュリティー: 各ユーザー・タイプと、各タイプが権限を持っている機能やデータを識別し、リストアップします。
  • 各ユーザー・タイプに対してテストを作成し、各ユーザー・タイプに固有のトランザクションを作成して権限を検証します。
  • 同じユーザーに対して、ユーザー・タイプを変更してテストを再度実行します。 各ケースで、その他の機能やデータが適切に使用できるか、 あるいは適切に拒否されることを検証します。
  • システム・アクセス (下の「特に注意すべき点」を参照)
完了基準 既知の各ユーザー・タイプに対して適切な機能やデータが使用可能になり、前述のアプリケーション機能テストですべてのトランザクションが予測どおりに機能し、実行される。
特に注意すべき点:
  • システムへのアクセス権については、該当のネットワーク管理者 またはシステム管理者と検討、協議する必要があります。 このテストは、ネットワーク管理またはシステム管理用の機能であるため、 必要でない場合があります。
 

3.1.10 フェイルオーバーと回復のテスト

このセクションは、アーキテクチャー・プロトタイプのテストには該当しません。

3.1.11 構成テスト

構成テストでは、異なるソフトウェアとハードウェアの構成で ソフトウェアの操作を検証します。ほとんどの稼働環境では、 クライアント・ワークステーション、ネットワーク接続、 データベース・サーバーに対するハードウェアの仕様は異なります。 クライアント・ワークステーションには、 さまざまなソフトウェア (アプリケーション、ドライバーなど) がロードされています。 アクティブになっているソフトウェアの組み合わせも、使用しているリソースも、 そのときによってさまざまです。

 

テストの目標 規定のクライアント・ワークステーションでクライアント・アプリケーションが正しく機能することを検証します。
技法
  • 統合テストとシステム・テストのスクリプトを使用します。
  • テスト中に、あるいはテストの開始前に、さまざまなコンピューター・アプリケーションを開いて閉じます。
  • 選択したトランザクションを実行して、さまざまなコンピューター・アプリケーションに対するユーザー・アクティビティーをシミュレートします。
  • クライアントの利用可能な基本メモリーを最小化して、上のプロセスを繰り返す。
完了基準 プロトタイプとコンピューター・アプリケーションの各組み合わせに対して、トランザクションが障害なく完了した。
特に注意すべき点:
  • クライアントではどんなコンピューター・アプリケーションが使用可能、アクセス可能か。
  • どのアプリケーションが通常使用されるか。
  • アプリケーションではどんなデータを実行するのか (Excel での大規模なスプレッドシート、Word での 100 ページのドキュメントなど)。
  • システム全体、ネットワーク・サーバー、データベースなどもこのテストの一環として文書化する必要があります。

 

3.1.12 インストール・テスト

このセクションは、C- 登録アーキテクチャー・プロトタイプのテストには該当しません。

3.2 ツール

アーキテクチャー・プロトタイプのテストには、次のツールを使用します。

  ツール バージョン
テスト管理 Rational RequisitePro

Rational Unified Process

TBD (未定)
テスト設計 Rational Rose TBD (未定)
障害追跡 Rational ClearQuest TBD (未定)
機能テスト Rational Robot TBD (未定)
パフォーマンス・テスト Rational Visual Quantify TBD (未定)
テスト・カバレッジの監視、分析 Rational Visual PureCoverage TBD (未定)
その他のテスト・ツール Rational Purify

Rational TestFactory

TBD (未定)
プロジェクト管理 Microsoft Project

Microsoft Word

Microsoft Excel

TBD (未定)
DBMS ツール TBD (未定) TBD (未定)
 

4.    リソース

    このセクションでは、C- 登録アーキテクチャー・プロトタイプのテストに推奨するリソース、 その主要な責務、その知識やスキルのセットを示します。

4.1 ロール

この表は、プロトタイプのテストの予定要員を示します。

 

人材

ロール 推奨する最小限の要員

(フルタイムで割り当てられるワーカーの数)

特定の責務/コメント
テスト管理者 1 - ケリー ストーン 管理監督を行う。

責務

  • 技術的な指示
  • 適切な要員の確保
  • 管理レポート
テスト設計者 マーガレット コックス

キャロル・スミス

テスト・ケースの識別、優先順位付け、および実装を行う。

責務

  • テスト計画作成
  • テスト・セットの作成
  • テスト作業の有効性の評価
システム・テスト担当者 キャロル・スミス テストを実行する。

責務

  • テストの実行
  • 結果の記録
  • エラーからの回復
  • 障害の文書化
テスト・システム管理者 サイモン・ジョーンズ テスト環境とアセットが管理および保守されていることを確認する。

責務

  • テスト管理システムの管理
  • テスト・システムへのワーカー・アクセスのインストールと管理
データベース管理/データベース管理者 マーガレット コックス テスト・データ (データベース) 環境とアセットが管理および保守されていることを確認する。

責務

  • テスト・データ (データベース) の管理
設計者 マーガレット コックス テスト・クラスの操作、属性、および関連を識別して定義する。

責務

  • テスト・クラスの識別と定義
  • テスト・パッケージの識別と定義
実装担当者 マーガレット コックス テスト・クラスとテスト・パッケージを実装し、単体テストを実施する。

責務

  • テスト・セットに実装するテスト・クラスとテスト・パッケージの作成
 

4.2 システム

次の表では、C- 登録プロトタイプのテストに対するシステム・リソースを明らかにします。

システム・リソース

リソース 名前/タイプ/シリアル番号
Wylie カレッジ・サーバー シリアル番号: X179773562b
  コース・カタログ・データベース バージョン ID: CCDB-080885
  請求システム バージョン ID: BSSS-88335
クライアント・テスト・コンピューター
 
  リモート・コンピューター 3 台 (インターネット・アクセスあり) シリアル番号: A8339223

シリアル番号: B9334022

シリアル番号: B9332544

  ローカル・コンピューター 3 台 (LAN 経由で接続) シリアル番号: R3322411 (登録者用)

シリアル番号: A8832234 (IT 研究室)

シリアル番号: W4592233 (IT 研究室)

テスト・リポジトリー
 
  Wylie カレッジ・サーバー シリアル番号: X179773562b
テスト開発用コンピューター 6 台 シリアル番号: A8888222

シリアル番号: R3322435

シリアル番号: I88323423

シリアル番号: B0980988

シリアル番号: R3333223

シリアル番号: Y7289732

 

 

 5.    プロジェクトのマイルストーン

    C- 登録アーキテクチャー・プロトタイプのテストには、 前のセクションで説明した各テスト作業に対するテスト・タスクが組み込まれます。 個別のプロジェクト・マイルストーンは、 プロジェクトのステータスと達成度を伝えるために識別されます。

    全体的なフェーズやマスター・プロジェクト・スケジュールについては、「ソフトウェア開発計画書」 (参考資料 [13]) と「反復計画書 #E1」 (参考資料 [14]) を参照してください。

    マイルストーン・タスク 作業量 (pd) 開始日 終了日
    プロトタイプ・テスト計画 2 3 月 12 日 3 月 15 日
    プロトタイプ・テスト設計 3 3 月 15 日 3 月 18 日
    プロトタイプ・テスト開発 4 3 月 19 日 3 月 23 日
    プロトタイプ・テスト実行 3 3 月 24 日 3 月 26 日
    プロトタイプ・テスト評価 1 3 月 29 日 3 月 29 日

     

6.    ワーク・プロダクト

    このテスト計画で定義されたテスト・タスクのワーク・プロダクトの概要を、次の表に示します。

    ワーク・プロダクト 所有者 レビュー/配布 期日
    テスト計画書 K. ストーン シニア・プロジェクト管理チーム 3 月 15 日
    テスト環境 S. ジョーンズ - 3 月 18 日
    テスト・セット C. スミス と M. コックス 内部ピアのレビュー 3 月 23 日
    テスト・データ・セット M. コックス 内部ピアのレビュー 3 月 23 日
    テスト・スクリプト M. コックス - 3 月 23 日
    テスト・スタブ、ドライバー M. コックス - 3 月 23 日
    テスト障害レポート C. スミス シニア・プロジェクト管理チーム 3 月 26 日
    テスト結果 C. スミス - 3 月 26 日
    テスト評価レポート C. スミス シニア・プロジェクト管理チーム 3 月 29 日

6.1 テスト・セット

テスト・セットでは、すべてのテスト・ケースと、各テスト・ケースに関連するテスト・スクリプトを定義します。

6.2 テスト・ログ

RequisitePro を使用してテスト・ケースを識別し、 各テスト・ケースのステータスを追跡することが計画されています。 テスト結果は、RequisitePro で、テストなし、 合格、条件付き合格、不合格に分けられます。 大まかに言って、RequisitePro は、「Requirements Attributes Guidelines 」 (参考資料 [17]) で定義されたとおり、 各テスト・ケースの次の属性をサポートするために設定されます。

RequisitePro のテスト・ステータスを更新するのは、システム・テスト担当者の責務です。

テスト結果は、構成管理の下で保持されます。

6.3 障害レポート

個別の障害の記録と追跡には、Rational ClearQuest が使用されます。

7.    プロジェクトのタスク

次に説明するのは、C- 登録アーキテクチャー・プロトタイプをテストする際の、テスト関連のタスクです。

テスト計画

テストに関する要求の識別

リスク評価

テスト戦略の作成

テスト要員の特定

スケジュール作成

テスト計画作成

テストの設計

作業負荷の分析 (プロトタイプには該当しない)

テスト・セットの開発

テスト・ケースの識別と記述

テスト・スクリプトの識別と構成

テスト・カバレッジのレビューと評価 

テストの実装

テスト環境の設定

テスト・スクリプトの記録またはプログラミング

テスト・スタブとドライバーの開発

設計と実装モデルにおけるテスト固有の機能の識別

外部データ・セットの確立

テストの実行

テスト・スクリプトの実行

テストの実行評価

停止したテストからの復旧

結果の検証

予期せぬ結果の調査

障害の記録

テストの評価

テスト・ケース・カバレッジの評価

コード・カバレッジの評価

障害の分析

テスト完了基準と成功基準が達成されたかどうかの判断
テスト評価レポートの作成

Copyright  (c) IBM Corp. 1987, 2004. All Rights Reserved.

履修コース登録プロジェクト Web Example
バージョン 2001.03