一、引言
?對于大廠的同學來說，接口自動化是個老生常談的話題了，畢竟每年的MTSC大會議題都已經能佐證了，不是大數據測試，就是AI測試等等（越來越高大上了）。不可否認這些專項的方向是質量智能化發展的方向，但是凡事都遵循2/8定律，80%的從事軟件測試的同學或許對這些并不感冒，因為大部分測試同學分布于中小廠，而他們大多停留在如何更好更快地進行接口自動化的階段。

小廠質量團隊地位低，在團隊中發言分量輕，項目中往往處于劣勢，項目的測試時間不能保證，更別提搞什么高大上的質量專項了，能把接口自動化測試做好就是大事一件，節省不少時間了。

因此，聊聊接口自動化還是非常有必要的。

二、“JMeter式”的自動化設計思路
毫無疑問，聊起接口自動化，大家可能第一時間聯想的就是自動化工具、自動化框架，例如JMeter、Postman等。這些工具學習成本小，掌握這些工具用法算是一條腿邁進了自動化測試大門。當然我建議大多數測試菜鳥先從工具的使用學起，話說“讀書百遍，其義自見”，用多了你也就理解了工具本身的設計（模式）精髓，為將來自己動手設計工具打好基礎。

我也曾設計過接口測試工具（參考文章），但是現在回過頭再看看開發出來的東西，或多或少有些JMeter的影子！是的比葫蘆畫瓢，JMeter已經在你腦海里先入為主了，你開發的接口測試工具有它的影子也不足為怪。換句話說，這或許是JMeter式的重復造輪子。

以我之前設計的測試工具為例，使用它就要動手搜集接口信息，動手組裝入參，動手寫斷言。。這TM就是和使用JMeter寫用例要做的事情一樣的嘛！

JMeter式的自動化測試，我認為是“高級”的手工測試。自研的測試框架寫用例往往需要代碼基礎，但是寫過的都知道，業務用例代碼重復度挺高的。而更重的在于用例的維護，畢竟大家寫的代碼風格迥異，維護的難度更大，甚至不如JMeter的用例維護來的方便。

意識到這個問題后，我也嘗試在github上搜索stars比較多的開源自動化工具，遺憾的是這些框架始終擺脫不了這個“設計套路”。例如

當然，說上面這些并非不建議大家開發接口自動化測試框架，自研的接口測試框架同樣有很多優點。

測試工具開發的測試用例往往不易于維護，試想一下當你維護JMeter生成的各種JMX文件場景。

大量的測試用例可重用性差，例如登陸模塊，每個接口調用前都要獲取cookie，而登陸則是前置模塊，使用JMeter開發用例需要每個JMX文件都要包含登陸，重復度太高。

無法滿足自動化平臺訴求，短期內確實可以快速實現自動化，但是這些工具對于平臺非自動化能力的拓展成本較高，畢竟改動開源工具的成本比自研高很多。

使用開源工具不利于提升團隊在自動化技術方面的成長。自動化能力的提升離不開編程能力的提升，使用開源工具能提升工具學習使用能力，最終你的成長無外乎又掌握了一個測試工具的使用。

那么，如何擺脫JMeter式的傳統思路，用更多的自動化代替手工？？

三、讓自動化框架更自動化
接口自動化的核心是什么？接口、數據、斷言。

正如上文說的，這也是我們手工重復度比較高的工作內容，也是痛點所在。

傳統的自動化用例設計，往往需要人工采集接口信息（例如抓包，然后寫腳本提取接口信息HTTP Type、Method、Request等），人工造入參數據等，這些重復度是極高的。更進一步來說，人工造入參數據更是痛中之痛，畢竟不同的業務需要構造的request內容是不同的。

那么如何自動化實現呢？

不妨大家先考慮我們是在哪里獲取的這些信息。例如接口信息，你是否有過通過開發者工具提取接口信息？是否有過解析Charles工具har文件提取接口信息？以及解析swagger等接口文檔工具。。。。然后通過提取的接口信息生成自動化框架所需的接口請求service。

但是，接口信息就在那里，為什么還要將其從一種載體中提取出來再轉化為另一種類型的接口信息。難道直接使用類似har文件、swagger的接口信息就不行嗎？當然是可以的。例如美團的Lego測試平臺。

可以直接解析其他接口測試工具文件里的接口信息，以下拉列表的方式供測試使用者選擇要寫用例的接口，當然該接口request、Method等信息要同步填充到對應的輸入框。這樣就省去手工輸入接口信息的時間。

剛剛說了，構造入參數據是痛中之痛？這部分如何自動化？

我的答案，入參數據從線上服務器日志里去取。試問，我們構造的數據難道有線上業務真實跑出來的數據更貼合我們要測試的業務嗎？當然沒有。

so，線上服務器的日志格式務必要規范化，這樣可以方便我們提取xx接口的請求數據。有條件的公司可能會有自己的分布式鏈路追蹤，這樣可以基于trace提取出某個接口的請求和響應的所有信息。

斷言怎么自動化？

其實這個的解法和第2個問題一樣，我們在從日志中提取接口信息的同時，肯定也是有xx request參數下的xx response相應信息，我們可以將此次的響應信息作為基準，下次相同的request再次請求的時候，得到的響應和基準響應做比較就行了。當然，這個其實也是流量回放的思路。

四、總結
本文是我對此前設計的一個測試框架的反思，當時設計框架的“上下文”（即團隊基建能力、以及自身的設計水平和負責的項目的業務架構等背景）和現如今所在的公司質量基建是有很大差別的（有時候很多想法的實現是需要一定基建能力支撐的）。在一定程度上，也算是站的更高，看的更遠吧。

最后感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：

?

這些資料，對于【軟件測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴上萬個測試工程師們走過最艱難的路程，希望也能幫助到你！