代碼覆蓋率通常指跑完測試后, 由工具自動(dòng)統計的在跑測試的過(guò)程中被測代碼的覆蓋率, 細分的話(huà)包括語(yǔ)句覆蓋率, 分支覆蓋率, 函數覆蓋率等. 由于代碼覆蓋率可由工具自動(dòng)產(chǎn)生, 采集成本非常低, 而又比較直觀(guān), 所以歷來(lái)受到開(kāi)發(fā)團隊及管理者的歡迎, 有的組織甚至將其作為 KPI 指標之一.
然而圍繞著(zhù)代碼覆蓋率, 有很多有趣的事情, 尤其是將其作為 KPI 的時(shí)候. 你會(huì )發(fā)現, 長(cháng)期在低位徘徊的代碼覆蓋率, 突然之間會(huì )有一個(gè)比較大的提升. 究其原因, 是開(kāi)發(fā)團隊在短時(shí)間內加了”測試”. “測試”是打引號的, 因為當我們近距離觀(guān)察這些”測試”的時(shí)候, 會(huì )發(fā)現通常是調用了某個(gè)高層的入口函數, 因而牽出很多底層函數, 覆蓋率就上去了, 然而, 沒(méi)有一個(gè)斷言(assertion), 或者是區區幾個(gè)斷言. 也就是說(shuō), 把產(chǎn)品跑了一遍, 但沒(méi)有判斷其行為是否符合預期, 而代碼覆蓋率突然就達標了.
盡管對于追求自我改進(jìn)的團隊來(lái)說(shuō), 不會(huì )這么掩耳盜鈴, 代碼覆蓋率依然是有價(jià)值的反饋指標, 但這從側面說(shuō)明了代碼覆蓋率并沒(méi)有表達出我們對于外部質(zhì)量真正的關(guān)注點(diǎn). 那么我們對于質(zhì)量真正的關(guān)注點(diǎn)是什么呢?
是斷言的覆蓋率, 即測試覆蓋率. 換句話(huà)說(shuō), 我們真正關(guān)心的是, 我們總共應該有多少測試用例/驗收條件/檢查點(diǎn), 它們中有多少已經(jīng)被覆蓋了, 即做出了真正的斷言. 但目前為止, 還沒(méi)有工具能自動(dòng)統計跑完測試后, 測試覆蓋率是多少. 代碼覆蓋率僅僅是無(wú)法自動(dòng)統計測試覆蓋率時(shí)的一個(gè)替代品.
為了統計測試覆蓋率, 需要準備分子和分母的信息. 分母是產(chǎn)品”完整”的測試用例列表, 分子是已經(jīng)執行的測試用例列表, 包括手工和自動(dòng). 如果你關(guān)心測試覆蓋率, 而手頭又沒(méi)有這兩個(gè)東西, 就要開(kāi)始準備了.
注1: 利用現有的 xUnit 測試框架, 可以在某種程度上得到測試覆蓋率. 比如可以將”完整”的測試用例列表用 xUnit 的測試用例表達出來(lái), 其中對于還沒(méi)實(shí)現的, 設置為 ignore. 這樣可以從最后的報告中看出總數, 和 ignore 的數量(當然如果你不做斷言, 還是白搭). 現在更多的是借助管理工具甚至 Excel, 來(lái)手工維護”完整”的測試用例列表及狀態(tài). 如果你知道有更好的方式, 請告訴我.
注2: 前面”完整”的測試用例列表, “完整”一直打著(zhù)引號, 因為這是一個(gè)無(wú)法證明的問(wèn)題, 我們只能根據經(jīng)驗設計測試用例, 無(wú)法保證其完整性, 并且隨著(zhù)產(chǎn)品的開(kāi)發(fā), 這個(gè)列表也會(huì )動(dòng)態(tài)更新. 至于如何讓測試用例盡可能完整, 是組織應該投入的地方.
基于前面的描述, 那么當我的測試覆蓋率達到某個(gè)比較高的數值, 比如80%, 是不是我就可以比更低的數值比如20%, 對產(chǎn)品更有信心呢? 答案取決于你的測試用例的設計.
我們都聽(tīng)過(guò)80/20原則. 比如用戶(hù)80%的時(shí)間在使用20%的功能, 20%的功能就可以支撐起用戶(hù)最關(guān)鍵的業(yè)務(wù)場(chǎng)景. 那么, 如果80%的測試覆蓋率, 覆蓋的是那不常用的80%的功能, 而20%的覆蓋率, 覆蓋的恰恰是最常用最關(guān)鍵的那20%的功能, 那么, 你是否還像開(kāi)始那樣, 相信80%的覆蓋率帶來(lái)的安全感呢?
基于測試覆蓋率很難達到100%這個(gè)前提, 基于我們的發(fā)布時(shí)間總是很緊張而又要保證質(zhì)量這個(gè)前提, 我們必須投入精力, 做測試用例的價(jià)值分析, 挑選出最有價(jià)值的測試用例, 優(yōu)先安排資源實(shí)現和運行.
如果團隊的測試用例沒(méi)有經(jīng)過(guò)價(jià)值分析, 沒(méi)有優(yōu)先級劃分, 那么這就是接下來(lái)馬上應該做的事. 這牽扯到一個(gè)問(wèn)題, 測試人員及測試技能的價(jià)值.
最近幾年隨著(zhù)自動(dòng)化測試框架的流行, 評價(jià)一個(gè)人員測試能力的標準逐漸變成了是否能寫(xiě)自動(dòng)化測試. 如果照這個(gè)標準, 所有的開(kāi)發(fā)人員一夜之間都具備了合格的測試能力. 這顯然是一個(gè)不成立的結論.
測試至少分測試用例的設計和測試用例的編寫(xiě)執行兩部分. 自動(dòng)化測試的長(cháng)處僅僅在于編寫(xiě)執行. 使用自動(dòng)化測試框架并不會(huì )自動(dòng)讓我們的測試更有效, 更完備, 更具洞察力. 而測試的有效性和完備性, 通常是我們更關(guān)注的. 然而遺憾的是, 通常組織中這方面的知識比較欠缺, 關(guān)注度不夠, 技能交流較少.
如果我們交流測試知識時(shí), 更多的是談?wù)?xUnit, RobotFramework等, 而不是等價(jià)類(lèi)/邊界值, 惡鄰測試法/快遞測試法, 關(guān)鍵路徑分析等, 那幾乎可以肯定我們遺漏了更重要的東西.
要在時(shí)間資源人力資源有限的情況下保證產(chǎn)品質(zhì)量, 我們需要提高測試用例的設計能力, 價(jià)值分析能力, 安排合理的測試策略.
本文轉自：http://liguanglei.name/blogs/2015/06/01/code-coverage-vs-test-coverage/
聯(lián)系客服
