集成測試

^[2]  集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它最簡單的形式是：把兩個已經測試過的單元組合成一個組件，測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合為程序的更大部分。方法是測試片段的組合，並最終擴展成進程，將模塊與其他組的模塊一起測試。最後，將構成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應該成對測試它們，而不是同時測試所有進程。

集成測試測試組合單元時出現的問題。通過使用要求在組合單元前測試每個單元並確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。一個有效的集成測試有助於解決相關的軟件與其它系統的兼容性和可操作性的問題。

集成測試是在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規格説明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。也就是説，在集成測試之前，單元測試應該已經完成，集成測試中所使用的對象應該是已經經過單元測試的軟件單元。這一點很重要，因為如果不經過單元測試，那麼集成測試的效果將會受到很大影響，並且會大幅增加軟件單元代碼糾錯的代價。

集成測試是單元測試的邏輯擴展。在現實方案中，集成是指多個單元的聚合，許多單元組合成模塊，而這些模塊又聚合成程序的更大部分，如分系統或系統。集成測試採用的方法是測試軟件單元的組合能否正常工作，以及與其他組的模塊能否集成起來工作。最後，還要測試構成系統的所有模塊組合能否正常工作。集成測試所持的主要標準是《軟件概要設計規格説明》，任何不符合該説明的程序模塊行為都應該加以記載並上報。

所有的軟件項目都不能擺脱系統集成這個階段。不管採用什麼開發模式，具體的開發工作總得從一個一個的軟件單元做起，軟件單元只有經過集成才能形成一個有機的整體。具體的集成過程可能是顯性的也可能是隱性的。只要有集成，總是會出現一些常見問題，工程實踐中，幾乎不存在軟件單元組裝過程中不出任何問題的情況。從圖1可以看出，集成測試需要花費的時間遠遠超過單元測試，直接從單元測試過渡到系統測試是極不妥當的做法。

集成測試的目標是按照設計要求使用那些通過單元測試的構件來構造程序結構。單個模塊具有高質量但不足以保證整個系統的質量。有許多隱蔽的失效是高質量模塊間發生非預期交互而產生的。以下兩種測試技術是用於集成測試：

1）功能性測試。使用黑盒測試技術針對被測模塊的接口規格説明進行測試。

2）非功能性測試。對模塊的性能或可靠性進行測試。

另外，集成測試的必要性還在於一些模塊雖然能夠單獨地工作，但並不能保證連接起來也能正常工作。程序在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現。此外，在某些開發模式中，如迭代式開發，設計和實現是迭代進行的。在這種情況下，集成測試的意義還在於它能間接地驗證概要設計是否具有可行性。

集成測試是確保各單元組合在一起後能夠按既定意圖協作運行，並確保增量的行為正確。它所測試的內容包括單元間的接口以及集成後的功能。使用黑盒測試方法測試集成的功能。並且對以前的集成進行迴歸測試。

集成測試是一種正規測試過程，必須精心計劃，並與單元測試的完成時間協調起來。在制定測試計劃時，應考慮如下因素：

1、是採用何種系統組裝方法來進行組裝測試；

2、組裝測試過程中連接各個模塊的順序；

3、模塊代碼編制和測試進度是否與組裝測試的順序一致

4、測試過程中是否需要專門的硬件設備；

解決了上述問題之後，就可以列出各個模塊的編制、測試計劃表，標明每個模塊單元測試完成的日期、首次集成測試的日期、集成測試全部完成的日期、以及需要的測試用例和所期望的測試結果。

在缺少軟件測試所需要的硬件設備時，應檢查該硬件的交付日期是否與集成測試計劃一致。例如，若測試需要數字化儀和繪圖儀，則相應測試應安排在這些設備能夠投入使用之時，並需要為硬件的安裝和交付使用保留一段時間，以留下時間餘量。此外，在測試計劃中需要考慮測試所需軟件（驅動模塊、樁模塊、測試用例生成程序等）的準備情況。

單元測試後，有必要進行集成測試，發現並排除在模塊連接中可能發生的上述問題，最終構成要求的軟件子系統或系統。對子系統，集成測試也叫部件測試。

