您不希望為了覆蓋率而要求覆蓋率。您需要有意義的覆蓋率，以表明您已經(jīng)很好地測試了該軟件。

衡量代碼覆蓋率是始終引起我注意的那些事情之一。一方面，我經(jīng)常發(fā)現(xiàn)組織不一定知道他們?cè)跍y試期間覆蓋了多少代碼，這真是令人驚訝！在覆蓋范圍的另一端，對(duì)于一些組織來說，數(shù)字是如此重要，以至于測試的質(zhì)量和有效性已變得幾乎無關(guān)緊要。他們盲目地追逐100％的巨龍，并相信，如果擁有這個(gè)數(shù)字，該軟件將是優(yōu)秀的，甚至可能是最好的。這至少與不知道您所測試的內(nèi)容一樣危險(xiǎn)，實(shí)際上可能更危險(xiǎn)，因?yàn)樗赡芙o您帶來錯(cuò)誤的安全感。

代碼覆蓋率可以用來評(píng)估軟件質(zhì)量，這是一個(gè)很好且有趣的數(shù)字，但請(qǐng)務(wù)必記住，這是一種手段，而非目的。我們并不需要覆蓋，而是希望覆蓋，因?yàn)樗鼞?yīng)該表明我們?cè)跍y試軟件方面做得很好。如果測試本身沒有意義，那么肯定會(huì)有更多測試并不意味著軟件會(huì)更好。重要的目標(biāo)是確保測試每個(gè)代碼，而不僅僅是執(zhí)行代碼。沒有足夠的時(shí)間和金錢來全面測試所有內(nèi)容，至少要確保對(duì)所有重要的內(nèi)容都進(jìn)行了測試。

這就是說，低覆蓋率意味著我們可能測試不足，而高覆蓋率本身并不一定與高質(zhì)量相關(guān)聯(lián)——圖像要復(fù)雜得多。

顯然，擁有一個(gè)愉快的媒體環(huán)境，使您擁有“足夠”的覆蓋范圍，可以放心使用一個(gè)良好、穩(wěn)定、可維護(hù)的測試套件來發(fā)布軟件，該套件具有“足夠的測試”。但是，這些覆蓋陷阱仍然很常見。

陷阱1：“我們不知道我們的覆蓋率”

我不知道自己的覆蓋率似乎不合理——覆蓋率工具既便宜又豐富。我的一個(gè)朋友建議組織知道其覆蓋率不好，因此開發(fā)人員和測試人員不愿將覆蓋率不高的漏洞暴露給管理層。我希望這不是平常的情況。

團(tuán)隊(duì)在嘗試評(píng)估覆蓋率時(shí)遇到的一個(gè)實(shí)際問題是該系統(tǒng)過于復(fù)雜。當(dāng)您逐塊構(gòu)建應(yīng)用程序時(shí)，僅知道將覆蓋率計(jì)數(shù)器放置在何處可能是一項(xiàng)艱巨的任務(wù)。我建議，如果實(shí)際上很難衡量應(yīng)用程序的覆蓋率，則應(yīng)該對(duì)架構(gòu)進(jìn)行三思。

陷入這種陷阱的第二種方法發(fā)生在可能進(jìn)行大量測試但沒有實(shí)際覆蓋數(shù)量的組織中，因?yàn)樗麄儧]有找到合適的方法來匯總來自不同測試運(yùn)行的數(shù)量。如果您要進(jìn)行手動(dòng)測試，功能測試，單元測試和端到端測試，則不能簡單地將數(shù)字加起來。即使它們各自實(shí)現(xiàn)了25％的覆蓋率，結(jié)合起來也不太可能達(dá)到100％。實(shí)際上，當(dāng)您查看時(shí)，它更可能接近25％，而不是100％。

事實(shí)證明，實(shí)際上存在一種以有意義的方式一起測量和增加覆蓋率的方法。在Parasoft，我們利用報(bào)告和分析工具Parasoft DTP捕獲的大量細(xì)粒度數(shù)據(jù)，可以在這種情況下使用它來提供全面、匯總的代碼覆蓋率視圖。我們的應(yīng)用程序監(jiān)視器能夠在測試過程中直接從應(yīng)用程序中收集覆蓋率數(shù)據(jù)，然后將其發(fā)送到Parasoft DTP，后者會(huì)匯總所有測試實(shí)踐以及測試團(tuán)隊(duì)和測試運(yùn)行中的覆蓋率數(shù)據(jù)。

如果聽起來像是大量信息，那您是對(duì)的！DTP提供了一個(gè)交互式儀表板，可幫助您瀏覽此數(shù)據(jù)并就將測試重點(diǎn)放在哪里做出決策。請(qǐng)參閱下面的示例儀表板：

