如何實施軟件集成測試

如何實施軟件集成測試

集成測試      軟件測試

一、集成測試

集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求）如根據結構圖〕組裝成為子系統或系統，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。

二、集成測試的兩種模式

非漸增式測試模式。先分別測試每個模塊，再把所有模塊按設計要求一次全部組裝起來所要的系統，然后進行整體測試。

漸增式測試模式。把下一個要測試的模塊同已經測試好的模塊結合起來進行測試，測試完以后再把下一個模塊結合起來測試。

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

三、集成測試注意事項

1、接口一定要定義清晰和明確接口定義階段也需要測試人員的參與，定義好的接口，需要記錄并形成相關的文檔。
　
2、接口之間的規則，命名等一定要規范，且有據可依，各自嚴格遵守約定。
　
3、集成測試之前， 集成的各自系統以及模塊一定要做好充分的獨立功能測試， 并且通過造數據的方式模擬過一定程度的集成測試。否則在集成測試中碰到的問題要花大量的時間去查找到底是模塊自身的功能問題， 還是集成引起的問題。如果是自身引起的問題， 則會浪費很多時間在修改和回測， 造成其他集成方的時間浪費。
　
4、接口的任何變更一定要及時通知集成另外一方的開發和測試人員。

5、集成測試點、測試用例、甚至是測試數據都需要提前擬定，由兩方人員進行審核和確認，達成共識。

6、其他：集成測試時間安排一定要一致， 避免無謂的時間浪費雙方的版本控制問題。

四、集成測試常用方案選型

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

　　•自頂向下集成測試

　　自頂向下集成（Top-Down Integration）方式是一個遞增的組裝軟件結構的方法。從主控模塊（主程序）開始沿控制層向下移動，把模塊一一組合起來。分兩種方法：

　　第一：先深度：按照結構，用一條主控制路徑將所有模塊組合起來；

　　第二：先寬度：逐層組合所有下屬模塊，在每一層水平地沿著移動。

　　組裝過程分以下五個步驟：

　　步驟一：用主控模塊作為測試驅動程序，其直接下屬模塊用承接模塊來代替；

　　步驟二：根據所選擇的集成測試法（先深度或先寬度），每次用實際模塊代替下屬的承接模塊

　　步驟三：在組合每個實際模塊時都要進行測試；

　　步驟四：完成一組測試后再用一個實際模塊代替另一個承接模塊；

　　步驟五：可以進行回歸測試（即重新再做所有的或者部分已做過的測試），以保證不引入新的錯誤。

　　•自底向上集成測試

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

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

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

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

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

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

　　•核心系統先行集成測試

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

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

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

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

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

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

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

　　•高頻集成測試

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

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

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

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

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

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

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

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

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

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