カレッジ・スポーツ・ページング・システム

テスト計画

バージョン 1.0

改訂履歴

日付

バージョン 説明 作成者
1999 年 10 月 26 日 1.0 初版 Context Integration
目次

はじめに ページの先頭へ

目的

このカレッジ・スポーツ・ページング・システムのテスト計画書は、次の目標をサポートします。

  1. 既存のプロジェクト情報とテストするソフトウェア・コンポーネントを識別する。
  2. 推奨するテストについての要求 (概略) を一覧表示する。
  3. 採用するテスト戦略を推奨および説明する。
  4. 必要な要員を識別し、テスト作業量の見積もりを出す。
  5. テスト・プロジェクトの納入物要素を一覧表示する。

背景

カレッジ・スポーツ・ページング・システムでは、加入者が通知予約している大学スポーツのカテゴリー内でイベントが発生すると、 加入者に英数字のページングを行います。加入者は、個別化された Web サイトに接続し、ページングされたストーリーを、 その他の大学スポーツ・ニュースと同様に閲覧できます。

システムは、アプリケーション Web サーバーに含まれる 3 つの主なサブシステムから成り立ち、 ページング・ゲートウェイや既存の WebNewsOnLine Web サーバーと相互に作用します。サブシステムには次のものがあります。

  • コンテンツ管理 - このサブシステムはコンテンツを受け入れ、カテゴリーを記し、加入者に見出しを表示します。 特定の加入者グループ (通知予約プロファイルをもとに特定) に向けられる広告コンテンツも管理します。
  • ページング - このサブシステムは、新規のコンテンツがシステムにロードされるときにアクティブになります。 ページングを行う加入者の決定、ページング・ゲートウェイへのメッセージ送信を担当します。
  • レポート - このサブシステムは広告の閲覧について追跡およびレポートを行います。

システム・アーキテクチャーは、次のように表すことができます。

システム・アーキテクチャー図

 

範囲

カレッジ・スポーツ・ページング・システムでは、 単体テストとシステム・テストを行います。単体テストは機能的な品質に対応し、システム・テストはスケーラビリティーと性能に対応します。

サブシステムの相互作用は、次のようにテストします。

    1. ページングに対するコンテンツ管理
    2. レポートに対するコンテンツ管理

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

    1. カレッジ・スポーツ・ページング・システムと既存の WebNewsOnLine Web サーバー間
    2. カレッジ・スポーツ・ページング・システムとページング・ゲートウェイ間

最も重大なテストは、負荷およびパフォーマンス・テストです。これは次のように行います。

  1. 作成するページ数を最大 200,000 ページまで増やすテスト・シナリオを作成する。
  2. 20 秒 ごとに 1 項目の割合で新規コンテンツがシステムに着信するテスト・シナリオを作成する。
  3. 最後に、同時に処理する加入者負荷を最大 200,000 人まで増やすシミュレーションを行う。

プロジェクトの識別

次の表は文書と可用性を識別するものであり、テスト計画書の作成に使用されます。

文書
(バージョンと日付を含む)
作成済みまたは利用可能 受付済みまたはレビュー済み 作成者または要員 メモ
開発構想書 はい はい Context Integration  
補足仕様書 はい はい Context Integration  
ユースケース・レポート はい はい Context Integration  
プロジェクト計画書 はい はい Context Integration  
設計仕様書 いいえ いいえ    
プロトタイプ はい はい Context Integration  
プロジェクト/ビジネス・リスク評価書 はい はい Context Integration  

テストに関する要求ページの先頭へ

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

データベース・テスト

    加入者情報を入力および取得できることを検証する。

    コンテンツとカテゴリーを挿入および表示できることを検証する。

    広告主プロファイルとアカウント情報を入力および表示できることを検証する。

    加入者別の利用情報を追跡できることを検証する。

