Jeff：“因為 Mark 不編寫測試，剛被我解雇了。我需要您測試這個代碼并作一些改動。告訴我您需要多長時間�！�
Mary：“我至少需要兩天編寫測試，然后我會重構這個代碼，增加新的功能。我想總共需要四天吧�！�
正如他們所說的，知識的力量是強大的。開發人員可以在試圖修改代碼之前 使用覆蓋報告來檢查代碼質量。同樣，管理人員可以使用覆蓋數據更好地估計開發人員實際所需的時間。
2. 評估代碼質量
開發人員的測試可以降低代碼中存在缺陷的風險，因此現在很多開發團隊在新開發和更改代碼的同時需要編寫單元測試。然而正如前面所提到的 Mark 一樣，并不總是在編碼的同時進行單元測試，因而會導致低質量代碼的出現。
監控覆蓋報告可以幫助開發團隊迅速找出不斷增長的沒有 相應測試的代碼。例如，在一周開始時運行覆蓋報告，顯示項目中一個關鍵的軟件包的覆蓋率是 70%。如果幾天后，覆蓋率下降到了 60%，那么您可以推斷：
軟件包的代碼行增加了，但是沒有為新代碼編寫相應的測試（或者是新增加的測試不能有效地覆蓋新代碼）。
刪除了測試案例。
上述兩種情況都發生了。
能夠監控事情的發展，無疑是件好事。定期地查閱報告使得設定目標（例如獲得覆蓋率、維護代碼行的測試案例的比例等）并監控事情的發展變得更為容易。如果您發現測試沒有如期編寫，您可以提前采取一些行動，例如對開發人員進行培訓、指導或幫助。與其讓用戶 “在使用中” 發現程序缺陷（這些缺陷本應該在幾個月前通過簡單的測試暴露出來），或者等到管理人員發現沒有編寫單元測試時再感到驚訝（和憤怒），還不如采取一些預防性的措施。
使用覆蓋報告來確保正確的測試是一項偉大的實踐。關鍵是要訓練有素地完成這項工作。例如，使每晚生成并查閱覆蓋報告成為連續累計 過程的一部分。
3. 評定功能測試
假設覆蓋報告在指出沒有經過 足夠測試的代碼部分方面非常有效，那么質量保證人員可以使用這些數據來評定與功能測試有關的關注區域。讓我們回到 “飲水機” 團隊來看看 QA 的負責人 Drew 是如何評價 Joe 的代碼的：
Drew 對 Jeff 說：“我們為下一個版本編寫了測試案例，我們注意到很多代碼沒有被覆蓋。那好像是與股票交易有關的代碼�！�
Jeff：“哦，我們在這個領域有好些問題。如果我是一個賭徒的話，我會對這個功能區域給予特別的關注。Mary 正在對這個應用程序做一些其他的修改 —— 她在編寫單元測試方面做得很好，但是這個代碼也太差了點�！�
Drew：“是的，我正在確定工作的資源和級別，看上去我沒必要那么擔心了，我估計我們的團隊會對股票交易模塊引起足夠的關注�！�
知識再次顯示了其強大的力量。與其他軟件生命周期中的風險承擔者（例如 QA）配合，您可以利用覆蓋報告所提供的信息來降低風險。在上面的場景中，也許 Jeff 可以為 Drew 的團隊提供一個早期的不包含 Mary 的所有修改的版本。不過無論如何，Drew 的團隊都應該關注應用程序的股票交易方面，與其他具有相應單元測試的代碼相比，這個地方似乎存在更大的缺陷風險。
測試有什么好處
對單元測試范例而言，測試覆蓋度量工具是一個有點奇怪的組成部分。對于一個已存在的有益的過程，覆蓋度量可以增加其深度和精度。然而，您應該仔細地閱讀代碼覆蓋報告。單獨的高覆蓋率并不能確保代碼的質量。對于減少缺陷，代碼的高覆蓋并不是必要條件，盡管高覆蓋的代碼的確更少 有缺陷。
測試覆蓋度量的竅門是使用覆蓋報告找出未經 測試的代碼，分別在微觀和宏觀兩個級別。通過從頂層開始分析您的代碼庫，以及分析單個類的覆蓋，可以促進深入的覆蓋測試。一旦您能夠綜合這些原則，您和您的組織就可以在真正需要的地方使用覆蓋度量工具，例如估計一個項目所需的時間，持續監控代碼質量以及促進與 QA 的協作。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
