履修コース登録システム

C2 テスト評価のまとめ

 

バージョン 1.0

改訂履歴

日付

バージョン

説明

作成者

1999 年 3 月 28 日 1.0 R1.0 リリースのテスト評価 (C2 反復 - 初期リリースで作成) C. スミス
 
 
 
 
 
 
 
 

 

 

目次

  1. 目標
  2. 範囲
  3. 参考資料
  4. はじめに
  5. テスト・カバレッジ
  6. コード・カバレッジ
  7. 障害の分析
    7.1    障害密度
    7.2    障害の傾向
    7.3    障害の推移
  8. 推奨アクション
  9. ダイアグラム

C2 テスト評価のまとめ

1. 目標

    このテスト評価レポートでは、C- 登録リリース 1.0 システムのテストの結果を、 テスト・カバレッジ (要求ベースのカバレッジとコード・ベースのカバレッジ) と 障害分析 (障害密度) の点から説明します。 これらのテストは、C2 反復中に行われました。

2. 範囲

このテスト評価レポートは、C2 反復で実装された C- 登録 R1.0 リリースに適用されます。 テスト内容については、「テスト計画」 (参考資料 [5]) で説明しています。 評価レポートは、次の目的で使用します。

  • R1.0 システムの性能面での振る舞いの容認性と適切さを評価します。
  • テストの許容可能性の評価
  • テスト・カバレッジやテスト品質の向上のための改良点の識別

3. 参考資料

該当する参考資料は次のとおりです。

    1. 「履修コース登録システム 用語集 WyIT406、バージョン 2.0」 1999 年、Wylie College IT
    2. 「履修コース登録システム ソフトウェア開発計画書 WyIT418、バージョン 1.0」 1999 年、Wylie College IT
    3. 「履修コース登録システム C2 反復計画書 WyIT500、バージョン 1.0」 1999 年、Wylie College IT
    4. 「履修コース登録システム C2 統合ビルド計画書 WyIT502、バージョン 1.0」 1999 年、Wylie College IT
    5. 「履修コース登録システム テスト計画 WyIT501、バージョン 1.0」 1999 年、Wylie College IT

4. はじめに

    テスト・セットで定義されたテスト・ケースは、 「テスト計画」 (参考資料 [5]) で定義されたテスト戦略に従って実行されました。 テストの障害は記録され、中、高、重大のレベルの障害は現在、 修正のため所有者に割り当てられています。

    「テスト計画」 (参考資料 [5]) で定義されたユースケースとテスト要求を カバーするテスト・カバレッジ (セクション 5.0 参照) は、95% が完了しました。 全負荷の状態でのシステムの操作に関連する 10 のテスト・ケースが、 負荷シミュレーター・ソフトウェアのバグのため完了しませんでした。

    コード・カバレッジは Rational Visual PureCoverage を使用して測定され、結果はセクション 6.0 で説明しています。

    障害の分析 (セクション 7.0 参照) は、検出された障害の大部分が、 高または重大のレベルに分類される主要な問題であることを示しています。 もう 1 つの重要な発見は、コース・カタログ・システムへのインターフェースを 構成するソフトウェア・コンポーネントに非常に多くの障害が存在することです。

5. テスト・カバレッジ

テスト・セットで定義されたすべてのテスト・ケースが試行されました。 負荷シミュレーター・ソフトウェアの ソフトウェア・エラーのため、10 のテストが完了しませんでした。 実行されたテストのうち、15 のテストが失敗しました。

テスト・カバレッジの結果は次のとおりです。

実行されたテスト・ケースの割合 = 110/120 = 92%

成功したテスト・ケースの割合 = 95/110 = 87%

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

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

テスト・カバレッジについてさらに詳しくは、Rational RequisitePro とテスト・ケースのマトリックスに示されています。

6. コード・カバレッジ

    テストのコード・カバレッジの測定には、Visual PureCoverage が使用されました。

    LOC 実行率 = 94,399 / 102,000 = 93%

    およそ 93% のコードが、テスト中に実行されました。 このカバレッジは目標の 90% を越えています。

7. 障害の分析

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

7.1     障害密度

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

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

レベル別の障害の図は、記録された 36 の障害のうち、26 が 高または重大のレベルに分類されることを示しています。 この数値は非常に高いと考えられます。リリースを行うためには、 高と重大のレベルを持つすべての障害を解決する必要があります。

障害の発生元の図は、非常に高い割合の障害が、 コース・カタログ・システムへのインターフェースを構成する コンポーネント (c-abx、c-xxx) に関連することを示しています。 また、クライアント・ソフトウェアのインストールを制御する ソフトウェア・コンポーネント内に多数の障害があります。

障害ステータスの図は、障害が迅速に割り当てられ、 処理されつつあることを示しています。障害の大部分は、検証され、解決しました。

また、重大および高の障害の分析は、これらの障害の多くが、 高負荷の状態でコース・カタログ・システムにアクセスする際の 応答時間の悪さによるものであることを示しています。 (性能要求を検証するテスト・ケースのうち、50% のみが合格しました。)

7.2     障害の傾向

      障害の傾向 (時間経過に伴う障害数) は、セクション 9 の図表に示しています。 この傾向は、障害の発生が高いままであることを示しています。 この傾向が続く場合、コードの残りの障害を発見するために、 追加の反復が必要になる可能性があります。

7.3     障害の推移

障害の推移の図 (セクション 9 参照) は、いくつかの障害を解決するのにかかる日数が 30 日を超えることを示しています。

 8.  推奨アクション

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

  1. システム・エンジニアリング要員を、コース・カタログ・システムに関する 応答時間の問題に引き続き割り当てる。 性能要求を満たさなければ R1.0 リリースをリリースできないため、これは重要な問題です。
  2. マスター・スケジュールを見直し、作成フェーズに 4 つ目の反復を追加できるか検討する。 時間経過に伴う障害の傾向は、まだ多くの障害がコードに残っていることを示しており、追加のテスト・サイクルが推奨されます。
  3. 障害率の高いコンポーネントを、ビルドに再提出する前に検査する。 これには c-abx と c-xxx を含みます。
  4. 重大および高のレベルの障害の率が高いことは、設計が不完全で十分にレビューされなかったことを示していると考えられます。R2.0 リリースに追加の設計レビューを計画する。
  5. 負荷シミュレーター・ソフトウェアに関する問題を修正し、関連するテスト・ケースを再実行する。
  6. 障害の推移を調査する。いくつかの障害が解決するのに 30 日を超えたのはなぜか。
 9.  ダイアグラム
上記の本文で詳しく説明しています
上記の本文で詳しく説明しています
上記の本文で詳しく説明しています
上記の本文で詳しく説明しています
上記の本文で詳しく説明しています

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

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