?? 視頻學(xué)習(xí)：文末有免費的配套視頻可觀看

???關(guān)注公眾號【互聯(lián)網(wǎng)雜貨鋪】，回復(fù) 1?，免費獲取軟件測試全套資料，資料在手，漲薪更快

一、單元測試的概念

單元測試是對軟件基本組成單元進(jìn)行的測試，如函數(shù)或一個類的方法。當(dāng)然這里的基本單元不僅僅指的是一個函數(shù)或者方法，有可能對應(yīng)多個程序文件中的一組函數(shù)。

單元也具有一些基本的屬性。比如：明確的功能、規(guī)格定義，明確的與其他部分的接口定義等，可清晰地與同一程序的其他單元化分開來。

二、單元測試的目的

單元測試的目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種錯誤，主要是基于白盒測試。（也就是說，在單元測試過程中，用的最多的是白盒測試方法，也可能會有灰盒或者黑盒。單元測試和白盒測試是不同的劃分，不存在包含關(guān)系）。

在單元測試階段對應(yīng)的文檔是詳細(xì)設(shè)計文檔（LLD）；對應(yīng)的代碼就是單元代碼，因此單元測試的目的主要有3點：

1、驗證代碼是與設(shè)計相符合的；

2、發(fā)現(xiàn)設(shè)計和需求中存在的錯誤；

3、發(fā)現(xiàn)在編碼過程中引入的錯誤。

三、單元的常見錯誤

單元的常見錯誤一般出現(xiàn)在以下五個方面，因此這五個方面是單元測試應(yīng)該關(guān)注的重點。

1、單元接口。

2、局部數(shù)據(jù)結(jié)構(gòu)。

3、獨立路徑。

4、出錯處理。

5、邊界條件。

四、如何進(jìn)行單元測試

在單元測試時，由于單元本身不是一個獨立的程序，一個完整的可運行的軟件系統(tǒng)并沒有構(gòu)成，所以需要設(shè)置一些輔助測試單元，輔助測試單元有兩種，一種是驅(qū)動單元，另外一種是樁單元。

1、驅(qū)動單元：用來模擬被測單元的上層單元，相當(dāng)于被測函數(shù)的主函數(shù)，如main函數(shù)。所以驅(qū)動單元主要完成以下4個步驟：

（1）接受測試數(shù)據(jù)，包含測試用例輸入和預(yù)期輸出；

（2）把測試用例輸入傳送給被測單元，驅(qū)動被測單元測試；

（3）將被測單元的實際輸出和預(yù)期輸出進(jìn)行比較，得到測試結(jié)果；

（4）將測試結(jié)果輸出到指定位置。

2、樁單元：用來代替被測單元工作過程中調(diào)用的子單元。

樁單元模擬的單元可能是自定義函數(shù)：這些自定義函數(shù)可能尚未編寫完成，為了測試被測單元，需要構(gòu)造樁單元來代替它們，可能存在錯誤，會影響測試結(jié)果，所以需要構(gòu)造正確無誤的樁單元來達(dá)到隔離的目的。

驅(qū)動單元和樁單元都是額外的開銷，雖然在單元測試的時候必須寫，但是并不需要作為最終的產(chǎn)品提供給客戶。

五、單元測試策略

一般的單元執(zhí)行策略有三種：孤立的單元測試策略，自頂向下的單元測試策略和自底向上的單元測試策略。需要注意的是：在集成測試中也有自頂向下和自底向上的測試策略，但是測試對象不同。

1、孤立的單元測試策略

• 方法：不考慮每個模塊與其它模塊之間的關(guān)系，為每個模塊設(shè)計樁模塊和驅(qū)動模塊，每個模塊進(jìn)行獨立的單元測試。
• 優(yōu)點：這個方法比較簡單，最容易操作，可以達(dá)到很高的結(jié)構(gòu)覆蓋率，可以并行開展，該方法是純粹的單元測試。
• 缺點：樁函數(shù)和驅(qū)動函數(shù)工作量很大，效率低。

2、自頂向下的單元測試策略

• 方法：先對最頂層的單元進(jìn)行測試，把頂層所調(diào)用的單元做成樁模塊，其次對第二層進(jìn)行測試，使用上面已經(jīng)測試過的單元做驅(qū)動模塊，以此類推，直到測試完所有模塊。
• 優(yōu)點：可以節(jié)省驅(qū)動函數(shù)的開發(fā)工作，效率高。
• 缺點：隨著被測單元一個一個被加入，測試過程將變得越來越復(fù)雜，并且開發(fā)和維護(hù)的成本將增加。

