軟件測試流程：需求分析階段-軟件設計和編碼階段（進行單元測試）-集成、系統、驗收測試階段。
軟件測試模型：
傳統：項目計划——需求分析——軟件設計——程序開發——軟件測試——集成維護
V模型：需求分析-概要設計-詳細設計-軟件編碼-單元測試-集成測試-系統測試-驗收測試
W模型：用戶需求-需求分析-概要設計-詳細設計-編碼-單元測試-集成測試-驗收測試-單元測試設計-集成測試設計-系統測試設計-驗收測試設計-集成-實施-交付
H模型：測試准備-測試就緒點-測試執行-測試流程-其他流程
X模型：程序片段1-測試設計-工具配置-執行測試-編碼完成-執行測試-工具配置-測試設計-程序片段N；封版-執行測試-測試設計-工具配置-迭代1...N-探索式測試-執行測試
軟件V模型圖：
軟件測試W模型圖：
軟件H模型圖：
軟件X模型圖：
總結：在W模型基礎上結合H模型思想進行測試，當變更發生時，采用X模型思想進行處理，將開發和測試緊密結合，尋找恰當的就緒點開始測試，並反復迭代。
軟件測試按照研發階段一般分為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//
系統測試 通常意義上的系統測試包括 壓力測試（也稱為強度測試），容量測試，負載測試，性能測試，安全測試，容錯測試等。
軟件作為計算機系統的一部分，與硬件、網絡、外設、支撐軟件、數據以及人員結合在一起，在實際或模擬環境下，對計算機系統進行測試，
目的在於與系統需求比較，發現問題。
利用程序的用戶文檔或書面材料。通過分析目標文檔來設 計系統測試，分析用戶文檔來闡明測試用例。
由於沒有一個方法，系統測試需要大 量的創造性。事實上，設計好的系統測試用例比設計系統或程序需要更多的創造性、 智慧和經驗。
為了避免有所遺漏，設計測試用例時應考慮全部的 15 種類型。
能力測試、容量測試、強度測試、易用性測試、安全性測試、
性能測試、存儲測試、配置測試、兼容性/配置/轉換測試、安裝測試、
可靠性測試、可恢復性測試、適用性測試、文檔測試、過程測試。
//No.5//
驗收測試 包括：正式驗收，alpha測試，Beta測試。
以用戶為主的測試，軟件開發人員和質量保證人員參加，由用戶設計測試用例。
不是對系統進行全覆蓋測試，而是對核心業務流程進行測試。
根據合同、《需求規格說明書》或《驗收測試計划》對產品進行驗收測試。
對於通過驗收測試的軟件產品/參照《配置管理規范》中所規定的標識方法更改測試狀態，同時項目經理負責編制《驗收報告》。