構建感測是一個用在持續集成周期中，用以描述構建長期統計數據的術語。Bamboo，一個不錯的CI工具，它就提供了很高級的構建特性。構建感測為你提供了關于構建要花多久，是否成功，以及解決這個構建失敗問題要花多久等等之類的信息。這些數據很重要，因為它可以讓你知道構建過程長期以來是什么樣的。正是這種數據，而不是單個構建的結果，可以幫助你最終優化構建過程。
一定數量和頻率的構建失敗一直是一個不錯的著手點。隔離的構建失敗通常不需要擔心——你需要做的是去檢查一系列反復出現的構建失敗。當一個構建反復失敗時，也許是因為開發人員正糾結于一段非常麻煩的代碼，或者是團隊人員沒注意到。雖然這兩問題的原因不一樣，并且解決的方法也不一樣，但是它們都應當被進一步地調查。
通過深入分析測試結果，你可以了解到更多關于為什么構建會失敗的信息。許多現代的CI工具都可以讓你研究長期的測試行為，例如，把一直經常失敗的、或者要花很長時間進行解決的測試跟其他測試隔離開來。如果同樣的測試不斷失敗的話，這就意味著有什么地方過于復雜或者代碼過于脆弱，這種情況下可以做一些重構。除此之外，這些工具還能讓你知道測試運行了多久，這是另一類問題發生的源頭。
事實上，構建失敗不是唯一減慢開發進程的原因。緩慢的構建過程是另一個罪魁禍首。
導致構建過程緩慢的最常見的原因是結構混亂的測試套件。經驗豐富的Java開發人員常常會將單元測試與集成測試分開來。雖然兩者區別大差不差，但是一般來說，單元測試是相對孤立的、較小的、快速的、輕量級的測試類。它們主要是用來確保類能夠獨立地正常工作。而另一方面，集成測試則較為緩慢，需要更長的運行時間，并且可能會訪問外部的資源如測試數據庫，或者加載復雜的配置文件。它們被用來測試應用程序中的不同模塊和類如何共同工作。性能測試和集成測試差不多，但是兩者的目標有所不同。
輕量級且運行很快的單元測試可以被迅速的執行完，并且在測試失敗時能夠給出很快的反饋。而另一方面，如果緩慢運行的集成測試與單元測試混在一起，那么單元測試將要花上更多的時間來執行，結果開發人員也要等更久才會得到關于單元測試失敗的消息。解決之道就是為單元測試和集成/性能測試創建單獨的構建計劃。使用這種方式后，如果單元測試構建計劃失敗了，由于其執行速度很快，開發人員不再需要等待很長時間才被通知到構建失敗。如果單元測試成功后，集成測試和性能測試計劃才會開始。
另外，還有一個補充方法——可以使用分布式構建。例如，如果你的web功能測試由于要在幾個不同的瀏覽器上運行并因此消耗很長時間，那么可以為每一個瀏覽器設立一個構建作業，以讓它們(可能在不同的機器上)并行運行。
另一個問題來自過于緩慢和效率低下的測試用例。有許多方法可以用來監測這些緩慢的測試。提高測試上的運行時間意味著有些測試會由于所需時間太長而無法運行。這也許是因為它們被設計的很糟糕，也許是因為性能問題(需要進步一深究)，抑或是集成測試偽裝成了單元測試。
密切關注代碼質量
持續集成服務器不應當僅僅是一個自動構建的機器。它應當成為你團隊中溝通的中樞，尤其在代碼質量上。時刻關注編碼規范和一些度量值如代碼覆蓋率以及代碼復雜度，它們可以讓應用程序更加可靠且更易維護。
有很多優秀的工具可以幫助維護應用程序中良好規范的代碼。靜態分析工具如Checkstyle，PMD和FindBugs，它們根據代碼標準、最佳實踐或者潛在的bug來對代碼進行分析。你所有使用的工具如何配置要依賴于你想要達到的目標。例如，Checkstyle更多關注于編碼規范和最佳實踐，而 Findbugs則更傾向于找出錯誤的，破碎的或者危險的代碼。所有的這些工具可以很輕松地集成到自動化構建過程中，并且可以和Ant、Maven一起很好地工作。
覆蓋測試率是代碼質量的另一個方面。它用來衡量測試執行時所訪問的代碼行數。Java開發人員中對覆蓋測試率統計的相對值仍然有著分歧。事實上，雖然它可以告訴你應用程序中的哪些行被執行，但是沒法知道那些測試是寫得很徹底、寫得很好，抑或僅僅是簡單的走馬觀花�？偠灾�，測試覆蓋率不能保證你的測試質量很高——只有人工進行代碼檢查時才能確保如此。然而覆蓋測試率的度量值可以很好地展示出哪些代碼沒有被測試過。在Java世界里，用得最多的代碼覆蓋率測試工具當屬Clover和Cobertura，前者是一個非常強大的商業代碼覆蓋率測試工具，而后者是一個更加輕量級的開源工具。它們都可以很容易地集成到基于Ant和Maven的構建腳本中。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
