缺失測試 (Defect Testing) 測試程式讓系統的缺失呈現

目的 了解找出程式缺失錯誤(program faults)的技術 介紹介面測試(interface testing)的指導方針(guidelines) 了解物件導向測試的特定方法 了解支援測試用之CASE工具的原理

主題 缺失測試(defect testing) 整合測試(integration testing) 物件導向測試(object-oriented testing) 測試工作平台(testing workbench)

測試行程 (Testing Process) 元件測試(component testing) 測試獨立的程式元件 通常是元件開發者的責任(有時不適用於關鍵性系統(critical systems)) 根據發展者的經驗以導出測試 整合測試(integration testing) 測試元件群組整合而成的系統或子系統 獨立測試小組的責任 測試是根據系統規格而來

測試階段 (Testing Phases)

1. 缺失測試 (defect testing) 缺失測試的目的是發現程式內的缺失 一個成功的缺失測試是能讓程式執行異常(anomalous way) 測試展示缺失的存在，而非不存在

測試優先權 (Testing Priorities) 只有窮盡式的測試(exhaustive testing)可以展現程式沒有錯誤，然而窮盡式的測試是不可能達到的 測試應該實作系統的功能(capabilities)而非它的元件(components) 測試舊的功能(old capabilities)比測試新的功能(new capabilities)重要 測試典型的情況(typical situations)比臨界值案例(boundary value cases)重要

測試資料和測試案例 (Test Data and Test Cases) “輸入”是被設計用來測試系統 測試案例 若系統的操作(operation)是依據它的規格(specification)，藉著輸入資料到測試程式以產生預期的輸出結果

缺失測試行程 (Defect Testing Process)

1.1 黑盒測試 (Black-Box Testing) 程式測試案例(test cases)是依據系統規格 測試計劃可在軟體開發初期即開始

黑盒測試 (Black-Box Testing)

1.2 等價分類 (Equivalence Partitioning) 輸入資料與輸出結果通常屬於不同類別(different classes)，而一個類別中的所有成員都彼此相關(related) 每個類別都是一個等價分類，其中程式以等價的方式(equivalent way)對待每個類別成員(class member) 測試案例應該從各分類(partition)中被選取

等價分類 (Equivalence Partitioning)

等價分類 (Equivalence Partitioning) 系統輸入和輸出分類成等價集合(equivalence sets) 假設輸入是介於10,000到99,999的五位元整數(5-digit integer) 等價分類(equivalence partitions)為<10,000、10,000-99, 999和> 99,999 在這些集合邊界(boundary)選擇測試案例 9999, 10000, 99999, 100000

例子 一個程式規格指明可接受4~10個輸入，是大於10000的五位元整數

等價分類 (Equivalence Partition)

搜尋常式規格 (Search Routine Specification) procedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Pre-condition -- the array has at least one element T’FIRST <= T’LAST Post-condition -- the element is found and is referenced by L ( Found and T (L) = Key) or -- the element is not in the array ( not Found and not (exists i, T’FIRST <= i <= T’LAST, T (i) = Key ))

搜尋常式(Search Routine) -輸入分類(Input Partitions) 輸入符合(confirm)前條件(pre-condition) 輸入和前條件不相符 輸入的鍵值(key element)是陣列(array)的成員(member) 輸入的鍵值不是陣列的成員

測試指導方針(序列) (Testing Guidelines (Sequences)) 以只有單一值(single value)的序列(sequence)測試軟體 使用不同大小的序列(sequences of different sizes)測試不同的軟體 設計測試以對序列的首項、中間項及最後一項進行測試 測試長度為零的序列(sequences of zero length)

搜尋常式 (Search Routine) -輸入等價分類(Input Equiv. Partition)

1.3 結構測試 (Structural Testing) 有時稱作白盒測試(white-box testing) 依據程式結構(program structure)產生測試案例，對程式的了解可用來找出更多的測試案例 目標是實作程式中的所有敘述(exercise all program statements) ，而不是所有路徑組合(not all path combinations)

白盒測試 (White-Box Testing)

Binary Search (Java)

二元搜尋-等價分類 (Equiv. Partition) 滿足前條件，鍵值元素在陣列中 滿足前條件，鍵值元素不在陣列中 不滿足前條件，鍵值元素在陣列中 不滿足前條件，鍵值元素不在陣列中 輸入有單一個值的陣列 輸入有偶數個數值的陣列 輸入有奇數個數值的陣列

