(二) 軟體測試基礎

軟體測試的定義

軟體生命週期:制定計劃、需求分析和定義、軟體設計、程式設計、軟體測試、執行/維護
測試方法: 黑箱測試、白箱測試
測試策略和步驟: 單元測試、整合測試、確認測試、系統測試

相關定義和概念
靜態檢查: 評審和非執行手段來檢查
動態檢查: 在生命週期中進行測試(執行)
靜態測試: 在不執行程式的情況下檢查程式的執行情況，包括需求評審、設計評審、程式碼檢查
動態測試: 執行程式碼時進行的測試，包括單元測試、整合測試、系統測試、驗收測試、回歸測試
功能測試: 測試功能需求
結構測試: 驗證系統架構進行的測試
黑箱測試: 不了解系統結構的情況下以說明書作為基礎進行測試
白箱測試: 以系統內部結構和相關知識為基礎進行測試


測試的原則

1.開始測試的時間越早越好
2.測試用例包含測試輸入的資料和對應的預期輸出結果
3.程式設計師應避免測試自己的程式(debug不等於test)
4.設計測試用例時，應當包含合理/不合理的輸入條件
5.充分注意測試中的群集現象(同種類錯誤)
6.嚴格執行測試計劃，排除測試的隨意性
7.應當對每一個測試結果做全面檢查
8.保存測試計劃、測試用例、出錯統計和分析報告，為維護提供方便


測試在開發階段的作用

專案規劃階段
---專人負責從單元測試到系統測試的整個測試階段的監控

需求分析階段
---確保"測試需求分析"、"系統測試計劃"的制定
---"測試需求分析" 產品生命週期中測試所需要的資源、配置
---"系統測試計劃" 依據軟體的需求規則說明書，制定測試計劃和設計相應的測試用例

詳細設計和概要設計階段
---確保整合測試計劃和單元測試計劃完成

程式設計階段
---開發人員撰寫自己負責部分的測試程式碼

測試階段
---測試人員依據測試程式碼進行測試
---專人主持測試工作並提交相應的測試狀態報告
---測試計劃和測試用例的制定、測試程式碼的編寫及具體的測試，不僅在階段上是分離的，在執行中也是分離的 (區分為測試設計者/測試程式設計者/測試操作者)


程式錯誤分類

依照錯誤的影響(嚴重性)和後果分類:
較小: 只對系統輸出有一些非實質性影響 (EX 輸出的資料格式不合要求)
中等: 對系統的執行有局部影響 (EX 輸出的某些資料有錯誤)
嚴重: 系統的行為因錯誤的干擾而出現不合情理的現象 (EX 開出了0元支票 系統的輸出完全不可信賴)
非常嚴重: 系統執行中突然停機

依照錯誤的性質和範圍分類:

1.功能錯誤
--規格說明錯誤
--功能錯誤
--測試標準引起的錯誤

2.系統錯誤
外部介面錯誤: 外部介面指如印表機、通信線路等與外部環境通信的手段 (EX 對輸入資料不合理的容錯)
內部介面錯誤: 內部介面指程式之間的聯繫 (EX 輸入/輸出格式錯誤、資料保護不可靠)
硬體結構錯誤: 這類錯誤在於不能正確地理解硬體如何工作
軟體結構錯誤: 通常與系統的負載有關
控制與順序錯誤: 等待一個不可能發生的條件、漏掉先決條件、漏掉處理步驟等等
資源管理錯誤: 不正確的使用資源而產生的 (EX 使用未經獲准的資源、使用後未釋放資源、資源鎖死)

3.加工錯誤
算術與操作錯誤: 指在算術運算、函數求值和一班操作過程中發生的錯誤
初始化錯誤: 用不正確的格式、資料或類型進行初始化
控制和次序錯誤: 和系統錯誤中的同名錯誤類似但屬於局部錯誤 (EX 迴圈返回和終止的條件不正確)
靜態邏輯錯誤: 不正確的使用case語句( > < = )

