履修コース登録システム

 

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

テスト評価のまとめ

 

バージョン 1.0

改訂履歴

日付

バージョン

説明

作成者

1999 年 3 月 21 日 1.0 アーキテクチャー・プロトタイプのテスト評価 C. スミス
 
 
 
 
 
 
 
 

 

 

目次

  1. はじめに
  2. テスト結果のまとめ
  3. テスト・カバレッジ
  4. コード・カバレッジ
  5. 障害の分析
  6. 推奨アクション
  7. ダイアグラム

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

テスト評価のまとめ

  1. はじめに
    1. 目的
    2. テスト評価レポートでは、C- 登録アーキテクチャー・プロトタイプのテストの結果を、テスト・カバレッジ (要求ベースのカバレッジとコード・ベースのカバレッジ) と障害分析 (障害密度) の点から説明します。

    3. 範囲
    4. このテスト評価レポートは、C- 登録アーキテクチャー・プロトタイプに適用されます。 テスト内容については、「プロトタイプのテスト計画」 (参考資料 [5]) で説明しています。 評価レポートは、次の目的で使用します。

      • プロトタイプの性能の許容可能性と適切さの評価
      • テストの許容可能性の評価
      • テスト・カバレッジやテスト品質の向上のための改良点の識別
    5. 参考資料
    6. 該当する参考資料は次のとおりです。

        1. 「履修コース登録システム 用語集 WyIT406、バージョン 2.0」 1999 年、Wylie College IT
        2. 「履修コース登録システム ソフトウェア開発計画書 WyIT418、バージョン 1.0」 1999 年、Wylie College IT
        3. 「履修コース登録システム 反復計画書、推敲反復 #E1 WyIT420、バージョン 1.0」 1999 年、Wylie College IT
        4. 「履修コース登録システム アーキテクチャー・プロトタイプの統合ビルド計画書 WyIT430、バージョン 1.0」 1999 年、Wylie College IT
        5. 「履修コース登録システム アーキテクチャー・プロトタイプのテスト計画書 WyIT432、バージョン 1.0 1999 年」 1999 年、Wylie College IT
  2. テスト結果のまとめ

  3. プロトタイプのテスト・セットで定義されたテスト・ケースは、「テスト計画」 (参考資料 [5]) で定義されたテスト戦略に従って実行されました。

    「テスト計画」 (参考資料 [5]) で定義されたユースケースとテスト要求をカバーするテスト・カバレッジ (セクション 3.0 参照) が完了しました。

    コード・カバレッジはセクション 4.0 で説明しますが、 プロトタイプにとって非常に高いレベルの成功であるとはみなされませんでした。

    障害の分析 (セクション 5.0 参照) は、従来のコース・カタログ・システムに アクセスする際に重要な性能上の問題があることを示しています。 コース・カタログ・システムへの読み取りアクセスと書き込みアクセスに関する パフォーマンス・テストと負荷テストは、設定した目標をかなり下回っています。 管理チームでは、システム・エンジニアリング要員を割り当てて これらのテスト結果をさらに評価し、別の設計方法を決定する予定です。

  4. テスト・カバレッジ
  5. プロトタイプで実行されるテストは、その完了基準も含め、「テスト計画」 (参考資料 [5]) のセクション 5.1 で定義されています。 テスト・カバレッジの結果は次のとおりです。

    実行されたテスト・ケースの割合 = 40/40 = 100%

    成功したテスト・ケースの割合 = 30/40 = 80%

    失敗率が最も高かった領域のテストは、次のとおりです。

      • コース・カタログ・システムへのアクセスに関するパフォーマンス・テスト
      • コース・カタログ・システムへのアクセスに関する負荷テスト

    テスト・カバレッジの詳細については、Rational RequisitePro とプロトタイプ・テスト・ケース・マトリックスを使用して見ることができます。

     

  6. コード・カバレッジ
  7. プロトタイプ・テストのコード・カバレッジの測定には、Rational Visual PureCoverage が使用されました。

    実行された LOC の割合 = 12,874 / 48,916 (約 25%)

    テスト中に、コードの約 25% が実行されました。 すべてのインターフェースが完全に実行されたため、 このカバレッジはプロトタイプ・テストにとって適切であると判断されました。 後の反復では、コード・カバレッジを大幅に高める必要があります。

  8. 障害の分析
  9. このセクションでは、Rational ClearQuest を使用して作成された 障害分析の結果をまとめます。セクション 8 で、 障害分析で明らかになった点を処理するためのアクションを提案します。

    1. 障害密度
    2. 障害密度のデータは、ClearQuest レポートから抽出した データを使用して作成されています。 本書のセクション 9 には、次の内容を示す図表が収められています。

      • レベル別の障害 (重大、高、中、低)
      • 障害の発生元 (問題または障害が存在するコンポーネント)
      • 障害ステータス (記録済み、割り当て済み、修正済み、テスト済み、作業終了)

      「レベル別の障害」の図表は、重大な障害が 4 つと 高レベルの障害が 4 つ記録されたことを示しています。 障害ログの詳細な分析は、重大な障害と高レベルの障害がすべて、 従来のコース・カタログ・システムにアクセスする際の性能と負荷の問題に 関連していることを示しています。(メモ: 図表はありません。)

      「障害の発生元」の図表は、障害が非常に高い率でシステム・インターフェース・コンポーネントに存在することを示しています。

      「障害ステータス」の図表は、多くの障害が "記録済み" の状態で、まだ分析のために割り当てられていないことを示しています。

    3. 障害の傾向
    4. 障害の傾向 (時間経過に伴う障害数) は、アーキテクチャー・プロトタイプ・テストでは測定されませんでした。

    5. 障害の推移
    6. 障害の推移の追跡は、プロトタイプでは要求されていません。 現在の計画では、作成フェーズの初めに未解決の障害の推移の追跡を開始する予定です。 「障害の推移」の図表の作成には、ClearQuest が使用されます。

  10. 推奨アクション
  11. 推奨するアクションは、次のとおりです。

      1. 追加のシステム・エンジニアリング要員を割り当てて、 従来のコース・カタログ・システムへのアクセスに関連する 性能と負荷の問題をさらに評価する。プロジェクト・チームが 別の設計方法を検討した上で、解決法を実装する。
      2. エンジニアリング要員を割り当てて、プロトタイプの未解決の大きな障害を解決する。
      3. 重大な障害と高レベルの障害の解決を保留にして、次の反復の開始を遅らせる。
      4. 追加テストを設計し、コース・カタログ・システムに対する 負荷とアクセスをさらにテストする。Rational Visual Quantify を使用して、 性能上のボトルネックを識別し、分析する。
      5. 今後の反復には、外部インターフェースに関連するすべての設計 またはコードの検査を含めることをお勧めします。その検査によって、 テスト中に検出された問題の数を減らすことができるはずです。
7.  ダイアグラム
  1. 画像については上記の本文で説明しています
    画像については上記の本文で説明しています
    画像については上記の本文で説明しています
 
Copyright  (c) IBM Corp. 1987, 2004. All Rights Reserved.

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