軟體測試按照研發階段一般分為5個部分：單元測試、整合測試、確認測試、系統測試、驗收測試，下面將不同階段需要的一些工作內容做一下梳理希望可以幫助到大家。

//No.1//

單元測試

單元測試又稱為模組測試，是針對軟體設計的最小單位程式模組進行正確性檢查的測試工作，單元測試需要從程式內部結構出發設計測試用例，多個模組可以平行地獨立進行單元測試。

一、單元測試的內容：

1、模組介面測試

• 應對通過所測模組的資料流進行測試

• 呼叫所測模組時的輸入引數與模組的形式引數的個數、屬性和順序是否匹配

• 所測模組呼叫子模組時，輸入子模組的引數與子模組的形式引數在個數、屬性和順序上是否匹配。

• 輸出給標準函式的引數的個數、屬性和順序是否正確。

• 全域性變數的定義在各個模組中是否一致。

• 當模組通過外部裝置進行輸入/輸出操作，檔案屬性是否正確、open和close語句是否正確，規定的I/O格式說明與I/O語句是否匹配；緩衝區容量是否與記錄長度匹配，在讀寫之前是否打開了檔案，讀寫之後是否關閉了檔案，對I/O錯誤是否做了處理。

2、 區域性資料結構測試

• 區域性資料結構是最常見的錯誤來源

• 不一致的資料型別

• 不正確或不一致的資料說明

• 使用尚未賦值或尚未初始化的變數

• 錯誤的初始值或錯誤的預設值

3、 路徑測試

運算的優先次序、常見的比較和控制流

4、錯誤處理測試

遇見出錯的條件，並設定適當的出錯處理

5、邊界測試

例如迴圈的次數，最大或最小值

二、單元測試步驟：

• 利用設計文件設計測試用例；

• 建立被測模組的樁模組或驅動模組；

• 利用被測試模組、驅動模組和樁模組來建立測試環境，進行測試

• 驅動模組：相當於所測模組的主程式，它接收測試資料，把這些資料傳送給所測模組，最後再輸出實際結果

• 樁模組：用以代替所測模組呼叫的子模組。

 //No.2//

整合測試

又稱為組裝測試或聯合測試，在單元測試的基礎上，需要將所有模組按照概要設計說明書和詳細設計說明書的要求進行組裝。

• 在把各個模組連線起來的時候，穿越各個模組的介面的資料時候會丟失

• 一個模組的功能是否會對另一個模組的功能產生不利的影響

• 各個子功能組裝完成後，能否達到預期的父功能

• 全域性資料結構是否有問題

• 單個模組產生的誤差累計起來是否會放大

模組組裝成系統的方式：一次性組裝方式和增殖式組裝方式

一、一次性組裝方式

先對模組分別進行測試，再把所有模組組裝進行測試

  缺點：發現錯我不容易定位 

二、增值式組裝測試

先對一個個模組進行模組測試，然後將這些模組逐步組裝成系統，分為兩種方式：自頂向下的增殖方式和自底向上的增殖方式

1、自頂向下的增殖方式（不需要驅動模組）

將模組銨系統程式結構，嚴控制層次自頂向下進行組裝。

首先以主模組作為被測模組兼驅動模組，所有直屬主模組的下屬模組全部用樁模組代替，對主模組進行測試。再採用深度優先或廣度優先的策略，用實際模組代替樁模組，再用樁模組代替它們的直接下屬模組，與已經測試的模組構成新的子系統。然後進行迴歸測試。

2、自底向上的增殖方式（不需要驅動模組）

由驅動模組控制最底層模組的並行測試。

3、混合增殖式

• 自頂向下增殖方式：

優點：能夠較早的發現主要控制方面的問題

缺點：需要建立樁模組，增加了一些附加的測試，涉及演算法和輸入輸出的模組一般在底層，這些底層模組要到組裝和測試的後期才能發現。一旦發現問題就會出現過多的迴歸測試。

• 自底向上增殖方式：

優點：不需要建立樁模組，建立驅動模組要比建立樁模組要簡單得多，同時涉及到演算法已近輸入輸出的模組要先測試，把最容易出現問題的部分在早期解決。

缺點：程式一直未能作為一個實體存在，直到最後一個模組加上才能形成一個實體,控制方面最後才能接觸。

三、整合測試完成的標誌：

1、成功執行了測試計劃中規定的所有整合測試

2、修改了所發現的錯誤

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

4、整合測試需要提交的測試報告：

5、整合測試計劃、整合測試規格說明書以及整合測試分析報告

 //No.3//

確認測試

確認測試的目標是驗證軟體的功能和效能以及其他特性是否與使用者的要求一致。確認測試一般包括有效性測試和軟體配置複查。一般有第三方測試機構進行。

 一、進行有效性測試

現軟體確認要通過一系列黑盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃應規定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟體與需求是否一致。

無是計劃還是過程，都應該著重考慮軟體是否滿足合同規定的所有功能和效能，文件資料是否完整、準確人機介面和其他方面（例如，可移植性、相容性、錯誤恢復能力和可維護性等）是否令使用者滿意。

確認測試的結果有兩種可能，一種是功能和效能指標滿足軟體需求說明的要求，使用者可以接受；

另一種是軟體不滿足軟體需求說明的要求，使用者無法接受。專案進行到這個階段才發現嚴重錯誤和偏差一般很難在預定的工期內改正，因此必須與使用者協商，尋求一個妥善解決問題的方法

二、軟體配置複查

保證軟體配置的所有成分齊全，質量都符合要求。應該遵守使用者手冊和操作手冊中的規定步驟。

No.4

系統測試

軟體作為計算機系統的一部分，與硬體、網路、外設、支撐軟體、資料以及人員結合在一起，在實際或模擬環境下，對計算機系統進行測試，

目的在於與系統需求比較，發現問題

No.5

驗收測試

以使用者為主的測試，軟體開發人員和質量保證人員參加，由使用者設計測試用例。

不是對系統進行全覆蓋測試，而是對核心業務流程進行測試。