從第一印象看，這讓我驕傲。但是這個報告有什么誤導嗎？只是粗略地看一看報告中的數字，會導致您相信代碼是經過良好測試的�；谶@一點，您也許會認為出現缺陷的風險很低。這個報告并不能幫助您確定 or 縮短操作的后半部分是一個定時炸彈！
質量測試
我不止一次地說：您可以（而且應該）使用測試覆蓋工具作為您的測試過程的一部分。但是不要被覆蓋報告所愚弄。關于覆蓋報告您需要了解的主要事情是，覆蓋報告最好用來檢查哪些代碼沒有經過 充分的測試。當您檢查覆蓋報告時，找出較低的值，并了解為什么特定的代碼沒有經過充分的測試。知道這些以后，開發人員、管理人員以及 QA 專業人員就可以在真正需要的地方使用測試覆蓋工具。通常有下列三種情況：
估計修改已有代碼所需的時間
評估代碼質量
評定功能測試
現在我可以斷定對測試覆蓋報告的一些使用方法會將您引入歧途，下面這些最佳實踐可以使得測試覆蓋報告可以真正為您所用。
1. 估計修改已有代碼所需的時間
對一個開發團隊而言，針對代碼編寫測試案例自然可以增加集體的信心。與沒有相應測試案例的代碼相比，經過測試的代碼更容易重構、維護和增強。測試案例因為暗示了代碼在測試工作中是如何 工作的，所以還可以充當內行的文檔。此外，如果被測試的代碼發生改變，測試案例通常也會作相應的改變，這與諸如注釋和 Javadoc 這樣的靜態代碼文檔不同。
在另一方面，沒有經過相應測試的代碼更難于理解和安全地 修改。因此，知道代碼有沒有被測試，并看看實際的測試覆蓋數值，可以讓開發人員和管理人員更準確地預知修改已有代碼所需的時間。
再次回到飲水機邊上，可以更好地闡明我的觀點。
市場部的 Linda：“我們想讓系統在用戶完成一筆交易時做 x 工作。這需要多長時間。我們的用戶需要盡快實現這一功能�！�
管理人員 Jeff：“讓我看看，這個代碼是 Joe 在幾個月前編寫的，需要對業務層和 UI 做一些變動。Mary 也許可以在兩天內完成這項工作�！�
Linda：“Joe？他是誰？”
Jeff：“哦，Joe，因為他不知道自己在干什么，所以被我解雇了�！�
情況似乎有點不妙，不是嗎？盡管如此，Jeff 還是將任務分配給了 Mary，Mary 也認為能夠在兩天內完成工作 —— 確切地說，在看到代碼之前她是這么認為的。
Mary：“Joe 寫這些代碼時是不是睡著了？這是我所見過的最差的代碼。我甚至不能確認這是 Java 代碼。除非推倒重來，要不我根本沒法修改�！�
情況對 “飲水機” 團隊不妙，不是嗎？但是我們假設，如果在這個不幸的事件的當初，Jeff 和 Mary 就擁有一份測試報告，那么情況會如何呢？當 Linda 要求實現新功能時，Jeff 做的第一件事就是檢查以前生成的覆蓋報告。注意到需要改動的軟件包幾乎沒有被覆蓋，然后他就會與 Mary 商量。
Jeff：“Joe 編寫的這個代碼很差，絕大多數沒經過測試。您認為要支持 Linda 所說的功能需要多長時間？”
Mary：“這個代碼很混亂。我甚至都不想看到它。為什么不讓 Mark 來做呢？”
文章來源于領測軟件測試網 http://www.kjueaiud.com/