任何合理地組織集成測試，即選擇什麼方式把模塊組裝起來形成一個可運行的系統，直接影響到模塊測試用例的形式、所用測試工具的類型、模塊編號和測試的次序、生成測試用例和調試的費用。通常，有兩種不同的組裝方式：一次性組裝方式和增值式組裝方式。

怎樣判定集成測試過程完成了，可按以下幾個方面檢查：

1、成功地執行了測試計劃中規定的所有集成測試；

2、修正了所發現的錯誤；

3、測試結果通過了專門小組的評審。

集成測試應由專門的測試小組來進行，測試小組由有經驗的系統設計人員和程序員組成。整個測試活動要在評審人員出席的情況下進行。

在完成預定的組裝測試工作之後，測試小組應負責對測試結果進行整理、分析，形成測試報告。測試報告中要記錄實際的測試結果、在測試中發現的問題、解決這些問題的方法以及解決之後再次測試的結果。此外還應提出不能解決、還需要管理人員和開發人員注意的一些問題，提供測試評審和最終決策，以提出處理意見。

根據IEEE標準 集成測試劃分為4個階段：計劃階段，設計階段，實現階段，執行階段（實施階段）

計劃階段

1）時間安排 概要設計完成評審後大約一個星期

2）輸入 需求規格説明書 概要設計文檔 產品開發計劃路標

3）入口條件 概要設計文檔已經通過評審

4）活動步驟 1.定被測試對象和測試範圍 2.評估集成測試被測試對象的數量及難度，即工作量 3.確定角色分工和作任務4.標識出測試各階段的時間，任務，約束等條件5.考慮一定的風險分析及應急計劃6.考慮和準備集成測試需要的測試工具，測試儀器，環境等資源7.考慮外部技術支援的力度和深度，以及相關培訓安排8.定義測試完成標準

5）輸出 集成測試計劃

6）出口條件 集成測試計劃通過概要設計階段基線評審

設計階段

1）時間安排詳細設計階段開始

2）輸入需求規格説明書概要設計集成測試計劃

3）入口條件概要設計基線通過評審

4）活動步驟 1.被測對象結構分析 2.集成測試模塊分析3.集成測試接口分析4.集成測試策略分析

5.集成測試工具分析6.集成測試環境分析7.集成測試工作量估計和安排。

5）輸出集成測試設計（方案）

6.出口條件集成測試設計通過詳細設計基線評審。

實現階段

1）時間安排在編碼階段開始後進行

2）輸入需求規格説明書概要設計集成測試計劃集成測試設計

3）入口條件詳細設計階段

4）活動步驟：1.集成測試用例設計2.集成測試代碼設計（如果需要）3.集成測試腳本（如果需要）4.集成測試工具（如果需要）

5）輸出集成測試用例集成測試規程集成測試代碼集成測試腳本集成測試工具

6）出口條件測試用例和測試規程通過編碼階段基線評審

執行階段

1）時間安排單元測試已經完成後就可以開始執行集成測試了

2）輸入 需求規格説明書概要設計集成測試計劃集成高度設計集成測試例集成測試規程集成測試代碼（如果有）集成測試腳本集成測試工具詳細設計代碼單元測試報告

3）入口條件單元測試階段已經通過基線化評審

4）活動步驟執行集成測試用例迴歸集成測試用例撰寫集成測試報告

5）輸出集成測試報告

6）出口條件集成測試報告通過集成測試階段基線評審

集成測試需求所確定的是對某一集成工作版本的測試的內容，即測試的具體對象。集成測試需求主要來源於設計模型（Design Model）和集成構件計劃（Integration Build Plan）。集成測試着重於集成版本的外部接口的行為。因此，測試需求須具有可觀測、可測評性。

1． 集成工作版本應分析其類協作與消息序列，從而找出該工作版本的外部接口。

2． 由集成工作版本的外部接口確定集成測試用例。

3． 測試用例應覆蓋工作版本每一外部接口的所有消息流序列。

注意：一個外部接口和測試用例的關係是多對多，部分集成工作版本的測試需求可映射到系統測試需求，因此對這些集成測試用例可採用重用系統測試用例技術。

1、 軟件集成測試計劃

2、 集成測試用例

3、 測試過程

4、 測試腳本

5、 測試日誌

6、 測試評估摘要

