第二章 軟體測試概論

大綱 2.1 軟體測試的基礎 2.2 軟體測試規劃 2.3 軟體測試分類 2.4 結論

軟體測試的基礎 何謂軟體測試 為什麼要軟體測試 軟體測試的迷思 軟體產品品質的進化 軟體錯誤分類 軟體測試的基本步驟

何謂軟體測試 為了提早發現錯誤 程式設計的檢查 劃分方式不同，有以下分類 方法：黑箱、白箱、灰箱 過程：單元測試、整合測試、系統測試、驗收測試

為什麼要軟體測試1 提高軟體品質 一般程式設計師並非皆具有軟體測試能力 減少商業損失 軟體缺陷可能會造成無法補救的後果 訂單 利率 航太系統 醫療系統

為什麼要軟體測試2 軟體修正成本圖 成本 倍數 1000 100 10 1 需求階段 設計階段 開發階段 使用階段

軟體測試的迷思 軟體品質有問題，代表測試人員沒做好。 軟體測試比程式設計簡單。 軟體是程式設計師寫的，程式設計師應該懂軟體測試。 隨便找一個人就可以測試軟體。 測試是測試工程師的事，與程式設計師無關。 軟體開發完成後再做測試就可以了。

軟體產品品質的進化 Alpha版 Beta版 正式版 軟體所有功能已大致完成，可正常運作 所有功能已經通過測試 已找出的重大缺陷皆已被修改並通過測試 Beta版 已找出的次重大缺陷已被修改並通過測試 完成測試計劃的每一具體測試 一般皆徵求使用者下載測試 正式版 得到品質認證部門與技術支援部門的認可 錯誤發現率小於修正率，距離逐漸拉開 所有系統文件皆已完工

軟體錯誤分類1 依錯誤的性質與範圍分類 功能錯誤 系統錯誤 程式功能與使用者的需求不一致 作業系統錯誤 誤解硬體結構的錯誤 系統結構錯誤 控制與順序錯誤 系統資源分配錯誤

軟體錯誤分類2 程式內容錯誤 語法錯誤 打字錯誤 指令誤用 資料錯誤 靜態型資料錯誤 動態型資料錯誤 資料結構錯誤 資料型態錯誤

軟體錯誤分類3 處理錯誤 算術運算錯誤 初使化錯誤 邏輯錯誤

軟體錯誤分類4 依開發階段分成 需求分析錯誤 在軟體定義階段產出文件的錯誤 規格錯誤 規格與軟體定義不一致 不完整錯誤 不可行錯誤

軟體錯誤分類4 設計錯誤 控制邏輯錯誤 資料結構錯誤 設計不完全 程式設計錯誤 計算錯誤 比較錯誤 控制流錯誤 介面錯誤

軟體測試的基本步驟 資料收集與整理 準備測試軟體 制定測試方案 編寫測試計劃 設計測試案例 進行測試 測試記錄

軟體測試規劃 簡介 測試規劃

簡介 完成一份測試計畫書，在軟體測試中佔著非常重要角色。 然而，常常因為資源和時間上的問題，沒有一份比較完整和正規的測試計畫書作為測試依據。 測試計畫書可因某些因素加以修正或改善，例如：發現新的測試案例、計畫書內容無法實施。

測試規劃1 測試內容描述 測試項目 專案規劃、QA規畫、CM規劃 版本/修訂 層級 如何傳輸(網路(net)、光碟(disc)..) 軟體文件

測試規劃2 將測試的功能 說明測試的原因 不被測試的功能 說明不被測試的原因

測試規劃3 測試方法 測試成功與失敗的判定方法 暫停測試與恢復測試判定方法 測試活動、測試技術、工具 測試深入程度 列出測試限制(環境、人力…等) 測試成功與失敗的判定方法 暫停測試與恢復測試判定方法 測試過程中如何判定暫停測試及恢復測試

測試規劃4 測試過程的產出 測試計劃 (Test plan) 設計(Test design) 案例(Test case) 測試程序(Testing procedure) 記錄(Logs) 意外風險管理(Test crisis ) 總結(Summary)

