GTest(基於YApi)介面研發效能提升10倍 實戰

現在的網際網路行業已經不是大魚吃小魚的時代了，而是快魚吃慢魚的時代，具體來講就是從使用者需求轉化成企業服務的能力，其中研發效能的高低對使用者需求轉化速率起到了至關重要的作用，而API服務的研發效能是當中非常重要的一環。

隨著公司的發展，研發人員越來越多，公司產品多元化，模組複雜度不斷提升，API的研發效能也成為了決定公司研發能力的關鍵因素之一，同時對API研發管理，研發效率也有了新的挑戰：

挑戰

1. 介面協議同步不及時：API介面定義多是文件化管理，文件更新往往不及時，當介面協議發生變化時，無法及時同步給前端、測試等團隊。
2. 自動化水平低：測試用例一般通過Excel、Xmind等維護，需要手工測試，每次迴歸測試都需要人工手動執行測試用例，大大佔用測試資源。
3. 聯調週期長：每次聯調可能涉及多個模組，幾個研發團隊協作，一方出現問題，就會卡住整個流程，拖慢聯調進度。
4. 提測質量無法保證：研發自測不充分，冒煙測試用例執行情況無法量化，導致提測質量參差不齊，
5. 效能壓測：效能測試門檻高，壓測機器碎片化無法統一管理，缺乏專業的效能分析。

願景

我們希望能夠研發一個API管理平臺，可以滿足以下的需求：

1. 介面協議更新能夠及時同步。
2. 減少前端、後端、測試等團隊間的依賴。
3. 提升介面自動化水平。
4. 有專業的壓測平臺。

破局

對比了市面上已有的介面管理平臺，我們發現YApi可以說是最好用、功能最完善的API介面管理平臺了。

YApi原生已經支援以下功能：

• 視覺化介面管理
• 資料mock
• 自動化介面測試
• 資料匯入（各種，包括swagger、har、postman、json、命令列）
• 許可權管理
• 支援本地化部署
• 支援外掛
• 支援二次開發

我們決定基於YApi進行二次開發，滿足內部的定製化需求，演進出公司內部的GTest介面管理平臺。目前，圍繞著介面管理和效能提升，已經開發了以下平臺：

1. GTest(API管理平臺)：基於YApi1.3.22版本演進，支援內部RPC協議、介面定義優化、支援叢集模式、Chrome外掛功能擴充套件等功能，目前已經完全自主迭代。
2. 壓測平臺：基於Gatling開發，支援內部RPC協議壓測、動態隨機引數、返回值斷言等。結合GTest，選擇壓測模式，讓壓測像介面呼叫一樣便捷。
3. GDetector(API監控平臺)：支援Ping、Telnet、Http等協議的監測，對介面返回值進行斷言，可配置定時規則和告警規則，結合GTest測試集合也支援流程級別的監測。
4. GDevops(CICD平臺)：只需簡單配置即可進行程式碼質量監測、規範控制，自動化構建映象和K8S部署。

依託目前的GTest介面管理平臺，對比一下過去和現在的介面開發流程：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-Qtz7XE3Z-1603416507982)(/Users/wang/Downloads/API開發對比.png)]

案例

下面舉兩個例子來說下有了GTest平臺之後發生的變化：

研發提測質量：

之前規定研發提測前，需要開發把測試提供的冒煙用例執行一遍，但是這種方式無法保證測試用例的執行情況，也沒有資料化的校驗結果，比較主觀。

依託GTest平臺，在幾乎不需要人工參與的情況下，根據介面定義的欄位規則、欄位是否必須等自動生成介面測試用例集合，開發一鍵即可介面驗證，並生成詳細的測試報告。對於開發提測的版本，自動化執行冒煙測試集合，減少測試人員的參與，提測質量資料化展示，一目瞭然。

API業務監控：

之前每個業務上線，都需要業務方自行開發撥測系統用於監控服務的執行情況，各個業務方實現標準不統一，撥測系統本身的穩定性等很難保證。

依託API監控平臺，提供標準的定時監測功能、告警功能等，還可以直接複用GTest平臺的測試集合進行流程監控。隨著監控用例的完善，未來還可以評估線上故障的影響範圍，服務恢復情況等。

經驗

API研發效能的提升不是一蹴而就的，是一個不斷迭代和推進的過程。中間會涉及到前端、後端、測試、運維等多方面的人員。也會有基於技術的問題，基於流程的問題。下面是我們在推進API研發效能提升的一些經驗總結：

1. 引入流程

   可能很多人聽到流程的概念，都會想到繁文縟節、效率低下等字眼。但是對於像GTest這樣作為多方人員協作的平臺，無規矩，難成方圓。一個人能把平臺使用好不代表一幫人可以把平臺使用好。所以必須制定好流程。

   比如 介面開發流程：在介面開發之前，必須制定好詳細的介面協議。這樣後端開發人員根據介面協議進行開發，前端人員根據介面協議呼叫Mock服務，測試人員根據介面協議編寫測試用例，三方人員並行工作，不用相互依賴，阻塞自己的工作進度。

   比如 冒煙測試流程：測試人員應該在開發人員提測之前，在GTest上面編寫好冒煙測試集合。這樣開發人員在GDevops平臺提測打包時，會自動打包，部署服務到K8S，自動化執行冒煙測試集合，測試通過會自動傳送提測郵件。

2. 小範圍試用

   對於制定的規範、標準、新功能等先找一兩個團隊進行小範圍試用。小步快跑，快速驗證合理性、可行性。而且真正的應用到實際場景中，才能發現制定的標準示範合理，規範能否應用起來，新功能能否滿足真實的場景。小範圍的試用也方便與使用團隊的深入交流，如果直接推廣到整個公司，反而會引入穩定性、規範普及、場景未完全覆蓋等問題，疲於奔命，無法聚焦，還會留下難用的印象。

3. 制定標準

   對於GTest平臺，多方人員共同協作，維護著整個公司業務的API介面，那麼怎麼管理人員，管理API等也變成一個問題。只有制定相關的標準，才能井然有序的執行。

   比如：API介面需要按照分組 專案 分類 介面這樣的層級來維護，不然介面雜亂無章很難找到。

   比如：介面協議需要定義欄位是否必須 預設值 長度大小限制 規則，這樣API Mock環節，測試用例編寫才能根據定義的協議來完成。

展望

API研發效能提升涉及的面非常廣，有技術能力上的，也有管理規範上的。對於整個API研發生命週期，每個環節的提升，都會帶來API研發效能提升。未來，我們還有很長的路要走，比如 API自動生成平臺，API開放交易平臺等。

如果你有什麼問題，也歡迎關注公眾號：咻咻ing 後臺留言交流。