軟件測試模型與軟件測試流程5個階段

https://www.cnblogs.com/linxiu-0925/p/7761392.html

軟件測試流程：需求分析階段-軟件設計和編碼階段（進行單元測試）-集成、系統、驗收測試階段。

軟件測試模型：

    傳統：項目計劃——需求分析——軟件設計——程序開發——軟件測試——集成維護 
    V模型：需求分析-概要設計-詳細設計-軟件編碼-單元測試-集成測試-系統測試-驗收測試
    W模型：用戶需求-需求分析-概要設計-詳細設計-編碼-單元測試-集成測試-驗收測試-單元測試設計-集成測試設計-系統測試設計-驗收測試設計-集成-實施-交付
    X模型：程序片斷1-測試設計-工具配置-執行測試-編碼完成-執行測試-工具配置-測試設計-程序片斷N；封版-執行測試-測試設計-工具配置-迭代1...N-探索式測試-執行測試
    H模型：測試準備-測試就緒點-測試執行-測試流程-其餘流程
軟件V模型圖：

軟件測試W模型圖：

軟件H模型圖：

軟件X模型圖：

總結：在W模型基礎上結合H模型思想進行測試，當變動發生時，採用X模型思想進行處理，將開發和測試緊密結合，尋找恰當的就緒點開始測試，並反覆迭代。

---

軟件測試按照研發階段通常分爲5個部分：單元測試、集成測試、確認測試、系統測試、驗收測試，下面將不一樣階段須要的一些工做內容作一下梳理但願能夠幫助到你們。

//No.1//

單元測試（也稱爲模塊測試）

 

單元測試又稱爲模塊測試，是針對軟件設計的最小單位程序模塊進行正確性檢查的測試工做，單元測試須要從程序內部結構出發設計測試用例，多個模塊能夠平行地獨立進行單元測試。

 

1、單元測試的內容：（白盒爲主，黑盒爲輔）

一、模塊接口測試

• 應對經過所測模塊的數據流進行測試

• 調用所測模塊時的輸入參數與模塊的形式參數的個數、屬性和順序是否匹配

• 所測模塊調用子模塊時，輸入子模塊的參數與子模塊的形式參數在個數、屬性和順序上是否匹配。

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

• 全局變量的定義在各個模塊中是否一致。

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

 

二、 局部數據結構測試

• 局部數據結構是最多見的錯誤來源

• 不一致的數據類型

• 不正確或不一致的數聽說明

• 使用還沒有賦值或還沒有初始化的變量

• 錯誤的初始值或錯誤的缺省值

 

三、 路徑測試

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

 

四、錯誤處理測試

碰見出錯的條件，並設置適當的出錯處理

  

五、邊界測試

例如循環的次數，最大或最小值

 

六、增量測試【包括自頂向下測試：從程序頂部或初始化模塊開始 與自底向上測試：程序中的終端模塊開始】與非增量測試

 

 

2、單元測試步驟：

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

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

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

• 驅動模塊：至關於所測模塊的主程序，它接收測試數據，把這些數據傳送給所測模塊，最後再輸出實際結果

• 樁模塊：用以代替所測模塊調用的子模塊。

 

 

 //No.2//

集成測試（白盒和黑盒結合）

 

又稱爲組裝測試或聯合測試，在單元測試的基礎上，須要將全部模塊按照概要設計說明書和詳細設計說明書的要求進行組裝。

 

• 在把各個模塊鏈接起來的時候，穿越各個模塊的接口的數據時候會丟失

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

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

• 全局數據結構是否有問題

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

 

集成測試層次：子系統內集成測試；子系統間集成測試；模塊間集成測試。

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

 

1、一次性組裝方式(非增式集成）

 

先對模塊分別進行測試，再把全部模塊組裝進行測試

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

 

2、增值式組裝測試：自頂向下；自底向上；分層集成；三明治集成；基層集成；高頻集成。

 

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

 

一、自頂向下的增殖方式（不須要驅動模塊）

 

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

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

 

二、自底向上的增殖方式（不須要驅動模塊）

 

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

 

三、混合增殖式

 

• 自頂向下增殖方式：

優勢：可以較早的發現主要控制方面的問題

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

 

• 自底向上增殖方式：

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

缺點：程序一直未能做爲一個實體存在，直到最後一個模塊加上才能造成一個實體,控制方面最後才能接觸。

 

3、集成測試完成的標誌：

 

一、成功執行了測試計劃中規定的全部集成測試

二、修改了所發現的錯誤

三、測試結果經過專門小組的評審

四、集成測試須要提交的測試報告：

五、集成測試計劃、集成測試規格說明書以及集成測試分析報告

 

 //No.3//

確認測試（黑盒）

 

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

 

 1、進行有效性測試

 

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

 

無是計劃仍是過程，都應該着重考慮軟件是否知足合同規定的全部功能和性能，文檔資料是否完整、準確人機界面和其餘方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。

 

確認測試的結果有兩種可能，一種是功能和性能指標知足軟件需求說明的要求，用戶能夠接受；

 

另外一種是軟件不知足軟件需求說明的要求，用戶沒法接受。項目進行到這個階段才發現嚴重錯誤和誤差通常很難在預約的工期內改正，所以必須與用戶協商，尋求一個妥善解決問題的方法

 

2、軟件配置複查

 

保證軟件配置的全部成分齊全，質量都符合要求。應該遵照用戶手冊和操做手冊中的規定步驟。

 

//No.4//

系統測試  一般意義上的系統測試包括 壓力測試（也稱爲強度測試），容量測試，負載測試，性能測試，安全測試，容錯測試等。

 

 軟件做爲計算機系統的一部分，與硬件、網絡、外設、支撐軟件、數據以及人員結合在一塊兒，在實際或模擬環境下，對計算機系統進行測試，

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

 

利用程序的用戶文檔或書面材料。經過分析目標文檔來設 計系統測試，分析用戶文檔來闡明測試用例。

因爲沒有一個方法，系統測試須要大 量的創造性。事實上，設計好的系統測試用例比設計系統或程序須要更多的創造性、 智慧和經驗。

 爲了不有所遺漏，設計測試用例時應考慮所有的 15 種類型。

能力測試、容量測試、強度測試、易用性測試、安全性測試、

性能測試、存儲測試、配置測試、兼容性/配置/轉換測試、安裝測試、

可靠性測試、可恢復性測試、適用性測試、文檔測試、過程測試。

 

 

//No.5//

驗收測試  包括：正式驗收，alpha測試，Beta測試。

 

 以用戶爲主的測試，軟件開發人員和質量保證人員參加，由用戶設計測試用例。

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

根據合同、《需求規格說明書》或《驗收測試計劃》對產品進行驗收測試。

對於經過驗收測試的軟件產品/參照《配置管理規範》中所規定的標識方法更改測試狀態，同時項目經理負責編制《驗收報告》。