機能テスト

    加入者がページングを要求した情報を閲覧できることを検証する。

    コンテンツが到着するとページが加入者に送信されることを検証する。

    自動コンテンツ挿入が機能することを検証する。

    編集者の承認により、自動ではないコンテンツが挿入されることを検証する。

    通知予約の期限が切れた加入者はページを受信しないことを検証する。

    保管済みと記されたコンテンツは加入者に再表示されないことを検証する。

    古いコンテンツは削除されることを検証する。

    広告主レポートが正確であることを検証する。

    広告主レポートが、Microsoft® Word®、Microsoft® Excel ®、HTML のいずれかで受信できること検証する。

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

    なし

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

    すべてのユースケースを通って移動し、各 UI パネルが容易に理解できることを検証する。

    すべてのオンライン・ヘルプ機能を検証する。

    すべての画面が WebNewsOnLine の基準に準拠していることを検証する。

性能のプロファイル

    ページャー・ゲートウェイ・システムへのインターフェース応答時間を検証する。

    既存の WebNewsOnLine Web サーバーからのインターフェース応答時間を検証する。

    56Kbps モデムで接続した場合の応答時間を検証する。

    ローカルに (同じ LAN 上に) 接続された場合の応答時間を検証する。

負荷テスト

    同時に 200 人の加入者に対応する場合のシステムの応答を検証する。

    同時に 500 人の加入者に対応する場合のシステムの応答を検証する。

    同時に 1,000 人の加入者に対応する場合のシステムの応答を検証する。

    同時に 5,000 人の加入者に対応する場合のシステムの応答を検証する。

    同時に 10,000 人の加入者に対応する場合のシステムの応答を検証する。

    同時に 50,000 人の加入者に対応する場合のシステムの応答を検証する。

    同時に 100,000 人の加入者に対応する場合のシステムの応答を検証する。

    同時に 200,000 人の加入者に対応する場合のシステムの応答を検証する。

ストレス・テスト

    なし

ボリューム・テスト

    単独のコンテンツ要素が到着した場合、5 分以内にページが送信されることを検証する。

    20 秒おきにコンテンツが到着した場合、5 分以内にページが送信されることを検証する。

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

    非加入者は加入者のみ対象の情報にアクセスできないことを検証する。

    非編集者はコンテンツを承認できないことを検証する。

    広告主は各自の広告コンテンツのみ閲覧できることを検証する。

フェイルオーバー/復旧テスト

    なし

構成テスト

    Netscape V4.x ブラウザーを使用して動作検証をする。

    Microsoft® Internet Explorer® V5.x を使用して動作検証する。

インストール・テスト

    なし

テスト戦略 ページの先頭へ

テスト・タイプ

データとデータベースの整合性テスト
テスト目標 データベースのアクセス・メソッドおよびプロセスが正しく機能し、データの破損がないことを確認する。
技法
  • 有効データおよび無効データ (またはデータ要求) でデータベースのアクセス・メソッドとプロセスをそれぞれシードして呼び出す。
  • データベースを検査し、データが意図したとおりに組み込まれ、すべてのデータベース・イベントが適切に発生していることを確認する。または、戻されたデータをレビューし、(適切な理由により) 正確なデータが取り出されたことを確認する。
完了基準 すべてのデータベースのアクセス・メソッドおよびプロセスが設計通りに機能し、データの破損がないこと。
特に注意すべき点
  • プロセスは、手動で起動しなければなりません
  • 小さいサイズの (レコード数を制限した) データベースを使用し、受け入れられないイベントの可視性を向上させる。
機能テスト
テスト目標 移動、データ入力、処理、取得を含め、 テスト対象が適切に機能することを確認する。
技法 有効データと無効データを使用して、各ユースケース、ユースケース・フロー、機能を実行し、次の点について検証する。
  • 有効データを使用したときに予想された結果が得られたかどうか
  • 無効データを使用した場合、適切なエラーと警告メッセージが表示される。
  • 各ビジネス・ルールが適切に適用されたかどうか
