首頁 物件導向軟體工程

# 物件導向軟體工程 - 軟體測試

# Software Testing Black-Box Testing Techniques 軟體黑箱測試技術

# Black-Box Testing 黑箱測試

  • 專注於測試軟體的功能性與行為
  • 認為類別的書與可以有效的檢查錯誤
  • 考慮到了輸入值常常導致問題
  • 認為輸入值得結合會影響系統運作

# Black-Box Testing Techniques 黑箱測試技巧

  • Equivalence partitioning 等價劃分
  • Boundary value analysis 邊界值分析
  • Cause-effect testing 原因影響測試

# Equivalence Partitioning 等價劃分

  • 假設 S = {a1,a2,…an} 是一組元素

  • R 屬於 SXS 是個等價關係

    • reflexive 相反: <ai,ai> 屬於 R
    • symmetric 對稱: <ai,aj> 屬於 R -> <aj,ai > 也屬於 R
    • transitive 遞轉: <ai,aj> 屬於 R 且 <aj,ak > 屬於 R -> <ai,ak > 也屬於 R

  • 等價劃分是黑箱測試的方法

  • 他區分輸入數值領域至不相干的子及

  • 測試案例可以是選擇的輸入值來自每個不同的子集

  • 基於相信值在等價會偵測相似的錯誤，因此一個測試足夠一個劃分

  • 他減少測試案例的總數

  • 等價劃分如同輸出領與是可應用的

  1. 假設輸入條件特別指定一個範圍，一個有效與兩個無效等價類別被定義
    • 範例：輸入條件為 0~100 等價別如下
    • 負整數
    • 0~100 的整數
    • 超過 100 的整數
  2. 假設輸入條件需要一個特定值，一個有效與兩個無效等價類別要被定義
    • 範例：期望輸入條件是 10
    • 有效劃分 10
    • 無效劃分有
      • 所有小於 10 的整數
      • 所有大於 10 的整數
  3. 假設輸入條件特定一組資料，一個有效與一個無效等價類被定義
    • 期望輸入條件是 SunOS
    • 有效等價類
    • 無效等價類 是所有的字串組合 - SunOS
  4. 假設條件是 Boolean 一個有效與一個無效等價類會被定義

# Boundary Value Analysis 邊界分析

  • 邊界分析是一個測試資料產生技術來完成等價劃分
  • 邊界分析導致被選擇的測試案例的劃分邊界
  • 邊架分析衍生來自輸出領域測試案例

# Cause-Effect Testing 原因影響測試

  • 分析功能性趣辨別原因與它們的影響
  • 決策表示建構表達原因與影響的關係
  • 決策表規則會被用來衍生測試案例

步驟:

  1. Causes 原因 (輸入條件) 與 effect 影響 (動作) 會列出一個模組與他們的辨識他們被相互委任
  2. 決策表或決策數是被由多組輸入組合到執行產生的
  3. 決策表規則會被轉變成測試案例 測試資料會被選擇所以表內每個規則都是作用中的。很明顯的假設有個決策表已經被用了是個設計工具，原因影響分析就不必要了。
  • 檢查完整性：案例總數必須等於所有可能的測試案例數量
  • 檢查一致性：沒有兩個規則有相同的條件組合但不同動作的

# Inspection And Testing

# Inspection
  • 靜態
  • 驗證技巧
  • 可以檢查編程標準符合性
  • 不能檢查滿足程度與非功能性需求
# Testing
  • 動態
  • 有效技巧
  • 不能檢查編程標準符合性
  • 可以檢查滿足程度與非功能性需求

# White-Box Test 白箱測試

  • Basis Path Testing
    • Flow Graph Notation
    • Cyclomatic Complexity
    • Deriving Test Cases
  • Condition Testing
  • Data Flow Testing
  • Loop Testing
  • Symbolic Execution

# Basis Path Testing Steps 測試步驟基本路徑

  • 建構一個流程圖
  • 計算循環複雜度
  • 決定基本路徑
  • 檢查確保基本路徑數等於循環複雜度
  • 衍生測試案例去執行基本路徑根據需求覆蓋限制

