單元測試、系統測試、集成測試知識詳解

🍅 點擊文末小卡片，免費獲取軟件測試全套資料，資料在手，漲薪更快?

一、單元測試的概念

單元測試是對軟件基本組成單元進行的測試，如函數或一個類的方法。當然這里的基本單元不僅僅指的是一個函數或者方法，有可能對應多個程序文件中的一組函數。

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

二、單元測試的目的

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

在單元測試階段對應的文檔是詳細設計文檔（LLD）；對應的代碼就是單元代碼，因此單元測試的目的主要有3點：

1、驗證代碼是與設計相符合的；

2、發現設計和需求中存在的錯誤；

3、發現在編碼過程中引入的錯誤。

三、單元的常見錯誤

單元的常見錯誤一般出現在以下五個方面，因此這五個方面是單元測試應該關注的重點。

1、單元接口。

2、局部數據結構。

3、獨立路徑。

4、出錯處理。

5、邊界條件。

四、如何進行單元測試

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

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

（1）接受測試數據，包含測試用例輸入和預期輸出；

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

（3）將被測單元的實際輸出和預期輸出進行比較，得到測試結果；

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

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

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

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

五、單元測試策略

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

1、孤立的單元測試策略

方法：不考慮每個模塊與其它模塊之間的關系，為每個模塊設計樁模塊和驅動模塊，每個模塊進行獨立的單元測試。
優點：這個方法比較簡單，最容易操作，可以達到很高的結構覆蓋率，可以并行開展，該方法是純粹的單元測試。
缺點：樁函數和驅動函數工作量很大，效率低。

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

方法：先對最頂層的單元進行測試，把頂層所調用的單元做成樁模塊，其次對第二層進行測試，使用上面已經測試過的單元做驅動模塊，以此類推，直到測試完所有模塊。
優點：可以節省驅動函數的開發工作，效率高。
缺點：隨著被測單元一個一個被加入，測試過程將變得越來越復雜，并且開發和維護的成本將增加。

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

方法：先對最底層的模塊進行單元測試，將模擬調用該模塊的模塊設置為驅動模塊，然后再對上面一層做單元測試，用下面已經測試好的模塊做樁模塊，以此類推，直到測試完所有模塊。
優點：可以節省樁函數的開發工作量，測試效率較高。
缺點：不是純粹的單元測試，底層函數的測試質量對上層函數的測試將產生很大影響。

六、系統測試的概念

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

系統測試的對象：軟硬件集合在一起的系統，集成后的產品，不應是獨立的軟件與硬件環境。不僅僅包括需測試的軟件，還要包含軟件所依賴的硬件、外設，甚至包括某些數據、某些支持軟件的系統等。

目的：通過與系統的需求定義做比較，發現軟件與系統定義不符合或與之矛盾的地方，以驗證軟件的功能和性能等滿足其規約所指定的要求。

常見的系統分類：

純軟件：QQ.................
軟件和硬件：手機，PSP，空調，電梯
軟件硬件和維護人員：大型系統

七、系統測試的環境

真實環境：直接將整個系統和其交聯的物理設備真實的建立鏈接，進行測試

優點：可以發現某些只能在真實環境下出現的問題

缺點：構建這樣一個環境需要高昂的費用，它的測試運行也需要高昂的費用

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

優點：仿真環境和真實環境的軟件依賴是一樣的，并且它能夠保證測試的可重復性、完整性、可擴展性

Example 1：某系統環境搭建的要求

硬件環境：

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

內存：4GB及以上

硬盤：可用空間10G以上

軟件環境：

平臺要求：Windows XP/2003標準版+Apache2.2.X+Mysql5.0及以上版本

目錄權限：目錄/Attachment，/Cache及文件需要寫的權限

推薦平臺：推薦使用XAMPP作為安裝介質

選用測試工具應考慮的因素：

1.測試工具與被測軟件系統的匹配程度

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

3.測試工具的服務和技術支持

4.測試工具的價格

測試數據：

特點：

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

2.數據來源很多

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

來源：

1.產品數據

2.手工構造數據

3.生成數據（一般由工具設備構造）

4.捕獲數據（少用，與捕獲數據源有關，允許手工修改）

5.隨機數據（系統測試少用，它易于獲得，不夠真實，性能測試常用）

產品數據

1.最具真實性

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

3.數據敏感，很難保證正確性

4.隨時間變化

5.可能數據量太大（從而降低測試執行速度）

手工構造數據

1.費時間、枯燥

2.如果對系統的功能缺乏了解，數據不真實

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

生成數據

1.一般由工具或設備構造

2.數據取決于工具的完善程度和測試人員的關于如何構造數據的規格說明

捕獲數據

1.與捕獲數據源無關

2.允許手工修改

隨機數據

1.易于獲得，不夠真實

