テストのメトリクス
テストのメトリクスは、テストの網羅性やテストの欠陥検出能力を扱うものです。テスト自動化では、一例として以下の目的で活用できます。
- 自動化対象のテストが妥当か評価する[2]
- テスト設計・テスト実装を自動化した際に、生成したテストケース・テストスクリプトが問題ないか確認する
- 自動テストに不具合がないか確認する
なお、ギア本では、テストのメトリクスをテストの有効性とテストの徹底性の2つの特性で分類して解説しています。
注
[2]: 良いテストを自動化してこそよいテスト自動化となります。ゴミテストを自動化しても自動ゴミテストにしかなりません。
「テストの有効性」のメトリクス
まずギア本におけるテストの有効性のメトリクスは、テストがきちんとバグを抽出したか、という視点のメトリクスとしています。
テストの有効性のメトリクスに関して、ギア本では、以下の計算で算出される欠陥検出率（DDP）を重視しています。
欠陥検出率（DDP）＝
計測対象で検出された欠陥数
計測対象以降で検出された欠陥数
例えば、計測対象を単体テスト工程とした場合、分子は「単体テスト工程での検出欠陥数」、分母は「単体テスト工程と、それ以降で検出された検出欠陥数」となる。なお「それ以降で検出された」というスコープは実際には扱いが難しいので、「製品リリース後6ヶ月経過したまでに」といったスコープに置き換えることもある。
このDDPは、主に次の3つの用途に使えます。
- テスト開始前に各工程のDDPの見積もりを出し、それを各工程の欠陥検出目標とする
- プロジェクト実施中は、DDPの見積もり値と、実際の測定量の乖離を監視して、テストに問題がないか、見積もりが楽観的過ぎていなかったかをリアルタイムで把握する。問題があれば是正を行う
- プロジェクト活動後などにDDPを計測して、プロジェクトの各工程の欠陥検出手段が有効だったか評価する。結果は次のプロジェクトや他のプロジェクトの改善にフィードバックする
ちなみに国内では、類似のメトリクスとして、欠陥除去率（対象工程で除去した欠陥数 / 対象工程で存在した欠陥数）が多く使用されています。
その他、ギア本では、テストの有効性のメトリクスとして、
- 欠陥修正率（DFP）＝ 修正された欠陥数 / 検出された全ての欠陥数
- テストの信頼性についての、有識者からの意見の集計
を紹介しています。後者については、属人性の高い計測アプローチとなりますが、計測の穴の補完で活用できる場が意外とあると感じています。
「テストの徹底性」のメトリクス
次にテストの徹底性のメトリクスについてですが、こちらはテストがどれぐらい徹底的に対象を網羅しているか、という視点で計測します。具体的なメトリクスとして、ギア本では「有識者についての徹底性の意見の集計」と「テストカバレッジ（ステートメントカバレッジ、データフローカバレッジ、LCSAJなど）」を紹介しています。
このうちテストカバレッジは、テスト自動化でも定番のメトリクスです。ギア本ではコードに対するカバレッジの解説が中心ですが、それ以外も数多くあります。具体例を以下に列挙します。
- コードに対するカバレッジ
- コードの網羅性：C1・C2・MC/DCカバレッジ、ループカバレッジ、その他ログ出力の網羅性など
- 仕様に対するカバレッジ
- 状態遷移モデルに対する網羅性、画面遷移モデルに対する網羅性、仕様のデシジョンテーブルの網羅性
- 外部基準に対するカバレッジ
- 標準のチェックリスト履行についての網羅性、外部の規格や標準に対する網羅性
一般的に、DDPのような欠陥流出についてのメトリクスには、製品リリース後での計測といった事後評価にならざるを得ないというデメリットがあります。それに対し、テストカバレッジは作業中でも手軽に計測できます。そのため、現場のエンジニアの方にとって使いやすいメトリクスといえます。
なお、テストカバレッジでは「コードに対するカバレッジ」が定番ですが、テスト設計の自動化では「仕様に対するカバレッジ」の自動計測も有効です。自動テストが妥当かどうかの判断が容易になりますし、仕様からテストケースを生成するモデルベーステストの導入を支えるためです。
ちなみにテストのメトリクスは単独では情報が不足しがちです。そのため筆者も「テストの有効性」「テストの徹底性」の両方から複数のメトリクスを使って総合的に計測することが多いです。
自動テストのメトリクス
次に、もう1つのテスト自動化のメトリクスである自動テストのメトリクスについて説明します。こちらは自動テストの環境やスクリプトの品質を計測するものです。
前提として、自動テスト環境は、システムあるいはソフトウェアの一種といえます。そのため自動テストのメトリクス計測では、一般的に知られたシステム・ソフトウェアの品質モデルやメトリクスセットを直接参考にできます。例えば最近ですと、ISO/IEC 25000シリーズは、自動テストのメトリクスセットとしても活用できます。
ギア本でも、保守性、効率性、ユーザビリティといった、当時一般的だったソフトウェアの品質モデルに基づいてメトリクスを提示しています。 紹介までに、ギア本で解説されている自動テストのメトリクスの一部を紹介します。
| 項目 | メトリクス |
|---|---|
| 保守性 | テスト1つの変更に必要な工数、ソフトウェアの変更の発生頻度 |
| 効率性 | 特定のタスクに必要な工数、テストの実施時間、テストのセットアップ時間、テストの結果確認時間 |
| 信頼性 | 偽陽性の失敗数、偽陰性の失敗数、テスト環境起因のテスト失敗数 |
| 柔軟性 | テスト対象の修正時間、目的に見合ったテストを特定するのに必要な時間 |
| ユーザビリティ | テストの追加に必要な工数、自動テスト環境が要求する教育時間、自動テスト環境の良否の意見集計 |
| 堅牢性 | テスト環境のMTBF、テストの不具合調査時間 |
| 移植性 | 新しい環境への対応工数、テストツール対応工数 |
なお筆者の場合、まず機能適合性のメトリクスは大前提として計測しています。そしてテスト自動化で課題になりがちな点で、保守性（テスト対象の変更の受け入れやすさ、テストの保守コスト）、信頼性（テストケースを正確に実施できているか）、効率性（テスト実施のスピード、テスト実施の楽さ）を重視することが多いです。