3、自底向上的單元測試策略

• 方法：先對最底層的模塊進(jìn)行單元測試，將模擬調(diào)用該模塊的模塊設(shè)置為驅(qū)動模塊，然后再對上面一層做單元測試，用下面已經(jīng)測試好的模塊做樁模塊，以此類推，直到測試完所有模塊。
• 優(yōu)點：可以節(jié)省樁函數(shù)的開發(fā)工作量，測試效率較高。
• 缺點：不是純粹的單元測試，底層函數(shù)的測試質(zhì)量對上層函數(shù)的測試將產(chǎn)生很大影響。

六、系統(tǒng)測試的概念

系統(tǒng)測試的定義：將已經(jīng)集成好的軟件系統(tǒng)，作為整個基于計算機(jī)系統(tǒng)的一個元素，與計算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實際運行（使用）的環(huán)境下，對計算機(jī)系統(tǒng)進(jìn)行一系列的組裝測試和確認(rèn)測試。

系統(tǒng)測試的對象：軟硬件集合在一起的系統(tǒng)，集成后的產(chǎn)品，不應(yīng)是獨立的軟件與硬件環(huán)境。不僅僅包括需測試的軟件，還要包含軟件所依賴的硬件、外設(shè)，甚至包括某些數(shù)據(jù)、某些支持軟件的系統(tǒng)等。

目的：通過與系統(tǒng)的需求定義做比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或與之矛盾的地方，以驗證軟件的功能和性能等滿足其規(guī)約所指定的要求。

常見的系統(tǒng)分類：

• 純軟件：QQ.................
• 軟件和硬件：手機(jī)，PSP，空調(diào)，電梯
• 軟件硬件和維護(hù)人員：大型系統(tǒng)

七、系統(tǒng)測試的環(huán)境

真實環(huán)境：直接將整個系統(tǒng)和其交聯(lián)的物理設(shè)備真實的建立鏈接，進(jìn)行測試

優(yōu)點：可以發(fā)現(xiàn)某些只能在真實環(huán)境下出現(xiàn)的問題

缺點：構(gòu)建這樣一個環(huán)境需要高昂的費用，它的測試運行也需要高昂的費用

仿真環(huán)境：它能夠逼真的模擬被測試軟件運行所需的真實物理環(huán)境的輸入與輸出，并且能夠組織被測軟件的輸入，來驅(qū)動被測軟件運行，同時接收被測軟件的輸出結(jié)果。

優(yōu)點：仿真環(huán)境和真實環(huán)境的軟件依賴是一樣的，并且它能夠保證測試的可重復(fù)性、完整性、可擴(kuò)展性

Example 1：某系統(tǒng)環(huán)境搭建的要求

硬件環(huán)境：

CPU：主頻2GHZ以上，4核及以上

內(nèi)存：4GB及以上

硬盤：可用空間10G以上

軟件環(huán)境：

平臺要求：Windows XP/2003標(biāo)準(zhǔn)版+Apache2.2.X+Mysql5.0及以上版本

目錄權(quán)限：目錄/Attachment，/Cache及文件需要寫的權(quán)限

推薦平臺：推薦使用XAMPP作為安裝介質(zhì)

選用測試工具應(yīng)考慮的因素：

1.測試工具與被測軟件系統(tǒng)的匹配程度

2.測試工具提供的主要功能和輔助機(jī)制

3.測試工具的服務(wù)和技術(shù)支持

4.測試工具的價格

測試數(shù)據(jù)：

特點：

1.數(shù)據(jù)可以以消息、事物、記錄、文件等形式存在

2.數(shù)據(jù)來源很多

3.真實數(shù)據(jù)最好，但在很多情況下不易或者不能得到

來源：

1.產(chǎn)品數(shù)據(jù)

2.手工構(gòu)造數(shù)據(jù)

3.生成數(shù)據(jù)（一般由工具設(shè)備構(gòu)造）

4.捕獲數(shù)據(jù)（少用，與捕獲數(shù)據(jù)源有關(guān)，允許手工修改）

5.隨機(jī)數(shù)據(jù)（系統(tǒng)測試少用，它易于獲得，不夠真實，性能測試常用）

產(chǎn)品數(shù)據(jù)

1.最具真實性

2.不能覆蓋所需所有場景

3.數(shù)據(jù)敏感，很難保證正確性

4.隨時間變化

