構(gòu)建感測是一個用在持續(xù)集成周期中，用以描述構(gòu)建長期統(tǒng)計數(shù)據(jù)的術(shù)語。Bamboo，一個不錯的CI工具，它提供了很高級的構(gòu)建特性。構(gòu)建感測為你提供了關(guān)于構(gòu)建要花多久，是否成功，以及解決這個構(gòu)建失敗問題要花多久等等之類的信息。這些數(shù)據(jù)很重要，因為它可以讓你知道構(gòu)建過程長期以來是什么樣的。正是這種數(shù)據(jù)，而不是單個構(gòu)建的結(jié)果，可以幫助你終優(yōu)化構(gòu)建過程。

　　一定數(shù)量和頻率的構(gòu)建失敗一直是一個不錯的著手點。隔離的構(gòu)建失敗通常不需要擔心??你需要做的是去檢查一系列反復出現(xiàn)的構(gòu)建失敗。當一個構(gòu)建反復失敗時，也許是因為開發(fā)人員正糾結(jié)于一段非常麻煩的代碼，或者是團隊人員沒注意到。雖然這兩問題的原因不一樣，并且解決的方法也不一樣，但是它們都應當被進一步地調(diào)查。

　　通過深入分析測試結(jié)果，你可以了解到更多關(guān)于為什么構(gòu)建會失敗的信息。許多現(xiàn)代的CI工具都可以讓你研究長期的測試行為，例如，把一直經(jīng)常失敗的、或者要花很長時間進行解決的測試跟其他測試隔離開來。如果同樣的測試不斷失敗的話，這意味著有什么地方過于復雜或者代碼過于脆弱，這種情況下可以做一些重構(gòu)。除此之外，這些工具還能讓你知道測試運行了多久，這是另一類問題發(fā)生的源頭。

　　事實上，構(gòu)建失敗不是減慢開發(fā)進程的原因。緩慢的構(gòu)建過程是另一個罪魁禍首。

　　導致構(gòu)建過程緩慢的常見的原因是結(jié)構(gòu)混亂的測試套件。經(jīng)驗豐富的Java開發(fā)人員常常會將單元測試與集成測試分開來。雖然兩者區(qū)別大差不差，但是一般來說，單元測試是相對孤立的、較小的、快速的、輕量級的測試類。它們主要是用來確保類能夠獨立地正常工作。而另一方面，集成測試則較為緩慢，需要更長的運行時間，并且可能會訪問外部的資源如測試數(shù)據(jù)庫，或者加載復雜的配置文件。它們被用來測試應用程序中的不同模塊和類如何共同工作。性能測試和集成測試差不多，但是兩者的目標有所不同。

　　輕量級且運行很快的單元測試可以被迅速的執(zhí)行完，并且在測試失敗時能夠給出很快的反饋。而另一方面，如果緩慢運行的集成測試與單元測試混在一起，那么單元測試將要花上更多的時間來執(zhí)行，結(jié)果開發(fā)人員也要等更久才會得到關(guān)于單元測試失敗的消息。解決之道是為單元測試和集成/性能測試創(chuàng)建單獨的構(gòu)建計劃。使用這種方式后，如果單元測試構(gòu)建計劃失敗了，由于其執(zhí)行速度很快，開發(fā)人員不再需要等待很長時間才被通知到構(gòu)建失敗。如果單元測試成功后，集成測試和性能測試計劃才會開始。

　　另外，還有一個補充方法??可以使用分布式構(gòu)建。例如，如果你的web功能測試由于要在幾個不同的瀏覽器上運行并因此消耗很長時間，那么可以為每一個瀏覽器設立一個構(gòu)建作業(yè)，以讓它們(可能在不同的機器上)并行運行。

　　另一個問題來自過于緩慢和效率低下的測試用例。有許多方法可以用來監(jiān)測這些緩慢的測試。提高測試上的運行時間意味著有些測試會由于所需時間太長而無法運行。這也許是因為它們被設計的很糟糕，也許是因為性能問題(需要進步一深究)，抑或是集成測試偽裝成了單元測試。

　　密切關(guān)注代碼質(zhì)量

　　持續(xù)集成服務器不應當僅僅是一個自動構(gòu)建的機器。它應當成為你團隊中溝通的中樞，尤其在代碼質(zhì)量上。時刻關(guān)注編碼規(guī)范和一些度量值如代碼覆蓋率以及代碼復雜度，它們可以讓應用程序更加可靠且更易維護。

　　有很多的工具可以幫助維護應用程序中良好規(guī)范的代碼。靜態(tài)分析工具如Checkstyle，PMD和FindBugs，它們根據(jù)代碼標準、佳實踐或者潛在的bug來對代碼進行分析。你所有使用的工具如何配置要依賴于你想要達到的目標。例如，Checkstyle更多關(guān)注于編碼規(guī)范和佳實踐，而 Findbugs則更傾向于找出錯誤的，破碎的或者危險的代碼。所有的這些工具可以很輕松地集成到自動化構(gòu)建過程中，并且可以和Ant、Maven一起很好地工作。

　　覆蓋測試率是代碼質(zhì)量的另一個方面。它用來衡量測試執(zhí)行時所訪問的代碼行數(shù)。Java開發(fā)人員中對覆蓋測試率統(tǒng)計的相對值仍然有著分歧。事實上，雖然它可以告訴你應用程序中的哪些行被執(zhí)行，但是沒法知道那些測試是寫得很徹底、寫得很好，抑或僅僅是簡單的走馬觀花？偠灾，測試覆蓋率不能保證你的測試質(zhì)量很高??只有人工進行代碼檢查時才能確保如此。然而覆蓋測試率的度量值可以很好地展示出哪些代碼沒有被測試過。在Java世界里，用得多的代碼覆蓋率測試工具當屬Clover和Cobertura，前者是一個非常強大的商業(yè)代碼覆蓋率測試工具，而后者是一個更加輕量級的開源工具。它們都可以很容易地集成到基于Ant和Maven的構(gòu)建腳本中。