“集成測試”真的是陰謀?

     “集成測試”真的是陰謀?   集成測試工具

　　J.B.對集成測試作了定義，認為集成測試是：

　　在我的理解中，集成測試表示那些測試結果(成功或失敗)依賴于超過一個重要行為的實現正確性的測試。

　　簡單可以理解為集成測試是依賴于其他(多于一個)測試的測試。

　　J.B.為什么認為集成測試是一個因為，他的觀點是：

　　1、開發人員認為某一缺陷只能通過集成測試發現，因此認為應該integrate everywhere，要寫大量集成測試。

　　2、J.B.列舉一個中型web app的集成測試大概包含至少1000個集成測試，開發人員容易產生抵觸情緒。

　　3、J.B.以兩個測試進行對比，一個是對象測試(我的理解是單元測試)，另一個則是集成測試，對象測試花費6秒，集成測試花費1分鐘，而開發人員保持1分鐘屏幕關注時間是不可能的，一分鐘當中開發人員的注意力分散從而導致過多開銷和低效，J.B.稱之為集成測試的“隱含成本”。

　　關于觀點1，根據我的測試經歷，集成測試的目標應該關注于“集成可運行”上，比如一個集成涉及BO1, BO2,那么集成測試關注的應該是BO1+BO2得到的測試結果是可信的，而且測試結果通常不涉及太多可能性測試，比如通過不同的入口來測試集成結果的準確性，這樣成本的確很高，而且會跟BO1，BO2的單元測試產生重疊，這也是一些集成測試采用MOCK測試的原因。

　　關于觀點2，如果集成測試采用我說的那種“通過不同的入口來測試集成結果的準確性”的話，的確會發生抵觸情況，因為集成測試的測試周期相對較長，內聚性不強，需要耗費很多精力，比如有可能涉及很多條件分支。

　　關于觀點3，J.B.這里是拿集成測試和單元測試做比較，固然這是一個視角，但是這個視角是否全面我認為有失偏頗，拿一個JavaWebApp作例，對Service類做測試比較容易，如果把Action看作集成測試的話，Action測試的難度要較前者高，因而往往Action的測試有可能會被忽略掉，但是問題的發生在手工調試Action這一環節，比如出現Service中出現空指針，如果對Action做測試的話，問題有可能會在測試中發現并解決，而不是在對整個app進行編譯和啟動、運行、打開瀏覽器、輸入用戶名、密碼，手工集成測試之后才發現問題，而這一系列過程所花的時間完全不止1分鐘這么短，有可能是5分鐘——完全可以來JavaEye灌水了!

　　如果把集成測試都累積做完之后，整個app會形成一個很完整的測試體系，再通過持續化集成工具來輔助實現集成自動化，專門拉到一臺測試服務器做集成，J.B.說的那個1分鐘問題其實可以完全避免，因此我認為J.B.的陰謀論有些牽強。當然，集成測試必須建立在單元測試之上，這點毋庸置疑，集成測試的重點應該根據項目實情做出策略上調整，比如對集成目標、深度的制定上做修正。

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