「寫自動化測試最慘的不是寫不出來，而是花了三週寫完，最後發現維護它花的時間比手動測試還多。」

嗨，我是 Jane。剛接觸自動化測試的前兩年，我們很容易落入一個陷阱：只要看到重複的操作，就想把它寫成腳本。看到測試覆蓋率（Coverage）上升、看到 CI 上的綠燈一個個亮起，心中滿是成就感。

但到了第 3 年，當產品功能越來越複雜、頁面 UI 頻繁改版，你的 Pipeline 開始出現各種莫名其妙的失敗（Flaky），每天光是排查「到底是不是產品 Bug」就耗掉半天。這時你才會發現：不是所有測試，都值得寫成自動化。

今天這篇文章，我們要來建立一套清晰且可量化的「自動化測試候選評分框架」，幫你把精力集中在真正能帶來高 ROI（投資報酬率）的測試案例上。

一、 判斷測試是否自動化的 6 大核心維度

在決定要不要把一個測試案例寫成自動化腳本前，建議從以下 6 個維度進行評估：

1. 執行頻率 (Execution Frequency)

• 高價值：每次 Commit、每次 Build、每次 Release 都需要執行的測試（例如：Smoke Test、核心 API、登入流程）。
• 低價值：半年甚至一年才執行一次的邊界情境，或一次性的資料遷移驗證。

2. 商業風險 (Business Impact / Risk)

• 高價值：一旦壞掉會直接造成公司財務損失或核心服務中斷（例如：購物車結帳、付款 Gateway、使用者身分驗證）。
• 低價值：純視覺樣式微調、罕見的邊界組合，就算壞了也不會影響核心商業運作。

3. 產品與需求的穩定程度 (Feature Stability)

• 高價值：核心商業邏輯已經定型、UI 介面或 API 規格相對穩定的功能。
• 低價值：正在快速迭代、需求每週都在變動的 PM 實驗性功能。在需求穩定前寫 UI 自動化，本質上就是寫明日的廢程式碼。

4. 人工測試成本 (Manual Testing Cost)

• 高價值：手動執行非常耗時、繁瑣且容易因人為疏忽漏掉的步驟（例如：大資料量的邊界測試、多國語系多瀏覽器組合、複雜的權限交叉比對）。
• 低價值：手動點一下只需要 3 秒鐘，但寫成 UI 自動化要處理 Mock Data、動態元素等待，耗時兩天的大樓建立工程。

5. 自動化維護成本 (Maintenance Cost)

• 高價值：邏輯單純、依賴少、環境容易建構的測試。
• 低價值：極度依賴外部第三方服務（如：簡訊驗證碼、銀行付款頁面、第三方 Captcha），且無法進行容易 Stub/Mock 的測試。

6. 結果是否容易判定 (Assertability)

• 高價值：Pass/Fail 條件非常明確（例如：HTTP Status Code 200、資料庫特定欄位更新為 True）。
• 低價值：結果高度依賴主觀視覺感官、主觀體驗或複雜影像辨識（例如：「這張圖看起來有沒有歪掉」、「動效播起來順不順暢」）。

二、 實戰工具：自動化候選項目評分表 (Automation Candidate Scorecard)

為了避免團隊內部對於「這個要不要寫自動化」陷入無休止的主觀爭執，我們可以將上述維度轉化為一份量化的評分表。

評分機制：針對每個指標進行 1 ~ 5 分的打分（5 分代表最適合自動化），最後計算總分。

| 評估維度 | 評估基準 (1 分 → 5 分) | 權重 | 得分 (1-5) | 加權分數 |
| 執行頻率 | 1: 幾個月跑一次 → 5: 每天/每次 Build 都跑 | 20% |
| 商業風險 | 1: 影響極小 → 5: 核心營收/服務中斷 | 20% |
| 需求穩定度 | 1: 每週改版 → 5: 數月未變動 | 20% |
| 人工執行成本 | 1: 手動 10 秒完成 → 5: 手動需 30 分鐘以上 | 15% |
| 維護/開發難度 | 1: 極難自動化/易被外部影響 → 5: 邏輯單純/獨立 | 15% |
| 結果判定難易 | 1: 需人工視覺/主觀判斷 → 5: 斷言明確 (API/DB) | 10% |
| 總計 | 滿分：5.0 | 100% | | Weighted Score |

決策門檻 suggestion：

• 加權總分 > 3.8：絕對優先自動化（Smoke/Critical Path）。
• 加權總分 2.8 ~ 3.7：列入 Backlog，視團隊資源與測試層級（儘量往 API 層寫）決定是否自動化。
• 加權總分 < 2.8：維持手動測試或探索式測試，不要浪費時間寫腳本！

三、 資深 QA 的真心話：哪些坑千萬不要踩？

1. 不要為了「測試覆蓋率（Coverage）」數字而自動化

   許多團隊主管會要求「自動化覆蓋率要達到 80%」，這往往是災難的開始。工程師為了湊數字，會去寫大量加權分低於 2.5 的無意義 UI 腳本。最後結果是：覆蓋率漂亮了，但 CI 每天發警報，沒人敢相信測試結果。

2. UI 測試只做關鍵路徑，細節交給 API 和 Unit Test

   如果你評估一個功能商業風險很高，但 UI 介面變動非常頻繁，請思考：能不能改寫 API 自動化？ 商業邏輯留在 API 驗證，UI 層只留在最基本的 E2E 結帳主流程。

3. 探索式測試（Exploratory Testing）永遠無法也不該被取代

   自動化測試只能驗證「你知道可能會壞的地方（Known Knowns）」，真正的奇葩 Bug、邏輯漏洞以及使用者真實體驗問題，永遠需要依靠 QA 的直覺、經驗與探索式測試來發現。

結語與明日預告

自動化的本質是解放重複勞動的時間，讓測試人員專注於更有價值的高風險探索。學會說「這個不值得自動化」，才是資深工程師展現專業價值的開始。

確定了哪些案例值得寫之後，下一個問題來了：我們要寫在哪一層？

明天 Day 3，我們將一起來探討：《 Day 3｜測試金字塔還適用嗎？從 Unit 到 E2E 的分配策略》。