Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 17 Software Testing Strategies (High Order Testing (Validation…
Chapter 17 Software Testing Strategies
軟體測試
定義 : 把軟體交給客戶前，測試是否有錯誤
由誰來做
開發者 : 較了解系統，但test "gently" and, is driven by
delivery
獨立測試者 : 需學習系統，但will attempt to break it and, is driven by
quality
Verification vs Validation
Verification
: 確保程式有按照
設計
的要求進行實作 ("Are we building the product right?")
Validation
: 確保軟體有符合客戶的
需求
("Are we building the right product?")
Testing Strategy
項目
Unit test
Integration test
Validation test
System test
: 測試非功能性需求
說明
剛開始時
testing-in-the-small
，之後
testing-in-the-large
For 傳統軟體 : 最初focus on module(元件)，之後是模組的整合
For OO軟體 : 也是testing in the small，但是對象從模組變成class
Strategic Issues
根據產品需求建立量化指標
明確規定測試目標
充分了解軟體使用者，並替不同類的使用者建立profile
在進行測試前，先通過
formal technical reviews
為測試流程開發一個持續改進的方法
Unit Testing
(單元測試)
說明 : 每個單元測試會對應到一個元件或模組
Integration Testing
(整合測試)
策略
“big bang” approach : 把所有的元件、模組組合起來，進行測試
漸進式整合測試 : 小的小的開始測試，沒問題再合起來
整合方式
由上往下 : top module is tested with
stubs
，每次都更換一個stub(深度優先/廣度優先)。若有加入新模組，則有些測試子集要re-run
由下往上 : 把每個小模組合成cluser，每次都更換一個
driver
(深度優先)
三明治 : 上層模組tested with stubs，工作模組則 grouped into builds and integrated
Regression Testing
(回歸測試)
說明 : 在做整合測試時，若程式有改變，不能只跑新模組而已。必須要將有關的都重跑一遍
目標 : 確保進行修改後，沒有產生傳播性side effects
隨著整合測試進行(模組越多)，回歸測試所需的時間越多，為節省時間，僅執行重要的測試案例
Smoke Testing
(煙霧測試)
目的 : 發現錯誤，防止產生會導致計畫延遲的"show stopper" errors
說明 : 是一組用來確定系統處於穩定狀態、功能可正常運行的測試案例。主要用來確認新的程式碼有沒有問題。(幾乎每天都要執行)
Object-Oriented Testing
由於封裝，
unit
的概念改變了
整合focuses on 類別、類別的執行
使用傳統的
黑箱方法
進行驗證
類別測試等同單元測試
整合策略(3種)
thread-based testing : input或event會牽涉到哪些class，這些class就必須合起來一起測
use-based testing : 把與use-case有關的class合起來一起測
cluster testing : 彼此間有關係的物件類別合起來做整合測試
High Order Testing
Validation testing
: 軟體需求
System testing
: 系統整合
Alpha/Beta testing
: α給協力廠商，β給終端使用者
Recovery testing
: 故意設計案例讓系統發生錯誤，看錯誤影響會不會很大
Security testing
: 驗證系統不會受到駭客入侵
Stress testing
: 能否承受同意時間的大量請求
Performance Testing
: 系統效能是否夠快
Debugging
定義 : 了解什麼情況會引發什麼症狀
症狀與原因
原因與發生問題的地方可能離得很遠
另一個問題修好了，產新另一個新的問題
原本沒有錯，合起來就錯了
可能是系統或編譯器出錯
大家以為是對的的假設，其實是錯的
症狀可能是間歇性的
Debugging技巧
brute force / testing
backtracking
induction
deduction
Final Thoughts
不要貿然去改，應該要好好理解錯誤發生在何處
善用工具 (e.g. dynamic debugger)
如果陷入僵局，就去找人求救
在修正錯誤之後，務必進行回歸測試
軟體測試
白箱測試
說明 : 測試應用程式的內部結構或運作
目標 : 確認所有statements and conditions至少都有被執行一次
問題 : 窮舉太花時間，應找出獨立路徑(要會畫):star::star::star:
Cyclomatic Complexity
計算方法 : 畫流程圖 -> 計算cyclomatic complexity( 封閉區域數 + 1 )
迴圈複雜度越高，發生錯誤的機率越高
Deriving Test Cases
畫出對應的流程圖
決定迴圈的複雜程度
決定獨立路徑的basis set
黑箱測試
說明 : 測試應用程式的功能
定義 : 不考慮程式內部邏輯，專注於了解模組、元件是否符合需求
目標 : 找出錯誤的function、interface錯誤、起始即結束的錯誤等