
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
alpha
測試是由一個使用者在開發環境下的測試,也可以是公司内部使用者在模拟實際操作環境下進行的測試。這是在受控制環境下進行的測試,目的是評價軟體産品的功能、可使用性、可靠性、性能和支援,尤其注重産品的界面和特色。
5.2.2 beta
beta
beta
測試由軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試,與
alpha
測試不同,開發者通常不在測試現場。在
beta
測試中,由使用者記錄遇到的所有問題,包括真實的以及主觀認定的問題,定期向開發者報告,開發者綜合使用者的報告後做出修改。
5.2.3 回歸測試
5.2.3.1 定義
回歸測試是一種驗證已變更的系統的完整性與正确性的測試技術,是指重新執行已經做過的測試的某個子集,以保證修改沒有引入新的錯誤或者發現由于更改而引起的之前未發現的錯誤。
5.2.3.2 實施前提
回歸測試的實施前提包括:
- 當軟體中所含錯誤被發現時,如果錯誤跟蹤和管理系統不夠完善,可能會遺漏對這些錯誤的修改
- 開發者對錯誤的了解不夠透徹,也可能導緻所做的修改隻修正了錯誤的外在表現,而沒有修改錯誤本身
- 修改還有可能産生副作用,進而導緻軟體未被修改的部分産生新的問題
5.2.3.3 回歸測試的兩個政策
- 完全重複測試:選擇完全重複測試是指将所有的測試用例,全部再完全執行一遍,缺點是要把用例全部執行,會增加項目的成本以及影響項目的進度
- 選擇性重複測試:選擇一部分測試執行,以确認問題修改的正确性和修改後周邊是否受到影響,常見的方法包括覆寫修改法、周邊影響法、名額達成法、基于操作剖面、基于風險選擇測試
5.2.3.4 流程
- 在測試政策指定階段,制定回歸測試政策
- 确定回歸測試版本
- 回歸測試版本釋出,按照回歸測試政策執行回歸測試
- 回歸測試通過,關閉缺陷跟蹤單
- 回歸測試不通過,缺陷單傳回開發人員,重新修改後再次回歸測試