ソフトウェア テスト メトリクス: 種類と例とは
トーマス・ハミルトン
ソフトウェアテストにおけるテストメトリクス
ソフトウェアテストのメトリクス ソフトウェア テスト プロセスの進捗状況、品質、生産性、健全性を推定するために使用される定量的な尺度です。 ソフトウェア テスト メトリクスの目標は、ソフトウェア テスト プロセスの効率と有効性を向上させ、テスト プロセスに関する信頼できるデータを提供することで、その後のテスト プロセスに対するより適切な意思決定を支援することです。
メトリックは、システム、システム コンポーネント、またはプロセスが特定の属性をどの程度保有しているかを定量的な用語で定義します。指標を理解するための理想的な例は、メーカーが推奨する理想的な走行距離と比較した車の週間走行距離です。
ソフトウェア テストのメトリクス – ソフトウェア テスト プロセスの効率と有効性を向上させます。
ソフトウェア テスト メトリクスまたはソフトウェア テスト測定は、プロセスまたは製品の何らかの属性の範囲、容量、次元、量、またはサイズを定量的に示します。
ソフトウェアテスト測定例: 欠陥の総数
テスト指標が重要な理由
"We cannot improve what we cannot measure" and Test Metrics helps us to do exactly the same.
- 活動の次の段階について決定する
- 主張または予測の証拠
- 必要な改善の種類を理解する
- 意思決定、プロセス、テクノロジーの変更を行う
詳細についてはこちらをご覧ください テスト指標の重要性
テスト指標の種類
- プロセスメトリクス: SDLC のプロセス効率を向上させるために使用できます (ソフトウェア開発ライフサイクル)
- 製品メトリクス: ソフトウェア製品の品質を扱います
-
プロジェクトの指標: プロジェクト チームやその他の組織の効率を測定するために使用できます。 テストツール チームメンバーによって使用されている
正しいテスト指標を特定することは非常に重要です。 テスト指標を特定する前に考慮する必要があることはほとんどありません
- 指標準備の対象ユーザーを修正する
- 指標の目標を定義する
- プロジェクトのニーズに基づいて、関連するすべての指標を導入します
- 各指標のコストメリットの側面と、それが最大の成果をもたらすプロジェクトのライフスタイルフェーズを分析します。
手動テストの測定基準
In ソフトウエアエンジニアリング, 手動テストの指標は XNUMX つのクラスに分類されます。
- 基本メトリクス
- 計算されたメトリック
基本メトリクスは、テスト ケースの開発および実行中にテスト アナリストによって収集された生データです (実行されたテスト ケースの数、テスト ケースの数）。 一方、計算されたメトリクスは、基本メトリクスで収集されたデータから派生します。 計算されたメトリクスは、通常、テスト レポートの目的でテスト マネージャーによって追跡されます (完了率 (%)、テスト カバレッジ (%)).
プロジェクトまたはビジネス モデルに応じて、重要な指標の一部は次のとおりです。
- テストケース実行の生産性指標
- テストケース準備の生産性指標
- 欠陥メトリクス
- 優先度別の欠陥
- 重大度別の欠陥
- 欠陥ずれ率
ソフトウェアエンジニアリングにおけるテストメトリクスのライフサイクル
| メトリクスのライフサイクルのさまざまな段階 | 各ステージの手順 |
|---|---|
| 分析 |
|
| 意思疎通をします |
|
| 評価 |
|
| 外部リンク：レポート |
|
テストメトリクスの計算方法
| シニア# | メトリクスをテストする手順 | 例: |
|---|---|---|
| 1 | キーを特定する ソフトウェアテスト 測定対象のプロセス | テストの進捗状況の追跡プロセス |
| 2 | このステップでは、テスターはデータをベースラインとして使用してメトリクスを定義します。 | XNUMX 日あたりに実行される予定のテスト ケースの数 |
| 3 | 追跡する情報、追跡の頻度、責任者の決定 | XNUMX 日あたりの実際のテスト実行は、その日の終わりにテスト マネージャーによって記録されます。 |
| 4 | 定義された指標の効果的な計算、管理、解釈 | XNUMX 日に実行される実際のテストケース |
| 5 | 定義された指標の解釈に応じて改善の領域を特定する | その テストケース 設定した目標を達成できていない場合は、原因を調査し、改善策を提案する必要があります。 |
テスト指標の例
テスト メトリクスの計算方法を理解するために、実行されたテスト ケースの割合の例を見てみましょう。
テスト ケースの実行ステータスをパーセンテージで取得するには、次の式を使用します。
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
同様に、他のパラメータについても計算することができます。 テスト ケースが実行されなかった、テスト ケースが成功した、テスト ケースが失敗した、テスト ケースがブロックされたなど。
テスト指標の用語集
- 手戻り工数の比率 = (そのフェーズで費やされた実際のリワーク工数/そのフェーズで費やされた実際の工数の合計) X 100
- 要件クリープ = (追加された要件の総数/初期要件の数)X100
- スケジュールの差異 = (実際の配達日 – 配達予定日)
- テストで欠陥を見つけるコスト = (テストに費やした総労力/テストで見つかった欠陥)
- スケジュールの遅れ = (実際の終了日 – 終了予定日) / (終了予定日 – 開始予定日) X 100
- 合格したテストケースの割合 = (合格したテストの数/実行されたテストの総数) X 100
- 失敗したテストケースの割合 = (失敗したテストの数/実行されたテストの総数) X 100
- ブロックされたテストケースの割合 = (ブロックされたテストの数/実行されたテストの総数) X 100
- 修正された欠陥の割合 = (修正された欠陥/報告された欠陥) X 100
- 受け入れられた欠陥の割合 = (開発チームが有効と認めた欠陥数 / 報告された欠陥の総数) X 100
- 欠陥の延期率 = (将来のリリースに延期された欠陥数 / 報告された欠陥の総数) X 100
- 重大な欠陥の割合 = (重大な欠陥数 / 報告された欠陥の総数) X 100
- 開発チームが欠陥を修復するのにかかる平均時間 = (バグ修正にかかった合計時間/バグの数)
- 期間ごとに実行されるテストの数 = 実行されたテストの数/合計時間
- テスト設計の効率化 = 設計されたテストの数 / 合計時間
- テストレビューの効率化 = レビューされたテストの数 / 合計時間
- バグ発見の丸暗記またはテスト時間当たりの欠陥数 = 欠陥総数/テスト時間総数