如果多個(gè)測試覆蓋了相同的代碼，則不會(huì)被計(jì)算在內(nèi)，而未經(jīng)測試的代碼部分則可以快速、輕松地看到。這向您顯示了應(yīng)用程序的哪些部分已經(jīng)過良好的測試，哪些沒有經(jīng)過測試。您可以在免費(fèi)的白皮書中閱讀所有內(nèi)容。

因此，沒有更多的借口不衡量覆蓋率。

陷阱2：“覆蓋率就是一切！”

人們常常誤以為覆蓋范圍就是一切。一旦團(tuán)隊(duì)能夠衡量覆蓋率，經(jīng)理們通常會(huì)說“讓我們?cè)黾舆@個(gè)數(shù)字”。最終，數(shù)字本身變得比測試更重要。最好的比喻可能是我從Parasoft的創(chuàng)始人Adam Kolawa那里聽到的：

“這就像要求鋼琴家遮蓋100％的鋼琴琴鍵，而不是僅敲擊在給定音樂中有意義的琴鍵。當(dāng)他演奏作品時(shí)，他會(huì)獲得有意義的任何數(shù)量的按鍵覆蓋?！?/span>

問題就出在這里——盲目的覆蓋范圍與盲目的音樂相同。覆蓋范圍需要反映出對(duì)代碼的真實(shí)、有意義的使用，否則只是噪音。

說到噪聲……覆蓋范圍的成本會(huì)隨著覆蓋范圍的增加而增加。請(qǐng)記住，您不僅需要?jiǎng)?chuàng)建測試，而且還必須維護(hù)它們。如果您不打算重復(fù)使用和維護(hù)測試，則可能一開始就不要浪費(fèi)時(shí)間來創(chuàng)建它。隨著測試套件的變大，噪聲量會(huì)以意想不到的方式增加。兩倍的測試可能意味著兩倍甚至三倍的噪聲。無意義的測試最終會(huì)比好的測試產(chǎn)生更多的噪音，因?yàn)樗鼈儧]有真實(shí)的上下文，但是每次執(zhí)行測試時(shí)都必須加以處理。談?wù)摷夹g(shù)債務(wù)！無用的測試是真正的危險(xiǎn)。

現(xiàn)在，在某些行業(yè)（例如對(duì)安全至關(guān)重要的行業(yè)）中，必須達(dá)到100％的覆蓋率指標(biāo)。但是即使在這種情況下，將一行代碼的任何執(zhí)行都視為有意義的測試也太容易了，這根本不是事實(shí)。我要問兩個(gè)基本問題，以確定一個(gè)測試是否是一個(gè)好的測試：

1. 測試失敗意味著什么？
2. 測試通過意味著什么？

 理想情況下，當(dāng)測試失敗時(shí)，我們會(huì)知道出了什么問題，如果測試真的很好，它將為我們指明正確的方向進(jìn)行修復(fù)。當(dāng)測試失敗時(shí)，很多時(shí)候沒有人知道為什么，沒有人可以復(fù)制它，而測試被忽略了。相反，當(dāng)測試通過時(shí)，我們應(yīng)該能夠知道所測試的內(nèi)容——這意味著某個(gè)特定功能或某項(xiàng)功能正常運(yùn)行。

如果您不能回答其中一個(gè)問題，則可能是您的測試有問題。如果您不能回答它們中的任何一個(gè)，則測試可能比它值得的麻煩更多。

擺脫陷阱的方法首先是要了解覆蓋率本身并不是目標(biāo)。真正的目標(biāo)是創(chuàng)建有用的有意義的測試。這當(dāng)然需要時(shí)間。在簡單的代碼編寫中，單元測試很簡單，但是在復(fù)雜的實(shí)際應(yīng)用程序中，這意味著編寫存根和模擬并使用框架。這可能會(huì)花費(fèi)很多時(shí)間，如果您一直不這樣做，很容易忘記所涉及的API的細(xì)微差別。即使您認(rèn)真對(duì)待測試，創(chuàng)建真正好的測試所花費(fèi)的時(shí)間也可能比您預(yù)期的要長。

實(shí)際上，我們的Java開發(fā)測試工具Parasoft Jtest中有一個(gè)針對(duì)此的新技術(shù)。單元測試助手承擔(dān)著完成正確的模擬和存根的繁瑣任務(wù)。它也可以幫助您以一種有效的方式來擴(kuò)展現(xiàn)有測試，以增加覆蓋范圍——幫助您創(chuàng)建良好的單元測試，并提出建議以提高測試覆蓋率和測試質(zhì)量。

希望您已經(jīng)了解覆蓋率很重要，并且提高覆蓋率是一個(gè)值得實(shí)現(xiàn)的目標(biāo)。但是請(qǐng)記住，僅僅追求百分比并沒有編寫穩(wěn)定、可維護(hù)和有意義的測試那么有價(jià)值。