履修コース登録システム テスト計画書
バージョン 1.0 改訂履歴
目次 テスト計画書
1. 目標
2. 範囲 このテスト計画は、C- 登録システムのリリース 1 と 2 で行われる統合とシステム・テストに適用されます。アーキテクチャー・プロトタイプのテスト戦略については、別の「テスト計画」 (参考資料 [17]) で説明しています。 単体テストによって、ソース・コードの拡張カバレッジ全体のブラック・ボックス・テストとすべてのモジュール・インターフェースのテストは既に行われているものとします。 このテスト計画は、「開発構想書」 (参考資料 [3])、「ユースケース仕様書」 (参考資料 [5] ~ [12])、および「補足仕様書」 (参考資料 [13]) に定義されている C- 登録システムのすべての要求のテストに適用されます。 3. 参考資料
4. テストに関する要求
次のリストは、テストの対象として指定された項目 (ユースケース、機能要求、
機能外要求) を洗い出したものです。
リストは、テストの内容を示しています。
各テストの詳細は、テスト・ケースの識別と
テスト・スクリプトの開発に伴って後で定義されます。 (メモ: このテスト計画の将来のリリースでは、Rational RequisitePro を使用して、開発構想書、ユースケース文書、補足仕様書の要求に直接リンクする予定です。)
データとデータベースの整合性テスト
コース・カタログ・データベースへのアクセスを検証します。
レコード読み取りの同時アクセスを検証します。
コース・カタログ更新中のロックアウトを検証します。
データベース データの更新の正しい取得を検証します。
システム・テスト (機能に関するテスト)
ログイン・ユースケース (参考資料 [6]) を検証します。
登録終了ユースケース (参考資料 [5]) を検証します。
学生情報の管理ユースケース (参考資料 [10]) を検証します。
教授情報の管理ユースケース (参考資料 [7]) を検証します。
成績表の提出ユースケース (参考資料 [11]) を検証します。
成績表の表示ユースケース (参考資料 [12]) を検証します。
コース登録ユースケース (参考資料 [8]) を検証します。
担当講座の選択ユースケース (参考資料 [9]) を検証します。
「補足仕様書」のセクション 4.1 を参照: すべてのシステム・エラーは記録されること。
致命的なシステム・エラーが発生した場合、通常と同じ方法でシステムがシャットダウンされること。 「補足仕様書」のセクション 4.1 を参照: システム・エラー・メッセージには、エラーのテキスト説明、
オペレーティング・システムのエラー・コード (該当する場合)、エラー状態を検出したモジュール、
日付スタンプ、タイム・スタンプを含めること。
すべてのシステム・エラーは、エラー・ログ・データベースに保存されること。 「開発構想書」のセクション 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 メインフレームで稼働する既存のコース費用請求システムと統合されること。 ビジネス・サイクルのテスト
ユーザー・インターフェースのテスト
パフォーマンス・テスト
負荷テスト
ストレス・テスト
ボリューム・テスト
セキュリティーとアクセス・コントロールのテスト
フェイルオーバー/回復のテスト
構成テスト
インストール・テスト
5. テスト戦略 テスト戦略は、ソフトウェア・アプリケーションのテストに対する推奨アプローチを表します。 前のセクション「テスト要求」では何が テストされるかを説明しましたが、 ここでは、どのように テストされるかを説明します。 テスト戦略の主な検討事項は、使用する技術と、テスト完了を判断する基準です。 次に示す各テストの検討事項に加えて、テストは、安全な環境で、制御された既知のデータベースでのみ実行する必要があります。 次のテスト戦略は一般的なもので、本書のセクション 4 でリストアップした要求に適用されます。
6. リソース
テスト作業とマイルストーンは開発反復に大きく依存しています。 作成フェーズは 3 つの反復に分けられます。各反復には、テスト計画、設計、 開発、実行、評価の完全なテスト・サイクルが含まれます。 マスター・スケジュール、開発反復を示す作成フェーズの計画については、「ソフトウェア開発計画書」 (参考資料 [14]) と反復計画書を参照してください。 次の表は、テストのマイルストーンを示しています。 作業、開始日、終了日は、反復内容の計画に伴って決定されます。
このテスト計画で定義されたテスト・タスクのワーク・プロダクトの概要を、次の表に示します。 これらのワーク・プロダクトのいくつかは、テスト・サイクル または反復のたびに 1 度作成され、合計で複数回作成されます。 テスト計画など、その他のワーク・プロダクトは、開発反復のたびに更新されます。
テスト・セットでは、すべてのテスト・ケースと、各テスト・ケースに関連するテスト・スクリプトを定義します。
9. プロジェクトのタスク
|
|