5.可能數(shù)據(jù)量太大（從而降低測試執(zhí)行速度）

手工構(gòu)造數(shù)據(jù)

1.費時間、枯燥

2.如果對系統(tǒng)的功能缺乏了解，數(shù)據(jù)不真實

3.有時是獲得特定測試用例所需獨特數(shù)據(jù)的唯一手段

生成數(shù)據(jù)

1.一般由工具或設(shè)備構(gòu)造

2.數(shù)據(jù)取決于工具的完善程度和測試人員的關(guān)于如何構(gòu)造數(shù)據(jù)的規(guī)格說明

捕獲數(shù)據(jù)

1.與捕獲數(shù)據(jù)源無關(guān)

2.允許手工修改

隨機(jī)數(shù)據(jù)

1.易于獲得，不夠真實

2.對強(qiáng)度或負(fù)載測試是非常有用的

八、系統(tǒng)測試的類型

常見的測試類型：

• 功能測試（配置測試、恢復(fù)性測試、備份測試）
• 性能測試（壓力測試、穩(wěn)定性測試、容量測試）
• GUI測試（可用性測試）
• 兼容性測試
• 安全性測試（網(wǎng)絡(luò)測試）
• 安裝性測試
• 文檔測試

功能測試

概念：根據(jù)SRS和 需求列表，驗證產(chǎn)品的功能實現(xiàn)是否符合產(chǎn)品的需求規(guī)格

目標(biāo):

1.是否有不正確或者遺漏了的功能（做錯或少做）

2.功能實現(xiàn)是否滿足用戶需求和系統(tǒng)設(shè)計的隱藏需求

3.能否正確的接受輸入，能否正確的輸出結(jié)果

功能測試步驟：

1.對每個明確的功能需求進(jìn)行標(biāo)號

2.對每個隱含的功能需求進(jìn)行標(biāo)號

3.對可能出現(xiàn)的功能異常進(jìn)行分類分析并且標(biāo)號

4.把功能劃分為關(guān)鍵功能和非關(guān)鍵功能

5.對每個功能進(jìn)行測試分析，分析其是否可測，如何測試，可能的輸入、輸出

6.腳本化和自動化

性能測試

概念：用來測試軟件在集成系統(tǒng)中的運行性能

目標(biāo): 度量系統(tǒng)各項指標(biāo)，確認(rèn)系統(tǒng)有無各種性能瓶頸

特點：混合白盒測試和黑盒測試的方法

性能測試考慮的兩個方面:

1.驗證系統(tǒng)實現(xiàn)的性能是否與性能需求完全一致

2.檢測系統(tǒng)實現(xiàn)的具體性能到底怎樣

常用方法：探針，測試驅(qū)動

常用工具：Loadrunner,WebLoad,SilkPerformer

GUI測試

概念：針對軟件系統(tǒng)界面進(jìn)行的測試

目標(biāo)：1.測試界面實現(xiàn)與界面設(shè)計的吻合情況 ? 2.確認(rèn)界面處理的正確性

關(guān)注點：界面層與功能接口層上（GUI系統(tǒng)分為三個層次：界面層、界面與功能的接口層、功能層）

常用工具：QTP，QARun

兼容性測試

概念：考慮被測試軟件在其他軟件（例如操作系統(tǒng)）或硬件設(shè)備下的運行情況。

目標(biāo)：1.與輔助軟件的結(jié)合情況（操作系統(tǒng)，其他應(yīng)用程序，測試軟件，監(jiān)控軟件，瀏覽器等）； ?2.與硬件設(shè)計的結(jié)合情況（由于兼容性測試對硬件要求較多，一般無特殊要求都只會針對軟件要求做測試）。

安全性測試

概念：驗證集成在系統(tǒng)內(nèi)的保護(hù)機(jī)制是否能夠在實際中保護(hù)系統(tǒng)不受非法的侵入，用來保護(hù)數(shù)據(jù)本身的完整性和保密性。廣義的還包括物理安全和業(yè)務(wù)安全。

范圍：主要從幾個方面考慮：系統(tǒng)登錄，用戶管理，防火墻，系統(tǒng)數(shù)據(jù)，WEB安全，數(shù)據(jù)庫安全，內(nèi)部通訊，系統(tǒng)防毒測試等。

保護(hù)測試是安全測試中的一種常見的測試，主要用于測試系統(tǒng)的信息保護(hù)機(jī)制

安裝性測試

