トピック

概論 ページの先頭へ

テストの主要な基準には、カバレッジと品質が含まれます。

テスト カバレッジはテストの完全性の基準であり、テスト要求とテスト ケースのカバレッジ、または実行されたコードのカバレッジによって説明されるテストのカバレッジに基づきます。

品質は、テストの対象 (テストされるシステムやアプリケーション) の信頼性、安定性、性能の基準です。品質は、テスト結果の評価、テストによって明らかになった変更要求 (障害) の分析を基に判断します。

カバレッジの基準ページの先頭へ

カバレッジのメトリクスは、「テストの完全性は?」との問いに答えを提示するものです。最も一般に使用されるカバレッジの基準は、ソフトウェア要求とソースコードのカバレッジに基づきます。基本的に、テスト カバレッジはあらゆる要求から照らした完全性の基準 (要求ベース) であるか、ユース ケースの検証 (要求ベース) や全コードの実行 (コード ベース) といったコード設計や実装基準 (コードベース) です。

体系的なテストは、必ず少なくとも 1 つのテスト カバレッジ戦略をベースとしています。カバレッジ戦略では、テストの全体としての目的を明らかにすることによりテスト ケースの設計を導きます。カバレッジ戦略の記述は、すべての性能の検証と同じくらい単純であり得ます。

要求を完全にカタログに構成する場合、テストの完成性について定量化可能な基準を生み出すのに要求ベースのカバレッジ戦略は十分な機能を果たすでしょう。例えば、すべての性能テストの要求が明らかになっていれば、テスト結果を参照して基準を得ることができます。例えば、性能テストの要求の 75% が検証されている場合などです。

コード ベースのカバレッジを適用する場合には、テストによって実行されたソース コードの量という側面から、テスト戦略が定型化されます。この種のテスト カバレッジ戦略は、特に高い安全性が求められるステムにとって非常に重要になります。

いずれの基準も、手作業で得る方法 (以下の 2 つの項目に示した方程式を使用) と、テスト自動化ツールを使って算出する方法とがあります。

要求に基づくテスト カバレッジ ページの先頭へ

テスト ライフサイクル中に数回測定される要求ベースのテスト カバレッジでは、テスト ライフサイクルのマイルストーンでテスト カバレッジを特定します。例えばテスト カバレッジの計画、実装、実行、完了などです。

  • テスト カバレッジは、次の方程式を使って計算されています。

Test Coverage = T(p,i,x,s) / RfT

ここで
T は、テスト プロシージャやテストケースとして説明される (計画、実行、実装、完了した) テストの数です。

RfT は、テストの要求の総数です。

  • テストの計画では、次の方法でテスト カバレッジを算出し、テスト カバレッジの計画を決定します。

Test Coverage (planned) = Tp / RfT

ここで
Tp は、テスト プロシージャやテスト ケースとして説明される計画されたテストの数です。

RfT は、テストの要求の総数です。

  • テストの実装では、テストプロシージャが実装された時 (テスト スクリプトとして)、テスト カバレッジを次の方程式を使って計算します。

Test Coverage (implemented) = Ti / RfT

ここで
Ti は、実装されたテストの数です。これは、関連するテスト スクリプトがあるテスト プロシージャまたはテスト ケースの数として説明されます。

RfT は、テストの要求の総数です。

  • テストの実行で使用されるテスト カバレッジの基準は、2 つあります。1 はテストの実行によって実行したテスト カバレッジを識別し、もう 1 つは成功したテスト カバレッジ (障害や予期せぬ結果といった失敗がなく実行できたテスト) を識別します。

    これらのカバレッジ基準は次の方程式を使って計算します。

    Test Coverage (executed) = Tx / RfT

    ここで
    Tx は、テスト プロシージャあるいはテストケースとして説明されるテストの数です。

    RfT は、テストの要求の総数です。

  •  

Test Coverage (executed) = Tx / RfT

ここで
Ts は、実行されたテストの数であり、これは問題なく完了できたテスト プロシージャやテスト ケースの数として説明されます。

RfT は、テストの要求の総数です。

     

上の割合をパーセンテージに変換すると、要求ベースのテスト カバレッジの次の記述が可能になります。

