ソフトウェア テスト メトリクス: 種類と例とは
トーマス・ハミルトン
⚡ スマートサマリー
ソフトウェアテストメトリクスは、テストプロセスの進捗状況、品質、生産性を定量的に測定する指標です。このガイドでは、3種類のメトリクス、基本値と計算値の区別、メトリクスのライフサイクル、そしてすぐに適用できる数式用語集について解説します。
ソフトウェアテストの指標とは何ですか？
ソフトウェアテストのメトリクス ソフトウェア テスト プロセスの進捗状況、品質、生産性、健全性を推定するために使用される定量的な尺度です。 ソフトウェア テスト メトリクスの目標は、ソフトウェア テスト プロセスの効率と有効性を向上させ、テスト プロセスに関する信頼できるデータを提供することで、その後のテスト プロセスに対するより適切な意思決定を支援することです。
指標とは、システム、コンポーネント、またはプロセスが特定の属性をどの程度備えているかを定量的に表すものです。分かりやすい例としては、自動車の実際の週間の燃料消費量とメーカーが公表している数値との比較が挙げられます。
ソフトウェア テストのメトリクス – ソフトウェア テスト プロセスの効率と有効性を向上させます。
ソフトウェア テスト メトリクスまたはソフトウェア テスト測定は、プロセスまたは製品の何らかの属性の範囲、容量、次元、量、またはサイズを定量的に示します。
ソフトウェアテスト測定例: 欠陥の総数
テスト指標が重要な理由とは？
「測定できないものは改善できない。」テスト指標は、テストプロセスを測定可能にするために存在する。
- 次の活動段階は何をすべきか決定する
- 品質に関する主張や予測の根拠となる証拠を提示する
- どのような改善が必要かを特定する
- プロセスまたは技術の変更を正当化する
詳細についてはこちらをご覧ください テスト指標の重要性
テスト指標の種類
- プロセスメトリクス: SDLC のプロセス効率を向上させるために使用できます (ソフトウェア開発ライフサイクル)
- 製品メトリクス: ソフトウェア製品の品質を扱います
-
プロジェクトの指標: プロジェクト チームやその他の組織の効率を測定するために使用できます。 テストツール チームメンバーによって使用されている
多くの指標を収集することよりも、適切な指標を選択することの方が重要です。指標のセットを決定する前に、以下の点を考慮してください。
- 指標準備の対象ユーザーを修正する
- 指標の目標を定義する
- プロジェクトのニーズに基づいて、関連するすべての指標を導入します
- 各指標のコストとメリット、そしてそれが最も価値を発揮するプロジェクトライフサイクルフェーズを比較検討する。
手動テストの測定基準
In ソフトウエアエンジニアリング, 手動テストの指標は XNUMX つのクラスに分類されます。
- 基本メトリクス
- 計算されたメトリック
基本メトリクスは、テスト ケースの開発および実行中にテスト アナリストによって収集された生データです (実行されたテスト ケースの数、テスト ケースの数）。 一方、計算されたメトリクスは、基本メトリクスで収集されたデータから派生します。 計算されたメトリクスは、通常、テスト レポートの目的でテスト マネージャーによって追跡されます (完了率 (%)、テスト カバレッジ (%)).
プロジェクトやビジネスモデルによって異なりますが、最も重要な指標は通常以下のとおりです。
- テストケース実行の生産性指標
- テストケース準備の生産性指標
- 欠陥メトリクス
- 優先度別の欠陥
- 重大度別の欠陥
- 欠陥ずれ率
手動テストと自動テストの指標の比較
上記の指標は、手動で実行されるテストスイートを前提としています。自動化されたテストスイートは、実行にかかる労力が制約とならないため、測定方法が異なります。
| 基準 | 手動テストの指標 | 自動化テストの指標 |
|---|---|---|
| 主な焦点 | 努力と実行の進捗状況 | カバー範囲、安定性、および実行時間 |
| 標準的な測定値 | 1日あたりのテストケース実行数 | 自動化の普及率 |
| 品質信号 | 検査時間あたりの発見欠陥数 | 不安定なテストの割合、不安定なテストの割合 |
| コスト対策 | テスターの勤務時間 | リリースごとのスクリプト保守時間 |
| 速度測定 | 周期期間（日数） | スイートの実行時間（分） |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
テストの実施率が低い場合は特に注意が必要です。実施率が約5%を超えると、チームはテスト失敗（レッドビルド）を無視し始め、その時点でテストスイートはカバレッジの高さに関わらず情報を提供しなくなります。
ソフトウェアエンジニアリングにおけるテストメトリクスのライフサイクル
| メトリクスのライフサイクルのさまざまな段階 | 各ステージの手順 |
|---|---|
| 分析 |
|
| 意思疎通をします |
|
| 評価 |
|
| 外部リンク：レポート |
|
テスト指標の計算方法
| シニア# | メトリクスをテストする手順 | 例: |
|---|---|---|
| 1 | キーを特定する ソフトウェアテスト 測定対象のプロセス | テストの進捗状況 tracキングプロセス |
| 2 | このステップでは、テスターはデータをベースラインとして使用してメトリクスを定義します。 | XNUMX 日あたりに実行される予定のテスト ケースの数 |
| 3 | 追跡すべき情報の決定、頻度 trac国王と責任者 | XNUMX 日あたりの実際のテスト実行は、その日の終わりにテスト マネージャーによって記録されます。 |
| 4 | 定義された指標の効果的な計算、管理、解釈 | XNUMX 日に実行される実際のテストケース |
| 5 | 定義された指標の解釈に応じて改善の領域を特定する | If テストケース 実行状況が合意された目標を下回った場合は、原因を調査し、是正措置を提案する。 |
テスト指標の計算例
実行されたテストケースの割合を例として考えてみましょう。実行状況をパーセンテージで表すには、次の式を使用します。
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
250個のテストケースが作成され、175個が実行された場合、結果は(175 / 250) x 100 = 70パーセント.
他のすべての実行パラメータ（未実行、合格、失敗、ブロックされたテストケース）にも同様のパターンが適用されます。それぞれは、同じ分母に対する異なる分子にすぎません。
最も重要なテスト指標 Track
このチュートリアルの最後にある用語集には、よく使われるすべての数式が掲載されています。実際には、レポートに必要な数式は8つを超えることはほとんどありません。これらは、意思決定を左右する重要な数式です。
| メトリック | 答えは | 気をつけて |
|---|---|---|
| テストケース実行率 | 計画していた走行コースのどのくらいまで進んだでしょうか？ | 品質については何も語っておらず、進歩についてのみ語っている。 |
| 欠陥密度 | 単位サイズあたりの欠陥数で考えると、どのモジュールが最も弱いのか？ | 一貫したサイズ測定に依存します |
| 欠陥除去効率 | リリース前に発見できた欠陥の割合はどれくらいだったでしょうか？ | 生産データが到着してから最終決定できます |
| 欠陥漏洩 | 顧客に届いた不良品は何件でしたか？ | 最も重要な品質シグナル |
| テストカバレッジ | 要件セットのうち、どの程度が実際に実施されているか？ | 根拠の薄い主張による過剰な報道は何の証明にもならない |
| 欠陥重大度指数 | 開いている欠陥は深刻なものですか、それとも外観上のものですか？ | 重み付けをせずに欠陥数を数えることは誤解を招く |
| 平均修復時間 | チームはどれくらいの速さで問題を解決してくれるのか？ | いくつかの長期にわたる欠陥によって歪められている |
| テスト実行の生産性 | テスターは1日に何件の案件を処理しますか？ | ターゲットとして使用すると浅いテストを助長する |
経営陣がよく求める2つの公式を用語集に追加しておくと良いでしょう。
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
測定の罠。 目標として使用される指標は、いずれ適切な指標ではなくなります。例えば、1日30件のテストケースという生産性目標を設定すれば、テスターは30件とも些細なテストケースを作成するでしょう。指標は単独で報告するのではなく、セットとして報告し、すべての生産性指標には品質指標を関連付けてください。
ソフトウェアテスト指標の計算式用語集
- 手戻り工数の比率 = (そのフェーズで費やされた実際のリワーク工数/そのフェーズで費やされた実際の工数の合計) X 100
- 要件クリープ = (追加された要件の総数/初期要件の数)X100
- スケジュールの差異 = (実際の配達日 – 配達予定日)
- テストで欠陥を見つけるコスト = (テストに費やした総労力/テストで見つかった欠陥)
- スケジュールの遅れ = (実際の終了日 – 終了予定日) / (終了予定日 – 開始予定日) X 100
- 合格したテストケースの割合 = (合格したテストの数/実行されたテストの総数) X 100
- 失敗したテストケースの割合 = (失敗したテストの数/実行されたテストの総数) X 100
- ブロックされたテストケースの割合 = (ブロックされたテストの数/実行されたテストの総数) X 100
- 修正された欠陥の割合 = (修正された欠陥/報告された欠陥) X 100
- 受け入れられた欠陥の割合 = (開発チームが有効と認めた欠陥数 / 報告された欠陥の総数) X 100
- 欠陥の延期率 = (将来のリリースに延期された欠陥数 / 報告された欠陥の総数) X 100
- 重大な欠陥の割合 = (重大な欠陥数 / 報告された欠陥の総数) X 100
- 開発チームが欠陥を修復するのにかかる平均時間 = (バグ修正にかかった合計時間/バグの数)
- 期間ごとに実行されるテストの数 = 実行されたテストの数/合計時間
- テスト設計の効率化 = 設計されたテストの数 / 合計時間
- テストレビューの効率化 = レビューされたテストの数 / 合計時間
- バグ発見率または、テスト時間あたりの欠陥数 = 欠陥総数 / テスト時間総数
