1 測試覆蓋率
計算公式：已設計測試用例的需求數/需求總數。
測試覆蓋率從緯度上說包括廣度覆蓋和深度覆蓋；從內容上說包括用戶場景覆蓋、功能覆蓋、功能組合覆蓋、系統場景覆蓋。
首先說廣度，是否需求規格說明書中的每個需求項都在測試用例中得到設計。其次說深度，通俗的說，是不使我們的測試設計流于表面，是否能夠透過客戶需求文檔，挖掘出可能存在問題的地方。例如：重復點擊某個按鈕10次，或者依次執行新增、刪除、新增同一數據的記錄、再次刪除該記錄操作。在筆者的實際工作中碰到過這么一個例子，一個使用PL/SQL編寫的系統，在某個查詢界面，重復點擊《查詢》按鈕6次后，系統就會出現查詢功能失效的問題。經調試，開發人員發現是由于gdi資源未完全釋放的緣故。
在設計測試用例時，我們很少單獨設計廣度或深度方面的測試用例，而一般是結合在一起設計。為了從廣度和深度上覆蓋測試用例，我們需要考慮設計各種測試用例，如：用戶場景（識別最常用的20%的操作）、功能點、功能組合、系統場景、性能、語句、分支等。在執行時，需要根據測試時間的充裕程度按照一定的順序執行。通常是先執行用戶場景的測試用例，然后再執行具體功能點、功能組合的測試。
測試覆蓋率數據的收集，我們可以通過需求跟蹤矩陣RTM來實現。在需求跟蹤矩陣，測試人員填寫的“系統測試用例”列的數據，如圖一所示。測試人員通過計算RTM列出的需求數量，和已設計測試用例的需求數量，可以快速的計算出測試覆蓋率。通過RTM，測試人員，包括項目組成員都可以很清楚的、快速的知道當前這個項目測試的測試覆蓋情況。
圖一 需求跟蹤矩陣例子
注：本RTM例子中，筆者將“概要設計”、“詳細設計”、“編碼”等列隱藏，只顯示與測試覆蓋率計算有關的內容。
2測試執行率
執行率，顧名思義，就是指實際執行過程中確定已經執行的測試用例比率。
計算公式：已執行的測試用例數/設計的總測試用例數。
讀者肯定覺得很奇怪了，我們設計的測試用例肯定都是要執行的，即使是按模塊來執行測試，那該模塊的測試執行率肯定是100%，為什么還要設置這個指標？
其實不然。在實際測試過程中，經常有如下這種情況發生。一種情況是，因為系統采用迭代方式開發，每次Build時都有不同的重點，包含不同的內容；第二種情況是，由于測試資源的有限，不可能每次將所有設計的測試內容都全部測試完畢。由于這兩種情況的存在，所以在每次執行測試時，我們會按照不同的測試重點和測試內容來安排測試活動，所以就存在了“測試執行率”這個指標。
通常，我們的測試目標是確保100%的測試用例都得到執行，即執行率為100%。但是，如前面所提到的，實際中可能存在非100%的執行率。如果不能達到100%的測試執行率，那么我們需要根據不同的情況制定不同的測試執行率標準——主要考慮風險、重要性、可接受的測試執行率。在考慮可接受的測試執行率時，就涉及到了測試用例執行順序的問題。
在設計測試用例時，我們需要從廣度和深度上盡可能的覆蓋需求，所以我們就需要設計各種測試用例，如正常的測試用例、異常的測試用例、界面的測試用例等。但是在執行時，測試人員需要根據項目進度和測試時間的充裕程度，參考測試執行率標準，將測試用例按照一定的順序執行。通常是先執行用戶場景對應的測試用例，然后再執行具體功能點、功能組合的測試，完成這些測試后，再進行其它測試，如系統場景、性能、語句等測試。
例如，某項目共設計了280個測試用例。該項目某一階段的測試共分四個版本，其中有一個版本執行了134個測試用例，那么該版本的測試執行率為47.9%。
3測試執行通過率
文章來源于領測軟件測試網 http://www.kjueaiud.com/
