隨著公司業務的增長、專案需求的不斷變化，運維的成本越來越高，開發人員996也越來越常態化，而在大部分公司實行前后端分離的當下，研發團隊用在溝通、測驗、管理API中的時間和用在開發專案代碼上的時間也越來越相差無幾，
以下和API相關的問題廣泛出現：
API 檔案不清晰而不知道怎么對接和測驗，需要反復和后端溝通，甚至要看代碼；
前端和測驗需要等待API開發完成才能繼續進行作業，測驗用例無法復用；
API變更了沒有及時跟進，不知道哪里改動；
介面檔案和測驗是兩套系統，來回切換并且無法同步資料；
自動化測驗需要寫腳本，學習成本、時間成本、維護成本高；
不著急說解決方案，我們先來理一下API開發的驅動方式，
在API開發的程序中，基本可以分為檔案驅動和測驗驅動，前者是指開發前先寫好介面檔案，用標準檔案代替口頭約定和筆記檔案；后者是指在開發前先寫好測驗用例，快速用測驗結果推動開發進度，
那么這兩種驅動方式是割裂的嗎？答案我會說不是，
傳統介面檔案的缺陷在于三點：自然語言的描述容易產生歧義；不能自動化地驗證；不能保證檔案與開發同步，由此，延伸出了與之對應的測驗驅動，
那么換個思路，如果有個工具，能自動生成檔案、還可以滿足大部分的介面測驗功能，不就可以了？
我們公司最近由于國產化需求，開始找新的API管理工具，后面找到了一個還不錯的，叫Eolinker，能滿足我們研發團隊的API開發管理需求，還能直接匯入原來的Postman和Swagger上的API專案和介面檔案，
放兩張使用的圖，有用過的可以一起交流一下~
場景1：前端開發已經對接完API，將當前API狀態改為待測驗，并且通知相關測驗人員進行測驗，
場景2：后端已經開發完成API，自行使用測驗人員寫好的測驗用例對API進行批量測驗，排查錯誤，
使用地址：www.eolinker.com
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/242750.html
標籤：其他