十多年了，介面自動化測試越來越雞肋？

引言

從《 Google 軟體測試之道》到後來的敏捷開發、DevOps ，10 多年了，介面自動化測試一直是測試領域必談的重點。各種自動化測試工具（ Postman 類）、自動化測試框架、自動化測試平臺層出不窮，每個公司/部門甚至每個團隊都有一套直接的自動化解決方案。但盲目投入後，反而會感覺越來越雞肋，食之無用棄之可惜。

介面自動化的價值

不管你是 B/S 還是 C/S 架構，APP 還是小程式，還是什麼協議，總體來說是由 GUI 和服務端 API 組成。通常一個迭代是 PM 需求、RD 開發/聯調、QA 單功能測試、bugfix(穿插多輪)、合碼 QA 整合/迴歸測試、發版。在這一套模式下，大家常說的介面自動化測試（暫不考慮 UI 自動化）的價值如下：

提高測試效率/降低人力成本？

因為自動化測試執行很快，所以引入介面自動化測試能提高測試效率。但有個很現實的問題，介面自動化只覆蓋了服務端 API ，GUI 這部分也有很多邏輯，RD 也是有大量工作量投入的，這部分的測試是少不了的。即使是偏服務端 API 的功能，你的手工 GUI 測試替代率是多少？介面自動化執行完了能不需要手工測試嗎？這恐怕不敢打包票吧。所以對於一個端到端的測試團隊，反而介面自動化 case 的編寫和維護成了額外的負擔。

降低人力成本也是無稽之談，因為你手工 GUI 測試的成本並沒有降下來，反而需要投入寫介面自動化的人力。除非你之前就有一批人是使用 Curl 測介面的。

提高測試覆蓋率？

這個理論上有道理，一些介面引數分支，UI 上無法走到，透過介面則可以直接覆蓋到，提升了覆蓋率，後面 UI 上增加了此分支能保證基本的質量，提升迭代效率。但事實上產品變化很快，還沒等覆蓋到新引數分支，需求又變了，介面甚至都得重寫一遍。掉入了過早最佳化的陷阱。

持續整合和持續交付（ CICD ）！

網際網路大部分開發模式都是迭代開發、小步快跑。介面開發完成後還沒到測試環節，這時候跑一遍自動化（迴歸測試），能保證基礎功能沒影響，程式碼就可以合入了，過幾天就自動進入到測試環節。也能儘早發現問題，縮短交付週期。

同時還可以用作線上監控，保障服務穩定性。

保證結果的一致性和準確性！

手工用例總是需要人理解然後執行，因為各種原因，不同的人可能對同一條 case 理解不一樣，造成執行偏差。然後人總有惰性，雖然很少，但偶爾還是會有因覺得執行過程偷懶而導致的漏測。而介面自動化一旦成為規模，執行的結果就是可靠的。

總的來說，如果你是想只透過介面自動化這一種方式降本提效，那介面自動化可能會事與願違。而是應該把提質作為目的，即介面自動化作為質量保障的重要手段，儘早的寫（不應該在服務上線了補），穿插到整個研發生命週期裡面去，才能發揮更大的作用（特別是現在 DevOps 時代）。合適的度量指標：線上問題召回率（基本不可能透過手工召回）、自動化 Bug 發現比率（含 CICD 過程中發現的）。

介面自動化的成本

在評估自動化收益的時候我們常用這樣一個公式：自動化收益 = 迭代次數 x（手工執行成本 – 用例維護成本）- 用例編寫成本。但在介面自動化中不太合適，前面也說了，介面自動化和手工測試並不對等，並不是替代人工。不過自動化測試的成本倒是可以透過類似的公式計算：執行次數 x 用例維護成本 + 用例編寫成本。這可能和大家想象的不一樣，介面自動化通常被認為是邊際成本很低，即用例編寫成本會隨著執行次數增加而攤薄。但事實上維護成本也不低，而且無法攤薄，因為不執行就不需要維護，只要執行就會出問題，就需要排查、維護。

維護成本的來源可能是多方面的，雖然都有一定的解決辦法，但不能忽視這部分的成本，而且分散在日常中還是隱性成本，如果做的不好，甚至會出現團隊都很累，但質量又很差的情況。

維護成本來源	解決方案
介面引數不相容改動，需要相關 case 都改動	介面適當封裝，case 使用封裝後的模板或函式，方便使用和維護
前置變數失效導致 case 失敗，比如商品 id 或者說一個新環境的適配成本	一方面 case 裡面不能寫死 id，需要變數化，資料和邏輯分離；另一方面，case 需要自給自足，相關依賴資源在前置操作中產生，並在後置操作中銷燬
case 間的量子糾纏	適當的執行使用者隔離，一些資源操作加鎖

很多測試框架/平臺把重點放在寫 case 這塊，但其實都沒 Postman 好用，不過也有一些新方式，比如流量錄製匯入。但拉長 case 週期來看，編寫成本是一次性的，10 分鐘寫完一條 case 和 1 小時寫完一條差別不大。更多的應該放在如何寫好 case（場景構造、資料準備等）、維護好 case ，這才能降低最終的成本（放心沒廣告）。

總結

還是那句話：軟體工程沒有銀彈。雞肋不雞肋要看目的，降本增效可能不是直接的收益。同時也要注意介面自動化維護成本也不小，需要重點投入解決這塊的問題，才能使最終的 ROI 高。

當然，本文看著還是泛泛而談，並沒有說介面自動化該如何寫，但我認為具體怎麼寫都是招式問題，先修一下內功心法總綱更重要。

---

原文字人部落格： https://iyaozhen.com/api-automation-test-tasteless.html

初來寶地，我說的可能比較片面，但也希望大家討論討論，豐富下這塊的話題