【羅馬城非朝夕建成,測試體系非一日之功】
【概念】
說到測試，最主要的是，檢測代碼是否滿足特定的邏輯,檢測代碼是否滿足業務的需求。
測試還需要有一些附加特性，如：快速響應、可重複運行、可持續維護等。目前的測試基本可以分爲：
單元測試：檢測代碼片段的測試，基本是以代碼結構爲衡量，屬於百盒測試。集成測試：集成各個系統的各個模塊，各個代碼片段的，主要以業務爲角度。屬於黑盒測試。驗收測試：主要是人工頁面驗證，用戶演示，PD驗證等，此主要是測試功能是否正確，以業務爲出發點。一般是人工進行，比較難進行自動化。
【現狀】
單元測試、集成測試、驗收測試，三者之間合理的關係如下：
上圖是測試的黃金三角，但是我們由於過去自動化測試只是弄了一個概念，叫單元測試，後大家寫測試的時候，就弄成了如下的圖形了。單元測試寫的不成樣子，成了一窩粥了。如果把單元測試中寫得像集成測試的抽出來當做集成測試的話，在系統中的測試算得上單元測試的基本沒有多少了。那 就成了倒三角了。如下圖所示：痛一：單元測試沒有發揮單元測試的作用，寫得像集成測試的測試也寫得四不像的。維護成本非常高，基本不可維護了。
爲此，需要把單元測試中寫得像集成測試的case，名正言順的換了名稱，叫做集成測試（不是直接改，做集成測試需要新的方法，這裏只是笑談罷了）。單元測試做好本職的工作，完成代碼片段的測試。如果單元測試與集成測試的分工明確，測試代碼的可讀性也非常高。
痛二：驗收測試成本非常高，大量的手工測試，不可重複運行。
【集成測試】此點也需要引入以業務爲出發的集成測試，以業務爲出發點，減少驗收測試的比例。最終：把我們倒三角，變成正三角。因爲集成測試在其中起着非常重要的作用，下面講下，集成測試的一些討論及心得，
業界對集成測試有一定的定義，這裏主要講下我對集成測試的理解。集成測試主要是把模塊，代碼片段銜接起來的測試。在阿里巴巴核心系統，從代碼可行性出發，也就是從業務的角度設計集成測試的用例，也就是集成測試的用例主要是面向業務的。
【反對者】
不管啥東西，肯定都有反對的聲音的，目前主要的反對的聲音有：1、維護難，維護成本較高2、集成測試的成果怎麼評估。3、集成構建時間長，開發不容易專注。在互聯網上也有人（如：J.B. Rainsberger）說集成測試是一個陰謀。
【集成測試解決方案】
爲此，最近有同學組織了專門針對集成測試執行問題的討論。以下是會議紀要，我大致整理下，紅色字體是我的一些補充及觀點。1、集成測試做什麼、目的？集成測試是一種基於測試用例，業務驅動的自動化測試方法；通過與單元測試合理分工，解決單元測試、集成測試邊界不清、佔比少、單元測試因對數據庫依賴、加載spring時運行時間過長的問題。【基本靠譜，但是最好不要脫離集成測試的本質思想，他就是集成各個系統的各個模塊，各個代碼片段的。當然可以針對業務場景，業務用例case來實現】2、價值在哪裏？【以下總結還行的，其實以前是缺乏集成測試的，或者沒有好的指導方法。】1）減少手工測試執行比，實現代碼質量的短反饋；【可以自動】2）測試人員提前介入測試；3）界定單元測試、集成測試邊界；4）解決UI自動化運行慢、不穩定、對環境依賴性強的問題；5）可在項目結束後持續集成、對代碼重構、代碼核心業務功能的正常、穩定運行提供質量保證；6）測試代碼的可讀性強；7）在編碼過程中，發現代碼不可測或難於測試，提高業務代碼的可測性；3、開發、測試如何協同？【其實在很多的公司，如google，開發對系統的質量負有全部責任的。測試同學更多是提供一種測試的支持，測試更多是一個角色，不是一個崗位，阿里目前部分團隊還是有專門的測試同學的，導致開發很大程度上面把系統的質量交給測試了。】1）開發同學對集成測試代碼進行codeReview;2）通過協商，使單元測試、集成測試實現合理分工，避免重複測試、無效測試；3）開發同學的設計文檔中，對最接近web層代碼、service層接口詳細描述，並說明相關的交互場景、交互流程；4）開發同學協助測試人員搭建集成測試框架，重點包括：子工程目錄設計、antx.properties文件、intergration.xml文件、pom.xml文件等相關配置文件；4、集成測試可行性參考因素【集成測試本身是沒有問題，關鍵在於測試的用例設計，不要把case設計得過於細，對於一些user story，case比較多，是可以考慮把部分的case放到單元測試實現，個人感覺對於一個user story的case，4個用在集成測試下，應該是比較好的。user story的case比較多，那是否考慮，user story的合理性了。關於與單元測試的關係，單元測試主要關注代碼片段的邏輯。更本就不存在與單元測試重複的問題， 如果重複也應該是單元測試寫的有問題。】1）對核心、穩定（業務相對穩定）功能進行集成測試；2）不與現有單元測試覆蓋功能重複；5、會不會延長項目週期【此點在前期，框架不完善、測試開發對此不熟悉的情況下，還是可能會增加項目的工時的，但是等測試已經形成一定的規模後，還是可縮短測試時間的，特別是一些底層框架的升級，基本不需要測試手工運行測試了。】3）能減少手工測試執行時間、縮短項目週期；不會，QA提前介入、減少手工迴歸測試範圍；6、代碼編寫、維護成本如何減少？【當然第一靠case的質量，第二看開發者的抽象的能力，第三靠框架了。】框架優化,公司目前有專門的框架支持的。
以上基本可以回答反對者的擔心的問題了，還有一點就是集成測試構建時間的問題，對於單個case，可能需要幾分鐘，此點可以通過框架層解決。如：延遲加載等技術。對於測試集成慢，可以分階段集成，可以參考‘參考資料’。
【再此思考】
【參考資料】我們還是記住測試的黃金三角圖形，單元測試是保證代碼片段的質量的。集成測試主要以業務case的角度來編寫測試的，保障核心的業務功能。希望能通過自動化的集成測試，減少測試的手工測試成本。關於驗收測試，基本是客戶體驗，PD驗證了，此主要是通過手工驗證的。最後強調地是集成測試也並非銀彈，沒有一種實踐能解決所有的問題，必須合理把一些實踐合理地分工，才能解決大部分問題。
持續集成之“測試三角形與分段構建策略原則”：http://www.infoq.com/cn/news/2011/02/ci-test-triangleContinuous Integration (original version):http://www.martinfowler.com/articles/originalContinuousIntegration.htmlContinuous Integration:http://martinfowler.com/articles/continuousIntegration.html如果你看到這裏，請你評論下，留下你的觀點，討論下測試之痛。謝謝。
