【分享】圍繞 API 團隊協作與自動化測驗的實踐！

2022 年 7 月 8-9 日，QECon 全球軟體質量&效能大會在深圳舉辦，大會聚焦“研發效能、卓越工程、質量工程、數智化測驗” 四大主題，吸引了數千名行業從業者參與，

會上，Eolink CEO 劉昊臻發表主題演講《圍繞 API 團隊協作與自動化測驗的實踐》，在 API 資產被越來越多開發者和企業重視的情況下，我們如何做好圍繞 API 的全生命周期管理以及研發協作？

劉昊臻從行業趨勢、痛點，建設目標、實踐經驗、案例成果以及開源計劃等幾個方面，和大家分享了 Eolink 在 API 的團隊協作與自動化測驗方面的一些實踐，

演講概要：

• API 管理的行業趨勢、現狀、痛點

• API 管理平臺的建設目標

• API 管理與自動化測驗平臺的實踐經驗

• 應用案例與成果介紹

• 開源計劃與 Todo List

以下為劉昊臻演講全文：

大家好，我是 Eolink CEO 劉昊臻，我們在 2017 年創辦的 Eolink，至今為超過十萬家企業客戶管理 API，也是目前國內最大的 API 管理 SaaS 平臺，我們希望能幫助企業通過 API 連接全球的資料和服務，

| API 管理的行業趨勢、現狀、痛點

在早期開發軟體，由于軟體的系統復雜度不高，通常我們把所有代碼都封裝成一個整體，我們把這種架構叫做單體應用，

隨著軟體架構、開源生態的發展、以及我們對軟體開發效率的追求，企業逐步開始使用開源代碼或者第三方 API ，

現在隨著云原生的普及，和微服務架構改造，幾乎所有企業都大量使用了開源組件、第三方的 API ，甚至底層的核心技術幾乎都是來自于第三方 API ，

來自 Linux 基金會的資料顯示 7090% 的代碼是由開源和第三方 API 來組成的，并且通過 API 產生的經濟價值也變得非常巨大，現在行業內的絕大部分公司的現狀，發現大家都面臨一些基礎問題的挑戰，

比如有一半以上的團隊，將半數時間花在了圍繞 API 相關的作業上面，包括 API 開發、檔案管理、前后端對接聯調、自動化測驗、安全防護、穩定性保障等方面，

現在隨著企業對降本增效的進一步追求，代碼管理及 CI/CD 也已經普及的情況下，許多團隊也開始思考從 API 方面是否能夠進一步提高團隊的效率，讓大家能夠加更少的班，做出更好的產品，保障更好的質量，

Eolink 在過去每半年都會對用戶做一次訪談，了解用戶的一些痛點及需求的變化，

我們發現，大部分的團隊都會認為 API 管理是一個非常繁瑣的事情，API 的數量、協議、規范很多，撰寫麻煩，導致 API 檔案的維護成本居高不下，其中有以下幾項：

通過這些用戶反饋，我們會發現 API 管理的問題往往分布在不同的團隊里面，各種的訴求也不一樣，因此很難通過一個簡單的單點產品來解決，

于是便有了第一個問題：

我們要建設一個什么樣的 API 管理平臺，它的建設目標是什么？

| API 管理平臺的建設目標

IT 系統的建設往往是為了實作業務目標，API 系統的建設，其實就是要讓 API 成為推動業務發展的手段，

良好的 API 能夠讓內部迭代新產品或者新版本更快，能夠讓外部的協作者，合作方或者是客戶更容易對接大家的產品，逐漸形成產品生態，甚至是讓 API 能夠產生交易的價值，前段時間企業微信就開始對微信第三方介面的呼叫進行收費，許多 SaaS 公司也將開放 API 作為重要的戰略，因此，建設 API 系統并不僅僅是為了降本增效，更加是為了讓 API 能夠幫助企業完成業務目標，甚至成為第二增長曲線，

在這個目標之下，我們首先要讓開發變得更簡單，讓我們 API 的管理變得更規范，讓測驗的作業能夠逐步自動化，讓運維能夠更加智能，并且讓 API 能夠成為一個平臺上的服務，而不是分散的管理，

