3. 評估階段
在確保輸入的 ODC 數據正確性的前提下，就可以對這些缺陷進行分析了。根據 ODC 的不同屬性進行分類統計，可得出不同方面的結論。以此來反映測試、開發或產品設計方面的問題，指出潛在的改進的機會。比如：缺陷被發現的如何、產品是否穩定等。下面挑幾個典型的評估方法進行說明。
對測試工作的評估
利用不同的 ODC 屬性的組合，可以從多方面來評估測試工作的完成情況。例如利用測試階段和 activity 屬性來評估是否應在某一測試階段中發現的缺陷卻被在下一測試階段中才發現；利用 activity 和 trigger 屬性來評估是否每個 activity 都使用了足夠多的與之對應的 trigger 來發現缺陷；利用時間和 trigger 屬性來評估是否隨著時間的推移測試變得更加復雜等。下面就利用第一種評估方法來進行舉例。
不同的測試階段有不同的測試重點。例如在功能測試階段，所對應的 activity 就是 Function Test( 功能測試 )。而在系統測試階段，所對應的 activity 就是 System Test（系統測試）。我們可以通過統計在每種測試階段中發現缺陷的 activity 來判斷是否本應在該測試階段中發現的缺陷被遺留到了下一測試階段。以此來評估測試工作的完成情況。如圖 5 所示。
圖 5. 利用測試階段和 activity 屬性得到的評估圖
由上圖我們可以看出，該項目在系統測試階段，有近一半缺陷的 activity 是功能測試。這說明本應該在功能測試階段發現的缺陷，卻被遺留到了系統測試階段才得以發現�？梢姽δ軠y試階段的測試工作做得不夠全面。
經驗和建議
- 這個評估方法常用于衡量是否本應該在功能測試階段發現的缺陷沒有被發現，而是到了系統測試階段才被發現。因此該評估方法最好在系統測試開始后使用，因為在此之前的階段使用沒有太大的幫助；
- 客觀上講，在系統測試階段發現一些功能測試階段的缺陷是正�，F象，這不會影響系統測試的正常運行。反而如果在系統測試階段沒有任何功能測試階段的缺陷，就說明有問題了。很可能是由于測試人員對 activity 屬性理解不正確導致的錯誤輸入引起的；
- 上圖所表現出來的問題是過多的本應在功能測試階段發現的缺陷卻在系統測試階段被發現。針對該問題，我們可以通過增加功能測試階段的測試用例來增加功能測試的覆蓋面�；蚴切薷墓δ軠y試階段的退出標準，例如必須發現多少缺陷才能進入系統測試階段等等。
對產品穩定度的評估
利用 ODC 屬性不僅可以評估測試工作的完成情況，同時還可以評估產品的穩定度。例如：隨著項目的進展，定期統計 qualifier 屬性的變化趨勢，以此來評估產品是否變得更加完善；或者定期統計 impact 屬性的變化趨勢，以此來評估影響產品功能性和可靠性的缺陷是否在減少。下面就以一個實例中的 qualifier 屬性為研究對象，來評估一下該實例是否隨著項目進展的過程而變得更加完善。如圖 6 所示。
圖 6. Qualifier 屬性趨勢圖
圖 6 顯示了 missing 和 incorrect 的百分比隨項目進展而發生的變化趨勢。對于一個逐漸趨向于穩定的產品來說，Qualifier 為 missing 的缺陷應該逐漸減少。因為任何未經測試過的新代碼的加入，都會增加潛在的風險。
但是從圖 6 中我們可以看到這個實例的穩定度并不樂觀。Qualifier 為 missing 的缺陷并沒有隨著項目的發展而有減少的趨勢。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
