第11回 整合測試的模式和方法

       單元測試主要由開發人員完成，所以從測試人員工作來看，整合測試可能是具體測試實施的第一個階段，雖然開發人員也比較多地參與整合測試。整合測試相對來說是挺複雜的，而且對於不同的技術、平台和應用，差異也比較大。不過，我們還是不得不面對它，保證系統整合成功，為後來的系統測試打下基礎。
      
       整合測試簡單的表現形式就是每日構建（Daily Build）, 保證Build構建成功，也就是保證軟體的組件或單元能組裝成一個系統。每日構建是一個很好的實踐，被許多軟體公司採用。

      整合測試，更多是和開發環境融合在一起，在編程過程中去實現，如MS Visual Studio.NET ，Borland JBuilder IDE， Compuware OptimalJ的整合開發/測試環境。更正確的說法，整合測試發要追溯到設計階段。當設計資料介面(DB，XML等）、組件介面、應用介面(API)之時，我們就要審查介面的規範性、一致性等，就已經開始了整合測試。

整合測試階段，測試方法是動態變化的，從白盒測試方法向黑箱測試方法逐漸過渡。在自底向上整合的早期，白盒測試方法占較大的比例，隨著整合測試的不斷深入，這種比例在測試過程中將越來越少，漸漸地，黑箱測試慢慢佔據著主導地位。

整合模式是軟體整合測試中的策略體現，其重要性是明顯的，直接關係到測試的效率、結果等，一般要根據具體的系統來決定採用哪種模式。整合測試基本可以概括為以下兩種：

• 非漸增式測試模式：先分別測試每個模組，再把所有模組按設計要求一次全部組裝起來所要的系統，然後進行整體測試。
  
• 漸增式測試模式：把下一個要測試的模組同已經測試好的模組結合起來進行測試，測試完以後再把下一個模組結合進來測試。

     非漸增式測試時可能發現一大堆錯誤，為每個錯誤定位和糾正非常困難，並且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是漸增式整合模式，程式一段一段地擴充，測試的範圍一步一步地增大，錯誤易於定位和糾正，介面的測試亦可做到完全徹底。兩種模式中，漸增式測試模式雖然需要編寫的Driver或Stub程式較多、發現模組間介面錯誤相對稍晚些，但漸增式測試模式還具有比較明顯的優勢。

在實際測試中，應該將兩種模式有機結合起來，採用並行的自頂向下、自底向上整合方式，而形成改進的三明治方法。而更重要的是採取持續整合的策略，軟體開發中各個模組不是同時完成，根據進度將完成的模組儘可能早的進行整合，有助於儘早發現缺陷，避免整合階段大量缺陷湧現。同時自底向上整合時，先期完成的模組將是後期模組的樁程式，而自頂向下整合時，先期完成的模組將是後期模組的驅動程式，從而使後期模組的單元測試和整合測試出現了部分的交叉，不僅節省了測試代碼的編寫，也有力於提高工作效率。

如果不採用持續整合策略，開發人員經常需要集中開會來分析軟體究竟在什麼地方出了錯。因為某個程式員在寫自己這個模組代碼時，可能會影響其它模組的代碼，造成與已有程式的變數衝突、介面錯誤，結果導致被影響的人還不知道發生了什麼，缺陷就出現了。隨著時間的推移，問題會逐漸惡化。通常，在整合階段出現的缺陷早在幾周甚至幾個月之前就已經存在了。結果，開發人員需要在整合階段耗費大量的時間和精力來尋找這些缺陷的根源。如果使用持續整合，這樣的缺陷絕大多數都可以在引入的第一天就被發現。而且，由於一天之中發生變動的部分並不多，所以可以很快找到出錯的位置。這也就是為什麼進行每日構建軟體包的原因所在。所以，持續整合可以提高軟體開發的品質與效率。

在現實中，整合測試和單元測試所處的情形相似，測試不徹底、不充分，沒有各種介面參數、各類介面資料進行充分測試。如果系統的架構的層次不清楚，這種問題會更嚴重。目強許多開放系統都支援API，其整合測試的內容就更多了，除了API手冊的內容正確性驗證之外，還要類比使用者調用API的各種Scenario，後者在編程技術、對產品的各類應用要很好掌握，才能做好測試。

預知後事如何，請讀下回分解：第12回 功能測試和適用性測試的標準

著作權，軟體測試演義

——系列討論的目錄，見： 軟體測試演義——中進階系列（序）