于是就有了介面快速生成、前后端對接、零代碼自動化測驗等等的一些需求，背后對接著各種的資料庫，各種型別的介面，幫助我們去整合微服務，甚至是與代碼管理等平臺能夠關聯起來，讓 CI/CD 體系更加完善，

API 全生命周期一覽圖

有了目標，有了整體設計，接下來我們把 API 的各個階段列出來，就能夠看到 API 管理其實是一個流程長，且內容復雜的系統性問題，我們把它稱之為 API 的全生命周期管理，

Eolink 在過去幾年經歷了許多探索，根據 API 全生命周期的需求，逐步推出了一系列 API 相關的產品，包括 API 快速生產、研發管理、自動化測驗、網關、監控、開放平臺等，實作對 API 的全生命周期覆寫，

| API 管理與自動化測驗的實踐經驗

我們團隊在 2016 年思考如何解決上述問題時，提出需要結合檔案驅動與測驗驅動兩種模式，

首先檔案驅動 指的是在開發 API 之前先把檔案寫好，明確功能需求、入參出參定義、例外情況處理等之后再進行開發，

測驗驅動，則是要求每次迭代、每個介面都需要及時測驗，如果測驗不通過則需要持續進行改進，盡量不要將測驗作業留到最后，

結合檔案與測驗驅動，就要求團隊用清晰的檔案代替口頭表達，讓開發、測驗、運維、協作有跡可循；用測驗結果推動開發進度，讓團隊溝通更直接，

我們發現在整個協作程序中，API 的資訊其實是在不同的團隊之間反復傳遞的，并且團隊與團隊之間往往存在等待的情況，前端需要等后端把介面先寫好才能進行對接，測驗團隊需要對照著介面檔案才能夠設計測驗用例，或者是撰寫測驗代碼，而介面在開發的程序中也不是一成不變的，即使上線了也有可能會修改，

因此，前端和測驗團隊就得根據最新的介面來調整自己的前端頁面，或者是測驗腳本，

于是我們總結出幾個關鍵的問題：

• 如何解決團隊之間的 API 共享？

• 如何讓前端能夠脫離后端提前進行對接？

• 如何能更快創建甚至自動創建測驗用例？

• 如何讓介面的變化能夠自動通知到相關人員，甚至是推送到相關的測驗用例或者是 Mock ？

• 如何解決多團隊之間的異步協作？讓大家都能夠同時作業，而不需要互相等待，

這些問題在當時業內都沒有很好的解決辦法，因為要實作跨團隊 API 協作，就需要打通不同團隊的工具及資料，而市面上的產品都比較獨立，

比如檔案管理用 Swagger、Wiki 甚至是 Word 和 Excel、測驗用 Postman、Jmeter、Pytest、運維也有自己的 APM 等，因此我們團隊只能通過自研的方式逐步完善產品，并且實作全流程覆寫，開始了一系列的填坑之旅，

檔案管理

首先一個好的檔案是成功的開始，

我們做了一個圖形化的 API 設計界面，支持 HTTP、Websocket、TCP、UDP 以及 Dubbo 等協議，讓我們可以通過模板以及資料結構來快速創建 API 檔案，檔案里面會記錄詳細的引數、說明、示例等資訊，并且自動生成 Mock，如果之前用過 Swagger 和 Postman 的也可以直接匯入資料，或者系結代碼倉庫，讓我們從注解中掃描生成檔案，

為了讓生成檔案更方便一點，我們做了 IDE 插件，可以直接滑鼠右鍵生成 API 檔案，目前支持 Java，未來也會考慮支持更多語言，

版本管理和共享

有了詳細的 API 檔案，接下來我們就可以像代碼一樣對 API 進行版本管理，比如每次 API 修改了哪里，欄位的增刪改查都可以標注出來，并且配合自動通知，比如通過郵件、飛書、企微、釘釘或者其他方式通知相關人員，讓 API 的變更通知更加及時，

