測試度量指標介紹.doc

測試度量指標介紹在CMMI4體系的測試過程中定義了四個度量指標：測試覆蓋率、測試執(zhí)行率、測試執(zhí)行通過率、測試缺陷解決率。為了使專/兼職測試人員理解這四個度量指標，了解如何利用現(xiàn)有資源收集度量數(shù)據(jù)，本文介紹這四個指標的含義及數(shù)據(jù)收集方法。1測試覆蓋率測試覆蓋率是指測試用例對需求的覆蓋情況。計算公式：已設(shè)計測試用例的需求數(shù)/需求總數(shù)。測試覆蓋率從緯度上說包括廣度覆蓋和深度覆蓋；從內(nèi)容上說包括用戶場景覆蓋、功能覆蓋、功能組合覆蓋、系統(tǒng)場景覆蓋。首先說廣度，是否需求規(guī)格說明書中的每個需求項都在測試用例中得到設(shè)計。其次說深度，通俗的說，是不使我們的測試設(shè)計流于表面，是否能夠透過客戶需求文檔，挖掘出可能存在問題的地方。例如：重復(fù)點擊某個按鈕10次，或者依次執(zhí)行新增、刪除、新增同一數(shù)據(jù)的記錄、再次刪除該記錄操作。在筆者的實際工作中碰到過這么一個例子，一個使用PL/SQL編寫的系統(tǒng)，在某個查詢界面，重復(fù)點擊查詢按鈕6次后，系統(tǒng)就會出現(xiàn)查詢功能失效的問題。經(jīng)調(diào)試，開發(fā)人員發(fā)現(xiàn)是由于gdi資源未完全釋放的緣故。在設(shè)計測試用例時，我們很少單獨設(shè)計廣度或深度方面的測試用例，而一般是結(jié)合在一起設(shè)計。為了從廣度和深度上覆蓋測試用例，我們需要考慮設(shè)計各種測試用例，如：用戶場景（識別最常用的20%的操作）、功能點、功能組合、系統(tǒng)場景、性能、語句、分支等。在執(zhí)行時，需要根據(jù)測試時間的充裕程度按照一定的順序執(zhí)行。通常是先執(zhí)行用戶場景的測試用例，然后再執(zhí)行具體功能點、功能組合的測試。測試覆蓋率數(shù)據(jù)的收集，我們可以通過需求跟蹤矩陣RTM來實現(xiàn)。在需求跟蹤矩陣，測試人員填寫的“系統(tǒng)測試用例”列的數(shù)據(jù)，如圖一所示。測試人員通過計算RTM列出的需求數(shù)量，和已設(shè)計測試用例的需求數(shù)量，可以快速的計算出測試覆蓋率。通過RTM，測試人員，包括項目組成員都可以很清楚的、快速的知道當前這個項目測試的測試覆蓋情況。圖一 需求跟蹤矩陣例子注：本RTM例子中，筆者將“概要設(shè)計”、“詳細設(shè)計”、“編碼”等列隱藏，只顯示與測試覆蓋率計算有關(guān)的內(nèi)容。 2測試執(zhí)行率執(zhí)行率，顧名思義，就是指實際執(zhí)行過程中確定已經(jīng)執(zhí)行的測試用例比率。計算公式：已執(zhí)行的測試用例數(shù)/設(shè)計的總測試用例數(shù)。讀者肯定覺得很奇怪了，我們設(shè)計的測試用例肯定都是要執(zhí)行的，即使是按模塊來執(zhí)行測試，那該模塊的測試執(zhí)行率肯定是100%，為什么還要設(shè)置這個指標？其實不然。在實際測試過程中，經(jīng)常有如下這種情況發(fā)生。一種情況是，因為系統(tǒng)采用迭代方式開發(fā)，每次Build時都有不同的重點，包含不同的內(nèi)容；第二種情況是，由于測試資源的有限，不可能每次將所有設(shè)計的測試內(nèi)容都全部測試完畢。由于這兩種情況的存在，所以在每次執(zhí)行測試時，我們會按照不同的測試重點和測試內(nèi)容來安排測試活動，所以就存在了“測試執(zhí)行率”這個指標。通常，我們的測試目標是確保100%的測試用例都得到執(zhí)行，即執(zhí)行率為100%。但是，如前面所提到的，實際中可能存在非100%的執(zhí)行率。如果不能達到100%的測試執(zhí)行率，那么我們需要根據(jù)不同的情況制定不同的測試執(zhí)行率標準主要考慮風(fēng)險、重要性、可接受的測試執(zhí)行率。在考慮可接受的測試執(zhí)行率時，就涉及到了測試用例執(zhí)行順序的問題。在設(shè)計測試用例時，我們需要從廣度和深度上盡可能的覆蓋需求，所以我們就需要設(shè)計各種測試用例，如正常的測試用例、異常的測試用例、界面的測試用例等。但是在執(zhí)行時，測試人員需要根據(jù)項目進度和測試時間的充裕程度，參考測試執(zhí)行率標準，將測試用例按照一定的順序執(zhí)行。通常是先執(zhí)行用戶場景對應(yīng)的測試用例，然后再執(zhí)行具體功能點、功能組合的測試，完成這些測試后，再進行其它測試，如系統(tǒng)場景、性能、語句等測試。例如，某項目共設(shè)計了280個測試用例。該項目某一階段的測試共分四個版本，其中有一個版本執(zhí)行了134個測試用例，那么該版本的測試執(zhí)行率為47.9%。3測試執(zhí)行通過率在介紹“測試執(zhí)行通過率”之前，需要說明測試用例的執(zhí)行結(jié)果定義。測試用例的執(zhí)行結(jié)果有以下四種定義：介紹了執(zhí)行結(jié)果定義后，我們來看測試執(zhí)行通過率。測試執(zhí)行通過率，指在實際執(zhí)行的測試用例中，執(zhí)行結(jié)果為“通過”的測試用例比率。計算公式：執(zhí)行結(jié)果為“通過”的測試用例數(shù)/實際執(zhí)行的測試用例總數(shù)。我們可以針對所有計劃執(zhí)行的測試用例進行衡量，可以細化到具體模塊，用于對比各個模塊的測試用例執(zhí)行情況。為了得到測試執(zhí)行通過率數(shù)據(jù)，我們在測試執(zhí)行時，需要在測試用例副本中記錄下每個測試用例的執(zhí)行結(jié)果，然后在當前版本執(zhí)行完畢，或者定期（如每周）統(tǒng)計當前測試執(zhí)行數(shù)據(jù)。通過原始數(shù)據(jù)的記錄與統(tǒng)計，我們可以快速的得到當前版本或當前階段的測試執(zhí)行通過率。下表是某項目某一測試版本使用測試用例執(zhí)行測試的統(tǒng)計數(shù)據(jù)：模塊測試執(zhí)行結(jié)果系統(tǒng)用例通過失敗阻塞忽略會員管理報名參賽（UC1）12004賽事查詢（UC2）5000比賽資格查詢（UC3）4003加入戰(zhàn)隊（UC4）18000組織我的戰(zhàn)隊（UC5）29000查詢我的戰(zhàn)隊（UC10）5000會員注冊11000修改會員資料9000基本信息管理比賽項目管理（UC6）12201賽區(qū)運營商（UC10）8100賽場管理（包括支持項目）（UC8）16000賽事管理賽事管理（UC9）22600戰(zhàn)隊管理（UC12）40000統(tǒng)計管理報名統(tǒng)計（UC13）9100系統(tǒng)參數(shù)管理系統(tǒng)參數(shù)配置（UC11）4000權(quán)限管理登錄系統(tǒng)5000操作員管理12000用戶組管理18100用戶密碼修改2000Session同步4000合計2451108通過計算可知，該測試版本的測試測試執(zhí)行通過率為92.8%。 4 缺陷解決率缺陷解決率，指某個階段已關(guān)閉缺陷占缺陷總數(shù)的比率。缺陷關(guān)閉操作包括以下兩種情況：正常關(guān)閉：缺陷已修復(fù)，且經(jīng)過測試人員驗證通過；強制關(guān)閉：重復(fù)的缺陷；由于外部原因造成的缺陷；暫時不處理的缺陷；無效的缺陷。這類缺陷經(jīng)過確認后，可以強制關(guān)閉。計算公式：已關(guān)閉的缺陷/缺陷總數(shù)在項目過程中，在開始時缺陷解決率上升很緩慢，隨著測試工作的開展，缺陷解決率逐步上升，在版本發(fā)布前，缺陷解決率將趨于100%，如圖二所示。一般來說，在每個版本對外發(fā)布時，缺陷解決率都應(yīng)該達到100%。也就是說，除了已修復(fù)的缺陷需要進行驗證外，其他需要強制關(guān)閉的缺陷必須經(jīng)過確認，且有對應(yīng)的應(yīng)對措施。可以將缺陷解決率作為測試結(jié)束和版本發(fā)布的一個標準。如果有部分缺陷仍處于打開或已處理狀態(tài)，那么原則上來說，該版本是不允許發(fā)布的。 圖二 缺陷解決率缺陷關(guān)閉數(shù)據(jù)，可以通過缺陷跟蹤工具定期（如每周）收集當前系統(tǒng)的缺陷數(shù)、已關(guān)閉缺陷數(shù)，通過這兩個數(shù)據(jù)，即可繪制出整