軟件測試之功能點覆蓋

         軟件測試之功能點覆蓋    軟件測試

　　很多測試人員為了對功能點進行覆蓋費勁了心思,可惜的是當他們將達到功能點覆蓋100%的,系統,仍然不斷出現問題,于是領導的責備,用戶的冷眼,開發人員的譏諷就全來了,這個時候測試人員唯一的解釋就是測試不是萬能的,不可能發現所有的問題。

　　這個時候別人一問:你的功能點不是100%覆蓋了嗎?為什么還有錯誤沒有發現,于是測試人員啞口無言了.

　　其實這個問題的關鍵問題在于如何功能點這個概念.

　　功能點的概念其實從開發中來的,在系統開發的時候一般會分層,最上邊的的是系統,然后是子系統、模塊、功能。一般來說功能是一個系統中最小的單位，這個概念被引入到了測試中來，于是出現了功能點覆蓋的概念。

　　功能點覆蓋一直一個沒有明確的概念，這個概念很容易迷惑測試人員，如何算功能點覆蓋了?

　　功能一般是系統完成一個具體的操作，比如在人力資源管理系統的中人員基本信息模塊中有一個增加新人員信息的功能。

　　我們在對這個功能進行覆蓋的時候，一般會考慮幾個方面

　　1.合法數據是否可以加入到系統中

　　2.非法數據是否可以檢驗出來，并給出相關提示

　　3.其他操作約束是否可以滿足，

　　如果這些方面都要測試到，那么用一個測試用例是不可能覆蓋的，

　　這里有問題了。

　　我就寫了一個測試用例是否就算覆蓋這個這個功能?

　　我用100個不同的測試用例進行測試是否算覆蓋了這個功能?

　　我用里10個測試用例發現了一個bug和用200個測試用例發現了一個bug ，對系統來說是否有什么不同?

　　所以個人認為在這個時候應該引入一個概念就是功能測試點的概念

　　我們在需求報告或者概要設計報告中很容易總結出系統所有的功能點，這些功能點是開發人員提供給測試人員的，那么測試人員要做什么?就是確定每一個功能(點)有多少個地方需要測試，而這些點就是功能測試點，

　　用來衡量測試人員工作效果的就是對功能測試點的覆蓋

　　這樣可以很好解釋，測試用例的數量和產品質量之間的關系。

　　比如功能(點)覆蓋達到了100%，但功能測試點的覆蓋只有10%，說明測試強度不夠，即使所有的功能都涉及到了，但測試強度還是很小的，產品的質量同樣是沒有保證的

　　同樣的是，一個功能點我用了10測試用例發現一個bug，和用1000測試用例發現一個bug，雖然從bug數量上來說是一樣，但后邊一種對代碼覆蓋率要大(按照測試用例的方法來編寫測試用例)，所以，說明第二個系統可靠性比第一個系統要高。

　　將功能點和功能測試點區分開來還有一個好處，就是在統計測試人員工作效果的時候比較好，

　　對于測試人員的工作成績不能單純地以發現bug數量來說明，否則容易造成偏頗，通過功能點覆蓋和功能測試點覆蓋率來分解統計可以比較精確反映測試人員實際工作量

原文轉自：http://www.anti-gravitydesign.com