完了基準
  • 計画したすべてのテストを実行済みであること。
  • 特定されたすべての障害が対処済みであること。
特に注意すべき点 なし
ユーザー・インターフェース・テスト
テスト目標 次の点について検証する。
  • テスト対象を通って移動すると、ウィンドウ間、フィールド間を含むビジネス機能と要求、および、アクセス・メソッド (タブ・キー、マウス移動、アクセラレーター・キー) の使用が適切に行われる。
  • メニュー、サイズ、位置、状態、フォーカスなどの Web オブジェクトと特性が、基準に準拠している。
技法 ウィンドウごとにテストを作成または修正し、適切に移動できること、および、各アプリケーション・ウィンドウおよびオブジェクトの状態が適切であることを検証する。
完了基準 各ウィンドウが、ベンチマーク・バージョンと矛盾がなく、許容できる基準の範囲内であることを検証済みであること。
特に注意すべき点 カスタム・オブジェクトやサード・パーティー・オブジェクトの、すべてのプロパティーにアクセスできるわけではありません。
性能のプロファイル
テスト目標 次の条件で、指定したトランザクションまたはビジネス機能の実行状況を検証する。
  • 通常予想される作業負荷
  • 通常より悪いケースで想定される作業負荷
技法 機能またはビジネス・サイクル・テスト用に開発されたテスト・プロシージャーを使用します。

データ・ファイルを修正してトランザクションの数を増やすか、スクリプトを修正して各トランザクションが発生する反復の数を増やす。

スクリプトは 1 台のコンピューターで実行し (ベンチマークの最良のケースは、単一ユーザー、 単一トランザクション)、複数のクライアントで繰り返す必要があります (仮想的に、または実際に。 下の「特に注意すべき点」を参照)。

完了基準 単一トランザクションまたは単独ユーザー: テスト・スクリプトが、予定の、または要求された、時間の割り当ての中で、障害もなく正常に完了すること。

複数トランザクションまたは複数ユーザー: テスト・スクリプトが許容可能な時間の割り当ての中で、障害もなく正常に終了すること。

特に注意すべき点 包括的なパフォーマンス・テストには、サーバーの「バックグラウンド」の作業負荷を考慮することも含む。

次のものを含む複数のメソッドが、この実行に使用されます。

  • 通常 SQL コールの形式で、直接サーバーへ「トランザクションをドライブ」する。
  • 「仮想の」ユーザー負荷を作成して、多数のクライアント (通常は数百) をシミュレートします。 リモート端末エミュレーション・ツールを使用してこの負荷をかけます。この技術は、ネットワークに「トラフィック」の負荷をかけるのにも使用できます。
  • 複数の実際のクライアントを使用して、それぞれテスト・スクリプトを実行し、システムに負荷を掛ける。

パフォーマンス・テストは、テスト専用のコンピューター上で、 またはテスト専用の時間帯に実行しなければなりません。 これによって、 測定を完全に制御し、正確に実行することができます。

パフォーマンス・テストに使用するデータベースは、実際のサイズまたは均等に拡大したものとする。

負荷テスト
テスト目標 さまざまな作業負荷条件のもとで、指定されたトランザクションまたはビジネス・ケースの実行時間を検証する。
技法 機能またはビジネス・サイクル・テストに向けて開発されたテストを使用する。

データ・ファイルを修正してトランザクションの数を増やすか、テストを修正して各トランザクションが発生する回数を増やす。

完了基準 複数トランザクションまたは複数ユーザー: テストが許容可能な時間の割り当ての中で、障害もなく正常に終了すること。
特に注意すべき点 負荷テストは、テスト専用のコンピューター上、 またはテスト専用の時間帯に実行しなければなりません。 これによって、 測定を完全に制御し、正確に実行することができます。

負荷テストに使用するデータベースは、実際のサイズまたは均等に拡大したものとする。

