履修コース登録システム
アーキテクチャー・プロトタイプのテスト計画書
バージョン 1.0
改訂履歴
日付 | バージョン | 説明 | 作成者 |
---|---|---|---|
1999 年 3 月 7 日 | 1.0 | 初期リリース - プロトタイプ・テスト計画 | K. ストーン |
|
|
|
|
|
|
|
|
|
|
|
|
目次
アーキテクチャー・プロトタイプ
の
テスト計画書
1. 目標
1.1 目的
本書では、C- 登録システムのアーキテクチャー・プロトタイプのテストに関する 計画について説明します。このテスト計画書は、次の目標をサポートします。
このテスト計画では、「Integration Build Plan for the Prototype」 (参考資料 [16]) で識別されるサブシステムとコンポーネントの統合に続いて、アーキテクチャー・プロトタイプで行われる統合とシステム・テストについて説明します。
ブラック・ボックス・テスト、ソース・コードの拡張カバレッジ、すべてのモジュール・インターフェースのテストによって、単体テストは既に行われているものとします。
アーキテクチャー・プロトタイプを組み立てる目的は、 選択したアーキテクチャーの実現可能性と性能をテストすることでした。 すべてのシステムとサブシステムのインターフェース、 そしてシステムの性能もこの初期の段階でテストすることは重要です。 システムの機能のテストは、プロトタイプでは行いません。
次のサブシステム間のインターフェースをテストします。
次のデバイスとの外部インターフェースをテストします。
テスト対象の最も重要な性能測定は、次のとおりです。
該当する参考資料は次のとおりです。
次のリストは、テストの対象として指定された項目 (ユースケース、機能要求、 機能外要求) を洗い出したものです。 リストはテストの内容 を示しています。
(メモ: このテスト計画の将来のリリースでは、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 インストール・テスト
なし
テスト戦略は、ソフトウェア・アプリケーションのテストに対する推奨アプローチを表します。 前のセクション「テスト要求」では何が テストされるかを説明しましたが、 ここでは、どのように テストされるかを説明します。
テスト戦略の主な検討事項は、使用する技術と、テスト完了を判断する基準です。
次に示す各テストの検討事項に加えて、テストは、安全な環境で、制御された既知のデータベースでのみ実行する必要があります。
次のテスト戦略は一般的なもので、本書のセクション 4 でリストアップした要求に適用されます。
3.1 テスト・タイプ3.1.1 データと データベースの整合性テスト
データベースとデータベース・プロセスは、別のシステムとして テストする必要があります。これらのシステムは、(データへの インターフェースとしての) アプリケーションなしでテストする必要があります。 次に説明するテストをサポートするために、DBMS への追加調査を行って、 存在するツール/技術を識別する必要があります。
テストの目標 | データベースのアクセス・メソッドおよびプロセスが正しく機能し、データの破損がないことを確認する。 |
技法 |
|
完了基準 | すべてのデータベースのアクセス・メソッドおよびプロセスが設計通りに機能し、データの破損がないこと。 |
特に注意すべき点: |
|
3.1.2 機能テストアプリケーションのテストは、 ユースケース (またはビジネス機能) とビジネス・ルールに 直接さかのぼることのできる要求を対象とする必要があります。 これらのテストの目的は、適切なデータの受容、処理、取得、 ビジネス・ルールの適切な実装を検証することです。 このタイプのテストは、ブラック・ボックス技術に基づいています。 つまり、GUI を通じてアプリケーションとやり取りすることによって、 アプリケーションと内部プロセスを検証し、アウトプット (結果) を分析します。 次に示すのは、各アプリケーションに推奨するテストの概要です。
テストの目標 | アプリケーションのナビゲーション、データ・エントリー、処理、取得が適切であることを確認します。 |
技法 |
|
完了基準 |
|
特に注意すべき点: |
|
3.1.3 ビジネス・サイクルのテスト
3.1.4 ユーザー・インターフェースのテストこのセクションは、アーキテクチャー・プロトタイプのテストには該当しません。
ユーザー・インターフェースのテストでは、 ユーザーとソフトウェアの相互作用を検証します。 UI テストの目的は、ユーザー・インターフェースが、アプリケーションの機能を通じてユーザーに適切なアクセスとナビゲーションの提供を確認することです。また、UI テストによって、UI 内のオブジェクトが予想どおりに機能し、社内標準または業界標準に適合していることを確認します。
テストの目標 | 次の点について検証する。
|
技法 |
|
完了基準 | 各ウィンドウが、ベンチマーク・バージョンと矛盾がなく、許容できる基準の範囲内であることを検証済みであること。 |
特に注意すべき点: |
|
3.1.5 性能の分析
パフォーマンス・テストでは、応答時間、トランザクション速度、その他の時間に関する要求を測定します。 パフォーマンス・テストの目的は、性能要求が達成されたことを検証することです。 パフォーマンス・テストは通常、何回か行われ、そのたびに異なる「バックグラウンド負荷」をシステムに使用します。最初のテストは、 対象のシステムで実行済みの (または予定している) 通常の負荷と同様に、「公称」負荷で行います。2 回目のパフォーマンス・テストは、ピーク負荷を使用して実行します。
さらに、パフォーマンス・テストを使用して、システムの性能を作業負荷やハードウェア構成などの条件による機能として分析し調整することができます。
メモ: 以下のトランザクションは、「論理ビジネス・トランザクション」を指しています。 これらのトランザクションは、システムのユーザーがアプリケーションを使用して行うと思われる特定の機能として定義されます。 例えば、契約の追加や修正などです。
テストの目標 | 指定されたトランザクションまたはビジネス機能に対するシステムの応答時間を、以下の 2 つの条件で評価します。 - 通常予測されるボリューム - 予想される悪い状態でのボリューム |
技法 |
|
完了基準 |
|
特に注意すべき点: |
|
3.1.6 負荷テスト負荷テストでは、テスト対象のシステムに変化する作業負荷をかけて測定し、異なる作業負荷の下で適切に機能し続けるシステムの能力を評価します。 負荷テストの目的は、予測された最大作業負荷を超えてもシステムが適切に機能することを確認することです。 また、負荷テストでは、性能特性 (応答時間、トランザクション速度、およびその他の時間関連の問題) を評価します。
メモ: 以下のトランザクションは、「論理ビジネス・トランザクション」を指しています。 これらのトランザクションは、システムのユーザーがアプリケーションを使用して行うと思われる特定の機能として定義されます。 例えば、契約の追加や修正などです。
テストの目標 | 変化する作業負荷の条件下での、指定されたトランザクションまたはビジネス・ケースに対するシステムの応答時間を検証します。 |
技法 |
|
完了基準 |
|
特に注意すべき点: |
|
3.1.7 ストレス・テスト
3.1.8 ボリューム・テストこのセクションは、アーキテクチャー・プロトタイプのテストには該当しません。
3.1.9 セキュリティーとアクセス・コントロールのテストこのセクションは、アーキテクチャー・プロトタイプのテストには該当しません。
セキュリティーとアクセス・コントロールのテストは、セキュリティーの 2 つの主要な領域を対象としています。
アプリケーションのセキュリティー。データやビジネス機能へのアクセスを含みます。
システム・セキュリティー: システムへのリモート・アクセスを含みます。アプリケーション・セキュリティーにより、セキュリティーのレベルに基づいて、ユーザーが使用できる機能またはデータが制限されます。 例えば、データの入力や新しいアカウントの作成は誰でもできるが、 それを削除できるのは管理者に限られる場合があります。 データ・レベルのセキュリティーがある場合、例えば、「タイプ」 1 のユーザーは財政データを含むすべての顧客情報を見ることができるが、 「タイプ」 2 のユーザーは同じクライアントの統計データしか見られない、ということをテストによって確認できます。
システム・セキュリティーによって、システムへのアクセスが認められたユーザーだけが、適切なゲートウェイを通じてアプリケーションにアクセスできます。
テストの目標 | 機能/データ・セキュリティー: ユーザーが、自分のユーザー・タイプに与えられた権限内の機能やデータにのみ、アクセスできることを検証します。
システム・セキュリティー: システムとアプリケーションへのアクセス権を持つユーザーのみが、それらにアクセスできることを検証します。 |
技法 |
|
完了基準 | 既知の各ユーザー・タイプに対して適切な機能やデータが使用可能になり、前述のアプリケーション機能テストですべてのトランザクションが予測どおりに機能し、実行される。 |
特に注意すべき点: |
|
3.1.10 フェイルオーバーと回復のテスト
3.1.11 構成テストこのセクションは、アーキテクチャー・プロトタイプのテストには該当しません。
構成テストでは、異なるソフトウェアとハードウェアの構成で ソフトウェアの操作を検証します。ほとんどの稼働環境では、 クライアント・ワークステーション、ネットワーク接続、 データベース・サーバーに対するハードウェアの仕様は異なります。 クライアント・ワークステーションには、 さまざまなソフトウェア (アプリケーション、ドライバーなど) がロードされています。 アクティブになっているソフトウェアの組み合わせも、使用しているリソースも、 そのときによってさまざまです。
テストの目標 | 規定のクライアント・ワークステーションでクライアント・アプリケーションが正しく機能することを検証します。 |
技法 |
|
完了基準 | プロトタイプとコンピューター・アプリケーションの各組み合わせに対して、トランザクションが障害なく完了した。 |
特に注意すべき点: |
|
3.1.12 インストール・テスト3.2 ツールこのセクションは、C- 登録アーキテクチャー・プロトタイプのテストには該当しません。
ツール | バージョン | |
---|---|---|
テスト管理 | 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. リソース
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 |
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 日 |
このテスト計画で定義されたテスト・タスクのワーク・プロダクトの概要を、次の表に示します。
ワーク・プロダクト | 所有者 | レビュー/配布 | 期日 |
テスト計画書 | 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]) で定義されたとおり、 各テスト・ケースの次の属性をサポートするために設定されます。
- テスト・ステータス
- ビルド番号
- テスト担当者
- テスト日
- テスト・メモ
7. プロジェクトのタスクRequisitePro のテスト・ステータスを更新するのは、システム・テスト担当者の責務です。
テスト結果は、構成管理の下で保持されます。
6.3 障害レポート個別の障害の記録と追跡には、Rational ClearQuest が使用されます。
次に説明するのは、C- 登録アーキテクチャー・プロトタイプをテストする際の、テスト関連のタスクです。
テスト計画 |
|
|
|
|
|
|
テストの設計 |
|
|
|
|
|
テストの実装 |
|
|
|
|
|
テストの実行 |
|
|
|
|
|
|
テストの評価 |
|
|
|
テスト完了基準と成功基準が達成されたかどうかの判断 |
テスト評価レポートの作成 |
Copyright (c) IBM Corp. 1987, 2004. All Rights Reserved. |
履修コース登録プロジェクト Web Example |