(一)、測試方法的分類

1. 靜態測試方法
   • 不執行程式的測試方法
   • 主要用於測試文件跟程式碼(檔案)
2. 動態測試方法 - 通過運行程式來發現缺陷的測試方法
   • 黑箱測試
     • 又稱為功能測試、數據驅動測試、基於規格說明書測試。
     • 從使用者觀點出發，主要以軟體規格說明書為依據，對功能和API進行測試，對輸入輸出數據之間的對應關係進行測試。
     • 不涉及內部結構，如果外部特性或規格有問題，則無法察覺
       • 安全性測試、可交互運行性測試也屬於功能測試
       • 方法如大綱法、場景法、等價類、邊界值、決策表、錯誤猜測等
     • 黑箱測試還用於測試軟體的非功能性特性。
       • 非功能性測試用於測試系統運行的如何，包含但不限於：
         • 可用性、可靠性、穩定性、健壯性、可恢復性測試
         • 可維護性測試
         • 易用性測試
         • 兼容性測試
         • 配置測試
         • 文件測試
         • 國際化測試、本地化測試
       • 當不涉及程式內部結構時，上述測試類型也使用黑箱測試
   • 白箱測試
     • 又稱結構測試、邏輯驅動測試、基於程式本身的測試、工程師測試。
     • 結構測試需要完全了解程式結構和處理過程，按照程式內部邏輯測試程式，檢驗程式中每條通路是否按照預定要求工作。
   • 黑箱測試與白箱測試的差別

(二)、靜態測試方法

1. 評審
   1. 評審是什麼?
      • 評審的含義
        • 對產品進行靜態檢查，以確定與計畫結果所存在的誤差，並提供改進建議。
        • 定義多個腳色和一個包括評審會議(review meeting)在內的基本評審過程
        • 評審(review)和審查(inspection)既是各類團隊測試的通用概念，又是指某一特定類型的檢查！
        • 與動態測試相反，評審活動能夠在缺陷成為缺陷前，發現這些缺陷。
      • 評審過程
        • 評審組對選擇的評審對對象進行審查和討論(如：需求規格說明書、系統設計、程式碼、用戶手冊、網頁、測試策略、測試計畫、測試規範說明書、測試腳本)
      • 評審目的
        • 在評審過程中發現評審對象的錯誤、缺漏、不精確處，也包含了維護的不完善和API的錯誤描述等
        • 查找與需求、指南、標準或規定的不符之處
        • 評審的目的不僅僅在於解決問題，而是發現問題
   2. 評審的角色有哪些?
      • 通常有：經理、主持人、作者(寫程式碼的人)、評審員、紀錄員、評審對象(要被評的文件)
      • 評審通常是同行評審(peer review)，也就是在同級人員間進行
   3. 評審的分類
      • 文件審查
      • 程式碼審查
      • 程式碼走查
   4. 程式碼審查
      1. 程式碼審查的含義、過程和目的
         • 定義
           • 一種同級評審，通過檢查文件以檢測缺陷，例如不符合開發標準，不符合更上層的文件。這是最正式的評審技術，因此總是基於文件化的過程[IEEE 610,IEEE 1028]
         • 特性
           • 最正式的評審活動
           • 由接受過專門培訓的主持人(不是作者本人)來領導
           • 通常是同行檢查
           • 定義了不同角色
           • 引入了度量
           • 根據入口、出口規則的檢查列表和規則定義正式的評審過程
           • 會議前需要進行準備
           • 出具審查報告和發現問題列表
           • 正式的追蹤過程
           • 允許審查過程的改進和讀者
         • 主要目的
           • 發現缺陷
      2. 程式碼審查的方法和範圍
         • 具體作法方法 - 互查
         • 通常合格的程式碼應該具備正確性、清晰性、規範性、一致性和高效性，概括起來涵蓋下列方面：
           • 業務邏輯的審查
           • 算法的效率
           • 程式碼風格
           • 編程規則
   5. 程式碼走查
      • 定義：由文件作者逐步陳述文件內容，以收集訊息並對內容達成共識[Frredman 和 Weinberg, IEEE1028]
      • 特性：
        • 由作者主持開會
        • 以情境、掩飾的行是和同行參加的方式進行
        • 開放式模式
        • 評審會議之前的準備、評審報告、發現的問題清單和紀錄員(非作者)都是可選的(ps.如果嚴格按照IEEE 1028的要求，準備工作是必須的)
        • 實際情形中可以是非常正式或非常不正式的
      • 主要目的：學習、增加理解、發現缺陷
      • 優點
        • 參加評審的人員準備工作較少
        • 可臨時召集
      • 缺點
        • 參加者必須對相關資料熟悉
        • 會議比一般評審費時(open end)
        • 錯誤或其他問題可能會被忽略