作為整個(gè)軟件項(xiàng)目的必經(jīng)環(huán)節(jié)，軟件測試是不可缺少的“查漏補(bǔ)缺”環(huán)節(jié)。而作為軟件測試中的重要一環(huán)——接口測試，幾乎串聯(lián)了整個(gè)項(xiàng)目所有的輸入和輸出環(huán)節(jié)。

前幾年，我在做后端測試時(shí)，接觸最多的正是接口測試?；诖耍蚁虢o大家分享一些我曾經(jīng)碰到過的接口測試難題，希望拋磚引玉，給正在做測試的小伙伴們提供一些避雷方案。

1、未釋放請求服務(wù)，導(dǎo)致APP執(zhí)行任務(wù)失敗

這個(gè)接口功能大概是這樣的：

這是一個(gè)算法轉(zhuǎn)換服務(wù)的接口。也就是說，我們需要把下單系統(tǒng)中的訂單的產(chǎn)品信息，轉(zhuǎn)換成生產(chǎn)系統(tǒng)的生產(chǎn)產(chǎn)品信息。然后根據(jù)轉(zhuǎn)換后的訂單，進(jìn)行生產(chǎn)。

基于我們要做不同系統(tǒng)間的調(diào)用，所以我們可選擇webserivce服務(wù)來做調(diào)用接口。在這個(gè)過程中，接口B將處理這些信息：

l 接收系統(tǒng)A傳的參數(shù)

l 調(diào)用轉(zhuǎn)換服務(wù)進(jìn)行轉(zhuǎn)換

l 轉(zhuǎn)換成功把轉(zhuǎn)換結(jié)果寫入數(shù)據(jù)庫

l 轉(zhuǎn)換失敗返回錯(cuò)誤信息

測試這樣的接口一般是先本地構(gòu)造數(shù)據(jù)，用接口工具進(jìn)行測試。在這里我們用的是soapui工具，然后就是用真實(shí)數(shù)據(jù)不同系統(tǒng)間進(jìn)行聯(lián)測。

當(dāng)然如果前端功能已經(jīng)實(shí)現(xiàn)，我們也可以直接用前端系統(tǒng)構(gòu)造數(shù)據(jù)直接調(diào)用接口，這樣構(gòu)造出來的數(shù)據(jù)更直接。特別是參數(shù)比較多，比較復(fù)雜的時(shí)候，這樣測試比直接用接口工具更快更省事。當(dāng)然，即使我們直接這樣測試，也不能取代聯(lián)測。為什么呢？

因?yàn)槟闳e人的系統(tǒng)自己構(gòu)造數(shù)據(jù)，構(gòu)造的數(shù)據(jù)只是根據(jù)參數(shù)來的，不一定能把別個(gè)系統(tǒng)所有產(chǎn)品的特性覆蓋全。

接下來，我們說說這個(gè)接口測試過程中，可能出現(xiàn)的問題。如果這個(gè)接口開發(fā)交付驗(yàn)收基本功能是正常的，但是一把代碼部署到測試環(huán)境里，沒運(yùn)行多久，這個(gè)接口的APP任務(wù)就出現(xiàn)執(zhí)行失敗，這就有問題了。

即便我們認(rèn)為一條失敗了，問題是出在數(shù)據(jù)構(gòu)造上。但如果多條連續(xù)失敗，甚至之前執(zhí)行成功的數(shù)據(jù)再次執(zhí)行轉(zhuǎn)換任務(wù)也失敗了，那我們應(yīng)該怎么辦呢？

其實(shí)很簡單，這個(gè)時(shí)候我們應(yīng)該去服務(wù)器取日志，進(jìn)行校驗(yàn)。如果發(fā)現(xiàn)是服務(wù)請求數(shù)超限，無法請求到服務(wù)，導(dǎo)致APP執(zhí)行超時(shí)導(dǎo)致失敗。那么，我們就應(yīng)該請開發(fā)人員協(xié)助處理了。

