Hello！大家好，我是BugBear，一個專注于分享軟件測試干貨的測試開發(fā)。上一篇文章我們講了 單元測試 相關知識，今天我們來聊聊集成測試的相關內容。

一、什么是集成測試？

我們通過工廠組裝手機的例子明白了單元測試，每個電子元件或者零部件就是一個單元測試，那么將這些電子元件或者零部件組裝起來形成一個功能模塊組件，例如喇叭，聽筒，麥克，FPC，按鍵板，攝像頭，LCD等。針對這些功能模塊組件進行測試，就類比于我們所知的集成測試。

集成測試的定義如下：

集成測試也叫組裝測試、聯(lián)合測試、子系統(tǒng)測試或部件測試。集成測試是在單元測試的基礎上，將所有模塊按照概要設計要求組裝成為子系統(tǒng)或系統(tǒng)。

集成測試的含義非常簡單，就是將單元測試模塊逐個集成/組合，并將行為測試為組合單元。該測試的主要功能或目標是測試單元/模塊之間的接口。我們通常在單元測試之后進行集成測試。一旦創(chuàng)建并測試了所有單個單元，我們就開始組合這些“單元測試”模塊并開始進行集成測試。首先單獨測試各個模塊。模塊經過單元測試后，逐個集成，直到所有模塊都集成在一起，檢查組合行為，驗證需求是否正確實現。在這里我們應該理解，集成測試不會在周期結束時發(fā)生，而是與開發(fā)同時進行，基于開發(fā)實現不斷在原來的基礎上逐步融入新的子模塊進行集成測試。

二、為什么要做集成測試？

• 各單元實現邏輯不同：在現實世界中，當開發(fā)應用程序時，它被分解為更小的模塊，并且為每個開發(fā)人員分配1個模塊。每個開發(fā)人員實現的邏輯完全不同，因此檢查開發(fā)人員實現的邏輯是否符合預期并根據規(guī)定的標準呈現正確的值變得很重要。

• 數據流轉校驗：很多時候，當數據從一個模塊移動到另一個模塊時，數據的面或結構會發(fā)生變化。附加或刪除某些值，這會導致后續(xù)模塊出現問題。

• 數據交互校驗：模塊還與某些第三方工具或API進行交互，這些工具或API也需要進行測試，以確保該API /工具接受的數據是正確的，并且生成的響應也是預期的。

• 單元頻繁變更：需求頻繁變更導致單元代碼迭代更新，但是多數時候開發(fā)人員在沒有單元測試的情況下部署更改，此時集成測試就非常重要。
  我們知道集成測試的重要性，那么集成測試會給我們帶來什么好處呢？

• 此測試可確保集成模塊/組件正常工作。

• 一旦要測試的模塊可用，就可以開始集成測試。它不需要完成其他模塊以進行測試，因為Stubs和Drivers可以用于相同的操作。

• 它檢測與接口相關的錯誤。

三、集成測試層次

集成測試層次如下：

• 模塊內集成測試：軟件模塊1、軟件模塊2、軟件模塊3、軟件模塊4、軟件模塊5
• 子系統(tǒng)內集成測試：軟件模塊1+軟件模塊2、軟件模塊3+軟件模塊4+軟件模塊5
• 子系統(tǒng)間集成測試：子系統(tǒng)1+子系統(tǒng)2

四、集成測試類型

1、大爆炸集成類型

- 優(yōu)點：

• 對于小型系統(tǒng)來說可以迅速完成集成測試，井且只要極少數的驅動和樁模塊設計。它需要的測試用例也是最少的;
• 該方法比較簡單;
• 多個測試人員可以并行工作，對人力，物力資源利用率較高

- 缺點：
大爆炸集成類型是一個耗時的過程，找到一個自身有缺陷的模塊會耗費大量時間與精力，因為他是一次性集成了所有模塊，我們無法明確知道具體是哪個模塊出了問題，必須要進行逐一排查來定位問題模塊。修復完畢問題模塊后若繼續(xù)出現問題，我們沒法判斷是由于修復代碼時造成了其他缺陷還是其他模塊本身存在的缺陷導致，為了定位問題又需要花費時間排查。

- 適用范圍：

