對一個開發團隊而言，針對代碼編寫測試案例自然可以增加集體的信心。與沒有相應測試案例的代碼相比，經過測試的代碼更容易重構、維護和增強。測試案例因為暗示了代碼在測試工作中是如何 工作的，所以還可以充當內行的文檔。此外，如果被測試的代碼發生改變，測試案例通常也會作相應的改變，這與諸如注釋和 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 來做呢？”
Jeff：“因為 Mark 不編寫測試，剛被我解雇了。我需要您測試這個代碼并作一些改動。告訴我您需要多長時間�！�
Mary：“我至少需要兩天編寫測試，然后我會重構這個代碼，增加新的功能。我想總共需要四天吧�！�
正如他們所說的，知識的力量是強大的。開發人員可以在試圖修改代碼之前 使用覆蓋報告來檢查代碼質量。同樣，管理人員可以使用覆蓋數據更好地估計開發人員實際所需的時間。
開發人員的測試可以降低代碼中存在缺陷的風險，因此現在很多開發團隊在新開發和更改代碼的同時需要編寫單元測試。然而正如前面所提到的 Mark 一樣，并不總是在編碼的同時進行單元測試，因而會導致低質量代碼的出現。
監控覆蓋報告可以幫助開發團隊迅速找出不斷增長的沒有 相應測試的代碼。例如，在一周開始時運行覆蓋報告，顯示項目中一個關鍵的軟件包的覆蓋率是 70%。如果幾天后，覆蓋率下降到了 60%，那么您可以推斷：
- 軟件包的代碼行增加了，但是沒有為新代碼編寫相應的測試（或者是新增加的測試不能有效地覆蓋新代碼）。
- 刪除了測試案例。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
