履修コース登録システム

テスト計画書

 

バージョン 1.0

改訂履歴

日付

バージョン

説明

作成者

1999 年 3 月 27 日 1.0 リリース 1 と 2 のテスト計画 K. ストーン
 
 
 
 
 
 
 
 
 
 
 
 

 

 

目次

  1. 目標
  2. 範囲
  3. 参考資料
  4. テストに関する要求
  5. テスト戦略
    1. テスト・タイプ
      1. データとデータベースの整合性テスト
      2. システム・テスト
      3. ビジネス・サイクルのテスト
      4. ユーザー・インターフェースのテスト
      5. パフォーマンス・テスト
      6. 負荷テスト
      7. ストレス・テスト
      8. ボリューム・テスト
      9. セキュリティーとアクセス・コントロールのテスト
      10. フェイルオーバー/回復のテスト
      11. 構成テスト
      12. インストール・テスト
    2. ツール
  6. リソース
    1. ワーカー
    2. システム
  7. プロジェクトのマイルストーン
  8. ワーク・プロダクト
    1. テスト・セット
    2. テスト・ログ
    3. 障害レポート
  9. プロジェクトのタスク

テスト計画書

 

1. 目標

本書では、C- 登録システムのテストに関する計画について説明します。 このテスト計画書は、次の目標をサポートします。

    • 既存のプロジェクト情報とテスト対象ソフトウェア・コンポーネントの識別
    • 推奨テスト要求 (概略) のリストアップ
    • 使用するテスト戦略の推奨と説明
    • 必要な要員を識別し、テスト作業量の見積もりを提供
    • テスト作業のワーク・プロダクト要素のリストアップ

2. 範囲

    このテスト計画は、C- 登録システムのリリース 1 と 2 で行われる統合とシステム・テストに適用されます。アーキテクチャー・プロトタイプのテスト戦略については、別の「テスト計画」 (参考資料 [17]) で説明しています。

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

    このテスト計画は、「開発構想書」 (参考資料 [3])、「ユースケース仕様書」 (参考資料 [5] ~ [12])、および「補足仕様書」 (参考資料 [13]) に定義されている C- 登録システムのすべての要求のテストに適用されます。

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. 「履修コース登録システム 補足仕様書 WyIT400、バージョン 1.0」 1999 年、Wylie College IT
    14. 「履修コース登録システム ソフトウェア開発計画書 WyIT418、バージョン 2.0」 1999 年、Wylie College IT
    15. 「履修コース登録システム ソフトウェア・アーキテクチャー説明書 WyIT431、バージョン 1.0」 1999 年、Wylie College IT
    16. 「履修コース登録システム Requirements Attributes Guidelines WyIT404、バージョン 1.0」 1999 年、Wylie College IT
    17. 「履修コース登録システム アーキテクチャー・プロトタイプのテスト計画書 WyIT432、バージョン 1.0 1999 年」 1999 年、Wylie College IT

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 メインフレームで稼働する既存のコース費用請求システムと統合されること。

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

新しいコース・カタログのダウンロードに続く操作を検証します。

複数の学期と複数の年にわたる操作を検証します。