4.資料錯誤
動態資料錯誤: 程式執行過程中暫時存在的資料，可能經由一連串的運算導致產生錯誤
靜態資料錯誤: 撰寫程式碼時IDE產生的錯誤提示 (通常就會不能執行)

5.程式碼錯誤
語法錯誤

依照軟體生存期階段分類:

1.問題定義(需求分析)錯誤
由於不滿足使用者的要求而導致的錯誤

2.規格說明錯誤
不一致性錯誤: 功能說明與問題發生矛盾
不完整性錯誤: 缺少某些必要的功能說明
不可行錯誤: 有些功能要求是不可行的
不可測試錯誤: 有些功能的測試要求是不符現實的

3.設計錯誤
設計不完全錯誤
演算法錯誤
控制邏輯錯誤
資料結構錯誤

4.程式設計錯誤
資料說明錯、資料使用錯、計算錯、比較錯、控制流措、介面錯、輸入/輸出錯


軟體缺陷

缺陷屬性
類型
嚴重程度
優先順序
狀態
根源(root cause)

缺陷類型
功能: 功能不正確
指定: 初始化或控制塊
介面: 呼叫參數
檢查: 提示的錯誤資訊
建置: 版本控制引起
文件: 注釋
演算法: 演算法錯誤
使用者介面: 人機交互的特性
效能: 執行時間

缺陷嚴重程度
嚴重: 不能執行正常工作功能或重要功能
大缺陷: 影響系統要求或基本功能的實現且沒有辦法更正
小缺陷: 影響系統要求或基本功能的實現但存在合理的更正辦法
輕微缺陷: 使操作者不方便或遇到麻煩但不影響執行工作功能或重要功能

缺陷優先順序
立即解決
正常排隊
不緊急

缺陷狀態
提交(submitted)
打開(opened)
拒絕(rejected)
解決(resolved)
關閉(closed)

缺陷根源
目標: 錯誤的範圍
過程、工具和方法: 過時的風險管理過程、不適用的專案管理方法、無效的變更控制過程
人: 缺乏培訓、沒有經驗
缺乏組織和通信: 缺乏使用者參予、職責不明確
硬體: 記憶體溢出
軟體: 工具軟體的錯誤
環境: 預算改變、中斷


測試方法

白箱測試的實施方案

定義測試準則
--為控制測試的有效性以及完成程度，必須定義準則和策略，以判斷何時結束測試階段

度量測試的有效性、完整性
--對每個測試的測試覆蓋資訊和累計資訊，用圖形方式顯示覆蓋比率，並根據策是執行情況即時更新，隨時顯示新的測試所反映的測試覆蓋情況

測試過程最佳化
--在測試階段的第一步，執行的測試是功能性測試。其目的是檢查所期望的功能是否已經實現。在測試的初期，覆蓋率迅速增加。像樣的測試工作一般能達到70%的覆蓋率。但是，此時要再提高覆蓋率是十分困難的，因為新的測試往往覆蓋了相同的測試路徑。在該階段需要對測試策略做一些改變：從功能性測試轉向結構化測試。也就是說，針對沒有執行過的路徑，構造適當的測試用例來覆蓋這些路徑

黑箱測試的實施方案

使用者端的測試
--主要關注應用的業務邏輯、使用者介面、功能測試等
--由於測試並不是進行一次就可以完成的過程。而是需要根據產品版本的變化生成不同的測試過程，如果這一過程僅透過手工方式完成是很難達到的
--需要透過工具的幫助，從而簡化測試的複雜程度，降低在測試成本上的開銷，縮短投放市場的時間。還有一個突出的特點就是應用程式的回歸測試，這是手工方式完成不了的過程，只有透過工具才能實施

伺服器端的測試
--主要關注伺服器的效能、衡量系統的回應時間、事務處理速度和其他時間敏感的需求
--以類別比合法使用者活動給系統的負載，負責測試的統計結果被用來預測使用者將體驗到的效能和回應時間