集成測試

　　Rami Jaamour

　　Web服務和SOA給IT界帶來了一個十分重要，而又保守的趨勢：復雜性。它是從應用代碼慢慢衍生變為架構的。服務被重用，事務在信息層整合，運行時策略操作信息中的元數據，有時按相應的路線發送這些數據。這些是我們從中看到各個單獨的應用所表現出來的復雜性的所有的因素。這個趨勢加強了“架構第一“的開發典范，即先創建系統，再進行應用代碼編制。

　　集成已經是問題的主要來源，并將一直持續到開發周期的末尾。因此，以一和生產環境盡可能一樣的開發環境來開始是很重要的，以一規則的(一般是每晚)基礎建立和部署模型，集成到開發系統中去。當這完成時，就有可能對系統建立和維護回歸測試用例，那么測試就可以隨著系統的進展而被創建，發展和維護。這樣的測試是可以和真實用例盡可能的一樣的，因為他們是運行在一個和最終產品很相近的預先部署環境上的，它使得這些測試在確定沒有產生bug和在整個生命周期中保證功能的正確性方面更為強大。

　　完成這個過程的一個主要挑戰是在一個類似于產品上下文的環境上下文中從開發中分離出一個應用。這里需要清除和仿真，這些需要做些初始化工作。但是這樣的初始化工作是會在這整個周期中獲得回報的，因為你最終獲得了一個可以做改動并且模型被立即測試和驗證的靈活的，連續的過程。這個系統事實上變得易于測試，這是部署之前的很重要的一個特點。只有這個方法使得過程可預測和控制，以便你可以繼續進行這個項目，同時知道最后不會有什么大的意料之外的事情發生。

　　總之，集成測試應該及早的進行，和其他測試(例如單元測試)并行，如果采用了這種方法后應用是不可測的，那么就是出錯了。應該在一開始就做一個投入使得它是可測的。如果系統不是可集成測試的，那么開發團隊會發現他們浪費大量的時間在手動建模和部署活動上。如果發生了這種情況，那么在項目結尾的時候情況將變得更加糟糕。

原文轉自：http://www.anti-gravitydesign.com