為了解決 API 在團隊間共享的問題，我們還加入了分享鏈接，可以設定密碼和分享范圍，直接把檔案鏈接發出去就可以讓其他成員查看或者測驗，有些情況下我們還希望對檔案進行歸檔或者發給外部人員，這時候直接匯出為離線檔案，比如 PDF、Word、Excel 或者 HTML 都會更加安全，

通過以上的一些功能，我們就可以基本解決 API 資訊在團隊之間的共享問題，

快速測驗

在整個 API 的迭代程序中，測驗是一個非常高頻且剛需的需求，當我們把 API 檔案給管理好之后，我們希望能夠讓程式自動幫我們生成介面的測驗頁面，

因為在 Postman 或者是其他的測驗工具里面去構造 Json 等資料是比較麻煩，只能夠直接寫一個完整的 Json 字串，所以我們做了一個 Json 資料的圖形化編輯器，讓新手也可以在界面上直接撰寫 Json 和 XML 的請求資料，相信大家在測驗程序中也經常需要對資料加解密或者生成隨機資料，為了解決這個需求，我們還做了一個叫做資料構造器的功能，讓開發和測驗的同學可以在界面上直接對資料進行處理，

比如做 MD5、SHA 加解密、截取字串或計算長度等，還可以隨機生成各種型別的資料，比如說像身份證，手機號，郵編等等，

為了讓測驗好的介面和資料能夠直接用在代碼里面，我們做了代碼的生成，可以直接從測驗用例來生成各種語言的代碼，直接復制粘貼就可以用在專案里面，

用例管理

當我們做完測驗，往往還希望把這些測驗的資料給保存成測驗用例，方便我們下一次測驗的時候能夠快速呼叫，因此，我們在產品里面也集成了測驗用例的管理，除了保存測驗用例之外，還可以在測驗用例里面設定斷言規則，讓系統自動判斷回傳結果，

下次當我們在進行回歸測驗的時候，就可以直接一鍵批量測驗完所有的用例，并且看到介面在各種條件下是否產生例外，可以極大的提升測驗的效率，

Mock

那么如何基于 API 檔案做前后端對接呢？這里就少不了要用到 Mock API，

Eolink 可以自動根據 API 檔案來生成 Mock API，比如 API 檔案里面標注了有幾種回傳結果，系統會自動針對每種回傳結果都生成一個對應的 Mock API，

如果覺得系統自動生成的 Mock 比較簡單，我們還可以手動創建更強的 Mock，比如根據不同的請求引數觸發不同的結果，通過撰寫 Javascript 來處理請求和回傳資料，還支持 MockJS 等工具來快速生成資料，基本可以模擬各類 API 的情況，API 檔案結合 Mock，讓 Mock API 的使用更加簡單，配合 API 版本管理和變更通知，也讓前后端的作業流程自然結合到了一起，

自動化測驗 & 測驗報告

解決了前后端協作，接下來就是讓測驗作業也能自動化起來，在這里我們也做了一些新嘗試，

比如有了 API 檔案，我們會根據檔案中對 API 的定義來排列組合，自動生成各種情況的測驗用例，比如邊界值、例外型別、引數缺失等情況，

而且可以在界面上直接編排測驗流程，比如注冊、登錄、下訂單、查物流、退出登錄等一系列流程，里面涉及引數傳遞、資料處理、資料庫查詢、結果校驗等作業，都可以在界面上完成，當我們設計好測驗流程，下一步就是考慮怎么樣能夠讓他自動地執行？在了解了許多用戶的使用場景之后，我們在產品里面加入了定時以及觸發式兩種方式來執行自動化測驗，

比如說我希望每天凌晨的兩點鐘，對關鍵業務或者是前一天提交的代碼進行完整的測驗，或者是每一次代碼提交的時候都能夠通過 Jenkins 或者是 Gitlab 之類的產品來呼叫我們的介面，觸發相應模塊的自動化測驗，測驗完成之后，我們還需要一個地方來統一管理所有的測驗報告，報告里面需要展示測驗的成功率，耗時，錯誤的用例串列以及錯誤的原因等，一個好的測驗報告，可以幫助我們快速排查錯誤，減少非常多的不必要溝通，