概念：主要依據(jù)軟件的測試特征列表、軟件安裝、配置文檔、設(shè)計安裝過程的測試用例，發(fā)現(xiàn)軟件在安裝過程中的錯誤。

目標(biāo)：找出軟件安裝的錯誤，安裝手冊的錯誤。

安裝測試前所要做的檢查工作：

1.安裝文檔是否齊全

2.安裝軟件的程序文件是否齊全

3.被測試的安裝文件是否齊全

4.軟件的文件格式是否與安裝指導(dǎo)中的要求的文件格式相符

常用自動化安裝測試軟件：Total Uninstall:它能夠監(jiān)視軟件安裝的所有過程，記錄下它對系統(tǒng)所做的任何改變FileRiver:可以自動監(jiān)視和準(zhǔn)確記錄下多個文件夾中的文件以及子文件的細(xì)微變化。

文檔測試

概念：主要針對軟件需求說明書，安裝手冊，配置指南等文檔，測試內(nèi)容主要是編寫規(guī)范，內(nèi)容正確性，無歧義性，完整性。

目標(biāo)：驗證用戶文檔是正確的并且保證操作手冊的過程能夠正確工作。

九、系統(tǒng)測試的過程

測試階段的劃分

系統(tǒng)測試計劃階段：完成系統(tǒng)測試計劃（規(guī)劃和步驟）

系統(tǒng)測試設(shè)計階段：完成系統(tǒng)測試方案

系統(tǒng)測試實現(xiàn)階段：完成系統(tǒng)測試用例，系統(tǒng)測試規(guī)程，系統(tǒng)測試預(yù)測試（冒煙測試）項

系統(tǒng)測試執(zhí)行階段：執(zhí)行系統(tǒng)測試預(yù)測試，系統(tǒng)測試用例，開展回歸測試，校驗已修復(fù)的問題，提交系統(tǒng)預(yù)測試報告，系統(tǒng)測試報告，缺陷報告

過程：軟件需求分析、設(shè)計（概要）、系統(tǒng)測試（執(zhí)行）

系統(tǒng)測試中的角色及職責(zé)

開發(fā)代表：解決資源需求，對系統(tǒng)測試結(jié)果進(jìn)行監(jiān)督

QA：系統(tǒng)測試過程質(zhì)量保證，參與相關(guān)評審，對過程進(jìn)行審計

配置管理組：對系統(tǒng)測試文檔，及測試代碼等相關(guān)配置進(jìn)行配置管理

軟件開發(fā)組：

1.系統(tǒng)測試計劃階段，提供軟件開發(fā)計劃SDP，參與系統(tǒng)測試計劃的評審

2.系統(tǒng)測試設(shè)計和實現(xiàn)階段，提供SRS，需求分析，測試建議，響應(yīng)系統(tǒng)測試需求，參與軟件系統(tǒng)測試方案的評審

3.系統(tǒng)測試執(zhí)行階段，跟蹤解決軟件測試項目組的缺陷問題報告單，參與系統(tǒng)測試報告的評審

軟件測試組：

1.系統(tǒng)測試計劃階段，制定系統(tǒng)測試計劃并組織評審

2.系統(tǒng)測試設(shè)計和實現(xiàn)階段，制定軟件測試方案并組織評審，按照軟件系統(tǒng)測試方案，實現(xiàn)測試用例，測試代碼和測試工具等設(shè)計，編寫測試規(guī)程

3.系統(tǒng)測試執(zhí)行階段，執(zhí)行系統(tǒng)測試，反饋并跟蹤缺陷問題報告單，完成系統(tǒng)測試報告并組織評審，輸出測試案例、總結(jié)等經(jīng)驗文檔

系統(tǒng)分析組：

1.提出系統(tǒng)測試需求

2.進(jìn)行測試需求跟蹤

3.進(jìn)行軟件系統(tǒng)可測性分析，確定系統(tǒng)測試的對象、范圍和方法

系統(tǒng)測試計劃的要點

1.明確系統(tǒng)測試的被測對象

2.完成系統(tǒng)測試的需求跟蹤

3.明確系統(tǒng)的通過或失敗標(biāo)準(zhǔn)

4.系統(tǒng)測試的掛起標(biāo)準(zhǔn)及恢復(fù)的必要條件

5.明確系統(tǒng)測試工作任務(wù)分配

6.系統(tǒng)測試結(jié)束后應(yīng)交付的工作產(chǎn)品

系統(tǒng)測試設(shè)計的要點

1.測試環(huán)境和測試數(shù)據(jù)的準(zhǔn)備

