代碼覆蓋率 vs. 測試覆蓋率

代碼覆蓋率通常指跑完測試后, 由工具自動(dòng)統(tǒng)計(jì)的在跑測試的過程中被測代碼的覆蓋率, 細(xì)分的話包括語句覆蓋率, 分支覆蓋率, 函數(shù)覆蓋率等. 由于代碼覆蓋率可由工具自動(dòng)產(chǎn)生, 采集成本非常低, 而又比較直觀, 所以歷來受到開發(fā)團(tuán)隊(duì)及管理者的歡迎, 有的組織甚至將其作為 KPI 指標(biāo)之一.

然而圍繞著代碼覆蓋率, 有很多有趣的事情, 尤其是將其作為 KPI 的時(shí)候. 你會(huì)發(fā)現(xiàn), 長期在低位徘徊的代碼覆蓋率, 突然之間會(huì)有一個(gè)比較大的提升. 究其原因, 是開發(fā)團(tuán)隊(duì)在短時(shí)間內(nèi)加了”測試”. “測試”是打引號的, 因?yàn)楫?dāng)我們近距離觀察這些”測試”的時(shí)候, 會(huì)發(fā)現(xiàn)通常是調(diào)用了某個(gè)高層的入口函數(shù), 因而牽出很多底層函數(shù), 覆蓋率就上去了, 然而, 沒有一個(gè)斷言(assertion), 或者是區(qū)區(qū)幾個(gè)斷言. 也就是說, 把產(chǎn)品跑了一遍, 但沒有判斷其行為是否符合預(yù)期, 而代碼覆蓋率突然就達(dá)標(biāo)了.

盡管對于追求自我改進(jìn)的團(tuán)隊(duì)來說, 不會(huì)這么掩耳盜鈴, 代碼覆蓋率依然是有價(jià)值的反饋指標(biāo), 但這從側(cè)面說明了代碼覆蓋率并沒有表達(dá)出我們對于外部質(zhì)量真正的關(guān)注點(diǎn). 那么我們對于質(zhì)量真正的關(guān)注點(diǎn)是什么呢?

是斷言的覆蓋率, 即測試覆蓋率. 換句話說, 我們真正關(guān)心的是, 我們總共應(yīng)該有多少測試用例/驗(yàn)收條件/檢查點(diǎn), 它們中有多少已經(jīng)被覆蓋了, 即做出了真正的斷言. 但目前為止, 還沒有工具能自動(dòng)統(tǒng)計(jì)跑完測試后, 測試覆蓋率是多少. 代碼覆蓋率僅僅是無法自動(dòng)統(tǒng)計(jì)測試覆蓋率時(shí)的一個(gè)替代品.

為了統(tǒng)計(jì)測試覆蓋率, 需要準(zhǔn)備分子和分母的信息. 分母是產(chǎn)品”完整”的測試用例列表, 分子是已經(jīng)執(zhí)行的測試用例列表, 包括手工和自動(dòng). 如果你關(guān)心測試覆蓋率, 而手頭又沒有這兩個(gè)東西, 就要開始準(zhǔn)備了.

注1: 利用現(xiàn)有的 xUnit 測試框架, 可以在某種程度上得到測試覆蓋率. 比如可以將”完整”的測試用例列表用 xUnit 的測試用例表達(dá)出來, 其中對于還沒實(shí)現(xiàn)的, 設(shè)置為 ignore. 這樣可以從最后的報(bào)告中看出總數(shù), 和 ignore 的數(shù)量(當(dāng)然如果你不做斷言, 還是白搭). 現(xiàn)在更多的是借助管理工具甚至 Excel, 來手工維護(hù)”完整”的測試用例列表及狀態(tài). 如果你知道有更好的方式, 請告訴我.

注2: 前面”完整”的測試用例列表, “完整”一直打著引號, 因?yàn)檫@是一個(gè)無法證明的問題, 我們只能根據(jù)經(jīng)驗(yàn)設(shè)計(jì)測試用例, 無法保證其完整性, 并且隨著產(chǎn)品的開發(fā), 這個(gè)列表也會(huì)動(dòng)態(tài)更新. 至于如何讓測試用例盡可能完整, 是組織應(yīng)該投入的地方.

此測試覆蓋率 vs. 彼測試覆蓋率

基于前面的描述, 那么當(dāng)我的測試覆蓋率達(dá)到某個(gè)比較高的數(shù)值, 比如80%, 是不是我就可以比更低的數(shù)值比如20%, 對產(chǎn)品更有信心呢? 答案取決于你的測試用例的設(shè)計(jì).

我們都聽過80/20原則. 比如用戶80%的時(shí)間在使用20%的功能, 20%的功能就可以支撐起用戶最關(guān)鍵的業(yè)務(wù)場景. 那么, 如果80%的測試覆蓋率, 覆蓋的是那不常用的80%的功能, 而20%的覆蓋率, 覆蓋的恰恰是最常用最關(guān)鍵的那20%的功能, 那么, 你是否還像開始那樣, 相信80%的覆蓋率帶來的安全感呢?

基于測試覆蓋率很難達(dá)到100%這個(gè)前提, 基于我們的發(fā)布時(shí)間總是很緊張而又要保證質(zhì)量這個(gè)前提, 我們必須投入精力, 做測試用例的價(jià)值分析, 挑選出最有價(jià)值的測試用例, 優(yōu)先安排資源實(shí)現(xiàn)和運(yùn)行.

如果團(tuán)隊(duì)的測試用例沒有經(jīng)過價(jià)值分析, 沒有優(yōu)先級劃分, 那么這就是接下來馬上應(yīng)該做的事. 這牽扯到一個(gè)問題, 測試人員及測試技能的價(jià)值.

當(dāng)我們談?wù)摐y試技能時(shí)我們在談什么

最近幾年隨著自動(dòng)化測試框架的流行, 評價(jià)一個(gè)人員測試能力的標(biāo)準(zhǔn)逐漸變成了是否能寫自動(dòng)化測試. 如果照這個(gè)標(biāo)準(zhǔn), 所有的開發(fā)人員一夜之間都具備了合格的測試能力. 這顯然是一個(gè)不成立的結(jié)論.

測試至少分測試用例的設(shè)計(jì)和測試用例的編寫執(zhí)行兩部分. 自動(dòng)化測試的長處僅僅在于編寫執(zhí)行. 使用自動(dòng)化測試框架并不會(huì)自動(dòng)讓我們的測試更有效, 更完備, 更具洞察力. 而測試的有效性和完備性, 通常是我們更關(guān)注的. 然而遺憾的是, 通常組織中這方面的知識比較欠缺, 關(guān)注度不夠, 技能交流較少.

如果我們交流測試知識時(shí), 更多的是談?wù)?xUnit, RobotFramework等, 而不是等價(jià)類/邊界值, 惡鄰測試法/快遞測試法, 關(guān)鍵路徑分析等, 那幾乎可以肯定我們遺漏了更重要的東西.

要在時(shí)間資源人力資源有限的情況下保證產(chǎn)品質(zhì)量, 我們需要提高測試用例的設(shè)計(jì)能力, 價(jià)值分析能力, 安排合理的測試策略.

本文轉(zhuǎn)自：http:///blogs/2015/06/01/code-coverage-vs-test-coverage/