6.2 軟體測試策略
6.2 軟體測試策略
軟體測試策略
- 作用：為軟體開發人員、質量保證組織、和客戶提供了一個路線圖、規定了測試的主要步驟
- 為保證可行性，須考慮人力成本、時間和資源
- 故應結合：測試計劃、測試用例設計、測試執行、測試結果資料的收集與分析
- 要求
- 靈活性：有足夠的可塑性來應付所有的大軟體系統 嚴格：保證對專案程序進行合理的計劃和跟蹤管理·
軟體測試策略注意事項
在著手開始測試之前，要對產品的需求進行量化。明確指出測試目標。為每類使用者建立描述互動場景的用例。建立一個強調“快速迴圈測試”的測試計劃。設計一個能夠測試自身是否“強壯”的軟體。在進行測試之前，對軟體進行有效的正式技術稽核。使用正式技術稽核來評估測試策略和測試用例本身。為測試過程建立一種持續的改進方法。
軟體測試策略基本步驟
執行階段
搭建測試環境
構造測試資料
執行測試並記錄問題
確認問題
撰寫測試報告
計劃階段
制定計劃
編寫與評審測試用例
編寫測試指令碼和準備測試環境
軟體測試策略V模型
-
單元測試
主要目的是驗證軟體模組是否按詳細設計的規格說明正確執行。
-
系統測試
主要目的是驗證整個系統是否滿足需求規格說明。
-
整合測試
主要目的是檢查多個模組間是否按概要設計說明的方式協同工作。
-
驗收測試
從使用者的角度檢查系統是否滿足合同中定義的需求，以及以確認產品是否能符合業務上的需要。
迴歸測試
迴歸測試可以在所有的測試級別執行，並應用於功能和非功能測試中。
- 範圍
- 缺陷再測試：重新執行所有發現故障的測試，而新的軟體版本已經修正了這些故障。
- 功能改變的測試：測試所有修改或修正過的程式部分。新功能測試：測試所有新整合的程式。完全迴歸測試：測試整個系統。
why
1、測試中，如有缺陷修正、功能增加，變化的部分必須再測試。
2、軟體的修改可能會導致新的缺陷及其他問題。為防止，需再測試。
what
迴歸測試:指有選擇地重新測試系統或其元件，以驗證對軟體的修改沒有導致不希望出現的影響，以及系統或元件仍然符合其指定的需求。
by
迴歸測試應該儘量採用自動化測試。
1、單元測試
單元測試概念
單元內涵
不同環境含義不同，面向過程：函式、過程等，面向物件：類、類中成員函式等。
單元測試
針對軟體設計的最小單位 ─ 程式模組，進行正確性檢驗的測試工作。
測試方法
單元測試需要從程式的內部結構出發設計測試用例。多個模組可以平行地獨立進行單元測試。
主要依據
詳細設計
進入和退出條件
√ 所用測試用例執行通過
√ 單元測試覆蓋率達到預定要求
√ 單元測試未被執行的程式碼進行
正式審查。
√ 被測程式碼編譯連結通過
√ 被測程式碼靜態檢查工具檢查通過
√ 已完成至少一輪程式碼檢視或走讀
√ 單元測試用例的檢視通過
√ 單元測試程式碼寫完並通過檢測
測試內容
單元測試主要內容
資料流測試
√ 呼叫本模組的輸入引數是否正確；
√ 本模組呼叫子模組時輸入給子模組的引數是否正確；
√ 全域性量的定義在各模組中是否一致；
內外存交換測試
√ 檔案屬性是否正確；
√ OPEN與CLOSE語句是否正確；
√ 緩衝區容量與記錄長度是否匹配；
√ 在進行讀寫操作之前是否打開了檔案；
√ 在結束檔案處理時是否關閉了檔案；
√ 正文書寫／輸入錯誤，
√ I／O錯誤是否檢查並做了處理。
•區域性資料結構測試
不正確或不一致的資料型別說明、使用尚未賦值或尚未初始化的變數、錯誤的初始值或錯誤的預設值、變數名拼寫錯或書寫錯誤、不一致的資料型別、全域性資料對模組的影響
路徑****測試
重要路徑
對模組中重要的執行路徑進行測試。
計算、控制流
查詢由於錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。
基本、迴圈
對基本執行路徑和迴圈進行測試可以發現大量的路徑錯誤。
錯誤處理測試
出錯的描述是否難以理解
、出錯的描述是否能夠對錯誤定位
、顯示的錯誤與實際的錯誤是否相符
、對錯誤條件的處理正確與否
、在對錯誤進行處理之前，錯誤條件是否已經引起系統的干預等
邊界測試
•流邊界：注意資料流、控制流中剛好等於、大於或小於確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，加以測試。
•關鍵路徑：如果對模組執行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模組執行時間的因素。
測試用例設計
測試環境搭建
•模組並非獨立程式，進行測試時，要考慮它和外界的聯絡，需用一些輔助模組去做相應模擬
•驅動模組 ： 用來模擬被測試模組的上一級模組，相當於被測模組的主程式。
•樁模組 ： 模擬被測試的模組所呼叫的模組，而不是軟體產品的組成的部分。
2、整合測試
整合測試含義
將軟體整合起來後進行測試。 別名：子系統測試、組裝測試、部件測試等。
目的
檢查諸如兩個模組單獨執行正常，但整合起來執行可能出現問題的情況。
主要方法
-
自頂向下的整合方法
-
自底向上的整合方法
-
SMOKE方法
測試用例的設計
- 通過性測試
- 失效性測試
- 覆蓋率
- 注意介面
-
顯性介面：函式呼叫（API）介面
-
隱形介面：訊息、網路協議等
-
（1）自頂向下的整合方法
基本思想：該整合方式將模組按系統程式結構，沿控制層次自頂向下進行整合。
內建方法：深度優先、廣度優先
優點
可以較早地驗證主要的控制和判斷點。按深度方向，可首先實現和驗證一個完整的軟體功能。
缺點
是樁模組，開發量較大
適用情況
- 控制結構清晰穩定;高層介面變化較小;
- 底層介面未定義或經常可能被修改;
- 介面控制組件具有較大的技術風險
- 需要儘早被驗證;
- 希望儘早能看到產品的系統功能行為。
（2）自底向上的整合方法
基本思想:從軟體結構最底層的模組開始，按照介面依賴關係逐層向上整合以進行測試。
優點
每個模組呼叫其他底層模組都已經測試,不需要樁模組;
缺點
必須編寫驅動模組;缺陷的隔離和定位不如自頂向下。
適用情況
- 底層介面比較穩定;
- 高層介面變化比較頻繁;
- 底層元件較早被完成。
應用注意事項
•實際工作中，常綜合使用：自底向上、自頂向下
如：按進度選擇優先測試已經完成的模組
If：被測模組所呼叫的模組未完成，用自頂向下，打樁測試。
If：被測模組的上層模組未完成，用自底向上，模擬根模組。
（3）SMOKE方法
基本思想
將已經轉換為程式碼的軟體構件整合為構造（build）。一個構造包括所有的資料檔案、庫、可複用的模組以及實現一個或多個產品功能所需的工程化構件。
目 標
設計暴露影響構造正確地完成其功能的錯誤的測試。以發現極有可能造成專案延遲的業務阻塞錯誤。
方 法
每天將該構造與其他構造，及整個軟體產品整合，冒煙測試。
兩種方法：自頂向下，自底向上，均可。
3、系統測試
含義
從使用者使用的角度進行測試，將完成了整合測試的系統放在真實的執行環境下進行。【軟體質量保證的最重要環節。】
目的
功能確認和驗證
測試方法
黑盒測試
測試內容：
面向:外部輸入層測試，如不做,則外部輸入層向介面層轉換的程式碼就沒有得到測試。
面向:系統所有元件相互協調，單元、整合測試未做。
測試角度：
系統測試依據:需求規格說明
單元、整合測試依據:技術規格說明
系統測試內容
-
壓力測試
-
效能測試
-
功能測試
-
恢復測試
-
安全測試
1\功能測試
在規定的一段時間內執行軟體系統的所有功能，以驗證這個軟體系統有無嚴重錯誤。
•測試方法
黑盒測試
•錯誤型別
功能****錯誤或遺漏、介面錯誤、•資料結構或外部資料庫訪問錯誤、效能錯誤、初始化
2\效能測試
檢查系統是否滿足在需求說明書中規定的效能。
- 結合
常常要與壓力測試結合進行，硬體和軟體檢測同時進行。 - 內容
- 響應時間
- 吞吐量
- 輔助儲存區，如緩衝區、工作區的大小、處理精度等。
3\壓力測試
在系統執行環境不正常乃至發生故障的情況下，系統可以執行到何種程度的測試
測試方法
-
把輸入資料速率提高一個數量級，確定輸入功能將如何響應
-
設計需要佔用最大儲存量或其它資源的測試用例進行測試。
-
設計出在虛擬儲存管理機制中引起“顛簸”的測試用例進行測試。
-
設計出會對磁碟常駐記憶體的資料過度訪問的測試用例進行測試。
另：
敏感性測試：壓力測試的一個變種。在程式有效資料界限內一個小範圍內的一組資料可能引起極端的或不平穩的錯誤處理出現，或者導致極度的效能下降。
4\恢復測試
用來證實——在克服硬體故障後，系統能否正常地繼續進行工作，並且不對系統造成任何損害。
手 段：人工干預等
測試方法
- 錯誤探測功能──系統能否發現硬體失效與故障；
- 裝置故障時，能否切換或啟動備用的硬體；
- 故障發生時，能否保護正在執行的作業和系統狀態；
- 系統恢復後，能否從最後記錄下來的無錯誤狀態開始繼續執行作業等。
- 掉電測試：電源中斷時，能否保護當時的狀態且不毀壞資料，然後在電源恢復時從保留的斷點處重新進行操作。
5\安全性測試
檢驗在系統中已經存在的系統安全性、保密性措施是否發揮作用，有無漏洞。
主要攻擊方法
- 正面、側面或背面攻擊系統中易受損壞的那些部分；
- 以系統輸入為突破口，利用輸入的容錯性進行正面攻擊；
- 申請和佔用過多的資源壓垮系統，以破壞安全措施，從而進入系統；
- 故意使系統出錯，利用系統恢復的過程，竊取使用者口令及其它有用的資訊；
- 通過瀏覽殘留在計算機各種資源中的垃圾（無用資訊），以獲取如口令，安全碼，譯碼關鍵字等資訊；
- 瀏覽全域性資料，期望從中找到進入系統的關鍵字；瀏覽邏輯上不存在，但物理上還存在的各種記錄和資料等
4、驗收測試
時間節點
系統的有效性測試及軟體配置審查通過之後。
人員組織
以使用者為主\開發人員\質量保證人員
測試內容
功能和效能的可移植性、相容性、可維護性、錯誤的恢復功能等
測試資料
是實際生產資料
測試停止標準
軟體是無法完全測試的 —— 何時停止測試？
對數泊松執行時間模型的軟體故障模型
μ(t) 是在測試時間t 後，預期的故障累積數目。λ0 是測試開始時初始軟體故障的密度。θ值決定了隨著軟體修正程序，故障密度呈指數遞減的情況。
驗收測試過程
驗收測試形式
α測試
模擬使用者在實際操作環境下的測試
原 因
交付後，使用者的實際使用程式是無法預測的
目 的
評價FLURPS特性（功能、局域化、可使用性、可靠性、效能和支援）。尤其介面和特色
開始時間
- 編碼結束後
- 模組（子系統）測試完成後
- 系統測試過程中產品達到一定的穩定和可靠程度後
β測試
多個使用者在實際使用環境下進行測試，這些使用者反饋有關錯誤資訊給開發者。
測試人員
開發者通常不在測試現場，開發者無法控制的環境下進行的軟體現場應用。
測試形式
使用者記錄所有問題(真實的、主觀的)，定期向開發者報告。開始條件
α測試達到一定的可靠程度時開始，
測試步驟
產品的FLURPS。著重產品的支援性（文件、客戶培訓和支援產品生產能力)
測試自標
測試的最後階段，所有手冊文字此階段完全定稿。
“朝著一個既定的方向去努力，就算沒有天賦，在時間的積累下應該也能稍稍有點成就吧。”