テスト ケースの x% (上の式の T(p,i,x,s)) は成功率 y% でカバーされています。

テスト カバレッジのこの有意義な記述は、定義された成功基準に対応するものです。基準が満たされない場合、この記述をベースとして、さらにどれだけのテスト作業が必要かを見積もることができます。

コードベースのテスト カバレッジ ページの先頭へ

コードベースのテスト カバレッジは、未実行のコードの数と比較することで、テスト中実行されたコードの数を測定します。コードカバレッジは、制御のフロー (記述、ブランチ、パスなど)、またはデータ フローをベースとします。

  • 制御フロー カバレッジの目的は、コード、その他ソフトウェアの制御フローの要素によって、コード行、ブランチ、条件、パスをテストすることにあります。
  • データ フロー カバレッジの目的は、ソフトウェアの実行によって、有効な状態のデータをテストすることにあります。例えば、使用される前にデータ要素が定義されているかどうかを確認するなどです。

コードベースのテスト カバレッジは次の方程式で計算します。

Test Coverage = Ie / TIic

ここで
Ie は、実行された項目の数であり、コードの記述、コードのブランチ、コード パス、データ状態の決定ポイント、データ要素名などで説明されます。

TIic はコードの項目の総数です。

 

この割合をパーセンテージに変換することで、コードベースのテスト カバレッジの次の記述が可能になります。

テスト ケースの x% (上の式の I ) は、成功率 y% でカバーされています。

テスト カバレッジのこの有意義な記述は、定義された成功基準に対応するものです。基準が満たされない場合、この記述をベースとして、さらにどれだけのテスト作業が必要かを見積もることができます。

知覚品質の基準 ページの先頭へ

テスト カバレッジの評価は、テスト作業の完全度の基準となりますが、一方、テスト中に検出された障害の評価は、実際に使用された時のソフトウェア品質に対する最良の指標となります。知覚品質は、ソフトウェア システム全体の総合的品質の根拠となります。ソフトウェアの知覚品質とは、ソフトウェアがその要求にどの程度応えているかの基準となります。この点から、障害は、テストの対象がソフトウェア要求を満たしていない変更要求と考えることができます。

障害の評価は、単純な障害のカウントから厳格な統計的モデリングに及ぶ方法をベースとすることができます。

厳格な評価では、テストプロセス中の欠陥の到着率、発見率の仮定を用います。一般的なモデルでは、その率はポアソン分配に準じると想定します。その後、障害率の実際のデータをモデルに適用します。この結果の評価では、現在のソフトウェアの信頼性を見積もり、そしてテストと障害除去を継続する場合に、信頼性がどう向上するか予測します。この評価方法は、ソフトウェアの信頼性の成長モデリングであり、この分野は現在活発に研究が行われています。この評価方法では使用できるツールが十分でないため、発生するコストと得られるメリットのバランスを考えなければなりません。

障害分析障害に関係する 1 つまたは複数の属性の障害分散の分析を行います。障害分析は、ソフトウェアの信頼性の指標となります。

障害分析では、主に次に示す 4 つの障害属性を分析します。

  • ステータス —障害の現在の状態 (未解決、修復中、対応済み、など)。
  • 優先順位 — 対応、解決された障害の重要性。
  • 重要度 — エンド ユーザー、組織、第三者などに対する障害の相対的な影響度。
  • ソース — この障害の根本となる原因、その場所。またこの障害を排除するためには、どのコンポーネントを修復すればよいか。

障害の数は、時間の関数を用い、障害傾向図、レポートという形で報告することができます。また、重要度やステータスなどのように、1 つまたは複数の障害属性の関数として、障害率レポートの中で報告することもできます。この種の分析は、障害の傾向や分散の観点から、ソフトウェアの信頼性を示すものです。

例えば、障害発見率は、テストと修復のプロセスの中で、最終的には低下するものと予測できます。障害や低品質のしきい値は、受け入れられないソフトウェア品質のレベルに設定することができます。障害数についても、実装モデルの原点で報告することができ、それによって「弱いモジュール」、「ホット スポット」、また修復を繰り返し、設計の根本的な欠陥を示唆するソフトウェア パーツの特定が可能になります。