而且和 Mock 一樣，測驗用例也是有可能發生改變的，那怎么樣能夠把這些 API 變更自動同步到測驗用例里面呢？我們做了幾種方案之后，最終決定做一個功能，可以一鍵將最新的 API 檔案同步到測驗用例里面，比如說檔案添加或者洗掉了某些欄位，那么用例里面也相應地增加或減少這些欄位，

這樣就可以進一步降低 API 自動化測驗的學習和維護門檻，讓一個實習生也能快速掌握 API 自動化測驗，

新的嘗試 & 改進

當然這還不夠，我們嘗試將流程圖也加入到自動化測驗中，讓我們可以真正地拖拉拽生成測驗流程，并且支持回圈、分支等判斷條件，更進一步的，我們在目前嘗試結合 AI 的功能，讓系統可以自動生成測驗流程和測驗資料，真正減少 90% 的自動化測驗作業，

經過以上的一些調整之后，我們就可以發現，原本的 API 協作流程從一個串行的流程變成了并行的流程，后端、前端以及測驗團隊能夠獨立的開展作業，又互相之間有合作，比如像現在的這個流程圖，后端先在產品里設計好 API，然后可以通過平臺來生成基礎的框架代碼，并且在框架代碼的基礎上繼續開發，

因為 API 檔案已經事先設計好了，所以系統能夠自動地根據 API 檔案來生成 Mock API，讓前端能夠直接對接 Mock API 來除錯頁面，測驗團隊也能夠直接在系統中基于 API 檔案來撰寫測驗用例，這些測驗用例并不是像傳統的那種思維導圖，而是能夠直接運行的測驗用例，相當于將測驗用例的設計和編碼作業都提前進行了，

當介面開發完成之后，后端可以自行使用測驗團隊寫好的測驗用例來自測，前端可以將 Mock API 的地址注釋掉然后再做更進一步的除錯，測驗團隊可以針對所有的介面進行冒煙，或者是回歸測驗，并且將測驗用例按照業務場景編排成測驗流程，設定定時測驗任務，或者是當下一次代碼提交或版本發布時，對整個專案進行大范圍的回歸測驗，保證系統質量，

| 應用案例與成果介紹

現在 Eolink 提供線上 SaaS 和私有化部署兩種產品，并且已經應用在了多家成熟企業中，比如像奇安信、深信服、泰康集團等客戶目前都在使用我們的 API 管理與自動化測驗產品，管理內部超過 10 萬的 API 資訊并且進行自動化測驗，

奇安信的許多產品線在版本發布地都需要經過我們進行全面自動化測驗，確保產品的核心業務流程沒有問題才可以繼續驗收，

接下來我拿某個金融行業的客戶作為例子，看一下圍繞 API 的團隊協作以及自動化測驗能夠如何提升研發效能以及產品質量，

我們在 2020 年收到某銀行的科技部邀請，希望我們能夠幫助建設開放銀行業務，其中很重要的一部分就是 API 的研發測驗一體化平臺，因為 API 是開放銀行的核心，所以他們希望能夠借此機會構建銀行的介面管理規范體系，加速 API 開發與測驗作業，為后續的開放銀行業務打好基礎，

銀行方面在我們之前已經試過許多產品，包括自研平臺、阿里云效、YAPI、RAP 等，但是都存在一些問題，比如對協議的支持比較少，一般只有 HTTP，缺乏版本管理，Mock 比較簡單，沒有將研發和測驗團隊的作業流程打通，導致效果并不理想，

而且熟悉銀行的朋友應該都知道，銀行內部往往有數量眾多的供應商提供系統服務，而且許多系統的存在時間非常長，可能已經運行了十幾年，因此不同的供應商、系統的 API 怎么做統一管理就是一個非常大的問題，

檔案驅動