二元搜尋-等價分類 (Equiv. Partition)

二元搜尋-測試案例

1.4 路徑測試 (Path Testing) 確證程式中的每條路徑至少執行一次 路徑測試開始於一個程式流程圖(program flow graph)，流程圖以節點(node)代表程式決策(decision)和以弧(arc)代表控制流程(control flow) 在流程圖中條件式的敘述(statements with conditions)是用節點表示

程式流程圖 (Program Flow Graphs) 當作計算循環複雜度(cyclomatic complexity)的基礎 描述程式控制流程(program control flow)，每個分支(branch)表示分開的路徑，迴圈(loop)則用箭頭以及回到迴圈條件節點(loop condition node)來表示

循環複雜度 (Cyclomatic Complexity) 循環複雜度(cyclomatic complexity，簡稱CC) = E - N + p E = 圖中邊(edge)的數目 N = 圖中節點(node)的數目 p = 連通元件(connected components)的數目

循環複雜度(cyclomatic complexity) 測試所有控制敘述(control statement)的測試數目等於循環複雜度 循環複雜度等於程式中條件(conditions)的數目 雖然所有路徑都被執行， 但不會執行路徑的所有組合(all combinations of paths)

二元搜尋流程圖 (binary search flow graph)

獨立路徑 (Independent Path) 1, 2, 3, 8, 9 1, 2, 3, 4, 6, 7, 2 1, 2, 3, 4, 5, 7, 2 1, 2, 3, 4, 6, 7, 2, 8, 9 測試案例應包括能執行這些所有路徑 動態程式分析者(dynamic program analyser)可檢查哪些路徑被執行

2. 整合測試 (Integration Testing) 整合測試應是黑盒測試(black-box testing)，其中測試是從系統規格而來(derived) 主要的困難是很難發現錯誤的所在(localising error) 遞增式整合測試(incremental integration testing)可降低此問題

遞增式整合測試 (Incremental Integration Testing)

2.1 整合測試方法 由上而下(top-down)測試 由下而上(bottom-up)測試 事際上，大部份的整合包括這兩種策略的組合 從高層系統(high-level system)開始，並由上而下在適當位置由stubs取代獨立元件(individual components) 由下而上(bottom-up)測試 整合各階層(levels)的獨立元件，直到完成系統建立 事際上，大部份的整合包括這兩種策略的組合

由上而下測試 (Top-Down Testing)

由下而上測試 (Bottom-Up Testing)

測試方法 架構的確認(architectural validation) 系統展示(system demonstration) 由上而下的整合測試較易發現系統架構的錯誤 系統展示(system demonstration) 由上而下的整合測試允許在開發初期階段進行有限度的展示(limited demonstration)

測試實作(test implementation) 當搭配由下而上(bottom-up)整合測試(integration testing)時較易執行 測試觀察(test observation) 兩種架構(top-down bottom-up)都有問題，需要額外程式碼(extra code)以觀察測試(observe tests)

2.2 介面測試 (Interface Testing) 發生在模組或子系統整合以建立更大系統時 目的是偵測因介面錯誤(interface errors)或無效的介面假設(invalid assumptions about interfaces)而產生的錯誤 根據它們的介面定義物件(objects are defined by their interfaces)對物件導向發展特別重要

介面測試 (Interface Testing)

介面類型 (Interfaces Types) 參數介面(parameter interface) 資料從一個程序(procedure)傳(pass)到另一個程序 共享記憶體介面(shared memory interface) 程序之間共享記憶體區塊(block of memory) 程序介面(procedural interface) 子系統封裝(encapsulate)一組被其它子系統呼叫的程序 訊息傳遞介面(message passing interface) 子系統對其它子系統要求(request) 服務

介面錯誤 介面誤用(interface misuse) 元件(component)在呼叫其它元件時，在使用它的介面時產生錯誤，例如參數傳遞的順序錯誤 介面誤解(interface misunderstanding) 呼叫元件預期被呼叫元件的行為是錯的(assume the behavior of the called component which are incorrect) 時間錯誤(timing error) 被呼叫元件和呼叫元件用不同的速度運作(operate at different speeds)，以及存取到過時的資訊

