【解決方案】1萬+接口測試與管理的進階之路

**【關鍵導讀】**

本文着重詳解了接口測試解決方案的進階之路，如何從典型的java+TestNG+Jenkins，圍繞着提高接口測試ROI（減小投入成本，增長使用率）的目標，一步步結合業務應用實踐，打造了一個高效的基於接口的團隊協做平臺GoAPI，讓接口測試人人能作，人人能用，隨處可用，以及如何作到1萬+接口的業務的接口測試與管理。

1、歷史的接口測試與管理

1.1 一個「活着」的接口

接口是應用開發中必然存在的產物，不管你是開發、測試仍是運維人員，你都會與接口產生千絲萬縷的聯繫。開發是接口的創造者，他們定義了接口，同時賦予了他們血肉之軀。測試是接口的健康守護者，不管在哪一個階段，都在默默的爲他們找出傷害他們健康的「蛀蟲」（To BUG）。聽了個人YY，有沒有以爲接口是有生命的，若是沒有，那麼能夠看下下圖

接口的「成長曆程」java

如此看來，接口是具備生命週期的，結合軟件研發流程來看的話，在不一樣的階段，不一樣角色都會圍繞着接口作不一樣的事情。以下，一個「典型」的接口生命週期

一個「典型」的接口生命週期node

接口生命週期中的每個階段都須要獲得「細心的照料」，這就涉及到接口的測試與管理。接下來，將從歷史的進程來看下，接口是如何被獲得「照顧」的。

1.2 "歷史」的接口管理與測試縮影

想到2014年，那是一個····的年頭，咱們的接口管理與測試是這麼玩的，接口文檔管理採用的是wiki，接口手工測試採用的是Postman/Jmeter，接口自動化是基於TestNG編寫的測試框架，接口線上監控是採用的Jenkins CI驅動。

2014年的接口測試與管理python

能夠看下當時封裝的接口自動化測試框架

Java+TestNG接口測試框架web

提及框架特色當時還很「自豪」的講出了幾大特色：特色:  Annotation  依賴性測試  支持併發測試  支持錯誤重運行測試  參數化測試  支持測試分組  經過testng.xml來管理測試  詳實的報告，可按照本身須要進行二次開發定同時在當時也調研過python的方案，Python Nose 方案，二者對好比下：

在業務的發展過程當中，對於接口的測試與管理，遇到了不少問題和瓶頸，以下也許會感同：

**同一件事情被多人重複作了:**

開發人員在開發完一個API接口，會部署到開發環境中，而後經過本身寫自動化腳本或者利用 POSTMAN工具驗證一下這個API 接口是否符合預期，這時候其實已經作過一個簡單的API測試了。到了提測階段開發會將寫好的API接口文檔給測試人員，測試人員會部署代碼到測試環境中去，而後經過 testNG 或者其餘自動化測試框架寫接口測試用例，咱們發現，API的正向用例測試，開發人員作過一次，測試人員用不一樣的方式又作了一次，有沒有可能開發人員作完後，測試人員就能夠直接拿來在測試環境裏面用呢?

**開發提測的質量不可度量:**

開發人員提測，通常只是執行一下冒煙測試用例，提交接口文檔，口頭敘述一下這些接口我在開發環境都驗證經過，符合提測標準了。可是對於測試人員來說這個口頭敘述是無法來度量提測的質量的，測試人員缺乏客觀的數據來評估接口的質量是否符合預期，從而致使後期由於質量問題出現版本回退的現象，拖延了開發週期。有沒有什麼辦法來客觀的度量開發的提測質量呢?

**API 接口的變更引發的疊加效應:**

API 接口變更是常有的事情，可是現有的流程中，一個接口的變更會牽扯出一系列的變更，接口文檔的變更，接口測試用例的變更，接口測試代碼的變更，持續集成的變更......，時間成本瞬間提升。有沒有辦法只要一個地方修改了這個變更，那麼其餘全部的事情都解決了呢?

「變更」的疊加效應docker

以上的問題都會致使在接口測試與管理上效率低下，也就是咱們常說的ROI低下，一個直觀的分析圖示以下

接口測試與管理ROI分析api

接口測試的ROI = f（成本，收益），要想提高ROI，那麼就應該作兩件事情：減小投入成本，增長使用率。減小投入成本，能夠從如下幾個方面入手：

減小用例編寫的成本（1個接口/10個用例/2小時）
減小用例優化的成本 (用例描述清楚，很難分層優化 )
減小用例維護的成本（1個接口變更，平均維護1小時）
減小工具開發的成本（公共測試服務無法公用，重複造輪子）

