本文章轉(zhuǎn)載于搜狗測(cè)試
提起服務(wù)端測(cè)試粉臊，第一反應(yīng)想到的可能就是http協(xié)議、socket連接驶兜、post/get發(fā)送請(qǐng)求等等扼仲≡洞纾回想起小編當(dāng)時(shí)初次接觸服務(wù)端測(cè)試，真可謂一臉懵逼屠凶，不知道要干什么也不知道從哪兒開始做驰后。服務(wù)端測(cè)試往往呈現(xiàn)給大家的是一個(gè)很大很寬泛的任務(wù)，我們知道要做服務(wù)端測(cè)試但卻不知道怎么做矗愧，流程是啥灶芝，用什么工具去做，要達(dá)到什么樣的效果唉韭。今天小編就結(jié)合最近自己做的一些服務(wù)端測(cè)試的任務(wù)监署，和大家聊聊服務(wù)端測(cè)試中的一個(gè)常見方法——接口測(cè)試。
一纽哥、什么是接口測(cè)試
先來看看接口測(cè)試的定義：
接口測(cè)試是測(cè)試系統(tǒng)組件間接口的一種測(cè)試。接口測(cè)試主要用于檢測(cè)外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個(gè)子系統(tǒng)之間的交互點(diǎn)栖秕。測(cè)試的重點(diǎn)是要檢查數(shù)據(jù)的交換春塌，傳遞和控制管理過程，以及系統(tǒng)間的相互邏輯依賴關(guān)系等簇捍。
如今的軟件系統(tǒng)通常采用前后端分離的模式進(jìn)行設(shè)計(jì)與實(shí)現(xiàn)只壳，即一個(gè)系統(tǒng)分為前端（客戶端）和后端（服務(wù)端）兩部分。通常服務(wù)端以接口的形式給客戶端提供服務(wù)暑塑，實(shí)際上接口和客戶端的功能之間是關(guān)聯(lián)的：每個(gè)接口都對(duì)應(yīng)著客戶端一個(gè)或多個(gè)功能點(diǎn)吼句；而客戶端同服務(wù)端的交互，一般也是以接口作為基礎(chǔ)事格，客戶端根據(jù)不同的需要請(qǐng)求不同的接口惕艳，服務(wù)端根據(jù)客戶端請(qǐng)求的接口及攜帶的參數(shù)進(jìn)行邏輯處理。因此服務(wù)端測(cè)試可以先從接口測(cè)試入手驹愚，保證其對(duì)客戶端提供的服務(wù)沒有問題后再進(jìn)行更加深入的業(yè)務(wù)邏輯測(cè)試远搪，這也是目前我們做服務(wù)端測(cè)試的一個(gè)“套路”。
定義中說的接口包括兩種：系統(tǒng)與系統(tǒng)之間的接口逢捺，內(nèi)部各個(gè)子系統(tǒng)之間的交互點(diǎn)谁鳍。根據(jù)不同的劃分會(huì)有不同的結(jié)果：如果我們把一個(gè)系統(tǒng)的客戶端和服務(wù)器看成一個(gè)整體，那么此時(shí)服務(wù)端的接口相當(dāng)于是內(nèi)部子系統(tǒng)之間的交互點(diǎn)劫瞳；如果我們把客戶端和服務(wù)端各自看成是一個(gè)整體倘潜，那么接口就相當(dāng)于是不同系統(tǒng)之間的交互點(diǎn)了。
二志于、接口測(cè)試常用工具
說到接口測(cè)試涮因，最常見的一種測(cè)試方式就是檢查服務(wù)端返回的數(shù)據(jù)正確性了。實(shí)際項(xiàng)目中恨憎，服務(wù)端在收到客戶端的請(qǐng)求之后蕊退，對(duì)請(qǐng)求進(jìn)行處理并將處理的結(jié)果返回給客戶端郊楣，這種結(jié)果比較常見的是Json、XML等數(shù)據(jù)格式瓤荔，所以測(cè)試的時(shí)候一個(gè)主要工作就是檢查這些數(shù)據(jù)的正確性净蚤。比如，服務(wù)端以Json的格式返回客戶端需要的數(shù)據(jù)输硝，那么在測(cè)試中我們就需要關(guān)注返回的Json中是否包含我們期望的字段今瀑、字段的內(nèi)容是否正確等等。這個(gè)時(shí)候自動(dòng)化腳本就顯得非常重要了点把。
小編在測(cè)試過程中發(fā)現(xiàn)好多接口都是以Json格式返回?cái)?shù)據(jù)的橘荠，在實(shí)際執(zhí)行中，我們用到了Python的一個(gè)開源框架Requests,該框架保留了所有urllib2的優(yōu)點(diǎn)郎逃，比起urllib2更加簡(jiǎn)潔明了哥童，更像是純粹的“Python”，該框架在平時(shí)接口測(cè)試中幾乎所有的自動(dòng)化腳本中都在使用褒翰，關(guān)于該框架贮懈，小編之前在一次公開課中做過一次分享，有興趣的話大家可以關(guān)注搜狗測(cè)試粉絲群（459645679）進(jìn)行查看哦优训。
還有一些工具在實(shí)際的操作中用的比較多朵你，比如Postman。Postman是谷歌Chrome的一個(gè)插件揣非，使用起來非常簡(jiǎn)單抡医，可以支持我們以get/post等各種方式發(fā)送請(qǐng)求，當(dāng)然也可以自己構(gòu)造請(qǐng)求早敬，服務(wù)器返回的數(shù)據(jù)會(huì)全部展示出來忌傻，便于檢查，這和Fiddler比較相似搁嗓。此外Postman還支持用戶自行構(gòu)造環(huán)境芯勘，設(shè)置檢查點(diǎn)等，不考慮時(shí)間的情況下基本能滿足接口數(shù)據(jù)驗(yàn)證的需求腺逛。關(guān)于Postman的安裝和使用教程荷愕，網(wǎng)上資源比較多，此處就不再贅述了棍矛。
接口測(cè)試的工具和自動(dòng)化框架可謂非常多安疗，除了上面羅列的之外，還有許多實(shí)踐中比較常用的：urllib/urllib2够委，Jmeter等等荐类，關(guān)于各種工具的使用和優(yōu)缺點(diǎn)，小編會(huì)在后續(xù)的文章中結(jié)合自己項(xiàng)目的使用情況和大家進(jìn)行分享茁帽。
三玉罐、接口測(cè)試的用例設(shè)計(jì)
不同于功能測(cè)試屈嗤，接口測(cè)試的用例設(shè)計(jì)出了要驗(yàn)證正常功能之外，還需要考慮其他的一些情況吊输，總結(jié)起來饶号，接口測(cè)試的用例設(shè)計(jì)可以從以下幾個(gè)方面入手：
1.功能用例設(shè)計(jì)
服務(wù)端的接口與客戶端的功能是對(duì)應(yīng)的，那么這個(gè)接口是否能提供給客戶端某個(gè)特定功能所需要的數(shù)據(jù)自然是我們需要驗(yàn)證的地方季蚂，功能性用例的主要目的是幫助我們驗(yàn)證該接口最初設(shè)計(jì)的功能是否被實(shí)現(xiàn)以及該功能是否按照規(guī)定的接口文檔進(jìn)行實(shí)現(xiàn)等等茫船。
2.業(yè)務(wù)邏輯用例設(shè)計(jì)
業(yè)務(wù)邏輯方面的測(cè)試用例主要是針對(duì)服務(wù)端接口的處理邏輯進(jìn)行的用例設(shè)計(jì)，這種用例設(shè)計(jì)不是針對(duì)某個(gè)功能點(diǎn)是否實(shí)現(xiàn)扭屁，而是對(duì)接口的處理邏輯以及一些相互依賴的業(yè)務(wù)進(jìn)行驗(yàn)證算谈，通常依照接口的邏輯流程圖來進(jìn)行。舉一個(gè)例子料滥，購(gòu)物系統(tǒng)中的兩個(gè)動(dòng)作：登錄和下單操作然眼，這兩個(gè)業(yè)務(wù)是相互依賴的，下單操作必須在登錄完成后（登錄狀態(tài)下）葵腹，否則無法完成下單罪治，這個(gè)時(shí)候我們就可以設(shè)計(jì)這樣一條case：沒有登錄的狀態(tài)下進(jìn)行下單操作，看服務(wù)端如何處理礁蔗。
3.異常處理的情況
服務(wù)端接口和客戶端之間通常是通過HTTP請(qǐng)求來傳遞數(shù)據(jù)，在發(fā)送請(qǐng)求的時(shí)候雁社，客戶端會(huì)攜帶各種不同的參數(shù)浴井，此時(shí)服務(wù)端會(huì)根據(jù)不同的參數(shù)進(jìn)行不同的處理，所以異常處理主要是針對(duì)請(qǐng)求中的參數(shù)情況：比如參數(shù)增加和缺省霉撵、參數(shù)的數(shù)據(jù)類型錯(cuò)誤磺浙，參數(shù)攜帶錯(cuò)誤的值、參數(shù)為空等等徒坡，這需要我們根據(jù)接口文檔中各種不同的參數(shù)去構(gòu)造不同的參數(shù)異常撕氧，檢查服務(wù)端的響應(yīng)情況。
4.性能和安全性方面
服務(wù)器的性能往往是個(gè)非常重要的關(guān)注點(diǎn)喇完，在實(shí)際的測(cè)試中我們主要關(guān)注的是接口的QPS數(shù)值伦泥，以及CPU和內(nèi)存占用等性能指標(biāo)，通常借助于其他工具比如LoadRunner進(jìn)行性能測(cè)試锦溪。安全性方面不脯，主要考慮一些常見的安全策略比如請(qǐng)求加密、sql注入等等刻诊。