假如此時(shí)，我們喊來開發(fā)小哥一起分析，發(fā)現(xiàn)是接口請求服務(wù)鏈接后，用完未進(jìn)行釋放（這個(gè)鏈接服務(wù)器是有一個(gè)數(shù)量限制的，達(dá)到一定量后就無法再進(jìn)行新的鏈接）導(dǎo)致的，我們接下來又應(yīng)該怎么處理呢？

當(dāng)然就是請開發(fā)小哥調(diào)整一下代碼處理方式，使每次請求用完后，都可以自動(dòng)釋放掉鏈接。這樣處理以后，我們只需再重新測試，直到不存在此問題即可。

2、前后端接口參數(shù)對不上，導(dǎo)致接口問題

假如前后端接口參數(shù)code對不上，導(dǎo)致數(shù)據(jù)讀取、接收不到或轉(zhuǎn)換，運(yùn)算結(jié)果失敗，我們應(yīng)該怎么處理呢？

這個(gè)是接口測試中常見的一個(gè)問題，特別是涉及到不同系統(tǒng)間調(diào)用接口傳參數(shù)時(shí)，很容易出現(xiàn)這樣的問題。

日常工作中，當(dāng)測試頁面功能時(shí)涉及到一個(gè)接口，功能大概是這樣的：查詢產(chǎn)品的目錄價(jià)，成交展示出來。當(dāng)時(shí)前臺入?yún)⒖赡苁沁@樣的：

l Productname:

l Productversion:

l Productcode:

l Listprice:

l Netprice:

后臺返回參數(shù)是這樣的：

l Productname:

l Productversion:

l Productcode:

l Listprice:

l Net_price:

如果單獨(dú)用接口工具測試這兩邊的參數(shù)，數(shù)據(jù)展示是沒有問題的。但只要前后臺聯(lián)測，就出現(xiàn)所有產(chǎn)品成交價(jià)都是0。遇到這樣的情況，我們應(yīng)該怎么辦？

只要我們對比兩邊消息體的參數(shù)，就不難發(fā)現(xiàn)，兩邊參數(shù)成交價(jià)的名稱code寫的不一致的。這也就是導(dǎo)致前臺讀取不到后臺傳過來的值，默認(rèn)展示為0的原因了。

類似這樣的問題還有很多。

比如： 前端系統(tǒng)想要參數(shù)1的值，而后臺傳過來的，卻是參數(shù)2的值，導(dǎo)致前端在拿過這個(gè)值進(jìn)行邏輯判斷或運(yùn)算的時(shí)候，怎么都不對。

再比如： 兩邊取值都是一樣的，但是在業(yè)務(wù)上，這個(gè)值就是取的不對，這樣即使測試沒問題，在實(shí)際應(yīng)用中，結(jié)果也是不對的。這個(gè)時(shí)候，就要求我們需要加深對業(yè)務(wù)知識的理解了。

為了避免我們在做測試時(shí)，遇到這樣的問題，我給大家做了一下總結(jié)：

1）接到這種傳參數(shù)的測試時(shí)，一定要先做靜態(tài)測試，核對兩邊的參數(shù)code；

2）對于接到參數(shù)取值相關(guān)的任務(wù)時(shí)，在做測試前，兩邊一定要溝通核對數(shù)值及其代表的含義；

3）要提前熟悉業(yè)務(wù)，看清楚每一個(gè)存儲的參數(shù)表示的含義，確保業(yè)務(wù)傳值正確。

3、參數(shù)判斷少了特殊情況，導(dǎo)致查詢結(jié)果不對

這個(gè)問題也是接口測試中常見的問題之一。多數(shù)情況下，這個(gè)問題是由于開發(fā)人員對當(dāng)前產(chǎn)品業(yè)務(wù)了解不夠造成的。

我印象比較深的一次，是一個(gè)關(guān)于權(quán)限優(yōu)化的需求。記得當(dāng)時(shí)有一個(gè)緊急版本要上線，我們的任務(wù)是：優(yōu)化權(quán)限的判斷邏輯，提高查詢性能。

這個(gè)功能大概是這樣的，當(dāng)前登錄人所在公司有分公司，那么，他同時(shí)可以查看分公司的訂單。邏輯如下：