ボリューム・テスト
テスト目標 次のような多量のシナリオのもとで、テスト対象が正常に機能することを検証する。
  • (実際の、または物理的に可能な) 最大数のクライアントを接続 (またはシミュレート) し、期間を延長して、同一の、最悪ケース (性能) のビジネス機能を実行する。
  • データベースのサイズを最大 (実際版または拡大版) にし、複数のクエリーおよびレポート・トランザクションを同時に実行する。
技法 性能のプロファイルまたは負荷テスト用に開発されたテストを使用します。

複数のクライアントにより同一のテストまたは相補的なテストを実行し、期間を延長して、最悪のケースのトランザクション量または組み合わせ (前述のストレス・テストを参照) を生成する。

最大のデータベースを作成し (実際版、拡大版、代表的なデータで埋めたもの)、期間を延長して、複数のクライアントにより同時にクエリーおよびレポート・トランザクションを実行する。

完了基準 計画したすべてのテストを実行し、ハードウェアもソフトウェアの障害もなく、指定したシステムの制限値に到達あるいは制限値を超過すること。
特に注意すべき点 量の多い条件の場合 (上で述べたとおり)、どの程度の期間を許容可能な時間とみなすか。
セキュリティーとアクセス・コントロールのテスト
テスト目標 アプリケーション・レベルのセキュリティー: アクターが、ユーザー・タイプに許可が与えられている機能およびデータのみアクセスできることを検証する。

システム・レベルのセキュリティー: システムおよびアプリケーションへのアクセス権を持つアクターのみが、これらへのアクセスを許可されていることを検証する。

技法 アプリケーション・レベル: 各アクター・タイプと、各タイプが許可されている機能またはデータを識別および一覧表示する。

各アクター・タイプのテストを作成し、各ユーザー・アクターに固有のトランザクションを作成することにより、それぞれの許可を検証する。

ユーザー・タイプを修正し、同じユーザーに対してテストを再実行する。各ケースで、 これらの追加機能およびデータが正しく有効化されるか、または拒否されることを検証する。

システム・レベル・アクセス (下の「特に注意すべき点」を参照)

完了基準 既知の各アクター・タイプに対して適切な機能およびデータが利用可能となり、すべてのトランザクションが予定通りに機能して前の機能テストで動作すること。
特に注意すべき点 システムへのアクセスについては、 適切なネットワークまたはシステム管理者と一緒に調査や検討を行う必要があります。このテストはネットワークやシステム管理の機能に含まれる場合があるので、 テストの実施が要求されないことがあります。
構成テスト
テスト目標

要求されるハードウェアおよびソフトウェア構成で、テスト対象が正常に機能することを検証する。

技法

機能テスト・スクリプトを使用する。

テストの一部として、または、テスト開始に先駆けて、Microsoft アプリケーションの Excel® や Word® など、テスト対象外の関連するさまざまなソフトウェアを開いたり閉じたりする。

選択したトランザクションを実行して、テスト対象ソフトウェアと非テスト対象ソフトウェアとのアクターの相互作用をシミュレートする。

クライアントの利用可能な基本メモリーを最小化して、上のプロセスを繰り返す。

完了基準

テスト対象ソフトウェアとテスト対象外ソフトウェアのそれぞれの組み合わせで、すべてのトランザクションが障害なく正常に完了すること。

特に注意すべき点

どのテスト対象外ソフトウェアが必要で、デスクトップで利用およびアクセス可能か。

どのアプリケーションが通常使用されるか。

アプリケーションでどのようなデータを使用するか (Excel で開く大規模なスプレッドシート、Word の 100 ページに及ぶ文書など)。

システム全体、ネットウェア、ネットワーク・サーバー、データベースなどについても、このテストの一部として文書化する。

ツール

このプロジェクトでは次のツールを採用します。

 

ツール

バージョン

障害追跡

Project HomePage

 
プロジェクト管理

Microsoft® Project®

 