2.測試工具的開發(fā)/場景設(shè)計

3.系統(tǒng)測試用例設(shè)計

4.測試策略的選擇（如：測試幾輪）

系統(tǒng)測試方案和系統(tǒng)測試計劃的區(qū)別

系統(tǒng)測試計劃：對系統(tǒng)測試全過程的組織、資源、原則等進(jìn)行規(guī)定和約束，并制定系統(tǒng)測試全過程各個階段的任務(wù)以及時間進(jìn)度安排，并提出對各項任務(wù)的評估、風(fēng)險分析和管理需求。

系統(tǒng)測試方案：描述系統(tǒng)需要測試的特性，測試的方法，測試環(huán)境的規(guī)劃，測試工具的設(shè)計和選擇，測試用例的設(shè)計方法，測試代碼的設(shè)計方案。（設(shè)計測試方法的細(xì)節(jié)文檔）

注：案需要在系統(tǒng)測試計劃的指導(dǎo)下進(jìn)行，系統(tǒng)測試計劃提出做什么，而系統(tǒng)測試方案明確提出“如何做”

系統(tǒng)測試執(zhí)行概述

1.按一定的系統(tǒng)測試計劃，依據(jù)系統(tǒng)測試用例，完成測試的各項操作任務(wù)

2.根據(jù)系統(tǒng)測試方案，搭建系統(tǒng)測試環(huán)境是系統(tǒng)測試執(zhí)行的一個重要步驟，測試環(huán)境時候與否會嚴(yán)重影響測試結(jié)果的真實性和正確性

3.系統(tǒng)測試執(zhí)行階段應(yīng)完成：環(huán)境準(zhǔn)備、測試操作、測試記錄、測試報告

4.執(zhí)行的時間安排：在集成測試執(zhí)行完成之后進(jìn)行系統(tǒng)測試的執(zhí)行

系統(tǒng)測試預(yù)測試

目的：驗證軟件系統(tǒng)基本功能或預(yù)測主要的系統(tǒng)功能，以確保其后的系統(tǒng)測試執(zhí)行能夠順利進(jìn)行。

時間安排：系統(tǒng)預(yù)測試應(yīng)在開發(fā)項目組提出軟件版本轉(zhuǎn)系統(tǒng)測試申請后進(jìn)行，主要是完成轉(zhuǎn)系統(tǒng)測試評審需要輸入的《軟件系統(tǒng)與測試報告》。

人員安排：執(zhí)行驗證軟件基本功能活動的主體可以是軟件開發(fā)項目組也可以是軟件測試項目組或聯(lián)合的組織。

轉(zhuǎn)系統(tǒng)測試評審

1.評審責(zé)任的主體為軟件項目測試組，需要完成軟件轉(zhuǎn)系統(tǒng)測試評審表

2.軟件版本轉(zhuǎn)系統(tǒng)測試通過后，才能啟動執(zhí)行系統(tǒng)測試過程

3.啟動執(zhí)行系統(tǒng)測試過程后，系統(tǒng)預(yù)測試相關(guān)的軟件版本，測試代碼，文檔，環(huán)境等均應(yīng)在配置管理中基線化

系統(tǒng)測試報告寫作和評審

1.依據(jù)系統(tǒng)測試計劃的測試通過準(zhǔn)責(zé)，結(jié)束系統(tǒng)測試后，撰寫系統(tǒng)測試報告

2.系統(tǒng)測試報告需要通過評審，責(zé)任人為軟件測試項目組，由軟件開發(fā)項目組，配置管理小組和QA參與

3.評審不通過，系統(tǒng)測試報告退回。在評審不符合項和問題解決后再提交評審申請，或重新啟動系統(tǒng)測試過程

4.評審?fù)ㄟ^后，系統(tǒng)測試相關(guān)文檔、代碼、工具等均需跟隨軟件代碼，開發(fā)文檔一起完成配置基線化，系統(tǒng)測試過程結(jié)束

系統(tǒng)測試日報的寫作目的

1.測試人員總結(jié)每天的測試工作，便于了解自己的測試進(jìn)度和測試情況，用以調(diào)整下一天的工作計劃

2.測試人員對被測對象每天給出評估結(jié)果，用以調(diào)整后續(xù)工作的測試策略

3.測試人員向測試經(jīng)理反映測試中的困難，保證測試的順利進(jìn)行

4.測試經(jīng)理通過測試日報，了解每個工作人員的測試進(jìn)度，把握測試的整體進(jìn)度，發(fā)現(xiàn)進(jìn)度上的風(fēng)險及時調(diào)整計劃

