認識軟體測試的世界 &
TDD/BDD 入門
Wan-Ting Jheng
2015/4/28

為什麼需要軟體測試?
● 正確性、完整性、安全性和品質評量的依據
● 評量項目
○ 是否符合使用者需求
○ 元件/模組功能是否正常
○ 效能
○ UI/UX
○ 安全性
○ 邊界案例 boundary/edge case
○ 壓力測試
○ ...

軟體測試技術
● 白箱測試
○ 目的：測試軟體的內部邏輯結構
○ 已知程式內部結構情況下進行測試
○ 依程式邏輯設計測試案例
○ 衍生出 覆蓋率 (coverage) 議題
■ Function, Statement, Branch, …
● 黑箱測試
○ 目的：測試軟體功能
○ 給定輸入，對處理過程結構流程一無所知，預測輸出
○ 需根據規格設計測試案例

軟體測試階段
● 單元測試
○ 針對程式最小單元，隔離外部模組下進行測試
● 整合測試
○ 在單元模組整合組裝後，針對各模組之間的互動運作測試是否正常
● 系統測試
○ 在實際或模擬實際環境下，對系統進行全面的測試
● 驗收測試
○ 由使用者設計測試案例
○ 使用實際資料測試產品功能是否滿足使用者需求

程式實作
V-model
使用者需求
系統需求
架構設計
細節設計
驗收測試
系統測試
整合測試
單元測試

單元測試
● 單元指的是程式裡的最小單位，通常是函數
● 待測物與外部環境/類別/資源/服務獨立，不直接相依
○ 讓變因降到只有一個
○ 避免其它真實物件拉長執行時間
● 產品程式設計好壞會影響測試程式是否好寫
○ 程式設計要符合高聚合，低耦合原則
○ 元件只相依於介面或抽象類別
● 試想情境：登入帳號密碼驗證
✕ 在驗證方法裡，建立資料庫、加密物件
⇨ 設計不夠彈性，無法輕易擴充抽換，不易撰寫測試程式
✓ 透過建構子、公開屬性等手段，將驗證元件與資料庫、加密物件連接

假物件
● Collaborator：協作者，和待測物有互動關係的元件
● 在單元測試中，待測物須獨立不能與外界相依
● 建立假物件模擬協作者
○ stub
○ mock
● 請務必搭配 TDD/BDD 開發流程
若用傳統開發流程，即先開發再寫測試
API 可能設計不良，導致要寫一堆複雜的假物件
且程式重構時會牽一髮動全身，改不完

單元測試三步驟：3A Pattern
● Arrange
○ 預先作業，場地佈置
○ 安排要進行測試的資料，或準備要執行該測試所需的變數
● Act
○ 執行待測物方法
● Assert
○ 斷言，驗證執行結果是否符合預期
○ 例如 assert.equal(3, 1+2);

xUnit: 單元測試框架
● xUnit 是單元測試框架的統稱 題外話，雖然實際上也真的有一套叫xUnit
○ 用來幫助測試的一套工具庫
● x: 為變數之意，程式語言的泛稱
● 幾乎各大程式語言都有類似的測試框架
○ PhpUnit
○ Junit
○ JsUnit
○ ... 族繁不及備載
p.s. 一種語言可能有很多套框架，名稱不一定後綴unit，以上所列為效果舉例
ref. http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

TDD (Test-driven development)
● 一種程式開發的流程，而不是工具
● 它講究的是
○ 小步前進
○ 快速且持續回饋，擁抱變化
○ 重視溝通
○ 滿足需求

Red / Green / Refactor
一次只針對一個案例，持續重覆以下三步驟
● (Red) 依規格寫測試程式，跑一遍確定測試失敗
○ 千萬不要省略這步，也許會覺得有點蠢、沒意義
○ 在這一步去思考如何使用產品程式，有助於介面設計
● (Green) 寫產品程式，通過測試
○ 盡可能寫愈少的程式碼，以剛剛好通過測試為目標
○ 以確保不會有冗餘程式、過度設計
● (Refactor) 重構產品程式碼

ref. wiki/TDD

失敗
通過
重構
ref. wiki/TDD

TDD 幾件事
● 一般只針對具有功能性的程式作 TDD
○ 例如: lib、元件、模組
● 不要寫下任何一行沒有相對應測試程式的產品程式
● 不要省略 red 步驟，有可能一開始測就是綠燈...!?
○ 程式裡有同樣功能的程式 => 測試程式需寫的更完善
○ 沒有測到重點的測試程式 => 需改善
● 測式程式中不能有邏輯
● 不需要測試私有方法
● 接到 bug 通知，第一件事是先寫對應的測試案例

