前幾天知識星球裏的同學問了這樣一個問題：API自動化測試，業內有沒有標杆指標？
問題背景大致如下：
接口自動化建設過程中遇到了一些困境，需要從團隊建設角度給出發展目標和具體的指標，主要問題有如下兩點：
- 大廠/有最佳實踐的團隊，接口自動化在微服務的角度覆蓋率需要達到多少？
- 接口自動化的穩定性(case通過率)需要達到多少纔算是達標，達到多少算比較優秀？
這個問題表面來看，是需要一些明確的指標，爲測試團隊的自動化測試工作開展指明目標。
但仔細思考一下，我個人認爲背後的原因在於，在開展接口自動化測試工作時，並沒有考慮清楚需要投入的成本，團隊當前的現狀，以及優先級最高的問題該如何解決。
從自動化測試的投入產出比金字塔模型來說，接口自動化確實是性價比最高的一種自動化測試方式。
單元測試的技術要求比較高，大部分測試團隊很難勝任；UI自動化又很考驗前端的編碼規範和UI的穩定性。而接口自動化測試的優勢在於如下幾點：
- 有賴於系統架構的演進，微服務和前後端分離的設計理念，系統和服務間的交互更爲解耦，數據交互基本都在接口層解決；
- 相比於UI的變化頻率而言，接口變更帶來的測試維護成本更低；
- 測試工具和框架越來越成熟，不需要太熟練的編碼能力，普通測試同學都可以參與到接口自動化測試工作中；
自動化測試的優勢毋庸多說，能提高測試驗證效率，縮短結果驗證反饋週期，但這些優勢之所爲能成爲團隊提效的優勢，背後需要的是前期一定成本的投入。
且自動化測試在前期建設階段，投入產出比勢必會有一段時間處在虧損狀態。
對測試團隊來說，自動化測試無論是測試左移右移，都是長期必須建設的技術設施。但需求是做不完的，迭代是幾乎不會停止的，如何保證在儘可能的吞吐需求的同時，保障測試的交付質量，同時還要投入一定資源開展自動化測試工作，這一點很考驗團隊管理者的能力。
業內有沒有自動化測試的最佳實踐呢？從普世的角度來說，只有一些方法論和注意事項可以參考；從現實角度出發，沒有適合絕大多數團隊的落地實踐案例。
因爲每個公司的業務特性和複雜度不同，測試團隊成員的技術能力不同，做事方式不同，測試方法和流程規範不同，以及測試團隊本身所能投入的資源多寡和管理層允許投入這些資源所期望的回報時效都不相同。
相比於前幾年互聯網行業大刀闊斧招聘和開發各種技術平臺，在當下的降本增效共識下，公司和團隊領導更需要的是能立即解決問題提高效率的技術實踐，而不是看着高大上但實際上回報週期更長的技術項目。
在KPI和營收壓力下，大家更關注的是當下，成本、人效和收益，永遠是老闆和管理層最關心的。
我個人的觀點是，測試團隊在當下要實施自動化測試，首先要做的事情是找到低效的原因和環節，能通過自動化測試快速覆蓋，讓case跑起來出結果，縮短反饋週期纔是最重要的。
至於所謂的覆蓋率，大家不要太迷信這個東西，畢竟統計學，是這個世界上最有魅惑力的學科。統計維度和週期不一樣，最終的數據指標上下限超乎你的想象。
本文最後，回答一些關於上述問題，我的一些實踐經驗，僅供參考。
- 不要迷信case覆蓋率和測試通過率，重點關注是否縮短了測試和反饋週期；
- 影響測試用例通過率的因素很多：腳本問題，數據問題，斷言問題，環境問題；
- 測試覆蓋率只是一個統計結果，測試同學更應該關注測試用例和業務場景的匹配度；
- 測試覆蓋率從一定角度來說是有用的，便於測試團隊評估自動化測試的粒度和投入成本；
- 建議按照核心業務-對應服務-核心接口來梳理，優先覆蓋核心業務應用的P0接口，以此類推；
- 自動化測試在前期落地過程中，建議優先覆蓋增量需求的核心接口，然後再考慮存量業務場景；
最後，我個人認爲，是否要做自動化測試，如何做，怎麼做，階段里程碑是什麼，都應該根據所處團隊的具體情況來制定落地計劃，然後根據落地情況實時調整，優先解決核心問題。
一個比較好的技術落地思維方式是這樣的：
- 目前團隊面臨的最大問題是什麼？——聚焦問題；
- 這個問題有業內有哪些解決方法？——分析根因，對比評審；
- 目前優先級最高的訴求是什麼？——能快速跑起來/規範操作和協作流程；
- 解決這些問題需要投入多少資源？——投入多寡對應的見效時間差距有多大；
- 快速小範圍落地實踐，觀察結果，評估效果和性價比，調整方案，繼續迭代！
軟件測試好歹也是一個技術崗位，對於技術實踐來說，最小可行性方案永遠比PPT更能解決問題！