5.測試經(jīng)理通過測試日報，了解各模塊缺陷發(fā)展的趨勢，判斷測試是否可以退出

6.開發(fā)經(jīng)理可以通過軟件測試日報了解當(dāng)前軟件的質(zhì)量情況，并可以調(diào)整缺陷修改的人力資源、

7.如果軟件有多個測試組并行測試，測試日報可以提供彼此測試交流的手段

系統(tǒng)測試步驟

需求分析 -> 計劃、方案 -> 用例設(shè)計 -> 環(huán)境搭建 -> 執(zhí)行 -> 測試報告

需求分類： 1. 項目需求（用戶自己提需求） 2．產(chǎn)品需求（產(chǎn)品人員進(jìn)行調(diào)查撰寫）

基線：第一種說法：軟件版本相對穩(wěn)定 ?第二種說法：文檔經(jīng)過多次評審修改之后封存起來，任何人需求修改都要提出申請。

十、集成測試概念

1.集成測試也叫組裝測試、聯(lián)合測試、子系統(tǒng)測試或部件測試。

2.集成測試是在單元測試的基礎(chǔ)上，將所有模塊按照概要設(shè)計要求（如根據(jù)結(jié)構(gòu)圖）組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。

十一、集成測試的目的

1.找出模塊接口以及整體體系結(jié)構(gòu)上的問題；

2.確保各組件組合在一起后能夠按照既定意圖協(xié)作運行，并確保增量的行為正確；

3.集成測試屬于灰盒測試；

? ? ?1)驗證接口是否與設(shè)計相符合；

? ? ?2)發(fā)現(xiàn)設(shè)計和需求中存在的錯誤。

十二、集成測試關(guān)注的重點

一些模塊雖可以單獨正常工作，但不能保證連接起來也能正常工作，程序在某些局部反映不出來的問題，在全局上就很有可能暴露出來，影響功能的實現(xiàn)。

因此，集成測試應(yīng)當(dāng)考慮一下兩個問題：

1.模塊間的接口（需要考慮的有兩點）

1)在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失；

2)全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題，會不會被異常修改。

2.集成后的功能（需要考慮三點）

1)各個子功能組合起來，能否達(dá)到預(yù)期要求的父功能；

2)一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；

3)單個模塊的誤差積累起來，是否會放大，從而達(dá)到不可接受的程度。

十三、集成測試的層次

一個產(chǎn)品的開發(fā)過程包括了一個分層的設(shè)計和逐步細(xì)化的過程，從最初的產(chǎn)品到最小的單元可以劃分為：產(chǎn)品——>子系統(tǒng)——>硬件子系統(tǒng)、軟件子系統(tǒng)——>軟件模塊——軟件程序——>單元。

一般單元測試針對最小的單元結(jié)構(gòu)，系統(tǒng)測試對應(yīng)于產(chǎn)品級，而當(dāng)中的所有各層測試都需要通過集成測試來完成，由于集成的力度不同，因此將集成測試劃分為3個級別：

1. 模塊內(nèi)集成測試（單元測試完成后）?
2. 子系統(tǒng)內(nèi)集成測試，即模塊間集成測試
3. 子系統(tǒng)間集成測試

十四、集成測試策略

集成測試策略是在測試對象分析的基礎(chǔ)上，描述軟件模塊集成（組裝）的方式、方法，分類如下：

1.大爆炸集成（Big Bang Integration）

是屬于非增值式集成（Non-Incremental Integration）的一種方法，也叫一次性組裝或整體拼裝。該集成把所有系統(tǒng)組件一次性集合到被測系統(tǒng)中，不考慮組件之間的相互依賴性或者可能存在的風(fēng)險。應(yīng)用一個系統(tǒng)范圍內(nèi)的測試包來證明系統(tǒng)最低限度的可操作性。

1)方法(策略)
a.在這種集成方式中，首先對每個模塊分別進(jìn)行單元測試
b.然后再把所有單元組裝在一起進(jìn)行測試?? ??? ?
c.最后得到要求的軟件系統(tǒng)? ? ?

2)目的

在最短時間內(nèi)把系統(tǒng)組裝出來，并且通過最少的測試來驗證整個系統(tǒng)

3)優(yōu)點
a.在有利的情況下，大爆炸集成可以迅速完成集成測試，并且只要極少數(shù)的驅(qū)動和樁模塊設(shè)計（如果需要的話）;
b.它需要的測試用例也是很少的;
c.該方法比較簡單；
d.多個測試人員可以并行工作，對人力，物力資源利用率較高。