增長使用率，能夠從如下幾個方面入手：

手工能用
人人能用
當工具用
各個階段用

爲此圍繞着接口測試與管理的ROI提高專項活動就不得不實施起來。從接口測試與管理的全生命週期分析所面臨的挑戰。

問題與挑戰安全

2、接口測試與管理的解決方案進階

2.1 接口測試編寫的6大要素

如何真正的減小「用例編寫、優化、維護」的成本，應該要分析接口測試用例編寫應該具有哪些部分，從中提取出能夠優化的元素進行細緻的分析和對症下藥。以下所示在接口測試編寫過程當中所列舉的6大要素：

接口測試編寫的6大要素markdown

針對其中2大要素示例展現下分析所面臨的問題及解決方案

**【面臨的問題】**

首先要明確的是參數化和生成器的定義，參數化：即把具體值換成參數形式來表達的過程就是參數化。生成器：根據需求去產生具體特性的值。能夠預知在構建一個接口測試場景的時候，一個接口入參，它多是固定值，亦或是變量，而變量的生成，須要根據需求按照場景去特定的去生成，好比建立賬號須要隨機生成，那麼就須要隨機數；參數的簽名和加解密；時間戳參數的構造；等等；另一個層面，參數是具有位置屬性和做用域屬性的。位置屬性中可能在路徑、URL、請求體或者請求頭。而做用域屬性多是對全部接口測試場景全局有效的公共參數，也多是在一個場景中生效的，甚至於只是臨時產生的。如此看來，要解決參數化及生成器的問題，要結合上述所分析的特色。

**【解決方案】**

針對參數化及生成器的解決，是做用於不一樣的接口測試場景及接口測試階段。參數化的實施分爲兩大類：通用型參數化和業務型參數化。通用型參數化實施是圍繞着GoAPI接口全生命週期測試平臺去完成的，業務型參數化是自研測試數據服務平臺

2.2 接口測試執行的5個多

從接口測試執行的多維度分析，涉及5個多：

多粒度：單接口、接口場景、執行集
多環境：測試環境、預發佈環境、生產環境
多角色：開發、測試、運維
多數據：global數據、local數據、temp數據
多階段：開發調試、自測冒煙、功能測試、發佈驗證、線上迴歸、持續集成、線上監控

接口測試執行的5個「多」架構

在接口測試執行層面分析面臨的問題及挑戰，涉及4個層面：

執行環境受限
使用階段受限
使用角色受限
線上監控不成體系

2.2.1 執行環境受限

分析歷史對於採用java+TestNG+ Jenkins的典型接口測試框架，在執行環境層面面臨的問題有以下3點：節點資源利用率不高、資源配置存在衝突、擴展節點遷移不便捷。如此第一階段實施，在當時採用的是「容器化」的思路：Jenkins集成docker實現slave容器化，根據不一樣環境構建不一樣類型的slave node鏡像模版，每次執行自動拉起對應容器，執行完整自動銷燬。

第二階段的實施，在完成接口測試平臺化以後，一樣的思路解決問題，也就是在GoAPI中引入執行器的概念，而每個執行器都是一個容器，容器內部會啓動一個服務與GoAPI平臺聯動。不管你是哪一個環境，能夠動態在執行接口測試任務的過程當中修改對應的hosts，保證環境的無縫切換，完全解決了執行環境受限的問題。整個容器管理採用的是rancher+K8s，以下圖所示

這種解決方案具有6大特色：

多節點：穩定可靠
多環境：知足平常功能測試、迴歸測試、預發佈驗證
多機房：快速驗證異地多機房的高可用架構
可管控：私有化部署線上監控執行器，對線上測試請求進行安全管控
可調度：與自動化發佈集成，發佈後馬上調度執行器，觸發自動化驗證
可共享：共享執行器信息，方便開發同窗快速自測，協同QA測試

2.2.2 接口測試使用階段受限

當你解決了接口測試編寫及執行過程的問題，將各個業務對應的接口覆蓋度提高到了95%以上的時候，就須要開展實施的是如何將已有的自動化價值最大化。而如何最大化，就是要讓已有的自動化用例使用貫穿整個軟件開發週期，且使用者要包含開發、測試、運維等

結合以上圖示分析，存在的問題是實施階段不完善，角色使用受限。那麼從解決方案來講能夠從如下3個方面實施：

