最近在來了新的領(lǐng)導(dǎo)，測試的內(nèi)容和范疇都變大了，工作內(nèi)容涉及到APP，線上出現(xiàn)了由于性能引起的bug，不得不進(jìn)行壓測，只能不斷的學(xué)習(xí)了
害，想做一條咸魚都那么難，找了很多關(guān)于接口性能測試的資料，領(lǐng)導(dǎo)一直強(qiáng)調(diào)異步接口不好做壓測
仔細(xì)研究了一下，覺得這篇帖子寫得不錯(cuò)，就拿出來分享，如果雷同純屬巧合

以前對(duì)接口做性能測試，接口都是同步處理的，請(qǐng)求之后等待響應(yīng)結(jié)果就知道處理結(jié)果了，這樣只要看這個(gè)接口是否異常，如果無異常無報(bào)錯(cuò)記錄這個(gè)接口的響應(yīng)時(shí)間、TPS等性能指標(biāo)進(jìn)行分析就可以了，最近在工作中遇到了異步處理的接口，邏輯是只要你請(qǐng)求參數(shù)全部合法，即返回成功。

通俗理解一下同步和異步的差別，舉個(gè)小例子：

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

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

那么問題來了，這種接口，如果還像以前一樣單純的看接口的響應(yīng)時(shí)間，就沒有任何意義了，那么如何判斷接口的性能呢？

先來描述一下被測系統(tǒng)：

這是一個(gè)專門負(fù)責(zé)發(fā)送消息的平臺(tái)，包括短信消息和設(shè)備消息，大概架構(gòu)如下：整個(gè)系統(tǒng)分為前端和后端，前端負(fù)責(zé)接收客戶端的傳參，把數(shù)據(jù)寫入數(shù)據(jù)庫并插入消息隊(duì)列MQ；后端負(fù)責(zé)發(fā)送消息，隊(duì)列MQ的消費(fèi)，并更新數(shù)據(jù)庫記錄隊(duì)列消息的消費(fèi)時(shí)間及發(fā)送狀態(tài)；接口全部為異步處理機(jī)制，下面以發(fā)送接口為例，簡述整個(gè)測試過程：

1、制定測試方案

開始性能測試了，說明系統(tǒng)功能已經(jīng)穩(wěn)定，無遺留嚴(yán)重bug，此時(shí)需要對(duì)系統(tǒng)的需求做個(gè)調(diào)研分析，確定被測系統(tǒng)的性能測試方案，這里可以從需求出發(fā)，初步確定性能測試方案。確定測試場景為單接口場景，選取三個(gè)調(diào)用頻率最高的接口來測試，和開發(fā)及運(yùn)維等相關(guān)人員確定壓測環(huán)境、服務(wù)器配置等數(shù)據(jù)，通過壓力測試工具jmeter關(guān)注響應(yīng)時(shí)間、每秒TPS及錯(cuò)誤率，同時(shí)使用阿里云監(jiān)控平臺(tái)監(jiān)控服務(wù)器內(nèi)存和CPU使用情況。采用循序漸進(jìn)增加線程數(shù)的方式得到接口的最大處理能力。

2、確定測試數(shù)據(jù)

為了盡量模擬真實(shí)場景，需準(zhǔn)備不小于并發(fā)數(shù)百分之20的數(shù)據(jù)作為壓測數(shù)據(jù)。

壓測數(shù)據(jù)寫在excel中

ps：這里有個(gè)坑，因?yàn)橄⑾到y(tǒng)是給用戶發(fā)送短信及消息，一不小心可能導(dǎo)致消息發(fā)送到真實(shí)用戶了。此處有兩個(gè)解決方案：a、讓開發(fā)處理手機(jī)號(hào)校驗(yàn)的代碼，把代碼注釋，手機(jī)號(hào)使用不存在的數(shù)字組合即可

b、開發(fā)做擋板，屏蔽調(diào)用第三方發(fā)送接口

3、根據(jù)測試場景編寫測試腳本

共三個(gè)接口，https協(xié)議post請(qǐng)求

調(diào)用接口無需token，因此只需要把入?yún)⑵唇优判蚣用芎灻纯?，入?yún)⑻幚矸椒梢杂胘ava寫好打包放到j(luò)meter的lib目錄，在beanshell中import進(jìn)來直接調(diào)用即可

4、執(zhí)行測試

測試腳本調(diào)試通過，就可以執(zhí)行測試了。

按照常規(guī)接口的測試方式：就是從1個(gè)線程數(shù)開始，每次壓測5分鐘左右，壓測過程中監(jiān)控服務(wù)器cpu及內(nèi)存占用情況，記錄tps及響應(yīng)時(shí)間，不斷增加并發(fā)數(shù)，找到tps隨并發(fā)數(shù)增大的拐點(diǎn)，即得出接口最大處理能力。

但是以上方式并不適用于這種異步的接口，那么如何處理呢？

此處通過查詢數(shù)據(jù)庫。當(dāng)所有請(qǐng)求全部完畢了，查詢數(shù)據(jù)庫的發(fā)送信息表，檢查請(qǐng)求時(shí)間字段和發(fā)送時(shí)間字段，請(qǐng)求時(shí)間字記錄該請(qǐng)求的調(diào)用時(shí)間，發(fā)送時(shí)間字段是后端發(fā)送消息后回寫到數(shù)據(jù)庫的發(fā)送時(shí)間，故請(qǐng)求時(shí)間字段和發(fā)送時(shí)間字段的差就是這一個(gè)請(qǐng)求的完整的響應(yīng)時(shí)間，可以算出所有請(qǐng)求的平均時(shí)間、90%時(shí)間，第一條開始請(qǐng)求的時(shí)間到最后一條發(fā)送成功的時(shí)間之差就為持續(xù)壓測時(shí)間，進(jìn)而通過請(qǐng)求數(shù)能夠計(jì)算出TPS，達(dá)到測試目的。

5、測試結(jié)果分析及調(diào)優(yōu)

這部分和普通接口的壓力測試是相同的，這里不多敘述。