百度搜索：小強測試品牌

員工經(jīng)過長期磨合與沉淀，具備了協(xié)作精神，得以通過團隊的力量開發(fā)出優(yōu)質(zhì)的產(chǎn)品。創(chuàng)新互聯(lián)堅持“專注、創(chuàng)新、易用”的產(chǎn)品理念，因為“專注所以專業(yè)、創(chuàng)新互聯(lián)網(wǎng)站所以易用所以簡單”。公司專注于為企業(yè)提供網(wǎng)站設(shè)計、成都網(wǎng)站設(shè)計、微信公眾號開發(fā)、電商網(wǎng)站開發(fā)，微信小程序定制開發(fā)，軟件按需定制等一站式互聯(lián)網(wǎng)企業(yè)服務(wù)。

本文來自小強測試品牌學(xué)員作品，歡迎大家多多投稿，也期望各位學(xué)員再接再厲！

背景

有一個接口http的接口，GetPaymentURL，傳遞參數(shù)很簡單，就是一個sessionID（類似于訂單號），這個接口本身并沒有什么東西，但是他調(diào)用了另外一個模塊錢包的接口，錢包最終會返回一個paymenturl等信息給到GetPayment這個接口。

一句話，GetPyamentURL只時負(fù)責(zé)傳遞參數(shù)給到錢包的接口，主要業(yè)務(wù)邏輯都是在錢包里面，最終由錢包把結(jié)果返回給GetPaymentURL ，拿到結(jié)果后再做簡單的處理，把結(jié)果返回出來。

小強點評：明白一個接口的邏輯是非常重要的，實際中我發(fā)現(xiàn)很多人只關(guān)注技術(shù)，卻不關(guān)注業(yè)務(wù)邏輯，導(dǎo)致很多一步可以完成的事情偏偏走了N步，得不償失??！

問題

當(dāng)時遇到一個情況，調(diào)用getpaymenturl接口有時非常慢（只是1個用戶進行調(diào)用，100次內(nèi)有27次是20秒以上，最長的都達到30秒以上。我這只是單個用戶進行請求啊，怎么能這么慢），但是直接調(diào)用錢包的接口非?？?。而且都是在同一網(wǎng)絡(luò)下用一個用戶分別進行測試100次，都是在我們公司的內(nèi)網(wǎng)發(fā)出請求的請求。

小強點評：我就想說棒棒噠，哈哈

分析

首先，因為直接調(diào)用錢包接口，響應(yīng)正常。所以我覺得問題應(yīng)該是在getpaymenturl這里。

我利用LR，把getpaymenturl的結(jié)果分析了一下，發(fā)現(xiàn)buffer time非常長，進一步分解，得到server time很慢，net time是正常的。所以我懷疑是不是GetPaymentURL接口本身的server端問題，導(dǎo)致慢。但又覺得說不過去啊，這個接口只是做了簡單的傳遞，怎么會這么慢，不太可能？所以我覺得還是保留一下網(wǎng)絡(luò)的原因。

然后我又想，不對啊，為什么直接調(diào)用錢包接口，都正常，說明網(wǎng)絡(luò)是正常的。后來與同事確認(rèn)后，后來發(fā)現(xiàn)直接調(diào)用錢包接口走的是公網(wǎng)（開發(fā)給我的測試地址是公網(wǎng)的），而getpaymenturl應(yīng)該走的是專線。雖然最終都是到達同一臺服務(wù)器進行處理，但是他們走的網(wǎng)絡(luò)節(jié)點是不一樣的。所以現(xiàn)在我更加肯定，網(wǎng)絡(luò)+VPOS都有可能有問題。

小強點評：分析邏輯嚴(yán)謹(jǐn)，能放能收。抓住網(wǎng)絡(luò)路徑的不同找突破口

這里還有一個小故事。VPOS一開始其實用的是公網(wǎng)地址，然后我們這邊的一個同事，配置了一個什么代理，就是無論VPOS用什么公網(wǎng)地址，都會被這個代理，轉(zhuǎn)一下，最終跳到一個固定的地址，然后再從這個地址轉(zhuǎn)出去，再到錢包。

這樣搞，顯然不行，一是對于這種涉及到錢的交易，肯定是走專線地址的。 而是即使走公網(wǎng)，為什么還繞了這么大一圈子，通過配的什么代理，兜一圈再出去。。。

于是立馬，讓同事修改成為指向錢包的專線地址，重新測試了一下，結(jié)果一切正常。

雖然結(jié)果有點大跌眼鏡，既不是網(wǎng)絡(luò)原因，也不是VPOS服務(wù)端的原因，而是莫名其妙的被兜了個大圈子，導(dǎo)致響應(yīng)時間較慢。

這是最終用單個用戶請求了200次的結(jié)果：

小強點評：為什么性能測試好玩？就是你會發(fā)現(xiàn)有時候你玩他，有時候他玩你啊，就和大家為啥都愛看懸疑推理破案片一個道理，所以耐心、堅持、邏輯思維真心很重要。不過這里我建議用的工具要保證一致性，畢竟每個工具的統(tǒng)計原理不一樣，如果換著用會對數(shù)據(jù)的比較造成一定的干擾。這里學(xué)員用了jmeter，而上面用的是loadrunner。

總結(jié)

1. 遇到這種接口很慢的情況，無非就是網(wǎng)絡(luò)+Server端的原因。

2. 對于這種接口調(diào)接口的情況（某個接口本身封裝了另外一個接口），可以進一步拆分。比如直接調(diào)用錢包的接口，看看他是否正常，如果他本身就有問題，那肯定是要首先分析錢包的接口。 如果錢包接口本身沒有問題，那就要分析是不是getpaymenturl本身接口的問題

3. 遇到問題，要與相關(guān)人員進行確認(rèn)。

小強點評：這里的總結(jié)看起來短短幾字卻透出了我一直傳達的一個信息，那就是分析問題要學(xué)會分層拆分！只有把大的拆成小的我們才能慢慢找到突破口，很多人覺得分析難不會分析，本質(zhì)就兩點，一點是基礎(chǔ)不夠扎實，二點就是不會拆分，不知道該怎么一步步拆解。

如果對你有一丟丟幫助，轉(zhuǎn)發(fā)+點贊=支持

分享名稱：接口性能測試實戰(zhàn)小結(jié)（附點評）
標(biāo)題鏈接：http://m.rwnh.cn/article48/jdgchp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App設(shè)計、做網(wǎng)站、全網(wǎng)營銷推廣、云服務(wù)器、企業(yè)網(wǎng)站制作、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)