集成測試的實施方案有很多種，如自底向上集成測試、自頂向下集成測試、Big-Bang集成測試、三明治集成測試、核心集成測試、分層集成測試、基於使用的集成測試等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高頻集成測試一般採用如下步驟來完成：

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

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

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

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

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

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

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

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

1.1編寫目的

本文是描述****集成測試的大綱文章，主要描述如何進行集成測試活動？如何控制集成測試活動？集成測試活動的流程以及集成測試活動的工作安排。本文主要的讀者對象是項目負責人，集成部門經理，集成測試設計師。

1.2背景

項目名稱：***集成測試

項目相關對象：******************

1.3定義

**********：********************

1.4參考資料

《*********》

本測試主要為***系統的集成測試，***的版本為2.0,測試是***的最終集成測試，是建立在開發組程序員開發完畢自己的測試以及開發組測試的基礎之上

3.1操作性測試

主要測試操作是否正確，有無誤差？分為兩部分：

3.1.1返回測試

由主界面逐級進入最終界面，按EXIT鍵逐級返回，檢查返回時候屏幕聚焦是否正確

比如：

1. 進入“系統設置”

2. 進入“頻道搜索”

3. 進入“自動頻道搜索”

4. 按EXIT鍵返回，檢查當前聚焦是否為“頻道搜索”

5. 按EXIT鍵返回，檢查當前聚焦是否為“系統設置”

3.1.2進入測試

由主界面逐級進入最終界面，按MENU鍵返回主界面，再次進入，檢查是否聚焦正確

比如：

1. 進入“系統設置”

2. 進入“頻道搜索”

3. 進入“自動頻道搜索”

4. 按MENU鍵返回主界面

5. 當前聚焦是否為“系統設置”

6. 進入“系統設置”，當前聚焦是否為“頻道搜索”

3.2功能測試

測試機頂盒中每個應用的功能是否正確

3.3性能測試

3.3.1疲勞性測試

測試連續開機1個月不關機器，每3天去運行一次應用。看系統的穩定性

3.3.2大容量數據測試

前段***數據庫表中含有大量數據，測試***功能

1. 書寫測試計劃

2. 審核測試計劃，未通過返回第一步

3. 書寫測試用例；

4. 審核測試用例，未通過返回第三步

5. 測試人員按照測試用例逐項進行測試活動，並且將測試結果填寫在測試報告上；（測試報告必須覆蓋所有測試用例）

6. 測試過程中發現bug，將bug填寫在bugzilla上發給集成部經理；（bug狀態NEW）

7. 集成部經理接到bugzilla發過來的bug

7.1 對於明顯的並且可以立刻解決的bug，將bug發給開發人員；（bug狀態ASSIGNED）；

7.2 對於不是bug的提交，集成部經理通知測試設計人員和測試人員，對相應文檔進行修改； （bug狀態RESOLVED，決定設置為INVALID）；

7.3 對於無法修改的，將這個bug放到下一輪次進行修改；（bug狀態RESOLVED，決定設置為REMIND）

8. 開發人員接到發過來的bug立刻修改；（bug狀態RESOLVED，決定設置為FIXED）

9. 測試人員接到bugzilla發過來的錯誤更改信息，應該逐項複測，填寫新的測試報告（測試報告必須覆蓋上一次中所有REOPENED的測試用例）；

10. 如果複測有問題返回第六步（bug狀態REOPENED）

11. 否則關閉這項BUG（bug狀態CLOSED）

12. 本輪測試中測試用例中有95%一次性通過測試，結束測試任務；

13. 本輪測試中發現的錯誤有98%經過修改並且通過再次測試（即bug狀態CLOSED），返回第五步進行新的一輪測試；

14. 測試任務結束後書寫測試總結報告；

15. 正規測試結束進入非正規測試，首先是ALPHA測試，請公司裏其他非技術人員以用户角色使用系統。發現bug通知測試人員，測試人員以正規流程處理bug事件；

16. 然後是BETA測試，請用户代表進行測試。發現bug通知測試人員，測試人員以正規流程處理bug事件。

幾點説明：

O 測試迴歸計劃為三次；

O 測試用例應該寫得比較詳盡，步驟一定要標明清楚（應該包括：編號，測試描述，前置條件，測試步驟以及測試希望結果）；

