軟件測試階段的過程度量內容或項目比較多，包括軟件測試進度、測試覆蓋度、測試缺陷出現/到達曲線、測試缺陷累積曲線、測試效率等。在進行測試過程度量時，要基于軟件規模度量（如功能點、對象點等）、復雜性度量、項目度量等方法，從三個不同的測度來完整度量測試的過程狀態：
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測試（類似消防訓練的用戶壓力/驗收測試）等其他手段發現缺陷。
4.測試執行的效率和質量
測試執行的質量一般可以用軟件發布后所遺留的軟件缺陷和總缺陷數的比值來衡量，一般要求低于0.5%，也可以通過種子公式或交叉測試等方法衡量。測試執行的效率可以用下列幾種方法來綜合度量：
* 每個人日所執行的測試用例數
* 每個人日所發現的缺陷數
* 每修改的KLOC所運行的測試用例數
5.缺陷報告的質量
正/關閉的（等級高的）缺陷和測試人員所報的所有（等級高的）缺陷的比值，這個值越接近1，有效性就越高，如果考察等級高的缺陷，其正常值大約在0.92 – 0.96
* 缺陷報告質量，可以用一些中間狀態為“需要補充信息”、“不是缺陷”的缺陷數量來衡量，一般占總缺陷數的3%-5%為正常，高于或低于這個值都可能不正常，高于5%，可能說明缺陷報告質量低；低于3%，可能說明測試人員缺少懷疑精神。
6.基于需求的測試覆蓋評估
基于需求的測試覆蓋評估是依賴于對已執行/運行的測試用例的核實和分析，所以基于需求的測試覆蓋評測就轉化為評估測試用例覆蓋率：測試的目標是確保100% 的測試用例全部成功地執行。一般在測試計劃中，就定義了測試的工作量、測試用例數量和測試用例覆蓋率（98%-100%），我們根據事先確定的測試日程安排，可以將測試計劃值做成曲線，然后根據實際執行結果，定期（每天或每周）去畫實際值曲線，從而可以進行測試全過程監控和預測。
在執行測試活動中，評估測試用例覆蓋率又可分為兩類測試用例覆蓋率估算：
* 確定已經執行的測試用例覆蓋率，即在所有測試用例中有多少測試用例已被執行。假定Tx已執行的測試過程數或測試用例數，Rft是測試需求的總數：
* 已執行的測試覆蓋 ＝ Tx／Rft
* 確定成功的測試覆蓋，即執行時未出現失敗的測試，如沒有出現缺陷或意外結果的測試，假定Ts是已執行的完全成功、沒有缺陷的測試過程數或測試用例數。
* 成功的測試覆蓋 ＝ Ts／Rft
7.基于代碼的測試覆蓋評估
基于代碼的測試覆蓋評測是對被測試的程序代碼語句、路徑或條件的覆蓋率分析。如果應用基于代碼的覆蓋，則測試策略是根據測試已經執行的源代碼的多少來表示的。這種測試覆蓋策略類型對于安全至上的系統來說非常重要。
評估代碼覆蓋率，需要斷定測試目標期望的、總的測試代碼行數，在測試中真正執行的代碼行數及其百分比，將此結果記錄在測試評估報告中。測試過程中已經執行的代碼的多少，與之相對的是要執行的剩余代碼的多少。代碼覆蓋可以建立在控制流（語句、分支或路徑）或數據流的基礎上�？刂屏鞲采w的目的是測試代碼行、分支條件、代碼中的路徑或軟件控制流的其他元素。數據流覆蓋的目的是通過軟件操作測試數據狀態是否有效，例如，數據元素在使用之前是否已經定義。
基于代碼的測試覆蓋通過以下公式計算：
已執行的測試覆蓋 ＝ Tc／Tnc
其中Tc是用代碼語句、條件分支、代碼路徑、數據狀態判定點或數據元素名表示的已執行項目數，Tnc（Total number of items in the code）是代碼中的項目總數。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
