關於代碼覆蓋率，你不可不知的兩大陷阱！

在作單元測試時，代碼覆蓋率經常被拿來做爲衡量測試好壞的指標，甚至，用代碼覆蓋率來考覈測試任務完成狀況。可是我相信，你不是爲了覆蓋率纔要求覆蓋率的。你須要有意義的覆蓋率，以代表你已經很好地測試了該軟件。

衡量代碼覆蓋率相關的問題老是可以引發個人注意。一方面，我常常發現，公司和組織不必定知道他們在測試期間覆蓋了多少代碼，這確實很使人驚訝！另外一方面，對於一些組織來講，代碼覆蓋率的數字是如此重要，以致於測試的質量和有效性卻變得幾乎可有可無了。他們盲目地追逐100％的代碼覆蓋率，並相信，若是擁有這個數字，該軟件將是優秀的，甚至多是最好的。其實，這樣跟不知道你所測試的內容同樣危險，實際上可能更危險，由於它可能給你帶來錯誤的安全感。

代碼覆蓋率能夠用來評估軟件質量，這是一個很好且有趣的數字，但請務必記住，這是一種手段，而非目的。咱們並非爲了覆蓋率而要求覆蓋率，由於它應該代表咱們在測試軟件方面作得很好。若是測試自己沒有意義，那麼再高的覆蓋率也並不意味着軟件會更好。重要的目標是確保測試每一個代碼，而不只僅是執行代碼。沒有足夠的時間和金錢來全面測試全部內容，至少要確保對全部重要的內容都進行了測試。

這就是說，低覆蓋率意味着咱們可能測試不足，而高覆蓋率自己並不必定與高質量相關聯——實際狀況要複雜得多。

顯然，擁有一個愉快的測試環境，使你擁有「足夠」的覆蓋率，能夠放心使用一個良好、穩定、可維護的測試套件來發布軟件，該套件具備「足夠的測試」，這是最好的狀態。可是，實際上，這些覆蓋率陷阱仍然很常見。

陷阱1：「咱們不知道咱們的覆蓋率」

不知道本身的代碼覆蓋率彷佛並不合理——市面上的代碼覆蓋率工具既便宜又豐富。個人一個朋友告訴我，其實開發人員通常都知道本身的代碼覆蓋率不理想，所以開發人員和測試人員不肯將覆蓋率不高的漏洞暴露給管理層。固然我但願這不是廣泛的狀況。

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

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

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

若是聽起來像是包含了至關大的信息量，那你是對的！DTP提供了一個交互式儀表板，可幫助你瀏覽此數據並就將測試重點放在哪裏作出決策。請參閱下面的示例儀表板：

若是多個測試覆蓋了相同的代碼，則不會被計算在內，而未經測試的代碼部分則能夠快速、輕鬆地看到。這向你顯示了應用程序的哪些部分已通過良好的測試，哪些沒有通過測試。你能夠在免費的白皮書中閱讀全部內容。

所以，沒有更多的藉口不衡量覆蓋率。

陷阱2：「覆蓋率就是一切！」

人們經常誤覺得覆蓋率就是一切。一旦團隊可以衡量覆蓋率，領導一般會說「讓咱們來增長這個數字」。最終，數字自己變得比測試更重要。正如Parasoft的創始人Adam Kolawa所說的：

「這就像要求鋼琴家按照100％的覆蓋率敲擊鋼琴琴鍵，而不是根據曲譜的須要僅敲擊那些有意義的琴鍵。當他演奏做品時，他會得到有意義的任何數量的按鍵覆蓋。」

問題就出在這裏——盲目的要求覆蓋率與盲目的音樂演奏相同。覆蓋率須要反映出對代碼的真實、有意義的使用，不然只會是「噪音」。

說到「噪音」……覆蓋率的成本會隨着覆蓋率的增長而增長。請記住，你不只須要建立測試，並且還必須維護它們。若是你不打算重複使用和維護測試，則可能一開始就不要浪費時間來建立它。隨着測試套件的變大，「噪音」量也會以意想不到的方式增長。兩倍的測試可能意味着兩倍甚至三倍的「噪音」。無心義的測試最終會比好的測試產生更多的「噪音」，由於它們沒有真實的上下文，可是每次執行測試時都必須加以處理。想想技術債務吧！無用的測試是真正的危險。

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

1. 測試失敗意味着什麼？
2. 測試經過意味着什麼？

理想狀況下，當測試失敗時，咱們會知道出了什麼問題，若是測試真的很好，它將爲咱們指明正確的方向進行修復。當測試失敗時，不少時候沒有人知道爲何，沒有人能夠複製它，而測試被忽略了。相反，當測試經過時，咱們應該可以知道所測試的內容——這意味着某個特定功能或某項功能正常運行。

若是您不能回答其中一個問題，則多是你的測試有問題。若是你不能回答它們中的任何一個，則測試帶來的麻煩可能比它產生的價值更多。

擺脫陷阱的方法首先是要了解覆蓋率自己並非目標。真正的目標是建立有用的有意義的測試。這固然須要時間。在簡單的代碼編寫中，單元測試很簡單，可是在複雜的實際應用程序中，這意味着編寫存根和模擬並使用框架。這可能會花費不少時間，若是你一直不這樣作，很容易忘記所涉及的API的細微差異。即便你認真對待測試，建立真正好的測試所花費的時間也可能比你預期的要長。

爲了提升單元測試的效率，Java開發測試工具Parasoft Jtest中有一個針對於此的新技術——單元測試助手。單元測試助手承擔着完成正確的模擬和存根的繁瑣任務。它也能夠幫助你以一種有效的方式來擴展示有測試，以增長覆蓋範圍——幫助你建立良好的單元測試，並提出建議以提升測試覆蓋率和測試質量。

但願你已經瞭解到覆蓋率的重要性，而且提升覆蓋率是一個值得實現的目標。可是請記住，單純的追求百分比並無編寫穩定、可維護和有意義的測試更有價值。