在做單元測試時，程式碼覆蓋率常常被拿來作為衡量測試好壞的指標，甚至，用程式碼覆蓋率來考核測試任務完成情況。但是我相信，你不是為了覆蓋率才要求覆蓋率的。你需要有意義的覆蓋率，以表明你已經很好地測試了該軟體。
衡量程式碼覆蓋率相關的問題總是能夠引起我的注意。一方面，我經常發現，公司和組織不一定知道他們在測試期間覆蓋了多少程式碼，這確實很令人驚訝！另一方面，對於一些組織來說，程式碼覆蓋率的數字是如此重要，以至於測試的質量和有效性卻變得幾乎無關緊要了。他們盲目地追逐100％的程式碼覆蓋率，並相信，如果擁有這個數字，該軟體將是優秀的，甚至可能是最好的。其實，這樣跟不知道你所測試的內容一樣危險，實際上可能更危險，因為它可能給你帶來錯誤的安全感。
程式碼覆蓋率可以用來評估軟體質量，這是一個很好且有趣的數字，但請務必記住，這是一種手段，而非目的。我們並不是為了覆蓋率而要求覆蓋率，因為它應該表明我們在測試軟體方面做得很好。如果測試本身沒有意義，那麼再高的覆蓋率也並不意味著軟體會更好。重要的目標是確保測試每個程式碼，而不僅僅是執行程式碼。沒有足夠的時間和金錢來全面測試所有內容，至少要確保對所有重要的內容都進行了測試。
這就是說，低覆蓋率意味著我們可能測試不足，而高覆蓋率本身並不一定與高質量相關聯——實際情況要複雜得多。
顯然，擁有一個愉快的測試環境，使你擁有“足夠”的覆蓋率，可以放心使用一個良好、穩定、可維護的測試套件來發布軟體，該套件具有“足夠的測試”，這是最好的狀態。但是，實際上，這些覆蓋率陷阱仍然很常見。
陷阱1：“我們不知道我們的覆蓋率”
不知道自己的程式碼覆蓋率似乎並不合理——市面上的程式碼覆蓋率工具既便宜又豐富。我的一個朋友告訴我，其實開發人員一般都知道自己的程式碼覆蓋率不理想，因此開發人員和測試人員不願將覆蓋率不高的漏洞暴露給管理層。當然我希望這不是普遍的情況。
團隊在嘗試評估覆蓋率時遇到的一個實際問題是該系統過於複雜。當你逐塊構建應用程式時，僅知道將覆蓋範圍計數器放置在何處可能是一項艱鉅的任務。我建議，如果實際上很難衡量應用程式的覆蓋範圍，則應該對架構進行三思。
陷入這種陷阱的第二種方法發生在可能進行大量測試但沒有實際覆蓋數量的組織中，因為他們沒有找到合適的方法來彙總來自不同測試執行的數量。如果你要進行手動測試、功能測試、單元測試和端到端測試，則不能簡單地將數字加起來。即使它們各自實現了25％的覆蓋率，結合起來也不太可能達到100％。實際上，當您檢視結果時，它更可能接近25％，而不是100％。
事實證明，實際上存在一種以有意義的方式一起測量和增加覆蓋範圍的方法。在Parasoft，利用報告和分析工具Parasoft DTP捕獲的大量細粒度資料，可以在這種情況下使用它來提供全面、彙總的程式碼覆蓋率檢視。應用程式監視器能夠在測試過程中直接從應用程式中收集覆蓋率資料，然後將其傳送到Parasoft DTP，後者會彙總所有測試實踐以及測試團隊和測試執行中的覆蓋率資料。
如果聽起來像是包含了相當大的資訊量，那你是對的！DTP提供了一個互動式儀表板，可幫助你瀏覽此資料並就將測試重點放在哪裡做出決策。請參閱下面的示例儀表板：
如果多個測試覆蓋了相同的程式碼，則不會被計算在內，而未經測試的程式碼部分則可以快速、輕鬆地看到。這向你顯示了應用程式的哪些部分已經過良好的測試，哪些沒有經過測試。你可以在免費的白皮書中閱讀所有內容。
因此，沒有更多的藉口不衡量覆蓋率。
陷阱2：“覆蓋率就是一切！”
人們常常誤以為覆蓋率就是一切。一旦團隊能夠衡量覆蓋率，領導通常會說“讓我們來增加這個數字”。最終，數字本身變得比測試更重要。正如Parasoft的創始人Adam Kolawa所說的：
“這就像要求鋼琴家按照100％的覆蓋率敲擊鋼琴琴鍵，而不是根據樂譜的需要僅敲擊那些有意義的琴鍵。當他演奏作品時，他會獲得有意義的任何數量的按鍵覆蓋。”
問題就出在這裡——盲目的要求覆蓋率與盲目的音樂演奏相同。覆蓋率需要反映出對程式碼的真實、有意義的使用，否則只會是“噪音”。
說到“噪音”……覆蓋率的成本會隨著覆蓋率的增加而增加。請記住，你不僅需要建立測試，而且還必須維護它們。如果你不打算重複使用和維護測試，則可能一開始就不要浪費時間來建立它。隨著測試套件的變大，“噪音”量也會以意想不到的方式增加。兩倍的測試可能意味著兩倍甚至三倍的“噪音”。無意義的測試最終會比好的測試產生更多的“噪音”，因為它們沒有真實的上下文，但是每次執行測試時都必須加以處理。想一想技術債務吧！無用的測試是真正的危險。
現在，在某些行業（例如對安全至關重要的行業）中，必須達到100％的覆蓋率指標。但是即使在這種情況下，將一行程式碼的任何執行都視為有意義的測試也太容易了，這根本不是事實。我要問兩個基本問題，以確定一個測試是否是一個好的測試：
- 測試失敗意味著什麼？
- 測試通過意味著什麼？
理想情況下，當測試失敗時，我們會知道出了什麼問題，如果測試真的很好，它將為我們指明正確的方向進行修復。當測試失敗時，很多時候沒有人知道為什麼，沒有人可以複製它，而測試被忽略了。相反，當測試通過時，我們應該能夠知道所測試的內容——這意味著某個特定功能或某項功能正常執行。
如果您不能回答其中一個問題，則可能是你的測試有問題。如果你不能回答它們中的任何一個，則測試帶來的麻煩可能比它產生的價值更多。
擺脫陷阱的方法首先是要了解覆蓋率本身並不是目標。真正的目標是建立有用的有意義的測試。這當然需要時間。在簡單的程式碼編寫中，單元測試很簡單，但是在複雜的實際應用程式中，這意味著編寫存根和模擬並使用框架。這可能會花費很多時間，如果你一直不這樣做，很容易忘記所涉及的API的細微差別。即使你認真對待測試，建立真正好的測試所花費的時間也可能比你預期的要長。
為了提高單元測試的效率，Java開發測試工具Parasoft Jtest中有一個針對於此的新技術——單元測試助手。單元測試助手承擔著完成正確的模擬和存根的繁瑣任務。它也可以幫助你以一種有效的方式來擴充套件現有測試，以增加覆蓋範圍——幫助你建立良好的單元測試，並提出建議以提高測試覆蓋率和測試質量。
希望你已經瞭解到覆蓋率的重要性，並且提高覆蓋率是一個值得實現的目標。但是請記住，單純的追求百分比並沒有編寫穩定、可維護和有意義的測試更有價值。