GTest(基於YApi)介面研發效能提升10倍 實戰
現在的網際網路行業已經不是大魚吃小魚的時代了,而是快魚吃慢魚的時代,具體來講就是從使用者需求轉化成企業服務的能力,其中研發效能的高低對使用者需求轉化速率起到了至關重要的作用,而API服務的研發效能是當中非常重要的一環。
隨著公司的發展,研發人員越來越多,公司產品多元化,模組複雜度不斷提升,API的研發效能也成為了決定公司研發能力的關鍵因素之一,同時對API研發管理,研發效率也有了新的挑戰:
挑戰
介面協議同步不及時:API介面定義多是文件化管理,文件更新往往不及時,當介面協議發生變化時,無法及時同步給前端、測試等團隊。
自動化水平低:測試用例一般通過Excel、Xmind等維護,需要手工測試,每次迴歸測試都需要人工手動執行測試用例,大大佔用測試資源。
聯調週期長:每次聯調可能涉及多個模組,幾個研發團隊協作,一方出現問題,就會卡住整個流程,拖慢聯調進度。
提測質量無法保證:研發自測不充分,冒煙測試用例執行情況無法量化,導致提測質量參差不齊,
效能壓測:效能測試門檻高,壓測機器碎片化無法統一管理,缺乏專業的效能分析。
願景
我們希望能夠研發一個API管理平臺,可以滿足以下的需求:
介面協議更新能夠及時同步。
減少前端、後端、測試等團隊間的依賴。
提升介面自動化水平。
有專業的壓測平臺。
破局
對比了市面上已有的介面管理平臺,我們發現YApi可以說是最好用、功能最完善的API介面管理平臺了。
YApi原生已經支援以下功能:
視覺化介面管理
資料mock
自動化介面測試
資料匯入(各種,包括swagger、har、postman、json、命令列)
許可權管理
支援本地化部署
支援外掛
支援二次開發
我們決定基於YApi進行二次開發,滿足內部的定製化需求,演進出公司內部的GTest介面管理平臺。目前,圍繞著介面管理和效能提升,已經開發了以下平臺:
GTest(API管理平臺):基於YApi1.3.22版本演進,支援內部RPC協議、介面定義優化、支援叢集模式、Chrome外掛功能擴充套件等功能,目前已經完全自主迭代。
壓測平臺:基於Gatling開發,支援內部RPC協議壓測、動態隨機引數、返回值斷言等。結合GTest,選擇壓測模式,讓壓測像介面呼叫一樣便捷。
GDetector(API監控平臺):支援Ping、Telnet、Http等協議的監測,對介面返回值進行斷言,可配置定時規則和告警規則,結合GTest測試集合也支援流程級別的監測。
GDevops(CICD平臺):只需簡單配置即可進行程式碼質量監測、規範控制,自動化構建映象和K8S部署。
依託目前的GTest介面管理平臺,對比一下過去和現在的介面開發流程:
案例
下面舉兩個例子來說下有了GTest平臺之後整個API研發過程發生的變化:
研發提測質量:
之前規定研發提測前,需要開發把測試提供的冒煙用例執行一遍,但是這種方式無法保證測試用例的執行情況,也沒有資料化的校驗結果,比較主觀。
依託GTest平臺,在幾乎不需要人工參與的情況下,根據介面定義的欄位規則、欄位是否必須等自動生成介面測試用例集合,開發一鍵即可介面驗證,並生成詳細的測試報告。對於開發提測的版本,自動化執行冒煙測試集合,減少測試人員的參與,提測質量資料化展示,一目瞭然。
API業務監控:
之前每個業務上線,都需要業務方自行開發撥測系統用於監控服務的執行情況,各個業務方實現標準不統一,撥測系統本身的穩定性等很難保證。
依託API監控平臺,提供標準的定時監測功能、告警功能等,還可以直接複用GTest平臺的測試集合進行流程監控。隨著監控用例的完善,未來還可以評估線上故障的影響範圍,服務恢復情況等。
經驗
API研發效能的提升不是一蹴而就的,是一個不斷迭代和推進的過程。中間會涉及到前端、後端、測試、運維等多方面的人員。也會有基於技術的問題,基於流程的問題。下面是我們在推進API研發效能提升的一些經驗總結:
引入流程
可能很多人聽到流程的概念,都會想到繁文縟節、效率低下等字眼。但是對於像GTest這樣作為多方人員協作的平臺,無規矩,難成方圓。一個人能把平臺使用好不代表一幫人可以把平臺使用好。所以必須制定好流程。
比如 介面開發流程:在介面開發之前,必須制定好詳細的介面協議。這樣後端開發人員根據介面協議進行開發,前端人員根據介面協議呼叫Mock服務,測試人員根據介面協議編寫測試用例,三方人員並行工作,不用相互依賴,阻塞自己的工作進度。
比如 冒煙測試流程:測試人員應該在開發人員提測之前,在GTest上面編寫好冒煙測試集合。這樣開發人員在GDevops平臺提測打包時,會自動打包,部署服務到K8S,自動化執行冒煙測試集合,測試通過會自動傳送提測郵件。
小範圍試用
對於制定的規範、標準、新功能等先找一兩個團隊進行小範圍試用。小步快跑,快速驗證合理性、可行性。而且真正的應用到實際場景中,才能發現制定的標準示範合理,規範能否應用起來,新功能能否滿足真實的場景。小範圍的試用也方便與使用團隊的深入交流,如果直接推廣到整個公司,反而會引入穩定性、規範普及、場景未完全覆蓋等問題,疲於奔命,無法聚焦,還會留下難用的印象。
制定標準
對於GTest平臺,多方人員共同協作,維護著整個公司業務的API介面,那麼怎麼管理人員,管理API等也變成一個問題。只有制定相關的標準,才能井然有序的執行。
比如:API介面需要按照
分組
專案
分類
介面
這樣的層級來維護,不然介面雜亂無章很難找到。比如:介面協議需要定義欄位
是否必須
預設值
長度大小限制
規則
,這樣API Mock環節,測試用例編寫才能根據定義的協議來完成。
展望
API研發效能提升涉及的面非常廣,有技術能力上的,也有管理規範上的。對於整個API研發生命週期,每個環節的提升,都會帶來API研發效能提升。未來,我們還有很長的路要走,比如 API自動生成平臺,API開放交易平臺等。
如果你有什麼問題,也歡迎後臺留言交流。