軟體測試概念
軟體測試的目的 測試定義 測試目的 以一套系統方法執行與檢查軟體，以發現錯誤。 發現軟體錯誤並進而修改軟體，以提昇軟體品質，避免錯誤造成嚴重損失。 花費最小精力及時間設計能發現最多錯誤的測試。
軟體測試的目的 越早發現軟體問題，開發費用越低 軟體品質越高，軟體發行後的維護費用越低。 軟體開始規畫時即應考慮測試的規畫時程及人力。 測試花費，占整個軟體發展工作至少30%以上時間及成本。 需求分析與設計發生錯誤約占65%，程式撰寫約占35% 早期觀點：Analysis Design Building Testing 現在觀點：Analysis, Design, Building, Maintenance，全程Testing
軟體測試的應用 軟體測試的應用主要有以下兩種： 驗證（verification）： 檢驗某個階段的產品發展是否符合其早先的規範，亦即正確地建造產品。 確認（validation）： 檢驗某個開發完成的系統是否符合用戶的需求，亦即建造對的產品。
軟體測試基本步驟 準備測試軟體 制定測試方案 編寫測試計劃 設計測試案例 進行測試 測試記錄 資料收集與整理
軟體測試V模型
軟體測試V模型 啟始概念 維護階段 計劃 開始 產品逐 步淘汰 需求分析 再改進 評估與簽訂合約 細部需 求規格 驗收測試與交貨 可交付項目 的驗收測試 需求規格 已驗證的系統 結構設計 系統整合與測試 品 質 保 證 品 質 保 證 已測試軟體 設計規格 整合的軟體 細部軟體設計 整合軟體與測試 已測 試的 模組規格 軟體 已除錯的模組 模組 撰寫程式及單元測試 計劃管理
軟體錯誤分類 功能錯誤：程式功能與使用者的需求不一致 系統錯誤：系統資源分配錯誤 語法錯誤：打字錯誤、指令誤用 資料錯誤：資料型態錯誤 處理錯誤：算術運算錯誤、邏輯錯誤
軟體測試方法 靜態分析(Static Analysis) 動態測試 靜態分析 不直接執行受測軟體，以人工或自動化方法評估軟體是否滿足規範 分為審查與檢視方法。 規範技術複審、文件複審、資料庫複審、演算法分析審查。
靜態分析優點 降低專案整體成本。 超過一半的軟體錯誤發生在需求或設計規格錯誤，審查與檢視可以在程式撰寫前發現錯誤，早期發現問題，可降低除錯與重測成本。 Defect distribution Relative cost to fix Requirements 57% X Design 27% X*10 Coding 7% X*100 Others 9% X*1000
靜態分析優點 靜態分析比動態測試有效率(1/3) 動態測試 清楚發現錯誤所在及原因，不需經過繁複鑑定錯誤、分析原因、修改與重測，可迅速修正錯誤。 有效找出規格模糊、程式撰寫風格錯誤、不合規定程式、與無效程式段落等動態測試難以發現之問題。 審查與檢視透過小組討論可以有效交換成員觀念與想法，協助經驗傳承與訓練溝通。 動態測試 須從系統非預期的行為、或錯誤結果推斷錯誤程式碼。 必須花許多時間診斷。
動態測試 程式開發後進行，執行軟體程式碼。 功能測試、性能測試。 檢查軟體界面及內部機制正確性。 分三種方式： 黑箱測試 只管輸入與輸出，主要以產品的功能為指標的測試方法。 白箱測試 測試人員直接在軟體程式上進行測試，這類測試包含了語法、邏輯、路徑等測試。 灰箱測試 介於白箱與黑箱之間的測試。
軟體動態測試程序 需求 驗收測試 系統測試 系統測試 設計 整合測試 程式 撰寫 單元 測試 測試方向
軟體動態測試程序 測試階段 各階段由不同人員及方法執行，以避免盲點。 各階段的工作執行時機各不相同，應以時程安排、及人力考量作適度的調整。 單元測試、整合測試、系統測試、驗收測試 各階段由不同人員及方法執行，以避免盲點。 各階段的工作執行時機各不相同，應以時程安排、及人力考量作適度的調整。 為使問題簡單化，使測試時可集中工作焦點，因此將測試工作分成數個階段
單元測試 低階測試 獨立測試 細節容易被看清楚 通常由程式設計師自行測試 又稱為元件測試、模組測試、程式測試
整合測試 多個單元測試 可用來測試無法單一測試的群組 單元間的溝通 非功能性觀點 測試策略 Top-down Bottom-up Functional
系統測試 系統測試是最後的整合步驟 功能性 非功能性 與功能性測試一樣重要 通常由測試人員進行測試 以功能或需求為基底做測試 商業流程為基底做測試 非功能性 與功能性測試一樣重要 通常不被重視 但此測試是必須被執行的 通常由測試人員進行測試
驗收測試 確認所被實現的功能是否符合當初使用者所要求，解決使用者想解決的事。