集成測試常用方案選型

集成測試的實施方案有很多種，如自底向上集成測試、自頂向下集成測試、Big-Bang集成測試、三明治集成測試、核心集成測試、分層集成測試、基于使用的集成測試等。在此，筆者將重點討論其中一些經實踐檢驗和一些證實有效的集成測試方案。
 

      ·自底向上集成測試

     自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地繼承、吸收了這種集成方式的思想。自底向上集成方式從程序模塊結構中最底層的模塊開始組裝和測試。因為模塊是自底向上進行組裝的，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）事前已經完成組裝并經過測試，所以不再需要編制樁模塊（一種能模擬真實模塊，給待測模塊提供調用接口或數據的測試用軟件模塊）。自底向上集成測試的步驟大致如下:

     步驟一:按照概要設計規格說明，明確有哪些被測模塊。在熟悉被測模塊性質的基礎上對被測模塊進行分層，在同一層次上的測試可以并行進行，然后排出測試活動的先后關系，制定測試進度計劃。圖2給出了自底向上的集成測試過程中各測試活動的拓撲關系。利用圖論的相關知識，可以排出各活動之間的時間序列關系，處于同一層次的測試活動可以同時進行，而不會相互影響。

     步驟二:在步驟一的基礎上，按時間線序關系，將軟件單元集成為模塊，并測試在集成過程中出現的問題。這里，可能需要測試人員開發一些驅動模塊來驅動集成活動中形成的被測模塊。對于比較大的模塊，可以先將其中的某幾個軟件單元集成為子模塊，然后再集成為一個較大的模塊。

     步驟三:將各軟件模塊集成為子系統（或分系統）。檢測各自子系統是否能正常工作。同樣，可能需要測試人員開發少量的驅動模塊來驅動被測子系統。

     步驟四:將各子系統集成為最終用戶系統，測試是否存在各分系統能否在最終用戶系統中正常工作。

     方案點評:自底向上的集成測試方案是工程實踐中最常用的測試方法。相關技術也較為成熟。它的優點很明顯:管理方便、測試人員能較好地鎖定軟件故障所在位置。但它對于某些開發模式不適用，如使用XP開發方法，它會要求測試人員在全部軟件單元實現之前完成核心軟件部件的集成測試。盡管如此，自底向上的集成測試方法仍不失為一個可供參考的集成測試方案。

      ·核心系統先行集成測試

     核心系統先行集成測試法的思想是先對核心軟件部件進行集成測試，在測試通過的基礎上再按各外圍軟件部件的重要程度逐個集成到核心系統中。每次加入一個外圍軟件部件都產生一個產品基線，直至最后形成穩定的軟件產品。核心系統先行集成測試法對應的集成過程是一個逐漸趨于閉合的螺旋形曲線，代表產品逐步定型的過程。其步驟如下:

     步驟一:對核心系統中的每個模塊進行單獨的、充分的測試，必要時使用驅動模塊和樁模塊;

     步驟二:對于核心系統中的所有模塊一次性集合到被測系統中，解決集成中出現的各類問題。在核心系統規模相對較大的情況下，也可以按照自底向上的步驟，集成核心系統的各組成模塊。

     步驟三:按照各外圍軟件部件的重要程度以及模塊間的相互制約關系，擬定外圍軟件部件集成到核心系統中的順序方案。方案經評審以后，即可進行外圍軟件部件的集成。

     步驟四:在外圍軟件部件添加到核心系統以前，外圍軟件部件應先完成內部的模塊級集成測試。

     步驟五:按順序不斷加入外圍軟件部件，排除外圍軟件部件集成中出現的問題，形成最終的用戶系統。

     方案點評:該集成測試方法對于快速軟件開發很有效果，適合較復雜系統的集成測試，能保證一些重要的功能和服務的實現。缺點是采用此法的系統一般應能明確區分核心軟件部件和外圍軟件部件，核心軟件部件應具有較高的耦合度，外圍軟件部件內部也應具有較高的耦合度，但各外圍軟件部件之間應具有較低的耦合度。

      ·高頻集成測試

     高頻集成測試是指同步于軟件開發過程，每隔一段時間對開發團隊的現有代碼進行一次集成測試。如某些自動化集成測試工具能實現每日深夜對開發團隊的現有代碼進行一次集成測試，然后將測試結果發到各開發人員的電子郵箱中。該集成測試方法頻繁地將新代碼加入到一個已經穩定的基線中，以免集成故障難以發現，同時控制可能出現的基線偏差。使用高頻集成測試需要具備一定的條件:可以持續獲得一個穩定的增量，并且該增量內部已被驗證沒有問題;大部分有意義的功能增加可以在一個相對穩定的時間間隔（如每個工作日）內獲得;測試包和代碼的開發工作必須是并行進行的，并且需要版本控制工具來保證始終維護的是測試腳本和代碼的最新版本;必須借助于使用自動化工具來完成。高頻集成一個顯著的特點就是集成次數頻繁，顯然，人工的方法是不勝任的。

     高頻集成測試一般采用如下步驟來完成:

     步驟一:選擇集成測試自動化工具。如很多Java項目采用Junit+Ant方案來實現集成測試的自動化，也有一些商業集成測試工具可供選擇。

     步驟二:設置版本控制工具，以確保集成測試自動化工具所獲得的版本是最新版本。如使用CVS進行版本控制。

     步驟三:測試人員和開發人員負責編寫對應程序代碼的測試腳本。

     步驟四:設置自動化集成測試工具，每隔一段時間對配置管理庫的新添加的代碼進行自動化的集成測試，并將測試報告匯報給開發人員和測試人員。

     步驟五:測試人員監督代碼開發人員及時關閉不合格項。

     按照步驟三至步驟五不斷循環，直至形成最終軟件產品。

     方案點評:該測試方案能在開發過程中及時發現代碼錯誤，能直觀地看到開發團隊的有效工程進度。在此方案中，開發維護源代碼與開發維護軟件測試包被賦予了同等的重要性，這對有效防止錯誤、及時糾正錯誤都很有幫助。該方案的缺點在于測試包有時候可能不能暴露深層次的編碼錯誤和圖形界面錯誤。

     以上我們介紹了幾種常見的集成測試方案，一般來講，在現代復雜軟件項目集成測試過程中，通常采用核心系統先行集成測試和高頻集成測試相結合的方式進行，自底向上的集成測試方案在采用傳統瀑布式開發模式的軟件項目集成過程中較為常見。讀者應該結合項目的實際工程環境及各測試方案適用的范圍進行合理的選型。

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