2.對強度或負載測試是非常有用的

八、系統測試的類型

常見的測試類型：

功能測試（配置測試、恢復性測試、備份測試）
性能測試（壓力測試、穩定性測試、容量測試）
GUI測試（可用性測試）
兼容性測試
安全性測試（網絡測試）
安裝性測試
文檔測試

功能測試

概念：根據SRS和需求列表，驗證產品的功能實現是否符合產品的需求規格

目標:

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

2.功能實現是否滿足用戶需求和系統設計的隱藏需求

3.能否正確的接受輸入，能否正確的輸出結果

功能測試步驟：

1.對每個明確的功能需求進行標號

2.對每個隱含的功能需求進行標號

3.對可能出現的功能異常進行分類分析并且標號

4.把功能劃分為關鍵功能和非關鍵功能

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

6.腳本化和自動化

性能測試

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

目標: 度量系統各項指標，確認系統有無各種性能瓶頸

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

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

1.驗證系統實現的性能是否與性能需求完全一致

2.檢測系統實現的具體性能到底怎樣

常用方法：探針，測試驅動

常用工具：Loadrunner,WebLoad,SilkPerformer

GUI測試

概念：針對軟件系統界面進行的測試

目標：1.測試界面實現與界面設計的吻合情況 ? 2.確認界面處理的正確性

關注點：界面層與功能接口層上（GUI系統分為三個層次：界面層、界面與功能的接口層、功能層）

常用工具：QTP，QARun

兼容性測試

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

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

安全性測試

概念：驗證集成在系統內的保護機制是否能夠在實際中保護系統不受非法的侵入，用來保護數據本身的完整性和保密性。廣義的還包括物理安全和業務安全。

范圍：主要從幾個方面考慮：系統登錄，用戶管理，防火墻，系統數據，WEB安全，數據庫安全，內部通訊，系統防毒測試等。

保護測試是安全測試中的一種常見的測試，主要用于測試系統的信息保護機制

安裝性測試

概念：主要依據軟件的測試特征列表、軟件安裝、配置文檔、設計安裝過程的測試用例，發現軟件在安裝過程中的錯誤。

目標：找出軟件安裝的錯誤，安裝手冊的錯誤。

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

1.安裝文檔是否齊全

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

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

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

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

文檔測試

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

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

九、系統測試的過程

測試階段的劃分

系統測試計劃階段：完成系統測試計劃（規劃和步驟）

系統測試設計階段：完成系統測試方案

系統測試實現階段：完成系統測試用例，系統測試規程，系統測試預測試（冒煙測試）項

系統測試執行階段：執行系統測試預測試，系統測試用例，開展回歸測試，校驗已修復的問題，提交系統預測試報告，系統測試報告，缺陷報告

過程：軟件需求分析、設計（概要）、系統測試（執行）

系統測試中的角色及職責

開發代表：解決資源需求，對系統測試結果進行監督

QA：系統測試過程質量保證，參與相關評審，對過程進行審計

配置管理組：對系統測試文檔，及測試代碼等相關配置進行配置管理

軟件開發組：

1.系統測試計劃階段，提供軟件開發計劃SDP，參與系統測試計劃的評審

2.系統測試設計和實現階段，提供SRS，需求分析，測試建議，響應系統測試需求，參與軟件系統測試方案的評審

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

軟件測試組：

1.系統測試計劃階段，制定系統測試計劃并組織評審

2.系統測試設計和實現階段，制定軟件測試方案并組織評審，按照軟件系統測試方案，實現測試用例，測試代碼和測試工具等設計，編寫測試規程

3.系統測試執行階段，執行系統測試，反饋并跟蹤缺陷問題報告單，完成系統測試報告并組織評審，輸出測試案例、總結等經驗文檔

系統分析組：

1.提出系統測試需求

2.進行測試需求跟蹤

3.進行軟件系統可測性分析，確定系統測試的對象、范圍和方法

系統測試計劃的要點

1.明確系統測試的被測對象

2.完成系統測試的需求跟蹤

3.明確系統的通過或失敗標準

4.系統測試的掛起標準及恢復的必要條件

5.明確系統測試工作任務分配

6.系統測試結束后應交付的工作產品

系統測試設計的要點

1.測試環境和測試數據的準備

2.測試工具的開發/場景設計

3.系統測試用例設計

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

系統測試方案和系統測試計劃的區別

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

系統測試方案：描述系統需要測試的特性，測試的方法，測試環境的規劃，測試工具的設計和選擇，測試用例的設計方法，測試代碼的設計方案。（設計測試方法的細節文檔）

注：案需要在系統測試計劃的指導下進行，系統測試計劃提出做什么，而系統測試方案明確提出“如何做”

系統測試執行概述

1.按一定的系統測試計劃，依據系統測試用例，完成測試的各項操作任務

