1. 測試廣度的測量提供了多少需求（在所有需求的數目中）在某一時刻已經被測試，來度量測試計劃的執行、測試進度等狀態；
2. 測試深度是對被測試覆蓋的獨立基本路徑占在程序中的基本路徑的總數的百分比的測度，基本路徑數目的度量可以用McCabe環形計算復雜度方法來計算。
3. 過程中收集的缺陷數度量，發現的、修正的和關閉的缺陷數量在過程中的差異、發展趨勢等，為過程質量、開發資源額外投入、軟件發布預測提供重要依據。
如前所述，測試過程的度量可以將過程狀態度量和過程結果度量結合起來分析，是測試過程度量更有效。
在測試階段，主要的過程質量度量有：
* 缺陷度量或缺陷分布度量
* 測試用例的深度、質量和有效性
* 測試執行的效率和質量
* 缺陷報告的質量
* 測試覆蓋度（測試整體的質量）
* 測試環境的穩定性或有效性
缺陷度量是測試階段的主要度量內容，包括產品缺陷度量和缺陷過程度量。產品缺陷度量將在下一回做詳細介紹，而測試環境的穩定性或有效性度量，就像軟件有效性一樣，用MTTF來測量。所以下面將簡單介紹其他度量內容，如 軟件缺陷到達模式、PTR出現/積壓模型、測試用例的度量、基于需求的測試覆蓋評估、基于代碼的測試覆蓋評估等等。
1. 基于時間的缺陷到達模式
產品的缺陷密度、或者測試階段的缺陷率是一個概括性指標，缺陷到達模式可以提供更多的過程信息，有時即使得到的整體缺陷率是一樣的，但其質量差異可能較大，原因就是缺陷到達的模式不一樣。越多的缺陷到達越早，則測試過程質量就越好。無論是從測試進展的觀點，還是從用戶重新發現(customer rediscoveries)的觀點來看，缺陷的過程跟蹤是非常重要的，開發周期里大量的嚴重缺陷將有可能阻止測試的進展，也必然直接影響軟件產品的質量和性能。
相對產品發布時間、上一個版本的缺陷水平來說，經常會被項目經理或開發經歷問的就是：
* 缺陷何時到達峰值？這個峰值有時多少？
* 在到達峰值后又要化多少時間趨于（降低）到一個低而穩定的水平？
* 低而穩定的水平持續多少時間，當前版本可以發布？
回答這些問題，正是缺陷達到模式要實現的目標。定性的分析比較容易，測試團隊越成熟，峰值到達得越早，有時可以在第一周末或第二周就達到峰值。這個峰值的數值取決于代碼質量、測試用例的設計質量和測試執行的策略、水平等，多數情況下，可以根據基線（或歷史數據）推得。從一個峰值達到一個低而穩定的水平，需要長得多的時間，至少是達到峰值所用的時間的4-5倍。這個時間取決于峰值、缺陷移除效率等等。
2. PTR累積模型
測試的目標在于盡早地發現軟件缺陷，通過測試用例可以更有效、更快地發現軟件中缺陷，而軟件缺陷通過PTR（問題跟蹤報告，Problem Tracking Report）來描述。因此，PTR的數量一定程度上代表了軟件的質量。每個缺陷/PTR都有一個生命周期，從測試人員發現問題并形成報告（稱為PTR出現，也稱缺陷到達），開發/設計人員要重現、修正這個PTR/缺陷，并構建、提交包含已修正PTR/缺陷的新軟件包(New Build)給測試組，所修正的問題得到驗證直到該問題通過測試為止（稱為PTR關閉），測試過程中特定時間PTR保持的數量（所有新發現的PTR和關閉的PTR的差值）——PTR累積/積壓值。PTR出現／累積模型就是根據問題跟蹤報告的兩種數據——某個時間單位內的PTR出現值和某個時間PTR累積值來度量測試中所發現的缺陷變化過程，即軟件產品質量狀態的變化過程。
3．測試用例的深度、質量和有效性
測試用例是測試執行的基礎，其質量的好壞直接關系到測試的質量，也就影響著軟件質量的保證過程。測試用例的度量將包含測試用例的深度、質量和有效性，而且包含自動化程度的度量，即多少比例的測試用例已被自動化了。
測試用例的深度（TCD, Test Case Depth）度量可以表示為每KLOC的測試用例數或每個功能點/對象點的測試用例數，而測試用例的效率可以用每100或1000個測試用例所發現的缺陷數來衡量，不同的測試階段是不一樣，應該對同一階段的不同版本進行比較，而不宜對同一版本的不同階段進行比較。而測試用例的質量（TCQ, Test Case Quality）可以用由測試用例發現的缺陷數量來度量，即
TCQ = 測試用例發現的缺陷數量/總的缺陷數量
因為還有一部分缺陷可以通過ad-hoc 測試（隨機、自由的測試）、集體走查(Work-through)和Fire-drill測試(類似消防訓練的用戶壓力/驗收測試)等其他手段發現缺陷。
文章來源于領測軟件測試網 http://www.kjueaiud.com/