自動化測試落地為什麼那麼難

提起自動化測試能力，作為現在測試人員技術能力體現的一部分，越來越多的人關注到這部分能力的提升。但是，很多團隊的落地效果並不佳，在轟轟烈烈的開始中，慢慢淪為 PPT 產物。那麼，如何讓團隊真實地享受到自動化帶來的提效呢？結合個人在不同公司的落地情況，說說自己的想法。

01 管理好預期

提效從來不意味著降本，如果你是想透過自動化測試，來減少測試人員的數量，節約人力成本，以此為目標的話，大機率是失敗的。個人認為，自動化測試的意義在於構建快速反饋的能力，不論是整合在 CICD 流水線上，還是作為線上巡檢的一部分，都能夠提升質量反饋的速度。在敏捷研發的大環境下，快速反饋能力是必不可少的。不能讓測試執行成為團隊交付瓶頸。

記住這個初衷，它將影響後續一系列的動作。不要讓它變形了。

02 自動化的前提是標準化

在之前的《透過抓包能否做好介面測試》中，有提到過，只有標準化後，才有可能自動化，很多測試負責人僅從測試的角度出發，透過一些取巧的方式來實現介面自動化（比如透過 Curl 或者錄製 har 檔案，來實現介面測試），雖然能在短期內看似落地了介面自動化，但是缺乏對介面的理解，是無法長期執行併產生效果的。

這裡的標準化，指的是介面文件的時效性問題，很多團隊也有自動維護的介面文件，但都是第一稿的資訊，後續在實現過程中的變更都沒有辦法在文件中體現，那麼做介面自動化就會非常的痛苦。

所以，推動上游的介面標準化、實時性，就成為關鍵問題，其實這是個雙贏的事。對研發而言規範了介面，自己聯調也方便。並不難推動。

03 需要具備工程化思維

如何解決第 2 點的問題呢？你不能期待讓研發人員手動去維護介面文件，也不能期待研發人員主動告訴你介面變更了，這是不現實的，也不要抱怨。解決這類問題，需要從工程能力的角度去著手。基於現在的研發能力，不論是 Swagger 還是 ApiDoc，都有能力直接從程式碼工程上自動生成介面文件，而且還是實時的。

個人的實踐是，如果團隊比較小，那就直接引用 Swagger 的標準化框架，然後直接對接 Swagger 路徑，去自動解析介面，監聽介面變更。如果團隊較大，可以寫個 SDK，來主動上報 Swagger 路徑，從而獲取介面資訊。

一個完整的介面自動化全鏈路大致如下：

這樣對研發而言，改動量最小，又能規範研發程式碼，讓研發主管也能從中受益，相互繫結利益，推動起來也容易。

04 貼合實際業務的場景化指令碼

很多時候，自動化測試淪為雞肋的原因是，大多數的測試用例都只是單介面的用例，透過引數的等價類、邊界、異常值作為人參就完事了。不是說這類測試不重要，而是真的沒太必要把時間花在這上面。這些完全可以透過介面定義和引數註解來約束，出問題的機率不大（做好 Code Review 和靜態掃描，用好框架，能解決 90% 的這類問題）。

從測試覆蓋的角度看，我們更希望看到的是多介面串聯場景，能夠真實地模擬業務操作，把資料流完整地跑通，配合上有效的檢查點，來幫助我們發現、攔截問題。

這部分的具體內容，可參考《介面測試這麼玩才明白》。

所以，貼合實際業務場景的鏈路介面操作，合理的檢查點設定，才能讓自動化有效地運轉起來，能幫助我們有效地去攔截問題。測試用例的數量和覆蓋率並不是我們追求的資料。切記。

05 最大化介面測試的價值

基於介面自動化的指令碼，我們還可以做很多事，讓這件事的價值最大化。常見的有以下幾類：

CICD 門禁：由於自動化的執行效率高，可以整合到 CICD 中，作為質量門禁的一部分，把問題攔截在開發環境，及時反饋問題。

造數工具：在合理的引數化場景下，多數介面測試場景都能用於測試資料的製造，特別是對於鏈路比較長的前置資料，介面造數是個非常可行的方案

輔助迴歸測試：基於介面自動化測試，可以快速覆蓋核心功能，把時間節約出來，做針對性的專項測試或者對新功能進行驗證。前提是你的用例足夠清晰和健壯。

線上巡檢：線上環境的撥測已經被越來越多的團隊重視，也是測試右移的一項重要能力，自動化測試可以作為業務線上巡檢的一部分，快速發現問題。

06 小結

自動化測試是構建測試人員快速反應能力的基本要求，也是提升效率的有效手段，它需要前期的投入，標準化的維護以及有效的測試用例設計，才能最大化地發揮它的價值。自動化測試的負責人，需要具備推動標準化落地的能力，並讓自動化在更多的地方體現出價值來。

任意一項技術手段的推廣與實踐，不論是研發過程的規範，還是測試活動的規範，都不是一次性的投入，都需要長期持續地投入維護，潛移默化地影響其他人。

關於自動化測試的 ROI，東東也寫了一篇估算的文章，大家可以參考下：自動化測試投入產出效益與價值