![BDD 測試案例句型
● 需求描述
○ User story：[標題 描述故事的單行文字]
○ 身為一個 [角色]，我想要 [特定功能]，以便 [得到好處]
● 系統行為，一個需求會有一系列的場景來定義驗證標準
○ Scenario [#]：[標題 描述場景的單行文字]
■ Given [上下文]
■ When [事件]
■ Then [結果] and [其它結果]
在什麼前提、環境下
發生什麼事
預期有什麼樣的結果
Arrange
Act
Assert](https://image.slidesharecdn.com/tdd-bdd-150429080530-conversion-gate01/85/TDD-BDD-17-320.jpg)
![● 需求描述
○ 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 [退提款卡]](https://image.slidesharecdn.com/tdd-bdd-150429080530-conversion-gate01/85/TDD-BDD-18-320.jpg)
認試軟體測試的世界 & TDD/BDD 入門
- 1. 認識軟體測試的世界 & TDD/BDD 入門 Wan-Ting Jheng 2015/4/28
- 2. 為什麼需要軟體測試? ● 正確性、完整性、安全性和品質評量的依據 ● 評量項目 ○ 是否符合使用者需求 ○ 元件/模組功能是否正常 ○ 效能 ○ UI/UX ○ 安全性 ○ 邊界案例 boundary/edge case ○ 壓力測試 ○ ...
- 3. 軟體測試技術 ● 白箱測試 ○ 目的：測試軟體的內部邏輯結構 ○ 已知程式內部結構情況下進行測試 ○ 依程式邏輯設計測試案例 ○ 衍生出 覆蓋率 (coverage) 議題 ■ Function, Statement, Branch, … ● 黑箱測試 ○ 目的：測試軟體功能 ○ 給定輸入，對處理過程結構流程一無所知，預測輸出 ○ 需根據規格設計測試案例
- 4. 軟體測試階段 ● 單元測試 ○ 針對程式最小單元，隔離外部模組下進行測試 ● 整合測試 ○ 在單元模組整合組裝後，針對各模組之間的互動運作測試是否正常 ● 系統測試 ○ 在實際或模擬實際環境下，對系統進行全面的測試 ● 驗收測試 ○ 由使用者設計測試案例 ○ 使用實際資料測試產品功能是否滿足使用者需求
- 6. 單元測試 ● 單元指的是程式裡的最小單位，通常是函數 ● 待測物與外部環境/類別/資源/服務獨立，不直接相依 ○ 讓變因降到只有一個 ○ 避免其它真實物件拉長執行時間 ● 產品程式設計好壞會影響測試程式是否好寫 ○ 程式設計要符合高聚合，低耦合原則 ○ 元件只相依於介面或抽象類別 ● 試想情境：登入帳號密碼驗證 ? 在驗證方法裡，建立資料庫、加密物件 ? 設計不夠彈性，無法輕易擴充抽換，不易撰寫測試程式 ? 透過建構子、公開屬性等手段，將驗證元件與資料庫、加密物件連接
- 7. 假物件 ● Collaborator：協作者，和待測物有互動關係的元件 ● 在單元測試中，待測物須獨立不能與外界相依 ● 建立假物件模擬協作者 ○ stub ○ mock ● 請務必搭配 TDD/BDD 開發流程 若用傳統開發流程，即先開發再寫測試 API 可能設計不良，導致要寫一堆複雜的假物件 且程式重構時會牽一髮動全身，改不完
- 8. 單元測試三步驟：3A Pattern ● Arrange ○ 預先作業，場地佈置 ○ 安排要進行測試的資料，或準備要執行該測試所需的變數 ● Act ○ 執行待測物方法 ● Assert ○ 斷言，驗證執行結果是否符合預期 ○ 例如 assert.equal(3, 1+2);
- 9. xUnit: 單元測試框架 ● xUnit 是單元測試框架的統稱 題外話，雖然實際上也真的有一套叫xUnit ○ 用來幫助測試的一套工具庫 ● x: 為變數之意，程式語言的泛稱 ● 幾乎各大程式語言都有類似的測試框架 ○ PhpUnit ○ Junit ○ JsUnit ○ ... 族繁不及備載 p.s. 一種語言可能有很多套框架，名稱不一定後綴unit，以上所列為效果舉例 ref. http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
- 10. TDD (Test-driven development) ● 一種程式開發的流程，而不是工具 ● 它講究的是 ○ 小步前進 ○ 快速且持續回饋，擁抱變化 ○ 重視溝通 ○ 滿足需求
- 11. Red / Green / Refactor 一次只針對一個案例，持續重覆以下三步驟 ● (Red) 依規格寫測試程式，跑一遍確定測試失敗 ○ 千萬不要省略這步，也許會覺得有點蠢、沒意義 ○ 在這一步去思考如何使用產品程式，有助於介面設計 ● (Green) 寫產品程式，通過測試 ○ 盡可能寫愈少的程式碼，以剛剛好通過測試為目標 ○ 以確保不會有冗餘程式、過度設計 ● (Refactor) 重構產品程式碼
- 12. ref. wiki/TDD
- 14. TDD 幾件事 ● 一般只針對具有功能性的程式作 TDD ○ 例如: lib、元件、模組 ● 不要寫下任何一行沒有相對應測試程式的產品程式 ● 不要省略 red 步驟，有可能一開始測就是綠燈...!? ○ 程式裡有同樣功能的程式 => 測試程式需寫的更完善 ○ 沒有測到重點的測試程式 => 需改善 ● 測式程式中不能有邏輯 ● 不需要測試私有方法 ● 接到 bug 通知，第一件事是先寫對應的測試案例
- 15. TDD 釋疑 許多剛接觸的人會有疑問... ● 誰要負責寫測試程式? ○ 由 API 開發者寫 => 開發工程師 ● 寫程式的時間都不夠了，還要先寫測試程式? ○ 並不會造成額外的成本，只是將測試移到一開始做罷了 ○ 而且可以減少未來測試/維護成本 ● 功能複雜，元件關係糾纏不清，這樣可以寫單元測試嗎? ○ 這種情形更需要 TDD ○ 在開發前先透過測試程式，思考產品 API
- 16. BDD (Behavior-driven development) ● 產品程式是為了滿足使用者需求而存在 ● 其實終端使用者對測試沒興趣... ● BDD 是基於 TDD 概念的進化版本 ○ BDD 從實際需求去思考 ○ TDD 從測試去思考程式如何實作 ● 用自然語言描述測試案例 ○ 使用者和工程師用同一種語言，避免溝通成本 ○ 測試後的輸出結果可以直接做為文件閱讀
- 17. BDD 測試案例句型 ● 需求描述 ○ User story：[標題 描述故事的單行文字] ○ 身為一個 [角色]，我想要 [特定功能]，以便 [得到好處] ● 系統行為，一個需求會有一系列的場景來定義驗證標準 ○ Scenario [#]：[標題 描述場景的單行文字] ■ Given [上下文] ■ When [事件] ■ Then [結果] and [其它結果] 在什麼前提、環境下 發生什麼事 預期有什麼樣的結果 Arrange Act Assert
- 18. ● 需求描述 ○ 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 [退提款卡]
- 19. BDD 的一些慣例 ● 一個元件配一隻測試程式，測試檔名後綴 spec ex. 加法器元件 Adder.js 搭配 AdderSpec.js ● describe ○ # 純方法 ○ . 類別成員方法
- 20. mocha http://mochajs.org ● javascript 測試框架 ○ 支援 node.js ○ web client ● 在 node.js 環境使用方式 ○ cmd：npm install -g mocha //npm 全域安裝 mocha ○ 測試程式放在專案目錄的 test 資料夾下 ○ cmd：mocha //執行 test 資料夾下的程式
- 21. mocha 基本用法 ● describe： 描術場景 ● it：代表一個測試案例; ”它”應該如何... ● done(err, arg) ○ 在非同步測試案例上，向測試框架提示已完成 ○ 用在花時間的測試上，如讀檔、DB連線 ○ 預設兩秒以上為超時 透過 this.timeout(milliseconds) 調整
- 22. 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) ○ ...
- 23. 總結 ● BDD ○ 有助於從呼叫者的角度對看程式 ○ 進而設計出良好的介面 ○ 以需求為導向的設計， ○ 語意化的測試案例，減少溝通成本 ○ 測試結果即文件 ○ 測試程式即範例 ● 練習 ○ CodeWars http://www.codewars.com/
- 24. 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