O 對於測試人員覺得應該進行的測試項目，測試人員應該報告測試設計人員，完善和健全測試用例；

O 測試報告與測試用例分開，測試報告標明測試用例序號以及是否通過Y/N；

O 對於集成部經理無法決定的上交項目負責人決定；

O 性能測試中的疲勞性測試可以結合在功能測試部分，即測試期間不關閉機器；

O 性能測試中的大容量數據測試放在測試後部分輪次（第二步，只需要進行一次）

測試結果與測試用例中期望的結果一致，測試通過，否則標明測試未通過。

6.1測試結果審批過程

6.1.1測試迴歸申請結束

測試人員提出申請這輪測試結束，提交集成部經理；

集成部經理召集本組人員開會討論；

討論通過，進行下一輪測試，並且部署下一輪測試的注意事項，流程等內容；

如果發現這輪測試還存在問題沒有解決，延期下一輪測試時間，討論下一步工作應該如何進行。

6.1.2測試結果申請結束

測試人員提出申請測試結束，提交集成部經理；

集成部經理召集本組人員開會討論；

1. 討論通過，結束測試任務；

2. 如果發現測試還存在問題沒有解決，延期測試結束時間，並且討論下一步工作應該如何進行。

7.1掛起條件

O 進入第一輪測試，測試人員大體瞭解一下產品情況，如果在一小時之內發現5個以上（含5個）操作性錯誤，或者3個以上（含3個）功能性錯誤，退回測試組測試；

O 遇到有項目優先級更高的集成測試任務；

O 遇到有項目優先級更高的集成任務；

O 在測試複測過程中發現產品無法運行下去；

O 人員，設備不足。

7.2恢復條件

O 符合進入集成測試條件（一小時之內發現5個以下（不含5個）操作性錯誤，或者3個以下（不含3個）功能性錯誤）；

O 項目優先級更高的集成測試任務暫告完成；

O 項目優先級更高的集成任務暫告完成；

O 複測過程中產品可以運行下去；

O 人員，設備到位。

O 測試計劃書

O 測試用例

O 測試報告

O 測試總結

O 制定審核測試計劃

O 制定和審核測試用例

O 進行測試活動

O 書寫測試報告

10.1硬件需求

***********

10.2軟件需求

************

10.3測試工具

*************

10.4測試需要的條件

**************

10.4.1 需要的文檔

O 用户手冊

O 應用手冊

O 安裝説明

10.4.2需要完成的任務

O 程序員本人測試

O 測試組完成測試

O 集成（測試）經理：控制並完成測試任務和測試過程，決定測試人員提交上來的bug是否需要修改；

O 測試設計人員：書寫集成測試用例；

O 測試人員：按照測試用例進行測試活動；

O 開發人員：MHP程序bug修改；

O 用户代表：進行BETA測試。

O 集成測試經理有責任對測試相關人員進行測試流程，規章制度培訓；

O 測試設計人員有責任對測試人員進行測試操作培訓

測試工作 進度（人*工作日）

測試計劃 8

測試設計 60

測試執行總共進度 30

每次迴歸進度 10

測試報告 2

設備不到位：加緊設備購買；

人員不到位

人員請假：請假人員回來加班或趕緊測試進度/申請調配新的人員；

人員離職：調配新的人員；

人員調配到其他部門或項目：調配新的人員；

開發人員開發頻頻出錯：通知開發部門，商量策略；

其他原因的測試工作頻頻被掛起或者掛起後遲遲恢復不了：加班或延期

集成部經理 技術部經理

姓名：姓名：

日期：日期：

單元測試是針對軟件的基本單元（如：函數）所做的測試，而集成測試則是以模塊和子系統為單元進行的測試，主要測試接口間的關係。

單元測試是針對軟件的詳細設計做的測試，測試用例的主要依據也是詳細設計。而集成測試是針對軟件的概括設計做的測試，測試用例的主要依據則是概括設計。

集成測試主要測試的是接口層的測試空間，單元測試主要測試的是內部實現層的測試空間。

集成測試關注的是接口的集成，和單元測試只關注單個單元，因此在具體測試方法上也不同。 ^[1]