淺談自動化測試

開發過程中常遇見需求溝通或理解不一致等問題，或每次要手動測試全部功能。自動化測試可以幫你解決這些問題。
本次簡述自動化測試，了解基本觀念。

Transcript

1. 淺談 自動化測試 2021/2/25
2. 你是否遇過以下問題 • 擔心害怕改 A 壞 B。 • 功能一直疊加測試不完。 • 想的與程式執行結果不一致，哪裡錯了？ • 系統越來越難改，改動牽一髮動全身。 • 系統可以正常運行，但不敢償還累積的技術債。 • 花費大量時間處理 BUGS。 • 無法測試（譬如串接 JCIC）。 • 平行開發，別人沒寫完我無法測試。
3. 回到初心 • 是否曾經追求過程式品質？期望寫出易讀、好懂、職責分明、乾 淨無暇的程式碼。 • 匠人精神，提高自己設計能力，將程式提昇到藝術層次。 • 當有需求時，容易且快速的改動系統，持續交付價值，進而提昇 客戶滿意度。
4. 自動化測試可以解決大部份問題！
5. 實務流程常見問題 SA 與 PG 溝通困難 PG 開發的不是 SA 想要的 需求變更程式大改 看不懂規格書 程式改不動了 不知道要測試什麼？ 越後面要測試的項目越來越多 BUGS 很多頻繁被退件 這不是使用者要的功能 溝通不良
6. 最大的問題在於溝通
7. 自動化測試可以解決大部份問題！
8. 什麼是測試程式？ 活文件 溝通 需求
9. 自動化測試總類 GUI Tests Integration Tests Unit Tests Manual Tests
10. 簡介單元測試 • 針對一個「工作單元」或是一個「使用案例」，驗證其具體最終 結果假設的正確性。 • 「單元」可以小到指包含一個方法（METHOD），也可以大到包 括實現某個功能的多個類別（CLASS）與函數（FUNCTION）。 • 環境（譬如網路、主機、資料庫…）相依性低。 • 執行速度快，通常一個測試個案執行時間小於 500 毫秒。
11. 單元測試範例 清晰易懂的命名 簡單展現測試意圖
12. 關於單元測試所展現意圖 • 讓測試程式像在跟你敘述需求情境。 • 測試程式是物件的使用說明書。 • 可執行的規格文件。 • 只留下必要資訊，適當的表達情境與意圖。
13. 單元測試最終定義 • 一個單元測試是一段自動化的程式碼，這段程式會呼叫被測試的 工作單元，之後對這個單元的單一最終結果的某些假設或期望進 行驗證。 • 單元測試幾乎都是使用單元測試框架進行撰寫。 • 撰寫單元測試很容易，執行起來快速。 • 單元測試可靠、易讀、並且很容易維護。 • 只要產品程式碼不發生變化，單元測試的執行結果是穩定一致的。
14. 簡介整合測試 • 對一個工作單元進行測試。 • 然而這個被測試的單元並沒有 完全控制。 • 意思是該單元一個或多個真實 依賴相依物件，例如時間、網 路、資料庫、執行緒、或亂數 產生器等等。 • 可在細分成以下幾種： • End to End Flow Tests • Workflow Tests • Biz Logic Acceptance Tests
15. 簡介 GUI 測試 • 測試粒度最粗的測試。 • 模擬使用者操作畫面的步驟， 驗證程式是否如我們預期的和 使用者互動。 • 又稱為 End to End（E2E） Test，在網頁上又稱之為 Web Testing。
16. 錄製 GUI 自動化測試 - DEMO • 簡單快速入門！
17. 錄製 GUI 優缺點 優點 • Simple（簡單）：點擊錄製，進入 網頁，操作畫面，關閉錄製，選擇 驗證項目。 • Auto（自動）：錄製好的可以儲存 或匯出，可以一直重複播放錄製內 容。 • Fast（快速）：不管是錄製速度和 播放速度都很快。 • Export（匯出）：可以將錄製結果 轉成程式碼，複製貼到測試專案內， 版控進 CI 就能一直跑一直跑了。 缺點 • 無法錄製 IE Only 的網頁。 • Export 出來的程式碼很醜，不夠語 意化，每次調整畫面勢必要調整這 些很醜的程式碼，不好維護。
18. GUI 測試之自己寫 Code • Specification by Example - 使用 gherkin 語法撰寫測試個案
19. GUI 測試之自己寫 Code • 寫測試個案
20. GUI 測試之自己寫 Code • 套用 Page Object Pattern 讓測試程式更好閱讀
21. Living Documentation
22. 整合 / GUI 測試存在意義 • 明明有了單元測試，為什麼還要整合測試或 GUI 測試呢？ • 每個單元都正常，不代表整合起來會正常。 • 減少團隊溝通問題。 • PO / SA 和開發人員雞同鴨講，沒有交集。 • PO / SA 和開發人員間花費太多時間溝通。 • 開發完才被告知「這不是使用者要的功能，不符合需求」。
23. 整合 / GUI 測試存在意義 • 缺點： • 因高度相依於環境，執行速度慢。 • 若 GUI 是瀏覽器時，當瀏覽器版本更新，程式中操作瀏覽器的套件可能要 更新。 • 因測試顆粒粗，很大機率只能發現問題而無法詳細定位發生問題的位置。 • 若頁面頻繁改版，可以考慮不要使用 GUI 測試，整合測試就變成非常重要。 • 雖然有缺點，但還是要整合 / GUI 測試來保護我們系統。
24. 三種測試總結 • Unit Tests（單元測試）：基於每個工作單元進行測試，顆粒最小， 有異常能馬上發現問題點。 • Integration Tests（整合測試）：用於模組間或各分層間的測試， 顆粒次粗。在有 Unit Tests 下，若 Integration Tests 異常代表夾 縫接合處有問題，或 Unit Tests 案例有缺漏，需馬上補上。 • End-to-End GUI Tests（端到端測試）：顆粒最粗的測試，串接 所有重要的流程，確保所有模組與分層串接上沒有問題。
25. 關於自動化測試… 還有很多很多可以談
26. Test-Driven Development, TDD • TDD 意指測試優先開發，即為以下三個步驟循環。 • 撰寫一個會失敗的測試 • 撰寫符合測試預期的產品程式碼，以通過測試 • 重構程式碼
27. Test-Driven Development, TDD • 如果大家認同「需求 ＝ 測試」，先將需求用測試程式描述，驅動 設計與開發產品程式碼是很正常的作法。
28. 早點發現問題，越能降低成本 1. Pair Programming 2. Continuous Integration 3. Test Driven Development
29. 測試驅動開發實務流程
30. 自動化測試導入/學習流程 • 基礎功 OOD 與 OOP。 • 先學單元測試。 • 再學 SOLID 原則與 Clean Code 與重構技巧。 • 然後學習 TDD。 • 最後學習 BDD。
31. 若要選擇今天其中一樣內容優先導入 • 我選擇 Specification by Example。
32. 常見問題 三個問題與一個觀念釐清
33. 問題一：實務中三種測試程式所佔的比例？
34. 問題二：誰寫測試程式？ • 單元測試：開發人員 • 整合測試 / End to End 測試：開發人員或 QA • Specification by Example：開發人員，SA / PO 輔助。
35. 問題三：都沒時間開發了還要寫測試程式！ 習慣 TDD 模式後， 加上善用 IDE， 可以比傳統開發快。
36. 觀念釐清：Checking vs. Testing • 已知的情境驗證稱之為 Checking，建議這種的寫成測試程式。讓 系統自動去驗證，不應該浪費人力反覆做這種驗證。 • 從未知中探索問題稱之為 Testing，全名為 Exploratory Testing （探索性測試），QA 應具備的技能。 • 一般探索性測試都會搭配 Recording Tool。 • 探索出的問題記得要回頭補上測試程式。
37. 總結 什麼是測試程式呢？
38. 測試程式 是需求與 Code 的橋樑 程式是照你寫的跑，不是照你想的跑。測試程式能確 保程式寫的和你想的一樣。
39. Thank you Q ＆ A
40. 推薦書籍 • 單元測試的藝術, 2/e (The Art of Unit Testing: with examples in C#, 2/e) • 無瑕的程式碼－敏捷軟體開發技巧守則 (Clean Code: A Handbook of Agile Software Craftsmanship) • 無瑕的程式碼－敏捷完整篇－物件導向原則、設計模式與 C#實踐 (Agile principles, patterns, and practices in C#) • Specification by Example 中文版：團隊如何交付正確的軟體 (Specification by Example: How Successful Teams Deliver the Right Software) • Working Effectively with Legacy Code : 管理、修改、重構遺留程式碼的藝術 (中文版) • 重構｜改善既有程式的設計, 2/e (繁中平裝版)(Refactoring: Improving The Design of Existing Code, 2/e) • Kent Beck 的測試驅動開發：案例導向的逐步解決之道 (Test-Driven Development: By Example)(TDD)