測試規劃5 測試工作內容及環境 內容工作定義 測試軟體、硬體 機房環境 測試專案管理 管理整個測試專案

測試規劃6 人員訓練(Training) 時程(Schedule) 資源需求 測試里程碑(Test milestone) 測試日期

軟體測試分類 測試分類方式 依測試方法分類 依測試過程分類 依程式狀態分類

測試分類方式 劃分方式不同，有以下分類 方法：黑箱、白箱、灰箱 過程：單元測試、整合測試、系統測試、驗收測試 程式狀態：靜態測試、動態測試

依測試方法分類 依測試方法大致分成三類: 白箱 黑箱 灰箱 測試人員直接在軟體程式上進行測試，這類測試包含了語法、邏輯、路徑等測試 只管Input與Output，主要以產品的功能為指標的測試方法 灰箱 介於白箱與黑箱之間的測試

依測試過程分類 過程包含4測試步驟： 單元測試 整合測試 系統測試 驗收測試

4測試步驟 單元測試 整合測試 整合測試 系統測試 驗收測試

V&V 驗證(Verification) 驗認(Validation) 主要用來確定軟體內所定義出來的功能有正確的被實現，而其所執行的功能皆完成 Are we building the product right? 單元測試、整合測試、系統測試 驗認(Validation) 確認所被實現的功能是否符合當初使用者所要求，解決使用者想解決的事 Are we build the right product? 驗收測試

V模型1 V模型特色 將測試表示成單一階段，分別為需求分析、高階設計、細部設計、程試寫作 V模型描述了數個不同的測試等級及每個層級的生命週期

V模型2 需求分析 驗收測試 結構設計 系統測試 細部設計 整合測試 程式寫作 單元測試

W模型 需求分析 驗收測試 需求測試 安裝系統 結構設計 建構系統 結構測試 系統測試 細部設計 設計測試 建構軟體 整合測試 程式寫作 單元測試

單元測試 低階測試 獨立測試 細節容易被看清楚 通常由程式設計師自行測試 又稱為元件測試、模組測試、程式測試

整合測試 多個單元測試 可用來測試無法單一測試的群組 單元間的溝通 非功能性觀點 測試策略 Top-down Bottom-up Functional

系統測試 系統測試是最後的整合步驟 功能性 非功能性 與功能性測試一樣重要 通常由測試人員進行測試 以功能或需求為基底做測試 商業流程為基底做測試 非功能性 與功能性測試一樣重要 通常不被重視 但此測試是必須被執行的 通常由測試人員進行測試

驗收測試 確認所被實現的功能是否符合當初使用者所要求，解決使用者想解決的事。

依程式狀態分類 依程式執行與否分類： 動態測試 測試執行中程式 靜態測試 (原始程式分析) 測試未執行的程式

動態測試1 單元測試(Unit test) 白箱測試(White box test) 黑箱測試(Black box test) 灰箱測試(Gray box test) 功能測試(Function test) 系統測試(System test)

動態測試2 驗收測試 (Acceptance test) Alpha版測試 (Alpha version test) Beta版測試 (Beta version test) 平台測試(Platform test) 回應測試(Response test) 壓力測試(Stress test) 自動測試 (Auto Test) 回復測試(Recovery Test)

靜態測試 1 靜態檢查 人工檢查

靜態測試 2 靜態檢查 資料類型檢查 錯誤路徑檢查 運算式檢查 語法檢查 函數檢查 邏輯檢查

靜態測試 3 人工檢查 桌前檢查(Desk Check) 同仁檢查(Peer Review) 走訪(Walkthroughs) 程式碼閱讀(Code reading)

結論 軟體測試是為了提早發現錯誤 軟體測試是為了提高軟體品質 驗收測試是為了確認軟體是否符合需求 好的測試與好的設計一樣重要

H模型 測試準備 執行測試 其它測試流程 測試過程 測試點

其他測試 修改後確認執行測試 確認修改後之程式有順利運作 錯誤應變度測試 使用非法輸入值測試程試錯誤應變度 存取度測試 Ad Hoc 測試