• 一個維護型項目（或功能增強型項目），其以前的產品已經很穩(wěn)定；
• 被測系統(tǒng)比較小，并且它的每個函數都經過了充分的單元測試；
• 新增的項目只有少數幾個組件被增加或修改，一旦集成測試出現問題，能夠快速排查問題所在；

2、自上而下集成策略類型

自上而下集成策略分為 深度優(yōu)先集成 與 廣度優(yōu)先集成 兩種策略。我們先來看看深度優(yōu)先集成策略。

- 深度優(yōu)先集成策略

- 廣度優(yōu)先集成策略

- 自上而下集成策略優(yōu)點：

• 自頂向下的集成方式在測試過程中較早地驗證了主要的控制和判斷點；如果選用按深度方向組裝的方式，可以首先實現和驗證個完整的軟件功能；
• 功能可行性較早得到證實，還能夠給開發(fā)者和用戶帶來成功的信心；
• 最多只需一個驅動（Driver程序），減少了驅動器開發(fā)的費用；
• 支持故障隔離。

- 自上而下集成策略缺點：

• 樁（Stub）的開發(fā)和維護是本策略的最大成本；
• 底層組件行為的驗證被推遲了;
• 隨著底層組件的不斷增加，整個系統(tǒng)越來越復雜，導致底層組件的測試不充分，尤其是那些被重用的組件。

- 自上而下集成策略適用范圍：

• 產品控制結構比較清晰和穩(wěn)定;
• 產品的高層接口變化比較小;
• 產品的底層接口未定義或經?？赡鼙恍薷?
• 產品的控制組件具有較大的技術風險，需要盡早被驗證;

3、自下而上集成策略類型

自下而上集成策略是先對程序結構最底層的代碼進行集成與測試，然后不斷融入上級模塊或代碼再次進行擴展測試。
組件是自底向上進行組裝，對于一個給定層次的組件，它的子組件(包括子組件的所有下屬組件)已經組裝并測試完成，所以不再需要樁程序。

通過上圖可以看到，從程序結構最底層從下往上進行組裝與測試，先測試E，然后E+B，以此類推。其他分支按照同樣的方式進行組裝測試，最后將所有分支與上級模塊A組裝進行測試。

- 自下而上集成策略優(yōu)點：

• 允許對底層組件行為的早期驗證?？梢栽谌魏我粋€葉子節(jié)點已經就緒的情況下進行集成測試;
• 在工作的最初可能會并行進行集成，在這一點上比使用自頂向下的策略效率高;
• 減少了樁的工作量，畢竟在集成測試中，樁的工作量遠比驅動的工作量要大得多。但是為了模擬一些中斷或異常，可能還是需要設計樁程序;
• 該方法也支持故障隔離。

- 自下而上集成策略缺點：

• 驅動的開發(fā)工作量也是很龐大的，每次組裝后都需要設定一個驅動程序來模擬上層模塊程序;
• 對高層的驗證被推遲到了最后，設計上的錯誤不能被及時發(fā)現，尤其對于那些控制結構在整個體系中非常關鍵的產品。

- 自下而上集成策略適用范圍：

• 底層接口比較穩(wěn)定、變動較少的產品;
• 高層接口變化比較頻繁的產品;
• 底層組件較早被完成的產品。

4、三明治集成策略類型

通過上面的學習我們不難發(fā)現，自上而下集成策略與自下而上集成策略都有各自的優(yōu)點與缺點，那么我們能不能發(fā)展兩者所長，避其兩者所短呢？答案是當然的，這就出現了三明治集成策略！

• 三明治集成就是這樣一種方法， 它把系統(tǒng)劃分成三層，中間一層為目標層。
• 測試的時候，對目標層上面的一層使用自上而下的集成策略，對目標層下面的一層使用自下而上的集成策略，最后測試在目標層會合。

- 優(yōu)點：集合了自下而上集成策略和自上而下集成策略，發(fā)展兩者所長，避其兩者所短
- 缺點：中間層在被集成前測試不充分
- 適用范圍：大部分軟件開發(fā)項目都可以使用這種集成策略

文末結語

BugBear軟件測試，專注于分享測試干貨，歡迎關注，交流成長