從零打造測試自動化：TAU 課程完整筆記

從零打造測試自動化：TAU 課程完整筆記 學了幾年自動化，一直是「需要什麼就學什麼」的被動模式。直到最近在 Test Automation University 上完 Angie Jones 的 Setting a Foundation for Successful Test Automation 這門課，才第一次把腦袋裡零散的概念整理成一套完整的思考框架。 這篇是我邊看邊記的筆記，加上自己的理解和工作經驗，希望對正在思考「要怎麼推動自動化」的 QA 有些幫助。 課程概覽 課程名稱 ：Setting a Foundation for Successful Test Automation 講師 ：Angie Jones（前 Twitter 自動化主管，現任 Block 首席 QA 工程師） 平台 ：Test Automation University（免費） 時長 ：約 47 分鐘 ／ 7 章節 Chapter 1：先想清楚「為什麼」 很多團隊的自動化失敗，不是因為工具選錯，而是根本沒想清楚為什麼要做自動化。 Angie 提出三個問題，開始之前一定要回答： What — 目標是什麼？ 常見的合理目標包括： 縮短回歸測試時間，讓測試人員能專注在新功能 減少 sprint 技術債，邊開發邊自動化 讓 CI pipeline 能持續驗證，每次 commit 都有信心 但有一個目標絕對是錯的： 「解決所有品質問題」 。自動化不是萬能藥。 最重要的是： 目標要說出來、讓整個團隊都知道 。所有後續的決策——誰來寫、選什麼工具、哪些測試要自動化——都應該對齊這個目標。 Who — 誰來做？ 這是我覺得最現實也最痛的部分。 Angie 直說： 測試自動化本身就是一個軟體開發專案 ，需要時間和技能。如果你把它當成開發或測試的「副業」，它就會失敗。 幾個選項的分析： 讓開發者寫？他們有時間嗎？ 讓手動測試者轉型？學習曲線和時間成本是否現實？ 聘專職自動化工程師？最理想，但也要讓他融入團隊，而不是孤立的外包角色 無論選哪條路，一定要記得： 自動化工程是全職工作，不是空閒時間才做的事 。 How — 如何執行？ 測試要跑幾次、在哪裡跑、誰負責 triage？ Angie 建議漸進式： 1. 先在本機跑，手動匯報結果（培養信任） 2. 搬到獨立的 CI job，大家看得到但不影響開發流程 3. 最後才整合進開發的 CI，成為 check in gate 千萬不要一開始就把不穩定的測試放進 CI gate ，這會讓開發者失去信任，然後整個自動化項目死亡。 Chapter 2：建立支持自動化的文化 策略定好了，還不夠。組織文化若不支持，一切都是空談。 Product Owner / BA 的角色 他們最清楚哪些功能有業務價值，因此也最清楚 哪些測試值得自動化、哪些不值得 。如果 PO 真的理解自動化的價值，他甚至會把「修復自動化測試」排進 backlog、和功能開發一起優先排序。我看過這樣的 PO，那個團隊的自動化健康程度真的很不一樣。 開發者的角色 開發者是自動化的最大受益者，因為有穩定的回歸測試，他們改 code 更有底氣。但他們也需要貢獻： 寫 unit tests 確保新功能對自動化友善（Testability） 自己造成的測試 failure，自己去 triage 測試者的角色 這點 Angie 說得很直白： 自動化不是要取代測試人員 。探索性測試、複雜場景、發現高價值 bug，這些都還是人做的。 自動化是測試人員的助手，不是威脅。如果組織裡有人覺得「自動化會讓測試師失業」，需要主動澄清這個誤解。 Chapter 3：讓應用程式「好測」 就算你的測試 code 寫得再好，如果應用程式本身不好測，也很難寫出穩定的自動化。 測試自動化金字塔 這是 Mike Cohn 提出的概念，Angie 在這裡解釋得很清楚： 原則很簡單： 盡量在最靠近 code 的層面寫測試 。不要每個測試都走完整的 UI 流程。 一個實際例子：驗證「加入購物車」功能。 錯誤做法：每次都從搜尋商品→點擊→加入購物車→驗證，全部走 UI 正確做法：直接開啟商品頁 URL（code seam），跳過搜尋，減少不必要的依賴 Code Seams — 測試的快捷方式 Seam（接縫）是指繞過 UI、直接觸及應用邏輯的方式。例如： 直接用 URL 導航到特定頁面 呼叫 API 預先建立測試資料 直接呼叫 business function 開發者可以主動提供這些接縫，這是他們對自動化最有價值的貢獻之一。 UI 元素識別碼 很多 flaky test 的根本原因： HTML 元素沒有穩定的 ID 或測試專用屬性 。 解法： 和前端開發者約定，所有互動元素必須有 data testid 屬性 加進 code review checklist 甚至用 linter 強制檢查 這件事如果沒有變成文化，就會一直靠測試人員事後補，效率極差。 Chapter 4：選對工具 工具的選擇要根據 使用者是誰 來決定，而不是根據「最流行」。 沒有工程師資源時 考慮 codeless 工具（Selenium IDE、Katalon 等）。雖然不需要寫 code，但 triage 和維護依然需要人力。 有工程師資源時 選 coded solution，靈活度和可維護性高得多。 基本需求 每個自動化專案至少需要： 1. 互動工具 ：能和應用程式互動（Selenium、Playwright、Appium...） 2. 驗證工具 ：讓 code 能 pass 或 fail（JUnit、pytest、Jest...） 進階需求（視情況加）： 報告工具（含截圖、影片） Gherkin / BDD 整合 CI 整合 選工具時要考慮：支援的語言、招聘難易度、社群活躍度、目標瀏覽器和裝置的相容性。 Chapter 5：為未來預做準備 很多團隊在測試數量還少的時候，沒有注意到設計問題。等到測試增長到幾百個，才發現當初的架構讓人抓狂。 平行執行 如果測試只能一個一個跑，500 個測試要跑很久。想要平行執行，測試本身必須： 互相獨立 ，不能有執行順序的依賴 不共享可變的測試資料 避免 static/global 變數 （thread safe） Clean Code 測試 code 也是 code，一樣要避免： 重複 code 過長的 class 和 method 硬等待（sleep(3000)） 設計模式 值得了解的模式： Page Object Model ：最常見，把頁面元素封裝成 class Screenplay Pattern ：以使用者行為為中心 Builder / Factory ：靈活建立測試資料 Singleton ：管理 driver 等共享資源 不需要全用，但要知道它們的存在，在需要時知道去哪裡找解法。 Chapter 6：擴展自動化的邊界 本機跑得很好，不等於可以直接上 production。 多環境 不同環境有不同的 URL、帳密、資料庫。解法：用 properties file 或環境變數管理環境設定，不要 hardcode。 跨瀏覽器 自動化的優勢之一就是可以在多個瀏覽器重複執行。但要評估：是自己維護瀏覽器矩陣，還是用 Browserstack / Sauce Labs 等雲端服務？ 多裝置 RWD 頁面：UI 元素可能在手機版不一樣，測試 code 要能處理 Native App：iOS 和 Android 可能是不同語言的 codebase，用 Appium 可以共用自動化 自建 device farm vs. 雲端服務，成本和維護複雜度要算清楚 這些決策如果等到「以後再說」，到時候要 refactor 的代價非常高。 Chapter 7：如何量化自動化的價值 很多自動化項目失敗，是因為 期望設定不切實際 。解法是一開始就講清楚要看哪些指標。 可追蹤的 ROI 指標 | 指標 | 說明 | | | | | 回歸測試時間 | 從幾天縮短到幾小時/分鐘 | | 回饋速度 | 從手動跑一次到每次 commit 都有結果 | | 開發信心 | 問開發者：「看到測試 pass，你相信沒有 regression 嗎？」 | | 擴展能力 | 能跑幾個環境、幾個瀏覽器、幾個裝置 | Angie 建議可以設定 SLA：整套測試最長跑幾分鐘。這會逼著工程師優化測試速度，而不是讓它無限膨脹。 一個值得記住的提醒： 自動化初期，學習成本和修 flaky test 的時間會讓數字難看 。這是正常的。要讓大家知道這是投資期，不是失敗的訊號。 我的總結 整門課最讓我印象深刻的一句話： Test automation is a software development project in and of itself. 這句話我聽過很多次，但在 Angie 的框架下，我第一次真正理解它的重量——它意味著自動化需要完整的計畫、資源、架構、維護，而不是「有空就順手做一下」的副業。 如果你的團隊正在考慮啟動自動化，或是已經啟動但覺得走得很辛苦，我非常推薦去看這門課。47 分鐘，把很多模糊的問題說清楚了。 課程連結：TAU Setting a Foundation for Successful Test Automation 參考資料 Test Automation University — Test Automation Foundations — 本文課程來源，Angie Jones 主講 Angie Jones — Personal Blog — Test automation 領域知名教育者 ISTQB — Foundation Level Syllabus — 測試自動化基礎的國際標準定義 Martin Fowler — TestPyramid — 測試金字塔概念原始出處 Capgemini — World Quality Report 2024 25 — 全球自動化測試趨勢年度報告