決定基本路徑

  • 計算測試案例需要執行所有基本路徑等於循環複雜度
  • 基本路徑是
    • 一個路徑從初始點到末點
    • 走訪循環不能是 0 次獲只有一次
  • 基本路徑是:
    • 開始，1,2,3,4,2,5,end
    • 開始，1,2,3,4,5,end
    • begin,1,2,5,end
# Flow Graph Notations 流程圖記號

# Cyclomatic Complexity 循環複雜度

三個方法去計算循環複雜度

  • 相近區域 + 1
  • 原子二元 謂詞 + 1
  • 邊界 - 節點號碼 + 2

# Condition Testing 條件測試

  • 專注於測試邏輯條件是

條件測試技巧

  • 分支測試 至少執行一次復合條件 C 和 C 中每個簡單條件的真假分支。
  • 領域測試
# Data Flow Testing 資料流測試
  • 選擇變數 可以是 計算用或是預測使用
  • 根據變量在程序中定義和使用的位置選擇程序的測試路徑，
  • 然後測試這些定義 - 使用鏈。 all-defines, all-uses, …—— 設計測試用例以滿足測試標準

# Loop Testing 迴圈測試

  • 4 種迴圈測試
    • 簡單迴圈：只有一個迴圈
    • 巢狀迴圈：迴圈裡面有迴圈
    • 串聯迴圈：迴圈之後有迴圈
    • 非結構化循環：複雜的巢狀和串聯循環
  1. 跳過迴圈
  2. 只走過一個迴圈
  3. 走過兩個迴圈
  4. m 次過迴圈 m < n
  5. n-1,n,n+1 走過迴圈
  • 變數可以處於以下狀態之一
    • d：定義、創建、初始化等
    • k：殺死、未定義、釋放
    • u：使用
      • ・c：計算使用
      • ・p：謂詞使用

Data Flow Anomalies 資料流程異常

有 9 個異常組合

  • buggy combination

    1. ku: using an undefined variable, a bug–possibly

  • anomal combinations
    2. dd: why define the variable twice? suspicious
    3. dk: why define the variable without using it, probably a bug
    4. kk: why kill a variable twice? suspicious

  • normal cases
    5-9. du, kd, ud, uk and uu

  • 讓 “-” 表示在動作之前或之後沒有發生任何感興趣的（d，k，u）。 有 6 種單字母情況：

    • 可能的異常情況・
      • -k：為什麼不對它做任何事情就殺死一個變量？・
      • -u：可能是異常的，除非變量是全局的並且之前已經定義了・
      • d-：可能是異常的，除非它是全局定義的或為其他例程定義的・
      • u-：可能表示未返回動態分配的存儲（內存洩漏）
    • 正常情況：
      • -d、k-
# Symbolic Evaluation 符號評估
  • 使用符號值而不是數值執行程序以按路徑驗證程序路徑。
  • 符號執行的結果是一組表示通過程序的路徑的邏輯表達式。
  • 每個邏輯表達式對應一個測試用例。
  • 約束求解器可用於導出測試數據 —— 滿足路徑條件的值。
  • 存在符號評估器軟件，也稱為符號執行器。
# Test Coverage 測試覆蓋率
  • 測試覆蓋率是品質目標
  • 範例
    • 100% 分支覆蓋 (要被完成)
    • 100% 分支覆蓋 (完成)
    • 100% 需求覆蓋 (要被完成如同完成)
# Usefulness of Generic Process 通用過程的用處
  • 促進了解測試方式因為測試方法遵從通用流程
  • 描述軟體測試步驟
  • 組織介紹與實做軟體測試指南

# Use Case Based Testing 基於用例的測試

步驟

  1. 使用需求 - 用例可追溯性矩陣對用例進行優先排序
  2. 從擴展的用例生成測試場景
  3. 識別測試用例
  4. 生成測試數據（值）
  5. 生成測試腳本

# Prioritizing Use Cases 對用例進行優先排序

  • 為甚麼要優先排序
    • 我們可能不需要資源或時間
    • 優先排序確保高優先度 Use Cases 會被測試
  • 需求用例可追溯性矩陣
    • 列為需求 欄為用例
    • 如果用例實現需求，則檢查條目
    • 底行總結了每個用例的優先級