リソースページの先頭へ

このセクションでは、カレッジ・スポーツ・ページング・システムのテスト労力として推奨する要員、その主な職務、知識またはスキルを示します。

ワーカー

この表は、想定されるこのプロジェクトの要員配置を示しています。

人材
ワーカー 推奨する最小限の要員 特定の責務およびコメント
テスト管理者、
テスト・プロジェクト管理者
1 ( カレッジ・スポーツ・ページング・システムのプロジェクト管理者 管理監督を行う。

責務

  • 技術的な指示
  • 適切な要員の確保
  • 管理レポート
テスト設計者 1 テスト・ケースの識別、優先順位付け、および実装を行う。

責務

  • テスト計画作成
  • テスト・モデル作成
  • テスト作業の有効性の評価
テスト担当者 4 (WebNewsOnLine より配置) テストを実行する。

責務

  • テストの実行
  • 結果の記録
  • エラーからの回復
  • 文書変更依頼
テスト・システム管理者 1 テスト環境とアセットが管理および保守されていることを確認する。

責務

  • テスト管理システムの管理
  • テスト・システムへのワーカー・アクセスの導入および管理
データベース管理/データベース管理者 1 (WebNewsOnLine より配置) テスト・データ (データベース) 環境とアセットが管理および保守されていることを確認する。

責務

  • テスト・データ (データベース) の管理
設計者 2 テスト・クラスの操作、属性、および関連事項を識別および定義する。

責務

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

責務

  • テスト・モデルに実装されるテスト・クラスおよびパッケージの作成

システム

次の表では、テスト・プロジェクトのシステム・リソースを示します。

テスト・システムの特定要素は、この時点では十分明らかにはなっていません。適宜アクセスやデータベース・サイズを縮小して、 システムが実稼働環境をシミュレートすることを推奨します。

システム・リソース
リソース 名前とタイプ
データベース・サーバー  
ネットワーク/サブネット TBD (未定)
サーバー名 TBD (未定)
データベース名 TBD (未定)
クライアント・テスト PC  
特別な設定要求を含む
TBD (未定)
テスト・リポジトリー  
ネットワーク/サブネット TBD (未定)
サーバー名 TBD (未定)
テスト開発 PC TBD (未定)

プロジェクトのマイルストーン ページの先頭へ

  マイルストーン・タスク   作業 開始日 終了日
  テストの計画立案        
  テストの設計        
  テストの実装        
  テストの実行        
  テストの評価        

納入物 ページの先頭へ

テスト・モデル

実行するテストごとに、テスト結果用紙が作成されます。これには、テスト名またはテスト ID、テストに関連するユースケースまたは補足仕様書、 テストの日付、テスト担当者の ID、要求されるテスト前の条件、テスト結果が含まれます。

テスト・ログ

Microsoft Word を使用して、テスト結果を記録およびレポートします。

障害レポート

障害は、Web を使う Project HomePage を使用して記録します。

付録 A: プロジェクト・タスク ページの先頭へ

次の表は、テストに関連するタスクの一覧です。

テストの計画立案
テストに関する要求の識別
リスク評価
テスト戦略の作成
テスト要員の特定
スケジュール作成
テスト計画作成
テストの設計
作業負荷分析
テスト・ケースの識別と記述
テスト・プロシージャーの識別と構成
テスト・カバレッジのレビューと評価 
テストの実装
テスト・スクリプトの記録またはプログラミング
設計および実装モデルにおけるテスト固有の機能の識別
外部データ・セットの確立
テストの実行
テスト・プロシージャーの実行
テストの実行評価
停止したテストからの復旧
結果の検証
予期せぬ結果の調査
障害の記録
テストの評価
テスト・ケース・カバレッジの評価
コード・カバレッジの評価
障害の分析
テスト完了基準と成功基準が達成されたかどうかの判断

 

 

© Copyright IBM Corp. 1987, 2005. All Rights Reserved.