学期が次の年にかかる場合の訂正操作を検証します。

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

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

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

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

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

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

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

    「補足仕様書」のセクション 5.3 を参照: C- 登録システムの各機能には、ユーザーが使用できる組み込みのオンライン・ヘルプがあること。オンライン・ヘルプは、 システムの使用について順を追った説明をすること。 オンライン・ヘルプには、用語と頭字語についての定義を含むこと。

    パフォーマンス・テスト

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

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

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

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

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

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

    負荷テスト

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

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

    「補足仕様書」のセクション 7.1 を参照: システムは、中央のデータベースに対して常に 2000 までのユーザーを同時にサポートし、ローカルのサーバーに対して 1 度に 500 までのユーザーを同時にサポートすること。

    ストレス・テスト

    プライム・タイムに UNIX サーバーを使用する際のシステムの反応を検証します。

    最大数の学生がログインした際のシステムの反応を検証します。

    ボリューム・テスト

    コース・カタログ・データベースの容量が 90% の場合のシステムの反応を検証します。

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

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

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

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

    「補足仕様書」のセクション 4.2 を参照: すべての機能は、インターネット接続を通してリモートで使用できること。

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

    「補足仕様書」のセクション 6.1 を参照: C- 登録システムは、1 日 24 時間、週 7 日間使用可能であること。ダウン時間が 4% を超えないこと。

    「補足仕様書」のセクション 6.2 を参照: 平均故障間隔が 300 時間を超えること。

    構成テスト

    「開発構想書」のセクション 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 ランタイム環境と互換性があること。

    インストール・テスト

    「補足仕様書」のセクション 8.1 を参照: C- 登録のクライアント・コンピューター部分に対するアップグレードを、インターネットを通して UNIX サーバーからダウンロードできること。

    サーバー部分のインストールを検証します。

    クライアント部分のインストールを検証します。

5. テスト戦略

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

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

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

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

    1. テスト・タイプ

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

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

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

2. システム・テスト

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

 

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

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

ビジネス・サイクル・テストでは、長い期間にシステムで実行されるアクティビティーを再現する必要があります。1 年間など の期間を定めて、その期間に発生するトランザクションとアクティビティーを実行します。 これには、日、週、月単位のすべてのサイクルが含まれ、また期日票など、日にちに関連するイベントが含まれます。

 

テストの目標: 該当のアプリケーションとバックグラウンド・プロセスが、必要なビジネス・モデルとスケジュールに従って機能することを確認します。
技法
  • テストでは、次のことを実行してさまざまなビジネス・サイクルをシミュレートします。
  • アプリケーション機能テストに使用されたテストを修正、改良して各機能が実行される回数を増やし、指定された期間中にいくつかの異なるユーザーをシミュレートします。
  • 有効な日付または期間と無効な日付または期間を使用して、時間特定または日付特定のすべての機能を実行します。
  • 周期的なスケジュールで発生するすべての機能を、適切な時期に実行または起動します。
  • テストには有効なデータと無効なデータを使用し、次の内容を検証します。
  • 有効データを使用したときに予想された結果が得られたかどうか
  • 無効なデータを使用した場合は、該当のエラー/警告メッセージが表示される。
  • 各ビジネス・ルールが適切に適用されたかどうか
完了基準
  • 計画したすべてのテストを実行済みであること。
  • 特定されたすべての障害が対処済みであること。
特に注意すべき点:
  • システム日付とイベントには、特別なサポート作業を要する場合があります。
  • 適切なテスト要求と手順を識別するには、ビジネス・モデルが必要です。

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

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

 

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

5. パフォーマンス・テスト

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

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

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

 

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

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

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

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

6. 負荷テスト

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

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

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

7. ストレス・テスト

ストレス・テストは、リソースが小さいか、 リソースの競合がある場合のエラーを発見することを目的としています。 メモリーまたはディスク容量を小さくすることによって、 通常の状態ではわからないソフトウェアの障害が明らかになる場合があります。 ほかには、データベース・ロックやネットワーク帯域幅のような 共有リソースの競合によって障害が発生する可能性があります。 ストレス・テストでは、システムが処理できるピーク負荷を識別します。

メモ: 次のトランザクションに対する参照は、論理ビジネス・トランザクションを指しています。

テストの目標 次のストレス条件下で、システムとソフトウェアが適切に機能し、エラーが発生しないことを検証します。
  • サーバーで使用できるメモリーがほとんどないか、全くない状態 (RAM と DASD)
  • (実際または物理的に可能な) 最大数のクライアントが接続した (またはシミュレートした) 状態
  • 複数のユーザーが同じデータまたはアカウントに対して同じトランザクションを実行した状態
  • トランザクションのボリュームまたはミックスが最悪の状態 (前述のパフォーマンス・テスト参照)