# Generating Use Case Scenarios 建立用例場景

  • 場警示實例化的用例
  • 場警示實體泛例表示使用者將會使會使用系統
  • 用例有高優先級場景 (一般用例) 與很多個場景 (罕見或例外的情況)
  • 這步驟應該產生充足的場景組數讓測試用例使用

# Identifying Test Cases 識別測試用例

  • 識別測試用例從場景使用測試用例矩陣
    • 列 列出識別的測試用例
    • 欄 列出場景與使用者輸入變數與系統狀態變數與預期結果在每個場景之中
    • 每個條目是
      • V 指對於場景是有效變數
      • I 指對於場景是無效變數
      • N/A 指不可應用變數值在此場景

識別測試用資料

# Object State Testing 物件狀態測試

# ClassBench: Automating Class Testing ClassBench：自動化類測試

  • 是自動測試類別的框架
  • 可以用在單元測試與回歸測試
  • 測試模型是個有限的狀態機 (finite state machine,FSM)
  • 支援 ClassBench 的工具包含測試模型的編輯器，測試模型走訪與多種有用的類別
  • 已經用在測試集合類別
  • 測試基於回應的類別很有用 (相較其他 UI 類別)

# Test Driver 測試驅動

  • 測試驅動是個類別或是函式可以建造或初始化實例化的測試類別 / 元件 (Class/Component under test,CUT)
  • 初始化變數與參數
  • 調用測試類別 / 元件
  • 檢查實際結果正確性
  • 驅動也會使用當軟體需要與其他外部系統交流通常比存根複雜

測試順序是從最簡單的底層類別由下往上測試起

# Test Stub 測試存根

  • 測試存根是個類別或是程式，是未測試的替代品或是未實作的類別 / 元件且會被 CUT 在測試期間調用
  • 簡單與實作指需要功能能夠被測試 CUT
  • 大多測試存根是拋棄式軟體

測試順序從最複雜的頂類從上往下測試起

# Test Oracle 測試神諭

  • 測試神諭是個類別可以模擬 CUT 行為
  • 被用來檢查 CUT 結果
  • 簡化測試驅動
  • 有相同的 CUT 方法成員
  • 實作更見單且不需要與 CUT 相同充足
  • ClassBench 他只關照測試模組的狀態與變化
  • 不會發出警告訊號

What a Tester Needs to Do 測試者需要做甚麼

開發測試模型 > 開發測試神諭 > 開發測試驅動 > 執行測試

# Test Model 測試模型

  • 方向圖
    • 節點表示 CUT 狀態
    • 邊界表示狀態轉變
    • 起始點表達出使狀態
    • 節點會被標記成 CUT 狀態表示
    • 包含會被測試達成的狀態

Test Coverage Criteria 測試覆蓋限制

  • 節點覆蓋，包含在弧覆蓋中
  • 弧覆蓋，包含路徑覆蓋
  • 路徑覆蓋，很難或不可能去達成
  • ClassBench 建議用弧覆蓋

Generating Test Cases 建立測試用例

  • 測試用例是測試模型的方向路徑
  • 測試覆蓋率建議是 100% 邊界覆蓋

Improving Code Coverage 提升程式碼覆蓋率

  • 去增加程式碼覆蓋率，可以使用更複雜的測試模型

Testing Exceotion Behavior 測試例外行為

  • CUT 會拋出三種例外
    • 重複例外
    • 完成例外
    • 找不到例外
  • 客戶邊必須了解或處理它們
  • 測試 CUT 應該確保例外被正確的拋出

# Testing Inheritance Hierarchy 測試繼承階層架構

  • 類別中的函式可以分類成:
    • 一組或更新可以改變類別狀態函式
    • 取得函式可以回傳一些類別狀態方面
    • get+set 函式可以改變或回傳類別狀態
  • Note: get and set 在這並不是常見的存取函式，也可以叫 getter and setter
  • 當子類化的函式可以是
    • 一個新介紹成員函式
    • 重新定義成員的函式
    • 重複利用或未改變的成員函式是繼承父類別而來的
更新於