TDD 釋疑
許多剛接觸的人會有疑問...
● 誰要負責寫測試程式?
○ 由 API 開發者寫 => 開發工程師
● 寫程式的時間都不夠了，還要先寫測試程式?
○ 並不會造成額外的成本，只是將測試移到一開始做罷了
○ 而且可以減少未來測試/維護成本
● 功能複雜，元件關係糾纏不清，這樣可以寫單元測試嗎?
○ 這種情形更需要 TDD
○ 在開發前先透過測試程式，思考產品 API

BDD (Behavior-driven development)
● 產品程式是為了滿足使用者需求而存在
● 其實終端使用者對測試沒興趣...
● BDD 是基於 TDD 概念的進化版本
○ BDD 從實際需求去思考
○ TDD 從測試去思考程式如何實作
● 用自然語言描述測試案例
○ 使用者和工程師用同一種語言，避免溝通成本
○ 測試後的輸出結果可以直接做為文件閱讀

BDD 測試案例句型
● 需求描述
○ User story：[標題 描述故事的單行文字]
○ 身為一個 [角色]，我想要 [特定功能]，以便 [得到好處]
● 系統行為，一個需求會有一系列的場景來定義驗證標準
○ Scenario [#]：[標題 描述場景的單行文字]
■ Given [上下文]
■ When [事件]
■ Then [結果] and [其它結果]
在什麼前提、環境下
發生什麼事
預期有什麼樣的結果
Arrange
Act
Assert

● 需求描述
○ User story：[帳戶持有人要領錢]
○ 身為一個 [帳戶持有人]，我想要 [從atm領錢]，以便 [可以在銀行關門後領
到錢]
● 系統行為, 一個需求會有一系列的場景來定義驗證標準
○ Scenario [1]：[帳戶裡有足夠的錢，要給錢]
■ Given [帳戶餘額100] and [有效的領款卡] and [提款機夠錢]
■ When [帳戶持有人要求提20元]
■ Then [提款機應該給20] and [帳戶餘額80] and [退提款卡]
○ Scenario [2]：[帳戶裡沒有足夠的錢，要提示餘額不足]
■ Given [帳戶餘額100] and [有效的領款卡] and [提款機夠錢]
■ When [帳戶持有人要求提120元]
■ Then [提示餘額不足] and [退提款卡]

BDD 的一些慣例
● 一個元件配一隻測試程式，測試檔名後綴 spec
ex. 加法器元件 Adder.js 搭配 AdderSpec.js
● describe
○ # 純方法
○ . 類別成員方法

mocha http://mochajs.org
● javascript 測試框架
○ 支援 node.js
○ web client
● 在 node.js 環境使用方式
○ cmd：npm install -g mocha //npm 全域安裝 mocha
○ 測試程式放在專案目錄的 test 資料夾下
○ cmd：mocha //執行 test 資料夾下的程式

mocha 基本用法
● describe： 描術場景
● it：代表一個測試案例; ”它”應該如何...
● done(err, arg)
○ 在非同步測試案例上，向測試框架提示已完成
○ 用在花時間的測試上，如讀檔、DB連線
○ 預設兩秒以上為超時 透過 this.timeout(milliseconds) 調整

chai http://chaijs.com/api/
● 提供語意化的斷言庫
○ expect('string').to.be.a('string') //type check
○ expect('string').to.equal('bar') //value
○ expect('string').to.have.length(6)
○ ...

總結
● BDD
○ 有助於從呼叫者的角度對看程式
○ 進而設計出良好的介面
○ 以需求為導向的設計，
○ 語意化的測試案例，減少溝通成本
○ 測試結果即文件
○ 測試程式即範例
● 練習
○ CodeWars http://www.codewars.com/

Reference
《軟體測試專案實作：技術、流程與管理》筆記
http://w1a2d3s4q5e6.blogspot.tw/2012/11/blog-post_7.html
30天快速上手 TDD
https://msdn.microsoft.com/zh-tw/library/dn743856.aspx
自動化測試
https://ihower.tw/rails4/testing.html
初探行为驱动开发（Bdd）
http://www.slideshare.net/dualface/bdd-1068404
Testing in Node.js
http://code.tutsplus.com/tutorials/testing-in-nodejs--net-35018
程式設計師升級必練內功：TDD Kata
https://ihower.tw/blog/archives/8162