メモ: ストレス・テストの目的は、システムが正常に機能し続けられない状態を識別して文書化することであるとも言えます。

技法
  • パフォーマンス・テスト用に開発されたテストを使用します。
  • 限定されたリソースをテストするために、テストは単一のコンピューターで実行し、またサーバーの RAM と DASD を小さくする (または限定する) 必要があります。
  • 残りのストレス・テストでは、複数のクライアントを使用して同じテストまたは補足テストを実行し、トランザクション・ボリュームまたはミックスを最悪の状態にします。
完了基準 計画されたすべてのテストが実行され、指定されたシステム限度がどのソフトウェアの障害もなく達成されたか、超過した (またはシステム障害の発生が、指定された状態の範囲外である状態)。
特に注意すべき点:
  • ネットワークにストレスをかけるには、ネットワークにメッセージまたはパケットをロードするためにネットワーク・ツールが必要な場合があります。
  • システムに使用される DASD は、データベースが発展する可能容量を制限するために、一時的に減少させる必要があります。
  • 同じレコードまたはデータ・アカウントへのクライアントの同時アクセスを同期化。

8. ボリューム・テスト

ボリューム・テストでは、ソフトウェアに大量のデータを処理させて、 ソフトウェア障害の原因となる限度に達したかどうかを判断します。 ボリューム・テストではまた、システムが一定の期間に処理できる 継続的な最大負荷またはボリュームを識別します。 例えば、ソフトウェアがレポートを作成するために 一連のデータベース・レコードを処理する場合、ボリューム・テストでは 大規模なテスト・データベースを使用して、ソフトウェアが通常の動作をして 正しいレポートを作成したことを確認します。

テストの目標 アプリケーションまたはシステムが次のような大ボリュームのシナリオの下で正常に機能することを検証します。
  • (実際の、または物理的に可能な) 最大数のクライアントを接続 (またはシミュレート) し、期間を延長して、同一の、最悪ケース (性能) のビジネス機能を実行する。
  • データベース・サイズが最大の状態 (実際または等比率) で、複数のクエリーまたはレポートのトランザクションが同時に実行される。
技法
  • パフォーマンス・テスト用に開発されたテストを使用します。
  • 同じテストまたは補足テストを実行する複数のクライアントを使用して、拡張された期間、最悪のケースのトランザクション・ボリュームまたはミックスを作成する必要があります (前述のストレス・テスト参照)。
  • 最大データベース・サイズ (実際、等比率、または代表的データで満たされたもの) を作成して、複数のクライアントを使用して、拡張された期間、クエリーまたはレポートのトランザクションを同時に実行する必要があります。
完了基準 計画されたすべてのテストが実行され、指定されたシステム限度にどのソフトウェアの障害もなく達したか、超過した。
特に注意すべき点:
  • 量の多い条件の場合 (上で述べたとおり)、どの程度の期間を許容可能な時間とみなすか。

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

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

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

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

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

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

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

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

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

フェイルオーバー/回復のテストでは、 データまたはデータの整合性を不当に失うことなく、アプリケーションまたはシステム全体が正常にフェイルオーバーし、 ハードウェア、ソフトウェア、ネットワークのさまざまな障害から回復することを確認します。

フェイルオーバー・テストでは、稼働し続ける必要のあるシステムについて、フェイルオーバーの状況が発生したときに、代替システムまたはバックアップ・システムが障害の発生したシステムからデータまたはトランザクションを失うことなく適切に「引き継ぐ」ことを確認します。

回復テストは相反するテスト処理で、デバイスの入出力障害、 無効なデータベース・ポインターやキーなど、アプリケーションまたは システムが極端な状態 (またはシミュレートされた状態) にさらされます。 回復プロセスが呼び出され、アプリケーションまたはシステムが 監視および検査されて、アプリケーションまたはシステムとデータの回復が 正常に達成されたことが検証されます。

