集成測試
出自 MBA智库百科(https://wiki.mbalib.com/)
目錄 |
集成測試是指在單元測試的基礎上，將所有模塊按照設計要求組裝成為子系統或系統，進行測試。
集成測試最簡單的形式是：把兩個已經測試過的單元組合成一個組件，測試它們之間的介面。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合為程式的更大部分。方法是測試片段的組合，並最終擴展成進程，將模塊與其他組的模塊一起測試。最後，將構成進程的所有模塊一起測試。此外，如果程式由多個進程組成，應該成對測試它們，而不是同時測試所有進程。
集成測試測試組合單元時出現的問題。通過使用要求在組合單元前測試每個單元並確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的介面有關。這種方法將可能發生的情況數量減少到更簡單的分析級別。一個有效的集成測試有助於解決相關的軟體與其它系統的兼容性和可操作性的問題。
集成測試是在單元測試的基礎上，測試在將所有的軟體單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。也就是說，在集成測試之前，單元測試應該已經完成，集成測試中所使用的對象應該是已經經過單元測試的軟體單元。這一點很重要，因為如果不經過單元測試，那麼集成測試的效果將會受到很大影響，並且會大幅增加軟體單元代碼糾錯的代價。
集成測試是單元測試的邏輯擴展。在現實方案中，集成是指多個單元的聚合，許多單元組合成模塊，而這些模塊又聚合成程式的更大部分，如分系統或系統。集成測試採用的方法是測試軟體單元的組合能否正常工作，以及與其他組的模塊能否集成起來工作。最後，還要測試構成系統的所有模塊組合能否正常工作。集成測試所持的主要標準是《軟體概要設計規格說明》，任何不符合該說明的程式模塊行為都應該加以記載並上報。
所有的軟體項目都不能擺脫系統集成這個階段。不管採用什麼開發模式，具體的開發工作總得從一個一個的軟體單元做起，軟體單元只有經過集成才能形成一個有機的整體。具體的集成過程可能是顯性的也可能是隱性的。只要有集成，總是會出現一些常見問題，工程實踐中，幾乎不存在軟體單元組裝過程中不出任何問題的情況。從表中可以看出，集成測試需要花費的時間遠遠超過單元測試，直接從單元測試過渡到系統測試是極不妥當的做法。
活動 輸入 輸出 參與角色和職責 制定集成測試計劃 設計模型
設計模型集成測試用例
測試過程測試設計員負責設計集成測試用例和測試過程 實施集成測試 集成測試用例
測試過程
工作版本測試腳本（可選）
測試過程（更新）測試設計員負責編製測試腳本（可選），更新測試過程。 驅動程式或穩定樁 設計員負責設計驅動程式和裝，實施員負責實施驅動程式和樁 執行集成測試 測試腳本（可選）
工作版本測試結果 測試員負責執行測試並記錄測試結果 評估集成測試 集成測試計劃
測試結果測試評估摘要 測試員負責會同及成員、編碼員、設計員等有關人員（具體化）評估此次測試，並生成測試評估摘要。
集成測試的目標是按照設計要求使用那些通過單元測試的構件來構造程式結構。單個模塊具有高質量但不足以保證整個系統的質量。有許多隱蔽的失效是高質量模塊間發生非預期交互而產生的。以下兩種測試技術是用於集成測試：
1、功能性測試。使用黑盒測試技術針對被測模塊的介面規格說明進行測試。
2、非功能性測試。對模塊的性能或可靠性進行測試。
另外，集成測試的必要性還在於一些模塊雖然能夠單獨地工作，但並不能保證連接起來也能正常工作。程式在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現。此外，在某些開發模式中，如迭代式開發，設計和實現是迭代進行的。在這種情況下，集成測試的意義還在於它能間接地驗證概要設計是否具有可行性。
1、在把各個模塊連接起來的時候，穿越模塊介面的數據是否會丟失；
2、各個子功能組合起來，能否達到預期要求的父功能；
3、一個模塊的功能是否會對另一個模塊的功能產生不利的影響；
4、全局數據結構是否有問題；
5、是採用何種系統組裝方法來進行組裝測試；
6、組裝測試過程中連接各個模塊的順序；
7、模塊代碼編製和測試進度是否與組裝測試的順序一致；
8、測試過程中是否需要專門的硬體設備；
9、單個模塊的誤差積累起來，是否會放大，從而達到不可接受的程度。
因此，單元測試後，有必要進行集成測試，發現併排除在模塊連接中可能發生的上述問題，最終構成要求的軟體子系統或系統。對子系統，集成測試也叫部件測試。
任何合理地組織集成測試，即選擇什麼方式把模塊組裝起來形成一個可運行的系統，直接影響到模塊測試用例的形式、所用測試工具的類型、模塊編號和測試的次序、生成測試用例和調試的費用。通常，有兩種不同的組裝方式：一次性組裝方式和增值式組裝方式。
根據IEEE標準 集成測試劃分為4個階段：計劃階段，設計階段，實現階段，執行階段（實施階段）
1、時間安排 概要設計完成評審後大約一個星期；
2、輸入 需求規格說明書 概要設計文檔 產品開發計劃路標；
3、入口條件 概要設計文檔已經通過評審；
4、活動步驟：
（1）定被測試對象和測試範圍；
（2）評估集成測試被測試對象的數量及難度，即工作量；
（3）確定角色分工和作任務；
（4）標識出測試各階段的時間，任務，約束等條件；
（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、出口條件集成測試報告通過集成測試階段基線評審。
集成測試的實施方案有很多種，如自底向上集成測試、自頂向下集成測試、Big-Bang集成測試、三明治集成測試、核心集成測試、分層集成測試、基於使用的集成測試等。常見的有：
自頂向下集成（Top-Down Integration）方式是一個遞增的組裝軟體結構的方法。從主控模塊（主程式）開始沿控制層向下移動，把模塊一一組合起來。分兩種方法：
第一：先深度：按照結構，用一條主控制路徑將所有模塊組合起來；
第二：先寬度：逐層組合所有下屬模塊，在每一層水平地沿著移動。
組裝過程分以下五個步驟：
步驟一：用主控模塊作為測試驅動程式，其直接下屬模塊用承接模塊來代替；
步驟二：根據所選擇的集成測試法（先深度或先寬度），每次用實際模塊代替下屬的承接模塊
步驟三：在組合每個實際模塊時都要進行測試；
步驟四：完成一組測試後再用一個實際模塊代替另一個承接模塊；
步驟五：可以進行回歸測試（即重新再做所有的或者部分已做過的測試），以保證不引入新的錯誤。
自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地繼承、吸收了這種集成方式的思想。自底向上集成方式從程式模塊結構中最底層的模塊開始組裝和測試。因為模塊是自底向上進行組裝的，對於一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）事前已經完成組裝並經過測試，所以不再需要編製樁模塊（一種能模擬真實模塊，給待測模塊提供調用介面或數據的測試用軟體模塊）。自底向上集成測試的步驟大致如下：
步驟一： 按照概要設計規格說明，明確有哪些被測模塊。在熟悉被測模塊性質的基礎上對被測模塊進行分層，在同一層次上的測試可以並行進行，然後排出測試活動的先後關係，制定測試進度計劃。圖2給出了自底向上的集成測試過程中各測試活動的拓撲關係。利用圖論的相關知識，可以排出各活動之間的時間序列關係，處於同一層次的測試活動可以同時進行，而不會相互影響。
步驟二： 在步驟一的基礎上，按時間線序關係，將軟體單元集成為模塊，並測試在集成過程中出現的問題。這裡，可能需要測試人員開發一些驅動模塊來驅動集成活動中形成的被測模塊。對於比較大的模塊，可以先將其中的某幾個軟體單元集成為子模塊，然後再集成為一個較大的模塊。
步驟三： 將各軟體模塊集成為子系統（或分系統）。檢測各自子系統是否能正常工作。同樣，可能需要測試人員開發少量的驅動模塊來驅動被測子系統。
步驟四： 將各子系統集成為最終用戶系統，測試是否存在各分系統能否在最終用戶系統中正常工作。
方案點評： 自底向上的集成測試方案是工程實踐中最常用的測試方法。相關技術也較為成熟。它的優點很明顯： 管理方便、測試人員能較好地鎖定軟體故障所在位置。但它對於某些開發模式不適用，如使用XP開發方法，它會要求測試人員在全部軟體單元實現之前完成核心軟體部件的集成測試。儘管如此，自底向上的集成測試方法仍不失為一個可供參考的集成測試方案。
核心系統先行集成測試法的思想是先對核心軟體部件進行集成測試，在測試通過的基礎上再按各外圍軟體部件的重要程度逐個集成到核心系統中。每次加入一個外圍軟體部件都產生一個產品基線，直至最後形成穩定的軟體產品。核心系統先行集成測試法對應的集成過程是一個逐漸趨於閉合的螺旋形曲線，代表產品逐步定型的過程。其步驟如下：
步驟一： 對核心系統中的每個模塊進行單獨的、充分的測試，必要時使用驅動模塊和樁模塊；
步驟二： 對於核心系統中的所有模塊一次性集合到被測系統中，解決集成中出現的各類問題。在核心系統規模相對較大的情況下，也可以按照自底向上的步驟，集成核心系統的各組成模塊。
步驟三： 按照各外圍軟體部件的重要程度以及模塊間的相互制約關係，擬定外圍軟體部件集成到核心系統中的順序方案。方案經評審以後，即可進行外圍軟體部件的集成。
步驟四： 在外圍軟體部件添加到核心系統以前，外圍軟體部件應先完成內部的模塊級集成測試。
步驟五： 按順序不斷加入外圍軟體部件，排除外圍軟體部件集成中出現的問題，形成最終的用戶系統。
方案點評： 該集成測試方法對於快速軟體開發很有效果，適合較複雜系統的集成測試，能保證一些重要的功能和服務的實現。缺點是採用此法的系統一般應能明確區分核心軟體部件和外圍軟體部件，核心軟體部件應具有較高的耦合度，外圍軟體部件內部也應具有較高的耦合度，但各外圍軟體部件之間應具有較低的耦合度。
高頻集成測試是指同步於軟體開發過程，每隔一段時間對開發團隊的現有代碼進行一次集成測試。如某些自動化集成測試工具能實現每日深夜對開發團隊的現有代碼進行一次集成測試，然後將測試結果發到各開發人員的電子郵箱中。該集成測試方法頻繁地將新代碼加入到一個已經穩定的基線中，以免集成故障難以發現，同時控制可能出現的基線偏差。使用高頻集成測試需要具備一定的條件： 可以持續獲得一個穩定的增量，並且該增量內部已被驗證沒有問題； 大部分有意義的功能增加可以在一個相對穩定的時間間隔（如每個工作日）內獲得； 測試包和代碼的開發工作必須是並行進行的，並且需要版本控制工具來保證始終維護的是測試腳本和代碼的最新版本； 必須藉助於使用自動化工具來完成。高頻集成一個顯著的特點就是集成次數頻繁，顯然，人工的方法是不勝任的。
高頻集成測試一般採用如下步驟來完成：
步驟一： 選擇集成測試自動化工具。如很多Java項目採用Junit+Ant方案來實現集成測試的自動化，也有一些商業集成測試工具可供選擇。
步驟二： 設置版本控制工具，以確保集成測試自動化工具所獲得的版本是最新版本。如使用CVS進行版本控制。
步驟三： 測試人員和開發人員負責編寫對應程式代碼的測試腳本。
步驟四： 設置自動化集成測試工具，每隔一段時間對配置管理庫的新添加的代碼進行自動化的集成測試，並將測試報告彙報給開發人員和測試人員。
步驟五： 測試人員監督代碼開發人員及時關閉不合格項。
按照步驟三至步驟五不斷迴圈，直至形成最終軟體產品。
方案點評： 該測試方案能在開發過程中及時發現代碼錯誤，能直觀地看到開發團隊的有效工程進度。在此方案中，開發維護源代碼與開發維護軟體測試包被賦予了同等的重要性，這對有效防止錯誤、及時糾正錯誤都很有幫助。該方案的缺點在於測試包有時候可能不能暴露深層次的編碼錯誤和圖形界面錯誤。
