淺談 自動化測試 2021/2/25

你是否遇過以下問題 • 擔心害怕改 A 壞 B。 • 功能一直疊加測試不完。 • 想的與程式執行結果不一致，哪裡錯了？ • 系統越來越難改，改動牽一髮動全身。 • 系統可以正常運行，但不敢償還累積的技術債。 • 花費大量時間處理 BUGS。 • 無法測試（譬如串接 JCIC）。 • 平行開發，別人沒寫完我無法測試。

回到初心 • 是否曾經追求過程式品質？期望寫出易讀、好懂、職責分明、乾 淨無暇的程式碼。 • 匠人精神，提高自己設計能力，將程式提昇到藝術層次。 • 當有需求時，容易且快速的改動系統，持續交付價值，進而提昇 客戶滿意度。

自動化測試可以解決大部份問題！

實務流程常見問題 SA 與 PG 溝通困難 PG 開發的不是 SA 想要的 需求變更程式大改 看不懂規格書 程式改不動了 不知道要測試什麼？ 越後面要測試的項目越來越多 BUGS 很多頻繁被退件 這不是使用者要的功能 溝通不良

最大的問題在於溝通

自動化測試可以解決大部份問題！

什麼是測試程式？ 活文件 溝通 需求

自動化測試總類 GUI Tests Integration Tests Unit Tests Manual Tests

簡介單元測試 • 針對一個「工作單元」或是一個「使用案例」，驗證其具體最終 結果假設的正確性。 • 「單元」可以小到指包含一個方法（METHOD），也可以大到包 括實現某個功能的多個類別（CLASS）與函數（FUNCTION）。 • 環境（譬如網路、主機、資料庫…）相依性低。 • 執行速度快，通常一個測試個案執行時間小於 500 毫秒。

單元測試範例 清晰易懂的命名 簡單展現測試意圖

關於單元測試所展現意圖 • 讓測試程式像在跟你敘述需求情境。 • 測試程式是物件的使用說明書。 • 可執行的規格文件。 • 只留下必要資訊，適當的表達情境與意圖。

單元測試最終定義 • 一個單元測試是一段自動化的程式碼，這段程式會呼叫被測試的 工作單元，之後對這個單元的單一最終結果的某些假設或期望進 行驗證。 • 單元測試幾乎都是使用單元測試框架進行撰寫。 • 撰寫單元測試很容易，執行起來快速。 • 單元測試可靠、易讀、並且很容易維護。 • 只要產品程式碼不發生變化，單元測試的執行結果是穩定一致的。

簡介整合測試 • 對一個工作單元進行測試。 • 然而這個被測試的單元並沒有 完全控制。 • 意思是該單元一個或多個真實 依賴相依物件，例如時間、網 路、資料庫、執行緒、或亂數 產生器等等。 • 可在細分成以下幾種： • End to End Flow Tests • Workflow Tests • Biz Logic Acceptance Tests

簡介 GUI 測試 • 測試粒度最粗的測試。 • 模擬使用者操作畫面的步驟， 驗證程式是否如我們預期的和 使用者互動。 • 又稱為 End to End（E2E） Test，在網頁上又稱之為 Web Testing。

錄製 GUI 自動化測試 - DEMO • 簡單快速入門！

錄製 GUI 優缺點 優點 • Simple（簡單）：點擊錄製，進入 網頁，操作畫面，關閉錄製，選擇 驗證項目。 • Auto（自動）：錄製好的可以儲存 或匯出，可以一直重複播放錄製內 容。 • Fast（快速）：不管是錄製速度和 播放速度都很快。 • Export（匯出）：可以將錄製結果 轉成程式碼，複製貼到測試專案內， 版控進 CI 就能一直跑一直跑了。 缺點 • 無法錄製 IE Only 的網頁。 • Export 出來的程式碼很醜，不夠語 意化，每次調整畫面勢必要調整這 些很醜的程式碼，不好維護。

GUI 測試之自己寫 Code • Specification by Example - 使用 gherkin 語法撰寫測試個案

GUI 測試之自己寫 Code • 寫測試個案

GUI 測試之自己寫 Code • 套用 Page Object Pattern 讓測試程式更好閱讀

Living Documentation

整合 / GUI 測試存在意義 • 明明有了單元測試，為什麼還要整合測試或 GUI 測試呢？ • 每個單元都正常，不代表整合起來會正常。 • 減少團隊溝通問題。 • PO / SA 和開發人員雞同鴨講，沒有交集。 • PO / SA 和開發人員間花費太多時間溝通。 • 開發完才被告知「這不是使用者要的功能，不符合需求」。

整合 / GUI 測試存在意義 • 缺點： • 因高度相依於環境，執行速度慢。 • 若 GUI 是瀏覽器時，當瀏覽器版本更新，程式中操作瀏覽器的套件可能要 更新。 • 因測試顆粒粗，很大機率只能發現問題而無法詳細定位發生問題的位置。 • 若頁面頻繁改版，可以考慮不要使用 GUI 測試，整合測試就變成非常重要。 • 雖然有缺點，但還是要整合 / GUI 測試來保護我們系統。

三種測試總結 • Unit Tests（單元測試）：基於每個工作單元進行測試，顆粒最小， 有異常能馬上發現問題點。 • Integration Tests（整合測試）：用於模組間或各分層間的測試， 顆粒次粗。在有 Unit Tests 下，若 Integration Tests 異常代表夾 縫接合處有問題，或 Unit Tests 案例有缺漏，需馬上補上。 • End-to-End GUI Tests（端到端測試）：顆粒最粗的測試，串接 所有重要的流程，確保所有模組與分層串接上沒有問題。

關於自動化測試… 還有很多很多可以談

Test-Driven Development, TDD • TDD 意指測試優先開發，即為以下三個步驟循環。 • 撰寫一個會失敗的測試 • 撰寫符合測試預期的產品程式碼，以通過測試 • 重構程式碼

Test-Driven Development, TDD • 如果大家認同「需求 ＝ 測試」，先將需求用測試程式描述，驅動 設計與開發產品程式碼是很正常的作法。

早點發現問題，越能降低成本 1. Pair Programming 2. Continuous Integration 3. Test Driven Development

測試驅動開發實務流程

自動化測試導入/學習流程 • 基礎功 OOD 與 OOP。 • 先學單元測試。 • 再學 SOLID 原則與 Clean Code 與重構技巧。 • 然後學習 TDD。 • 最後學習 BDD。

若要選擇今天其中一樣內容優先導入 • 我選擇 Specification by Example。

常見問題 三個問題與一個觀念釐清

問題一：實務中三種測試程式所佔的比例？

問題二：誰寫測試程式？ • 單元測試：開發人員 • 整合測試 / End to End 測試：開發人員或 QA • Specification by Example：開發人員，SA / PO 輔助。

問題三：都沒時間開發了還要寫測試程式！ 習慣 TDD 模式後， 加上善用 IDE， 可以比傳統開發快。

觀念釐清：Checking vs. Testing • 已知的情境驗證稱之為 Checking，建議這種的寫成測試程式。讓 系統自動去驗證，不應該浪費人力反覆做這種驗證。 • 從未知中探索問題稱之為 Testing，全名為 Exploratory Testing （探索性測試），QA 應具備的技能。 • 一般探索性測試都會搭配 Recording Tool。 • 探索出的問題記得要回頭補上測試程式。

總結 什麼是測試程式呢？

測試程式 是需求與 Code 的橋樑 程式是照你寫的跑，不是照你想的跑。測試程式能確 保程式寫的和你想的一樣。

Thank you Q ＆ A

推薦書籍 • 單元測試的藝術, 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)