テストの目標 回復プロセス (手動または自動) が データベース、アプリケーション、システムを該当の既知の状態に 適切に修復することを検証します。次の種類の状態がテストに含まれます。
  • クライアントに対する電力切断
  • サーバーに対する電力切断
  • ネットワーク・サーバー経由の通信中断
  • DASD と DASD コントローラーに対する通信中断または電力切断
  • 不完全なサイクル (データ・フィルター・プロセスの中断、データ同期化プロセスの中断)
  • 無効なデータベース・ポインターまたはキー
  • データベースの無効なデータ・エレメントまたは破損したデータ・エレメント
技法 アプリケーション機能とビジネス・サイクルのテスト用に作成されたテストを使用して、 一連のトランザクションを作成する必要があります。該当のテスト開始点に達したら、次のアクションを個別に実行 (またはシミュレート) します。
  • クライアントに対する電力切断: コンピューターへの電力を止めます。
  • サーバーに対する電力切断: サーバーに対する電力停止手順をシミュレートまたは開始します。
  • ネットワーク・サーバー経由の中断: ネットワークとの通信切断をシミュレートまたは開始します (物理的に接続線をはずすか、ネットワーク・サーバーまたはルーターの電源を落とします)。
  • DASD と DASD コントローラーに対する通信中断または電力切断: 1 つまたは複数の DASD コントローラーまたはデバイスとの通信を物理的に切断するか、シミュレートします。

上記の状態またはシミュレートされた状態に達したら追加のトランザクションを実行し、2 つ目のテスト開始点の状態に達したら、リカバリー手順を呼び出します。

不完全なサイクルのテストでは、前と同じ手法を使用しますが、データベース・プロセス自体が停止する、または時期を早めて終了する点が異なります。

次の条件をテストするために、既知のデータベース状態に達している必要があります。 いくつかのデータベース・フィールド、ポインターとキーをデータベース内で直接 (データベース・ツールを使用して) 手動で破壊します。 アプリケーション機能とビジネス・サイクルのテスト用のテストを使用して、追加のトランザクションを実行して完全なサイクルを実行します。

完了基準 上記すべてのケースで、 アプリケーション、データベース、システムが、 リカバリー手順を完了して、既知の望ましい状態に戻ること。 この状態に含まれるデータ破損は、既知の壊れたフィールド、 ポインター、キー、レポートに限られ、プロセスまたは トランザクションが中断のため完了しなかったことを示すこと。
特に注意すべき点:
  • 回復テストは内部に立ち入る必要性が高いテストです。 ケーブルを切断するプロシージャー (電源や通信の消失をシミュレートします) は、 望ましくない、または実行不能の場合があります。 診断ソフトウェア・ツールなどの代替メソッドが要求されることがあります。
  • システム (またはコンピューター操作)、データベース、ネットワーク・グループのリソースが要求されます。
  • これらのテストは、時間をおいて実行するか、独立したコンピューターで実行する必要があります。

11. 構成テスト

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

 

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

12. インストール・テスト

インストール・テストには 2 つの目的があります。 最初の目的は、新規インストール、アップグレード、完全なインストール、カスタム・インストール、通常の状態、通常でない状態など、 考えられるすべての構成でソフトウェアをインストールできることを確認することです。 通常でない状態とは、不十分なディスク容量、ディレクトリーを作成する権限の欠如などです。2 つ目の目的は、 インストール後にソフトウェアが正常に動作することの検証です。 これは通常、機能テスト用に開発されたいくつかのテストの実行を意味します。

 

テストの目標 クライアント・ソフトウェアが次の条件下で各クライアントに正常にインストールされることを検証します。
  • 新規インストール、新規コンピューターで、インストールされたことがない。
  • 以前にインストール済みのコンピューターを同じバージョンで更新する。
  • 以前にインストール済みのコンピューターを古いバージョンで更新する。
