單元測試主要由開發人員完成，所以從測試人員工作來看，整合測試可能是具體測試實施的第乙個階段，雖然開發人員也比較多地參與整合測試。整合測試相對來說是挺複雜的，而且對於不同的技術、平台和應用，差異也比較大。不過，我們還是不得不面對它，保證系統整合成功，為後來的系統測試打下基礎。
整合測試簡單的表現形式就是每日構建（daily build）, 保證build構建成功，也就是保證軟體的元件或單元能組裝成乙個系統。每日構建是乙個很好的實踐，被許多軟體公司採用。
整合測試，更多是和開發環境融合在一起，在程式設計過程中去實現，如ms
visual studio.net ，
borland jbuilder ide， compuware optimalj
的整合開發/測試環境
。更正確的說法，整合測試髮要追溯到設計階段。當設計資料介面(db，xml等）、元件介面、應用介面(api)之時，我們就要審查介面的規範性、一致性等，就已經開始了整合測試。
整合測試階段，測試方法是動態變化的，從白盒測試方法向黑盒測試方法逐漸過渡。在自底向上整合的早期，白盒測試方法佔較大的比例，隨著整合測試的不斷深入，這種比例在測試過程中將越來越少，漸漸地，黑盒測試慢慢佔據著主導地位。
整合模式是軟體整合測試中的策略體現，其重要性是明顯的，直接關係到測試的效率、結果等，一般要根據具體的系統來決定採用哪種模式。整合測試基本可以概括為以下兩種：
非漸增式測試時可能發現一大堆錯誤，為每個錯誤定位和糾正非常困難，並且在改正乙個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是
漸增式整合模式，程式一段一段地擴充套件，測試的範圍一步一步地增大，錯誤易於定位和糾正，介面的測試亦可做到完全徹底。兩種模式中，
漸增式測試模式雖然需要編寫的driver或stub程式較多、發現模組間介面錯誤相對稍晚些，但漸增式測試模式還具
有比較明顯的優勢。
在實際測試中，應該將兩種模式有機結合起來，採用並行的自頂向下、自底向上整合方式，而形成改進的三明治方法。
而更重要的是採取持續整合的策略，軟體開發中各個模組不是同時完成，根據進度將完成的模組盡可能早的進行整合，有助於盡早發現缺陷，避免整合階段大量缺陷湧現。同時自底向上整合時，先期完成的模組將是後期模組的樁程式，而自頂向下整合時，先期完成的模組將是後期模組的驅動程式，從而使後期模組的單元測試和整合測試出現了部分的交叉，不僅節省了測試**的編寫，也有力於提高工作效率。
如果不採用持續整合策略，開發人員經常需要集中開會來分析軟體究竟在什麼地方出了錯。因為某個程式設計師在寫自己這個模組**時，可能會影響其它模組的**，造成與已有程式的變數衝突、介面錯誤，結果導致被影響的人還不知道發生了什麼，缺陷就出現了。隨著時間的推移，問題會逐漸惡化。通常，在整合階段出現的缺陷早在幾周甚至幾個月之前就已經存在了。結果，開發者需要在整合階段耗費大量的時間和精力來尋找這些缺陷的根源。如果使用持續整合，這樣的缺陷絕大多數都可以在引入的第一天就被發現。而且，由於一天之中發生變動的部分並不多，所以可以很快找到出錯的位置。這也就是為什麼進行每日構建軟體包的原因所在。
所以，持續整合可以提高軟體開發的質量與效率。
在現實中，整合測試和單元測試所處的情形相似，測試不徹底、不充分，沒有各種介面引數、各類介面資料進行充分測試。如果系統的架構的層次不清楚，這種問題會更嚴重。目強許多開放系統都支援api，其整合測試的內容就更多了，除了api手冊的內容正確性驗證之外，還要模擬使用者呼叫api的各種scenario，後者在程式設計技術、對產品的各類應用要很好掌握，才能做好測試。
預知後事如何，請讀下回分解：
第12回 功能測試和適用性測試的標準
®
——系列討論的目錄，見：
軟體測試演義——中高階系列（序）
第11回 整合測試的模式和方法
單元測試主要由開發人員完成，所以從測試人員工作來看，整合測試可能是具體測試實施的第乙個階段，雖然開發人員也比較多地參與整合測試。整合測試相對來說是挺複雜的，而且對於不同的技術 平台和應用，差異也比較大。不過，我們還是不得不面對它，保證系統整合成功，為後來的系統測試打下基礎。整合測試簡單的表現形式就是...
第13回 負載 效能測試和容量測試的關係和區別
對於軟體應用系統，僅僅從功能上滿足使用者的需求是不夠的，還需要從效能 可用性等方面更好地滿足客戶的需要。1 強度測試或壓力測試 強度或壓力測試是在一種需要異常數量 頻率或資源的方式下，執行可重複的負載測試 以檢查程式對異常情況的抵抗能力，找出效能瓶頸。異常情況,主要指那些峰值 極限值 大量資料的長時...
第13回 負載 效能測試和容量測試的關係和區別
對於軟體應用系統，僅僅從功能上滿足使用者的需求是不夠的，還需要從效能 可用性等方面更好地滿足客戶的需要。1 強度測試或壓力測試 強度或壓力測試是在一種需要異常數量 頻率或資源的方式下，執行可重複的負載測試 以檢查程式對異常情況的抵抗能力，找出效能瓶頸。異常情況,主要指那些峰值 極限值 大量資料的長時...