必須引入開發者測試的10個強烈信號

　　必須引入開發者測試的10個強烈信號  軟件測試

　　很少有企業會在一架飛機的構件做完壽命測試之前去做試飛實驗。然而如今的大多數軟件開發企業仍然在軟件單元測試通過之前將系統集成。假如你正負責用Java開發企業級的應用軟件，那你如今是發現了一個更便利的方法，來解決這個問題。請核對一下以下的10條信號，你將發現開發者測試對你的必要，以致你從今天開始就著手企業開發者測試(EDT)。

　　第十條：你的開發人員因軟件質量問題而花大量時間返工。

　　許多開發團隊在修補軟件和維護已發布的軟件上要花去50%以上的時間。當系統變得龐大時，這些工作就變得更為復雜。尤其是在許多現存缺陷的系統部件被集成在一起后。EDT的最大優點就是使開發團隊第一時間創造出高質量的軟件從而減少返工的時間。

　　第九條：因為低質量的系統納入了QA循環體系而延長了QA的周期。

　　我們經常遇到這樣的事，因為被測試的軟件無法啟動運行而使得計劃中的系統測試被取消。因為單元級的軟件缺陷導致系統無法運作，QA的資源是解決不了這類問題，這時開發的每一個參與者都蒙受損失。一旦當開發工程師運用EDT確保遞交QA的代碼是高質量的。那QA就可以更注重于檢測軟件功能的準確性以及在壓力情況下的表現能力

　　第八條：你發現極難維護現有的代碼基礎。

　　許多公司不得不維護很久以前編寫的軟件或者通過企業購買得到的軟件資產，這些軟件的開發人員都已經不在了，在這種情形之下，對軟件進行任何修改都變得風險較大。為了解決這類難題，軟件需要被重新整理和進行單元測試使開發人員對軟件代碼有所了解并建立信心。EDT可以為這類過程提供全自動的，帶管理功能的工具，使得這一流程變得更有效和經濟。

　　第七條：你的QA部門需要有一個單元測試標準來度量被允許進入QA循環的代碼。

　　一直以來，對于單元測試的程度成為很難去度量和評判。俗話說“不可用標準來度量的事，則不可能被管理起來”。EDT則可以對單元測試提供度量以及更為詳細的信息，從而使得開發團隊向QA移交代碼變得簡單易行。

　　第六條：你很難讓你的開發團隊在開發過程中引入單元測試。

　　假如企業希望單元測試成功，那就必須將單元測試集成到開發流程中去，然而開發團隊經常為了趕進度而放棄單元測試，實際上導致更多開發進度的延誤。EDT可將單元測試流程集成到現有的配置管理框架內，以便建立和監督測試目標，提供必要的度量和可觀察力，將單元測試作為核心開發流程的一部分來管理。

　　第五條：你必須了解你的單元測試資產才能管理你的開發團隊。

　　當軟件被很好的設計(包括單元測試)后，任何根據業務要求的軟件變更變得迅速。一旦開發人員了解并對自己的代碼有信心，軟件變更變得容易，從而使軟件能更好地服務于業務。當然目前只有少數的公司能對其單元測試有深入的了解。EDT不僅可以為企業的單元測試提供全局觀，可以提供詳細的單元測試信息

　　第四條：你可以用Junit來做單元測試，但因其的低質量和低覆蓋率導致對你的單元測試增值不大。

　　采納單元測試流程是個很好的開端，但很多公司在短期內看到的則是相對單元測試之前較差的投資回報率。單元測試是一個綜合的問題，EDT可以幫助在開發中自動生成單元測試，并隨代碼的變化而更新。運用EDT開發者可以達到更高的測試覆蓋率和質量，但又無需花太多的努力

　　第三條：你發現使用Junit做單元測試太費時費力。

原文轉自：http://www.kjueaiud.com