4)缺點

a.這種一次性組裝方式試圖在輔助模塊的協(xié)助下，在模塊單元測試的基礎(chǔ)上，將所測模塊連接起來進(jìn)行測試，但是由于程序中不可避免地存在模塊間接口、全局?jǐn)?shù)據(jù)結(jié)構(gòu)等方面的問題，所以一次試運行成功的可能性并不很大;
b.在發(fā)現(xiàn)錯誤的時候，其問題定位和修改都比較困難;
c.即使被測系統(tǒng)能夠被一次性集成，但還是會有很多接口錯誤很容易的躲過測試而進(jìn)入到系統(tǒng)范圍測試內(nèi)。

5)適用范圍
a.維護(hù)型項目（或功能增強(qiáng)型項目），其以前的產(chǎn)品已經(jīng)很穩(wěn)定，并且新增的項目只有少數(shù)幾個組件被增加和修改；
b.被測系統(tǒng)比較小，并且它的每個組件都經(jīng)過了充分的單元測試；
c.產(chǎn)品使用了嚴(yán)格的凈室軟件工程過程，并且每個開發(fā)階段的質(zhì)量和單元測試質(zhì)量都非常高。

2.自頂向下的集成策略（Top-Down Integration）

采用了和設(shè)計一樣的順序?qū)ο到y(tǒng)進(jìn)行測試，在第一時間內(nèi)對系統(tǒng)的控制接口進(jìn)行了驗證。

1)方法（策略）

a. 以主模塊為所測模塊兼驅(qū)動模塊，所有直屬于主模塊的下屬模塊全部用樁模塊替換，對主模塊進(jìn)行測試；
b.采用深度優(yōu)先（Depth-First）或者寬度優(yōu)先（Breath-First）的策略，用實際模塊替換相應(yīng)樁模塊，再用樁替代它們的直接下屬模塊，與已測試的模塊或子系統(tǒng)組裝成新的子系統(tǒng)；
c.進(jìn)行回歸測試，排除組裝過程中引起的錯誤的可能；
d.判斷所有的模塊是否都已組裝到系統(tǒng)中?如果是，則結(jié)束測試，否則轉(zhuǎn)到b步驟去執(zhí)行。

2）目的

從頂層控制開始，采用同設(shè)計順序一樣的思路對被測系統(tǒng)進(jìn)行測試，以驗證系統(tǒng)的接口穩(wěn)定性

3）優(yōu)點

a.自頂向下的增殖方式在測試過程中較早的驗證了主要的控制和判斷點;
b.功能可行性較早得到證實，還能夠給開發(fā)者和用戶帶來成功的信心;
c.最多只需要一個驅(qū)動模塊，減少了驅(qū)動器開發(fā)的費用；
d.由于和設(shè)計順序的一致性，可以和設(shè)計并行進(jìn)行，如果目標(biāo)環(huán)境可能存在改變，該方法可以靈活的適應(yīng)；
e.支持故障隔離。

4）缺點
a.樁的開發(fā)和維護(hù)是本策略的最大成本，隨著樁數(shù)目增加，成本急劇上升;
b.底層組件中一個無法預(yù)計的需求可能會導(dǎo)致許多頂層組件的修改，這破壞了部分先前構(gòu)造的測試包;
c.底層組件行為的驗證被推遲；
d.隨著底層模塊的不斷增加，整個系統(tǒng)越來越復(fù)雜。

5）適用范圍

適用于大部分采用結(jié)構(gòu)化編程方法的軟件產(chǎn)品，且產(chǎn)品的結(jié)構(gòu)相對比較簡單，對于具有以下屬性的產(chǎn)品，可以優(yōu)先考慮該策略：

a.產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；
b.產(chǎn)品的高層接口變化比較??；
c.產(chǎn)品底層接口未定義或經(jīng)?？赡鼙恍薷?；
d.產(chǎn)品控制模塊具有較大的技術(shù)風(fēng)險，需要盡早被驗證；
e.希望盡早可以看到產(chǎn)品的系統(tǒng)功能行為；
f.在極端編程（Extreme Program）中使用探索式開發(fā)風(fēng)格時，其集成策略可以采用自頂向下。

3.自底向上的集成策略（Bottom-Up Integration）