在了解情況之后，我們提出了檔案和測驗驅動的理念，建議通過一個統一的平臺來規范地管理銀行內部所有的 API 資訊，并且圍繞 API 資訊進行協作，聯動前端、后端和測驗人員，構建更加敏捷的團隊，并且這個 API 平臺還可以通過 OpenAPI 與其他系統對接，強化 DevOps 能力，

測驗驅動

在管理好了 API 之后，接下來就是要做自動化測驗，通過界面而非代碼的方式來做 API 自動化測驗，可以讓不同供應商的人員以及銀行內部人員都可以快速上手，并且極大地提高效率，在這個程序中還可以不斷完善測驗資料，通過定時任務和持續測驗來改進系統質量，

這個方案提出之后得到了銀行方面的認可，并且也得到了非常不錯的實施效果，我們一起來看一下，

• 亮點 1 : 通過平臺實作 API 變更與訂閱管理

首先是我們通過平臺來實作 API 的變更和訂閱的管理，值得特別關注的是，這里我們還對接了銀行內部的版本發布平臺，每次版本的迭代，或者是每個介面的變更，都可以設定版本號，當發布的時候就可以直接通知到介面的使用方，或者叫訂閱方，

在產品內部，我們還維護了一套 API 的訂閱關系，專案之間如果需要互相使用介面，則需要通過平臺提前訂閱，審核通過之后才能看到或者測驗、對接相應的 API，這樣也提高了介面呼叫的規范性和安全性，

• 亮點 2 : 通過平臺將 API 檔案轉換為標準 ESB 配置

其次是我們取代了低效的 Excel 表格來管理 API 資訊，之前銀行內部有接近 200 套系統，上萬個介面，這些介面存盤在大大小小的不同的 Excel 表格里面，發布的時候需要通過 FTP 將表格上傳到 Esb 系統的特定目錄才能完成發布，整個程序非常的麻煩，而且之前的介面變更是通過郵件和線下口頭溝通的方式，導致效率低下，

現在通過統一的 API 平臺來存盤 API 資訊，并且將 API 快速發布到 Esb 就可以完成介面的版本更新，讓整個程序更加簡單，更加自動化，

| 開源計劃與 Todo List

• Eoapi

借著這個機會，我們也很高興和大家聊聊產品的開源計劃，我們把兩個核心產品逐步開源，讓更多開發者和企業都能使用到我們的產品，并且促進 API 生態的發展，

首先是我們會把目前的 API 管理和測驗的核心模塊開源，我們把這個專案命名為 Eoapi，也就是 Easy & Open API，它能提供高效的 API 管理和測驗功能，并且可以通過自定義插件來擴展功能，和現在市面上的 API 管理或者測驗工具相比，Eoapi 的插件系統可以讓社區在產品上實作各種各樣的附加功能，如果你想將管理好的 API 資訊快速匯出為一種你們自定義的格式，或者接入一些 API 安全測驗工具，都可以通過插件來快速實作，

• Apinto

其次是 Apinto，這個名字是由 API 和 Into 兩個單詞組合而成，意味著 API 的入口，Apinto 是我們將 Eolink 的企業級 API 網關徹底重構之后，重新設計的開源網關產品，

這是一個完全由 Golang 撰寫的高性能微服務網關，在相同環境下最高可比 Nginx、Kong 等開源產品提高約 50% 的訪問性能，并且擁有極低的使用和部署門檻，和 Eoapi 一樣，Apinto 也是一個插件系統，可以自由撰寫插件來擴展功能，相比于已有的開源網關，Apinto 結合了我們在 API 全生命周期中的一些最佳實踐，而且基于 Go 語言開發，相信可以給喜歡 Go 語言的團隊一個新的選擇，

| 未 來

除了大力投入開源產品，目前我們也正在逐漸將AI能力融入產品中，讓我們可以通過更智能的方式解決 API 相關的問題，并且通過插件市場和 API 開放平臺，讓更多開發者和企業可以一起參與 API 生態的建設，

標籤：其他

上一篇：SpringCloud服務搭建

下一篇：leetcode 128. Longest Consecutive Sequence 最長連續序列(中等)