この種の分析では、確認済みの欠陥だけを対象とします。報告された障害が、すべて実際の欠陥を示すものとは限りません。一部には、プロジェクトの範囲から外れる要求の拡大に帰されるものや、すでに報告済みの障害が含まれている可能性があるためです。しかし、重複している障害や未確認の障害であっても、多くの欠陥の報告理由を見て、分析することは重要です。

障害レポート ページの先頭へ

Rational Unified Process では、次のようないくつかの報告カテゴリーに基く障害評価を推奨しています。

  • 障害分散 (密度) レポートでは、1 つまたは 2 つの障害属性の関数として、障害数を示します。
  • 障害エイジング レポートは、特殊なタイプの障害分散レポートです。このレポートでは、障害が特定の状態 (未解決など) にあった期間の長さを示します。どのエイジング カテゴリーに属する障害も、別の属性 (所有者など) の属性で分類することができます。
  • 障害向レポートでは、状態 (新規、未解決、対応済みなど) ごとに障害数を示します。このレポートは、累積的にも、非累積的にも作成することができます。

これらレポートの多くがソフトウェア品質の算定に有用ですが、テスト中のアプリケーションについて、複数の反復、テスト サイクルに渡り実行されたテストの結果を示すテスト結果とその進捗と共に分析すると、さらに有用性が高まります。一般的なテスト条件には、特定のカテゴリ (重要度など) 内で許容される未解決障害数などの記述が含まれますが、これは障害分散の評価で簡単にチェックすることができます。テストの動機付け要因によって分散をソートやグループ化することで、評価を重要な部分に集中させることができるためです。

なお、この種のレポートを効率的に作成するためには、通常ツールの使用が必要です。

障害率レポート ページの先頭へ

障害の状態と優先順位

各障害に優先順位を付けます。一般には、次に示すような 4 レベルの優先順位付けで十分実用に耐えます。

  • 緊急優先度 (直ちに解決が必要)
  • 優先度高
  • 優先度普通
  • 優先度低

メモ: 有効なテストの条件は、これら優先順位レベルの中での障害の分散状態で説明できます。例えば、有効なテストの条件は、「優先順位 1 の障害は皆無、優先順位 2 で未解決の障害は 5 つ以下」などとすることができます。次に示すような障害分散図を作成します。

 

条件が満たされていないことは明確です。テスト条件の要求に合わせて、ダイアグラムに未解決の障害だけを示すようにフィルターを含める必要があります。

障害の状態と重要度

障害の重要度レポートでは、各重要度のクラスごとにいくつの障害があるかを示します。例えば、致命的なエラー、主要な機能が機能しない、小さな問題などです。

障害の状態と実装モデル内での位置

障害のソース レポートでは、実装モデルの各要素の障害の分散を示します。

障害エイジング レポート ページの先頭へ

障害エイジング レポートでは、テストと障害除去の効率について有効なフィードバックを提供します。例えば、古い、未解決の障害の大多数が検証中の状態にある場合、再テストのリソースが十分でない可能性があります。

障害傾向レポート ページの先頭へ

障害傾向レポートでは、障害率を識別することで、テストの大きな一助となります。テスト サイクル中の障害傾向は、非常に予測しやすいパターンに従っています。障害は、サイクルの早期では障害率は速いスピードで上昇し、その後ピークに達した後は、長い時間をかけて遅い速度で減少していきます。

 

問題を検出するために、この傾向を考慮に入れてプロジェクト スケジュールを再検討することも可能です。例えば、4 週間のテスト サイクルの第 3 週に、まだ障害率が上昇しているなら、そのプロジェクトがスケジュール通りに進捗していないことは明らかです。

この単純な傾向分析は、障害が直ちに修正されて、次のビルドでその修正がテストされると想定しているので、障害の処理率は障害発見率と同じプロフィールに準じることになります。この通りにならない場合、それはそれは障害解決プロセスに問題があることを意味します。つまり、障害の修正リソース、再テストされたリソース、修正の検証などが不適切であった可能性があります。