是從程序模塊結(jié)構(gòu)的最底層的模塊開始組裝和測試，因為模塊是自底向上進(jìn)行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊下屬所有模塊）已經(jīng)組裝并測試完成，所有不在需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以通過直接運行子模塊得到。

4.三明治集成（Sandwich Integration）

也稱為混合式集成，集合了自頂向下和自底向上兩種策略的優(yōu)點，它將系統(tǒng)劃分為3層，中間一層為目標(biāo)層，測試的時候，對目標(biāo)層上面的一層使用自頂向下的集成策略，對目標(biāo)層下面的一層使用自底向上的集成策略，最后測試在目標(biāo)層會合。

5.基干集成（Backbone Integration）

在很多系統(tǒng)中，尤其是嵌入式系統(tǒng)，一般劃分為兩個部分：內(nèi)和部分（基干部分）和外圍應(yīng)用部分，這兩部分經(jīng)常被不同的項目組并行開發(fā)，該策略首先要識別應(yīng)用的控制組件部分，基干部分和應(yīng)用子系統(tǒng)部分，然后進(jìn)行測試。
結(jié)合自頂向下，自底向上和大爆炸集成的元素，驗證緊密耦合的子系統(tǒng)之間的互操作性。

6.分層集成（Layers Integration）

分層集成是針對分層模型使用的一種策略。
通過增量式集成的方法驗證一個具有層次體系結(jié)構(gòu)的應(yīng)用系統(tǒng)的穩(wěn)定性和可互操作性。

7.基于功能的集成（Function-Based Integration）

是從功能角度出發(fā)，按照功能的關(guān)鍵程度對模塊的集成順序進(jìn)行組織。
采用增值的方法，盡早的驗證系統(tǒng)關(guān)鍵功能。

8.基于進(jìn)度的集成（Schedule-Based Integration）

考慮了項目的進(jìn)度壓力，兼顧進(jìn)度和質(zhì)量，在兩者之間尋找均衡點進(jìn)行測試，該集成的最基本策略是把最早可獲得的代碼拿來立即進(jìn)行集成，必要的時候開發(fā)樁模塊和驅(qū)動模塊，在最大程度上保持與開發(fā)的并行性，從而縮短了項目集成的時間。

9.基于風(fēng)險的集成（Risk-Based Integration）

是基于假設(shè)：系統(tǒng)風(fēng)險最高的模塊間的集成往往是錯誤集中的地方，因此盡早的驗證這些接口有助于加速系統(tǒng)的穩(wěn)定。所以該集成需在第一時間內(nèi)驗證高危模塊間的接口，保證系統(tǒng)的穩(wěn)定性。

10.基于事件（消息）的集成（Event/Message-Based Integration）

針對基于狀態(tài)機(jī)的系統(tǒng)（工作原理是基于狀態(tài)變遷，內(nèi)部模塊間的接口主要通過消息來完成），因此該集成是從驗證消息路徑的正確性角度出發(fā)，漸增式的把系統(tǒng)集成到一起，從而驗證系統(tǒng)的穩(wěn)定性。

11.基于使用的集成（Use-Based Integration）

針對面向?qū)ο蟮南到y(tǒng)，從分析類之間的依賴關(guān)系出發(fā)，通過從最小依賴關(guān)系的類開始集成，逐步擴(kuò)大，最后集成到整個系統(tǒng)，通過該集成方法，可以驗證類之間接口的正確性。

12.分布式集成（Distributed Services Integration）

針對可以有許多并發(fā)運行、沒有專門控制軌跡的組件、以及沒有專門服務(wù)器層的分布式系統(tǒng)。
驗證松散耦合的同級組件之間交互的穩(wěn)定性。

13.客戶/服務(wù)器的集成（Client/Server Integration）

對于和單獨的服務(wù)器組件進(jìn)行松散耦合的客戶端組件，可以使用客戶/服務(wù)器集成來完成。
驗證客戶和服務(wù)器之間交互的穩(wěn)定性。

14.高頻集成（High-frequency Integration）

快速迭代式開發(fā)和增量式開發(fā)可能會導(dǎo)致系統(tǒng)功能的遺漏和沖突，該集成主要是為了避免以上問題，同時控制可能出現(xiàn)的基線偏差。

同時，在這我為大家準(zhǔn)備了一份軟件測試視頻教程（含面試、接口、自動化、性能測試等），就在下方，需要的可以直接去觀看，也可以直接【點擊文末小卡片免費領(lǐng)取資料文檔】

到了這里，關(guān)于軟件測試之單元測試、系統(tǒng)測試、集成測試詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！