技法
  • 手動で、または自動のスクリプトを開発して、対象のコンピューターの状態を検証します (新規 - インストールされたことがない、同じバージョンまたは古いバージョンが既にインストールされている)。
  • インストールを起動して実行します。
  • あらかじめ設定しておいた統合のサブセットまたはシステム・テスト・スクリプトを使用して、トランザクションを実行します。
完了基準 トランザクションが障害なく正常に実行されること。
特に注意すべき点:
  • アプリケーションが正常にインストールされ、主要なソフトウェア・コンポーネントが紛失していないことを確認するテストを構成するのに、どんなトランザクションを選択するべきか。

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 (未定)

6. リソース

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

    1. ワーカー

次の表は、テスト作業で想定される要員配置です。

人材

ワーカー

推奨する最小限の要員

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

特定の責務/コメント

テスト管理者 1 - ケリー ストーン 管理監督を行う。

責務

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

キャロル・スミス

ソフィー キング

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

責務

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

ソフィー キング

エイドリアン・ハームセン

テストを実行する。

責務

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

責務

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

責務

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

責務

  • テスト・クラスの識別と定義
  • テスト・パッケージの識別と定義
実装担当者 マーガレット コックス

エイドリアン・ハームセン

テスト・クラスとテスト・パッケージを実装し、単体テストを実施する。

責務

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

2. システム

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

システム・リソース

リソース

名前/タイプ/シリアル番号

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

シリアル番号: B9334022

シリアル番号: B9332544

<7 TBD>

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

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

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

シリアル番号: X3333411 (教授室)

シリアル番号: A987344 (科学研究室)

シリアル番号: X9834000 (学生組合)

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

シリアル番号: R3322435

シリアル番号: I88323423

シリアル番号: B0980988

シリアル番号: R3333223

シリアル番号: Y7289732

負荷シミュレーター シリアル番号: ABC-123

 

 

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

    テスト作業とマイルストーンは開発反復に大きく依存しています。 作成フェーズは 3 つの反復に分けられます。各反復には、テスト計画、設計、 開発、実行、評価の完全なテスト・サイクルが含まれます。

    マスター・スケジュール、開発反復を示す作成フェーズの計画については、「ソフトウェア開発計画書」 (参考資料 [14]) と反復計画書を参照してください。

    次の表は、テストのマイルストーンを示しています。 作業、開始日、終了日は、反復内容の計画に伴って決定されます。

    マイルストーン・タスク 作業量 (pd) 開始日 終了日
    反復 C1: ベータ・リリース

    テスト計画

    テスト設計

    テストの開発

    テストの実行

    テストの評価

    TBD (未定) 3 月 15 日 4 月 12 日
    反復 C2: R1.0 リリース

    テスト計画

    テスト設計

    テストの開発

    テストの実行

    テストの評価

    TBD (未定) 4 月 13 日 5 月 14 日
    反復 C3: R2.0 リリース

    テスト計画

    テスト設計

    テストの開発

    テストの実行

    テストの評価

    TBD (未定) 5 月 15 日 6 月 17 日

     

8. ワーク・プロダクト

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

    これらのワーク・プロダクトのいくつかは、テスト・サイクル または反復のたびに 1 度作成され、合計で複数回作成されます。 テスト計画など、その他のワーク・プロダクトは、開発反復のたびに更新されます。

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

     

1. テスト・セット

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

2. テスト・ログ

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

    • テスト・ステータス
    • ビルド番号
    • テスト担当者
    • テスト日
    • テスト・メモ

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

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

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

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

次に述べるのは、C- 登録システムをテストする際の、テスト関連のタスクです。

 

テスト計画

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

リスク評価

テスト戦略の作成

テスト要員の特定

スケジュール作成

テスト計画作成

テストの設計

作業負荷分析

テスト・セットの開発

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

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

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

テストの実装

テスト環境の設定

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

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

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

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

テストの実行

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

テストの実行評価

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

結果の検証

予期せぬ結果の調査

障害の記録

テストの評価

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

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

障害の分析

テスト完了基準と成功基準が達成されたかどうかの判断

テスト評価レポートの作成

 

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

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