介面測試指導方針 設計測試所傳給呼叫程序(called procedure)的參數，其值是選擇在它們範圍內的極值(extreme ends of their ranges) 總是以空指標(null pointers)測試指標參數(pointer parameters) 設計造成元件失敗的測試 在訊息傳遞系統使用壓力測試(stress testing) 在共享記憶體系統，以不同的順序啟動元件

2.3 壓力測試 (Stress Testing) 以超出系統最大的設計負荷(maximum design load)來執行系統，讓系統缺失在壓力下得以浮現 施加壓力給系統測試其故障行為(failure behavior)，系統不應該災難性的故障(fail catastrophically)，壓力測試檢測無法接受的服務或資料遺失 特別適用於分散式系統，當網路負載過重(overloaded)時，系統效能會呈現嚴重衰退(severe degradation)

3. 物件導向測試 (Object-Oriented Testing) 要測試的元件是物件類別，物件類別實化(instantiated)為物件 沒有明顯的所謂系統上層(“top” to the system)，而讓系統進行由上而下的整合及測試

測試層次 (Testing Level) 測試物件相關的操作(operations) 測試物件類別(object class) 測試合作物件(cooperating object)的叢集(cluster) 測試完整的物件導向系統

3.1 物件類別測試 (Object Class Testing) 對物件類別的完整測試涵蓋範圍(complete test coverage)包括 測試所有與物件相關的操作 設定(setting)和質問(interrogating)所有物件的屬性(attribute) 操作(exercise)物件所有可能的狀態(states) 當被測試的資訊無法局部化(localized) ，繼承(inheritance)使它更難設計物件類別測試(object class tests)

氣象台物件介面 (Weather Station Object Interface) 所有操作(operations)都需要測試案例 使用狀態模型(state model)識別測試的狀態轉變

測試序列(testing sequences)實例 關機(shutdown)→等待(waiting)→關機(shutdown) 等待(waiting)→校準(calibrating)→測試(testing)→傳 送(transmitting)→等待(waiting) 等待(waiting)→蒐集(collecting)→等待(waiting)→彙 整(summarising)→傳送(transmitting)→等待(waiting)

3.2 物件整合 (Object Integration) 叢集測試(cluster testing)是關於整合和測試合作物件(cooperating object)的叢集(cluster) 利用這些叢集實作之物件操作(operation of objects)和系統特色的知識辨識(identify)叢集

叢集測試的方式 使用案例(use-case)或情境模擬(scenario)測試 測試是根據使用者與系統之間的互動 根據使用者經驗(experienced by users)來測試系統特性 執行緒測試(thread testing) 以處理執行緒(process threads)的方式測試系統對事件(events)的回應(response) 物件互動測試(object interaction testing) 測試物件互動的序列(sequences of object interactions)，直至物件操作不再呼叫其他物件服務為止

情境為主的測試 (Scenario-Based Testing) 從案例(use-cases)及顯示在情境中之物件的互動圖(interaction diagram)辨識情境(scenario) 回顧在氣象台系統中，產生報告的情境

搜集氣象資訊

氣象台測試 方法執行緒(thread of methods executed) 輸入和輸出 CommsController:request → WeatherStation:report → WeatherData:summarise 輸入和輸出 輸入報告要求(report request)及最後報告的輸出 可藉由建立原始資料(raw data)，並確保它被適 當地彙整(summarized) 使用相同的原始資料(raw data)測試WeatherData 物件

4. 測試工作平台 (Testing Workbenches) 測試是個昂貴的行程階段，測試平台提供一系列工具降低所需時間和全部的測試成本

一個測試工作平台

測試工具 測試管理者(test manager) 測試資料產生器(test data generator) 預言(oracle) 管理程式測試的執行(running of program tests) 測試資料產生器(test data generator) 產生測試資料給被測試的程式 預言(oracle) 產生預期中的測試結果 檔案比較器(file comparator) 比較本次程式測試和之前程式測試結果，並回報它們之間的不同

報告產生器(report generator) 動態分析者(dynamic analyzer) 提供測試結果的報告定義和報告產生的工具 動態分析者(dynamic analyzer) 增加程式碼以計算每個敘述(statement)被執行的次數 模擬器(simulator) 目標模擬器(target simulators)模擬執行程式的機器

參考資料 Ian Sommerville, Software Engineering, 7th ed., Addison-Wesley，2004.