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

衡量代碼覆蓋率是始終引起我注意的那些事情之一。一方面，我經常發現組織不一定知道他們在測試期間覆蓋了多少代碼，這真是令人驚訝！在覆蓋范圍的另一端，對于一些組織來說，數字是如此重要，以至于測試的質量和有效性已變得幾乎無關緊要。他們盲目地追逐100％的巨龍，并相信，如果擁有這個數字，該軟件將是優秀的，甚至可能是最好的。這至少與不知道您所測試的內容一樣危險，實際上可能更危險，因為它可能給您帶來錯誤的安全感。

代碼覆蓋率可以用來評估軟件質量，這是一個很好且有趣的數字，但請務必記住，這是一種手段，而非目的。我們并不需要覆蓋，而是希望覆蓋，因為它應該表明我們在測試軟件方面做得很好。如果測試本身沒有意義，那么肯定會有更多測試并不意味著軟件會更好。重要的目標是確保測試每個代碼，而不僅僅是執行代碼。沒有足夠的時間和金錢來全面測試所有內容，至少要確保對所有重要的內容都進行了測試。

這就是說，低覆蓋率意味著我們可能測試不足，而高覆蓋率本身并不一定與高質量相關聯——圖像要復雜得多。

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

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

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

團隊在嘗試評估覆蓋率時遇到的一個實際問題是該系統過于復雜。當您逐塊構建應用程序時，僅知道將覆蓋率計數器放置在何處可能是一項艱巨的任務。我建議，如果實際上很難衡量應用程序的覆蓋率，則應該對架構進行三思。

陷入這種陷阱的第二種方法發生在可能進行大量測試但沒有實際覆蓋數量的組織中，因為他們沒有找到合適的方法來匯總來自不同測試運行的數量。如果您要進行手動測試，功能測試，單元測試和端到端測試，則不能簡單地將數字加起來。即使它們各自實現了25％的覆蓋率，結合起來也不太可能達到100％。實際上，當您查看時，它更可能接近25％，而不是100％。

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

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

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

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

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

人們常常誤以為覆蓋范圍就是一切。一旦團隊能夠衡量覆蓋率，經理們通常會說“讓我們增加這個數字”。最終，數字本身變得比測試更重要。最好的比喻可能是我從Parasoft的創始人Adam Kolawa那里聽到的：

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

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

說到噪聲……覆蓋范圍的成本會隨著覆蓋范圍的增加而增加。請記住，您不僅需要創建測試，而且還必須維護它們。如果您不打算重復使用和維護測試，則可能一開始就不要浪費時間來創建它。隨著測試套件的變大，噪聲量會以意想不到的方式增加。兩倍的測試可能意味著兩倍甚至三倍的噪聲。無意義的測試最終會比好的測試產生更多的噪音，因為它們沒有真實的上下文，但是每次執行測試時都必須加以處理。談論技術債務！無用的測試是真正的危險。

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

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

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

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

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

實際上，我們的Java開發測試工具Parasoft Jtest中有一個針對此的新技術。單元測試助手承擔著完成正確的模擬和存根的繁瑣任務。它也可以幫助您以一種有效的方式來擴展現有測試，以增加覆蓋范圍——幫助您創建良好的單元測試，并提出建議以提高測試覆蓋率和測試質量。

希望您已經了解覆蓋率很重要，并且提高覆蓋率是一個值得實現的目標。但是請記住，僅僅追求百分比并沒有編寫穩定、可維護和有意義的測試那么有價值。