軟體測試筆記（二）：軟體測試流程
1 測試流程概述
軟體測試流程包括：
測試計劃：測試計劃是指根據使用者需求報告中關於功能要求和效能指標的規格說明書，定義相應的測試需求報告，使得隨後所有的測試工作都圍繞著測試需求來進行，同時適當選擇測試內容，合理安排測試人員、測試時間和測試資源等
測試設計：測試設計是指將測試計劃階段制訂的測試需求分解，細化為若干個可執行的測試過程，併為每個測試過程選擇適當的測試用例，保證測試結果的有效性
測試開發：測試開發是指建立可重複使用的自動測試過程
測試執行：測試執行是指執行測試開發階段建立的自動測試過程，並對所發現的缺陷進行跟蹤管理，一般有單元測試、整合測試、確認測試等步驟組成
測試評估：測試評估是指結合量化的測試覆蓋域及缺陷跟蹤報告，對應用軟體的質量和開發團隊的工作進度以及工作效率進行綜合評價
其中測試執行由以下步驟組成：
單元測試：透過對每個最小的軟體模組進行測試，對原始碼的每一個程式單元實行測試，來檢查各個程式模組是否正確地實現了規定的功能，確保其能正常工作
整合測試：對已測試過的模組進行組裝整合，目的在於檢驗與軟體設計相關的程式結構問題
確認測試：檢驗軟體是否滿足需求規格說明中的功能和效能需求，確定軟體配置完全、正確，並檢驗軟體產品能否與實際執行環境中整個系統的其他部分協調工作
驗收測試：主要讓使用者對軟體進行測試，並重新執行已經做過的測試的某個子集，保證沒有引入新的錯誤
2 單元測試
2。1 定義
單元測試用於判斷一小段程式碼的某個特定條件或場景下某個特定函式的行為，主要測試軟體設計的最小單元在語法、格式、邏輯等方面的缺陷以及是否符合功能、效能等需求，程式的多個模組可以並行地進行單元測試工作。
2。2 內容
主要包括5個任務：
模組介面測試：透過對被測試模組的資料流進行測試，檢查進出模組的資料是否正確，因此必須對模組介面，包括引數表、呼叫子模組引數、全程資料、檔案輸入輸出操作進行測試
區域性資料結構測試：測試用例檢查區域性資料結構的完整性，如資料型別說明、初始化、預設值等方面的問題
執行路徑測試：對模組中重要的路徑進行測試，對基本執行路徑和迴圈進行測試往往可以發現大量路徑錯誤，測試用例必須能夠發現由於計算錯誤、不正確的判定或不正常的控制流而產生的錯誤
錯誤處理測試：檢查模組的錯誤處理功能是否包含錯誤或者缺陷，例如，是否拒絕不合理的輸入等
邊界條件測試：必須採用邊界值分析方法來設計測試用例，測試在為限制資料處理而設定的邊界處，測試模組是否能夠正常工作
2。3 步驟
一般單元測試需要輔助模組去幫助完成測試，輔助模組分為兩種：
驅動模組：用來模擬被測試模組的上一級模組，相當於被測模組的主程式，用於接收測試資料，並把這些資料傳送給被測模組，啟動被測模組並輸出結果
樁模組：用來模擬被測試模組工作過程中所呼叫的模組
被測試模組、驅動模組和樁模組共同構成了一個測試環境去進行測試。
3 整合測試
3。1 定義
將經過單元測試的模組連線起來，組成所規定的軟體系統的過程稱為整合，整合測試就是針對這個過程，按模組之間的依賴介面的關係圖進行測試。
3。2 任務
主要任務是解決如下問題：
將各模組連線起來，檢查模組相互呼叫時，資料經過介面是否丟失
將各個子功能組合起來，檢查能否到達預期要求的各項功能
一個模組的功能是否會對另一個模組的功能產生不利的影響
全域性資料結構是否有問題，會不會被異常修改
單個模組的誤差積累起來，是否被放大，從而達到不可接受的程度
3。3 方法
整合測試的方法，包括：
非增量式整合測試方法
增量式整合測試方法
3。3。1 非增量式整合測試方法
非增量式整合測試方法採用一步到位的方法來進行測試，對所有模組單元進行個別的單元測試後，按程式結構圖將各模組連線起來，把連線後的程式當作一個整體進行測試。
3。3。2 增量式整合測試方法
增量式測試整合方法可以分為：
自頂向下增量式測試
自底向上增量式測試
三明治整合測試
3。3。2。1 自頂向下增量式測試
自頂向下增量式測試按照結構圖自上而下逐步整合和逐步測試，模組整合的順序首先是整合主控模組（主程式），然後按照軟體控制層次結構向下進行整合，整合策略可以選擇廣度優先或深度優先。
優點包括：
在測試過程中較早地驗證主要的控制點
功能性的模組測試可以較早地得到證實
最多隻需要一個驅動模組就可以進行測試
支援缺陷故障隔離
缺點：
隨著底層模組不斷增加，會導致底層模組的測試不充分
每次組裝都需要提供樁，導致樁的資料急劇增加，從而維護樁的成本會快速上升
3。3。2。2 自底向上增量式測試
從原子模組（軟體結構中最底層的模組）開始，按結構圖從下而上逐步進行整合和測試。
優點：
總體上減少了樁模組的工作量
允許對底層模組行為進行早期驗證
測試初期可以並行整合
缺點：
隨著整合到頂層，整個系統變得越來越複雜，對於底層的一些模組很難覆蓋
驅動模組的開發工作量大
3。3。2。3 三明治整合測試
也叫混合整合，將自頂向下和自底向上的優缺點集於一身，三明治整合就是把系統分為三層，中間一層為目標層，對目標層上層採用自頂向下的整合測試方式，對目標層下層採用自底向上整合策略，最後對目標層進行測試。
4 確認測試
4。1 定義
用於驗證軟體的有效性，也就是驗證軟體的功能和效能以及其他特性是否與使用者要求一致。
4。2 內容
內容包括：
有效性測試：在模擬的環境下，運用黑盒測試的方法，驗證被測試軟體是否滿足需求規格說明書列出的需求
軟體配置審查：保證軟體配置的所有成分，包括與實際執行環境中整個系統的支援環境都應齊全，各方面的質量都符合要求
5 驗收測試
5。1 定義
驗收測試是以使用者為主的測試，但是軟體開發人員和質量保證人員也需要參加。由使用者參加設計測試用例，透過使用者介面輸入測試資料，分析測試的輸出結構。
5。2 內容
內容包括：
alpha
測試
beta
測試
迴歸測試
5。2。1
alpha
測試
alpha
測試是由一個使用者在開發環境下的測試，也可以是公司內部使用者在模擬實際操作環境下進行的測試。這是在受控制環境下進行的測試，目的是評價軟體產品的功能、可使用性、可靠性、效能和支援，尤其注重產品的介面和特色。
5。2。2
beta
測試
beta
測試由軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試，與
alpha
測試不同，開發者通常不在測試現場。在
beta
測試中，由使用者記錄遇到的所有問題，包括真實的以及主觀認定的問題，定期向開發者報告，開發者綜合使用者的報告後做出修改。
5。2。3 迴歸測試
5。2。3。1 定義
迴歸測試是一種驗證已變更的系統的完整性與正確性的測試技術，是指重新執行已經做過的測試的某個子集，以保證修改沒有引入新的錯誤或者發現由於更改而引起的之前未發現的錯誤。
5。2。3。2 實施前提
迴歸測試的實施前提包括：
當軟體中所含錯誤被發現時，如果錯誤跟蹤和管理系統不夠完善，可能會遺漏對這些錯誤的修改
開發者對錯誤的理解不夠透徹，也可能導致所做的修改只修正了錯誤的外在表現，而沒有修改錯誤本身
修改還有可能產生副作用，從而導致軟體未被修改的部分產生新的問題
5。2。3。3 迴歸測試的兩個策略
完全重複測試：選擇完全重複測試是指將所有的測試用例，全部再完全執行一遍，缺點是要把用例全部執行，會增加專案的成本以及影響專案的進度
選擇性重複測試：選擇一部分測試執行，以確認問題修改的正確性和修改後周邊是否受到影響，常見的方法包括覆蓋修改法、周邊影響法、指標達成法、基於操作剖面、基於風險選擇測試
5。2。3。4 流程
在測試策略指定階段，制定迴歸測試策略
確定迴歸測試版本
迴歸測試版本釋出，按照迴歸測試策略執行迴歸測試
迴歸測試透過，關閉缺陷跟蹤單
迴歸測試不透過，缺陷單返回開發人員，重新修改後再次迴歸測試