このレポートに反映される傾向では、プロジェクトの早期に新たに発見され、直ちに未処理状態と識別された障害は、経時的に数を減らしていくことが示されます。未解決の障害は、新しい障害の傾向に類似しますが、数は多少減ります。障害修正の傾向は、未解決の障害が修正、検証されていくにつれ、経時的に増加します。これらの傾向は、作業の成功を表しています。

つまり傾向がこれから大きく外れる場合には、問題があり、特定の開発、テスト作業にリソースの追加が必要であることが示唆されています。

障害分析とテスト カバレッジの基準とを組み合わせると、テスト完了基準のベースとなる、非常に有効な評価となります。

性能基準 ページの先頭へ

テスト対象の性能の振る舞いを評価し、応答時間、タイミング プロフィール、実行フロー、運用上の信頼性、制約などの振る舞いに関するデータを収集するために、多くの基準が用いられています。これらの基準は主にテストの評価作業で算定されますが、テストの実行時にテストの進捗と状態を評価するためには性能基準が用いられます。

主要な性能基準には次の通りです。

  • 動的監視 — テスト中に実行される各テスト スクリプトのステータスと状態のリアルタイムでの把握と表示。
  • 応答時間とスループット レポート — 特定のアクターやユース ケースに関する、テスト対象の応答時間やスループットの測定。
  • 百分率レポート — データ収集値の百分率と計算。
  • 比較レポート — 異なるテスト結果を示す 2 つまたはそれ以上のデータ間の相違、傾向。
  • トレース レポート — アクター (テスト スクリプト) とテスト対象の間のメッセージや会話の詳細。

動的監視 ページの先頭へ

動的監視では、テスト実行中に、棒グラフやグラフの形でリアルタイムで表示とレポートを行います。レポートでは、テスト スクリプトの現在の状態、ステータス、進捗を示すことにより、性能テストの実行を監視、評価します。

keymeas4.gif (4149 bytes)

例えば、上に示した棒グラフでは、同じユース ケースを実行する 80 のテスト スクリプトがあります。このうち、14 のテスト スクリプトがアイドル、12 がクエリー34 が SQL 実行、4 が SQL 接続、16 がその他の状態になっています。テストの進捗につれ、これらのスクリプトの数は変化していきます。表示には、普通に実行され、実行の中ごろにあるテストの典型例が示されるでしょう。しかし、テスト スクリプトが特定の状態に留まり続けたり、テスト実行中に変化がない場合には、テストの実行に問題があるか、他の性能基準を評価する必要があることを示唆しています。

応答時間とスループット レポート ページの先頭へ

応答時間とスループット レポートでは、名前の通り、時間とスループット (処理されたトランザクション数) に関係する性能の振る舞いを測定し算出します。通常、このレポートでは、「y」軸を応答時間 (トランザクション数)、「x」軸をイベントとしたグラフを示します。

keymeas5.gif (6939 bytes)

実際の性能の振る舞いを確認できるだけでなく、データ値の平均と標準偏差のような、統計的情報の計算結果を確認できることは往々にして重要です。

百分率レポート ページの先頭へ

百分率レポートでは、収集されたデータ タイプごとの人口率を表示することで、もう 1 つの統計的な計算結果を提示します。

keymeas6.gif (5644 bytes)

比較レポート ページの先頭へ

ある性能テスト結果を別の結果と比較することは重要であり、これによって性能の振る舞いに関するテスト間で行われた変更の影響を評価することができます。比較レポートを用い、2 つのデータ群 (それぞれ異なるテスト結果を示すもの) の比較をしたり、複数のテスト間の傾向を比較したりすることができます。

トレースとプロフィール レポート ページの先頭へ

性能の振る舞いが許容可能である場合や、性能の監視によりボトルネックの潜在を示唆された場合 (テスト スクリプトが長い期間一定の状態に留まり続けるなど)、トレース レポートは最も有用なレポートとなります。トレースとプロフィール レポートは、低レベルの情報をレポートします。この情報には、アクターテスト対象、実行フロー、データ アクセス、関数、システム コール間のメッセージが含まれます。



Rational Unified Process   2003.06.15