結合持續集成實施開發自測驗證
結合發佈平臺實施PE發佈過程驗證
結合GoAPI實施完整的線上接口監控

接下來看下這3個方面是如何實施的。

結合持續集成實施開發自測驗證併發

結合持續集成實施開發自測驗證

以上提供的是內部業務目前正在實施的持續集成pipeline，將在GoAPI上已有的自動化，歸入持續集成鏈路，只須要經過GoAPI提供的很是友好的OpenAPI，一樣的能夠花點看劇的時間寫個GoAPI執行驅動插件，也是極好的。以上流程扭轉以下：

開發提交代碼經過webhook自動觸發構建，構建成功；
執行單元測試卡點，所有PASS且覆蓋率卡點經過；
執行靜態代碼檢查，聯動sonar完成卡點判斷；
打包鏡像上傳到私有倉庫並執行部署服務；
調用GoAPI接口測試平臺openAPI執行對應接口自動化；
調用smartauto智能UI自動化平臺openAPI執行對應UI自動化；
調用npt性能壓測平臺openAPI執行對應性能自動化迴歸；
調用CR變動代碼覆蓋平臺獲取本輪變動代碼覆蓋率；
輸出總體質量測試報告，涵蓋多維度質量度量；

**結合發佈平臺實施PE發佈過程驗證**

某個業務線上應用集羣上百臺機器，而線上迴歸執行運行一次不能完整覆蓋到每臺機器上應用實例的可用性，可能會形成某臺應用實例由於不可知因素帶着問題上線，致使線上故障。那麼對於PE而言，他們的訴求是但願每次發佈的每一臺應用實例都是通過自動化迴歸過的，基於此，結合內部發布平臺實施方案以下

發佈自動迴歸方案

通常的發佈平臺都應該具有如下步驟：offline、deploy、check、online；先將當前實例下線，接着部署，而後check服務可用性，最後online到線上提供服務。只是當前check這一步只是健康檢查，而非服務功能性驗證。那麼如此能夠基於check擴展去調用GoAPI openAPI實施自動化執行，經過後再自動online。經過這個方案實施後，PE每次發佈不再會「提心吊膽」，由於每個應用實例都是通過嚴格功能迴歸後上線的。以上從軟件研發週期，針對開發自測、發佈過給出瞭解決方案，但最重要的環節是線上接口監控。經過監控是否可以及時發現接口不可用，減小對用戶的使用及體驗是很是重要的，接下來就聊下在作線上接口監控所面臨的問題及解決方案

2.3 線上接口監控閉環

回到2014年，基於java+TestNG+jenkins所實施的線上接口監控，所面臨有4大挑戰：

執行穩定性影響因素多（環境因素、用例依賴問題等）
告警機制不完善（只有單一的告警通知，且告警沒有可配置策略）
失敗分析耗時（基於TestNG執行日誌分析以及用例場景鏈路數據依賴，耗時長）
未很好的造成閉環（告警準確率低，線上接口問題召回率低）

爲此針對以上問題結合接口監控，分析監控應該具有6大要素：

持續穩定的7*24小時監控
完善的告警通知機制
接口返回碼監控
接口異常監控
接口性能監控
接口業務邏輯監控

接口監控6大要素及解決方案

結合內部監控系統完成對接口異常、返回碼、性能等的監控，而業務邏輯定向監控依賴GoAPI接口管理平臺實施從監控、告警、處理、歸檔、統計造成有效閉環，以下圖示是1個業務線的監控實施狀況：

2.4 接口測試與管理的收益

圍繞着減小投入成本和增長使用率兩個方面進行了多項實踐活動，使得總體的ROI獲得了大幅度的提高。以下基於一個內部業務的統計分析

接口測試與管理的ROI

3、一個行業領先的接口測試平臺

GoAPI 是圍繞接口全生命週期管理、提高研發與測試效率爲目標的團隊協做平臺。平臺提供便捷的接口管理，無門檻與多維度的自動化測試，完善的 OpenAPI 擴展等多種豐富能力，大幅下降企業研發和測試成本。體驗訪問：[GoAPI接口測試平臺](https://www.163yun.com/product/goapi?fromyice=M_juejin_6857026426718453768)

基於接口的團隊協做平臺

一個xx業務應用詳情，來感覺下1萬+接口的測試是如何作到的：

產品概覽

接口測試

場景測試

執行集

【關鍵總結】

一個平臺的誕生必定是源於業務的問題與挑戰不斷的演進而成；
如何提高ROI，其核心是圍繞着減小投入成本和增長使用率；