2.根據系統測試方案，搭建系統測試環境是系統測試執行的一個重要步驟，測試環境時候與否會嚴重影響測試結果的真實性和正確性

3.系統測試執行階段應完成：環境準備、測試操作、測試記錄、測試報告

4.執行的時間安排：在集成測試執行完成之后進行系統測試的執行

系統測試預測試

目的：驗證軟件系統基本功能或預測主要的系統功能，以確保其后的系統測試執行能夠順利進行。

時間安排：系統預測試應在開發項目組提出軟件版本轉系統測試申請后進行，主要是完成轉系統測試評審需要輸入的《軟件系統與測試報告》。

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

轉系統測試評審

1.評審責任的主體為軟件項目測試組，需要完成軟件轉系統測試評審表

2.軟件版本轉系統測試通過后，才能啟動執行系統測試過程

3.啟動執行系統測試過程后，系統預測試相關的軟件版本，測試代碼，文檔，環境等均應在配置管理中基線化

系統測試報告寫作和評審

1.依據系統測試計劃的測試通過準責，結束系統測試后，撰寫系統測試報告

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

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

4.評審通過后，系統測試相關文檔、代碼、工具等均需跟隨軟件代碼，開發文檔一起完成配置基線化，系統測試過程結束

系統測試日報的寫作目的

1.測試人員總結每天的測試工作，便于了解自己的測試進度和測試情況，用以調整下一天的工作計劃

2.測試人員對被測對象每天給出評估結果，用以調整后續工作的測試策略

3.測試人員向測試經理反映測試中的困難，保證測試的順利進行

4.測試經理通過測試日報，了解每個工作人員的測試進度，把握測試的整體進度，發現進度上的風險及時調整計劃

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

6.開發經理可以通過軟件測試日報了解當前軟件的質量情況，并可以調整缺陷修改的人力資源、

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

系統測試步驟

需求分析 -> 計劃、方案 -> 用例設計 -> 環境搭建 -> 執行 -> 測試報告

需求分類： 1. 項目需求（用戶自己提需求） 2．產品需求（產品人員進行調查撰寫）

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

十、集成測試概念

1.集成測試也叫組裝測試、聯合測試、子系統測試或部件測試。

2.集成測試是在單元測試的基礎上，將所有模塊按照概要設計要求（如根據結構圖）組裝成為子系統或系統，進行集成測試。

十一、集成測試的目的

1.找出模塊接口以及整體體系結構上的問題；

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

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

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

? ? ?2)發現設計和需求中存在的錯誤。

十二、集成測試關注的重點

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

因此，集成測試應當考慮一下兩個問題：

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

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

2)全局數據結構是否有問題，會不會被異常修改。

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

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

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

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

十三、集成測試的層次

一個產品的開發過程包括了一個分層的設計和逐步細化的過程，從最初的產品到最小的單元可以劃分為：產品——>子系統——>硬件子系統、軟件子系統——>軟件模塊——軟件程序——>單元。

一般單元測試針對最小的單元結構，系統測試對應于產品級，而當中的所有各層測試都需要通過集成測試來完成，由于集成的力度不同，因此將集成測試劃分為3個級別：

模塊內集成測試（單元測試完成后）?
子系統內集成測試，即模塊間集成測試
子系統間集成測試

十四、集成測試策略

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

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

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

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

2)目的

在最短時間內把系統組裝出來，并且通過最少的測試來驗證整個系統

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

4)缺點

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

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

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

采用了和設計一樣的順序對系統進行測試，在第一時間內對系統的控制接口進行了驗證。

1)方法（策略）

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

2）目的

從頂層控制開始，采用同設計順序一樣的思路對被測系統進行測試，以驗證系統的接口穩定性

3）優點

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

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

5）適用范圍

適用于大部分采用結構化編程方法的軟件產品，且產品的結構相對比較簡單，對于具有以下屬性的產品，可以優先考慮該策略：

a.產品控制結構比較清晰和穩定；
b.產品的高層接口變化比較小；
c.產品底層接口未定義或經常可能被修改；
d.產品控制模塊具有較大的技術風險，需要盡早被驗證；
e.希望盡早可以看到產品的系統功能行為；
f.在極端編程（Extreme Program）中使用探索式開發風格時，其集成策略可以采用自頂向下。

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

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

4.三明治集成（Sandwich Integration）

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

5.基干集成（Backbone Integration）

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

6.分層集成（Layers Integration）

分層集成是針對分層模型使用的一種策略。
通過增量式集成的方法驗證一個具有層次體系結構的應用系統的穩定性和可互操作性。

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

是從功能角度出發，按照功能的關鍵程度對模塊的集成順序進行組織。
采用增值的方法，盡早的驗證系統關鍵功能。

8.基于進度的集成（Schedule-Based Integration）

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