分析一下這個(gè)功能，主要有以下幾種場景：

情況1： 登錄人所在公司，只有一個(gè)總公司，沒有分公司。且總公司有訂單，當(dāng)前登錄人可以查看所在公司的訂單；

情況2： 登錄人所在公司是總公司。且該公司有多個(gè)分公司，每個(gè)分公司都有訂單，總公司沒有訂單，當(dāng)前登錄人可以查看到所有分公司的訂單；

情況3： 登錄人所在總公司有多個(gè)分公司，總公司和分公司都有訂單，當(dāng)前登錄人可以查看總公司和分公司的所有訂單；

情況4： 登錄人所在公司是總公司且其下有多個(gè)分公司，分公司沒有訂單，只有總公司有訂單。當(dāng)前登錄人可以查看到總公司訂單。

場景分析完后，接下來，我們就是需要據(jù)場景，構(gòu)造數(shù)據(jù)進(jìn)行測試了。

這里，我主要就【情況1】的場景給大家做一個(gè)分析。假設(shè)在【情況1】里：一進(jìn)行場景測試，就出現(xiàn)：因?yàn)槊髅饔杏唵蔚?，頁面上卻展示空白。

這是怎么回事呢？

此時(shí)，我們需要先用postman調(diào)用后臺接口看看。假如后臺接口返回的數(shù)據(jù)是正常確的，那接下來怎么處理呢？這就需要我們回頭去服務(wù)器查日志了。當(dāng)我們發(fā)現(xiàn)只有一個(gè)總公司，沒有分公司時(shí)，分公司對應(yīng)的參數(shù)都是空的，程序就直接跳過沒再執(zhí)行后面的查詢了。根據(jù)這種情況，只需我們找開發(fā)人員加一個(gè)接口：判斷分公司是否有值。沒有值時(shí)，直接跳過，計(jì)算總公司的數(shù)據(jù)即可。

當(dāng)然，接口測試常見的問題還有：內(nèi)存溢出、性能問題、查詢接口還會(huì)涉及到安全問題，等等。這些問題都要根據(jù)接口的實(shí)際功能，進(jìn)行分析和有針對性的測試，這里就不一一列舉了。感興趣的小伙伴也可以在留言區(qū)留言，提出問題，我們共同探討，共同進(jìn)步。

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

包括，測試人技術(shù)進(jìn)階路徑圖，50多天的視頻教程、16個(gè)項(xiàng)目實(shí)例，30多個(gè)測試工具，37份測試文檔，70個(gè)軟件測試相關(guān)問題，40篇測試經(jīng)驗(yàn)級文章分享，還有軟件測試面試小程序，求職簡歷的優(yōu)化模板。

加油吧，如果你需要提升技術(shù)儲備，那就行動(dòng)，在路上總比在起點(diǎn)觀望的要好。一切的迷茫都是因?yàn)橄氲锰喽龅奶伲?/p>

你可以在公眾號：傷心的辣條?！ 自行領(lǐng)取一份216頁軟件測試工程師面試寶典文檔資料【免費(fèi)的】。以及相對應(yīng)的視頻學(xué)習(xí)教程免費(fèi)分享！，其中包括了有基礎(chǔ)知識、Linux必備、Shell、互聯(lián)網(wǎng)程序原理、Mysql數(shù)據(jù)庫、抓包工具專題、接口測試工具、測試進(jìn)階-Python編程、Web自動(dòng)化測試、APP自動(dòng)化測試、接口自動(dòng)化測試、測試高級持續(xù)集成、測試架構(gòu)開發(fā)測試框架、性能測試、安全測試等。

現(xiàn)在我邀請你進(jìn)入我們的軟件測試學(xué)習(xí)交流群：【746506216】，備注“入群”， 大家可以一起探討交流軟件測試，共同學(xué)習(xí)軟件測試技術(shù)、面試等軟件測試方方面面，還會(huì)有免費(fèi)直播課，收獲更多測試技巧，我們一起進(jìn)階Python自動(dòng)化測試/測試開發(fā)，走向高薪之路。