對非同步處理的http介面進行效能測試

以前對介面做效能測試，介面都是同步處理的，請求之後等待響應結果就知道處理結果了，這樣只要看這個介面是否異常，如果無異常無報錯記錄這個介面的響應時間、TPS等效能指標進行分析就可以了，最近在工作中遇到了非同步處理的介面，邏輯是隻要你請求引數全部合法，即返回成功。

通俗理解一下同步和非同步的差別，舉個小例子：

同步就是你媽喊你吃飯，你說等一下，然後你媽媽就一直在旁邊等著你，專門等著你，等你做完了，一起去吃飯；

非同步就是你媽喊你吃飯，你說等一下我忙完了就過去，你媽就走了，該幹啥幹啥去了，你忙完了，直接過去吃飯。

那麼問題來了，這種介面，如果還像以前一樣單純的看介面的響應時間，就沒有任何意義了，那麼如何判斷介面的效能呢？

先來描述一下被測系統：

這是一個專門負責傳送訊息的平臺，包括簡訊訊息和裝置訊息，大概架構如下：整個系統分為前端和後端，前端負責接收客戶端的傳參，把資料寫入資料庫並插入訊息佇列MQ；後端負責傳送訊息，佇列MQ的消費，並更新資料庫記錄佇列訊息的消費時間及傳送狀態；介面全部為非同步處理機制，下面以傳送介面為例，簡述整個測試過程：

1、制定測試方案

開始效能測試了，說明系統功能已經穩定，無遺留嚴重bug，此時需要對系統的需求做個調研分析，確定被測系統的效能測試方案，這裡可以從需求出發，初步確定性能測試方案。確定測試場景為單介面場景，選取三個呼叫頻率最高的介面來測試，和開發及運維等相關人員確定壓測環境、伺服器配置等資料，通過壓力測試工具jmeter關注響應時間、每秒TPS及錯誤率，同時使用阿里雲監控平臺監控伺服器記憶體和CPU使用情況。採用循序漸進增加執行緒數的方式得到介面的最大處理能力。

2、確定測試資料

為了儘量模擬真實場景，需準備不小於併發數百分之20的資料作為壓測資料。

壓測資料寫在excel中

ps：這裡有個坑，因為訊息系統是給使用者傳送簡訊及訊息，一不小心可能導致訊息傳送到真實使用者了。此處有兩個解決方案：a、讓開發處理手機號校驗的程式碼，把程式碼註釋，手機號使用不存在的數字組合即可

b、開發做擋板，遮蔽呼叫第三方傳送介面

3、根據測試場景編寫測試指令碼

共三個介面，https協議post請求

呼叫介面無需token，因此只需要把入參拼接排序加密簽名即可，入參處理方法可以用java寫好打包放到jmeter的lib目錄，在beanshell中import進來直接呼叫即可

4、執行測試

 測試指令碼除錯通過，就可以執行測試了。

按照常規介面的測試方式：就是從1個執行緒數開始，每次壓測5分鐘左右，壓測過程中監控伺服器cpu及記憶體佔用情況，記錄tps及響應時間，不斷增加併發數，找到tps隨併發數增大的拐點，即得出介面最大處理能力。

但是以上方式並不適用於這種非同步的介面，那麼如何處理呢？

此處通過查詢資料庫。當所有請求全部完畢了，查詢資料庫的傳送資訊表，檢查請求時間欄位和傳送時間欄位，請求時間字記錄該請求的呼叫時間，傳送時間欄位是後端傳送訊息後回寫到資料庫的傳送時間，故請求時間欄位和傳送時間欄位的差就是這一個請求的完整的響應時間，可以算出所有請求的平均時間、90%時間，第一條開始請求的時間到最後一條傳送成功的時間之差就為持續壓測時間，進而通過請求數能夠計算出TPS，達到測試目的。

5、測試結果分析及調優

 這部分和普通介面的壓力測試是相同的，這裡不多敘述。