接口測試作為確認(rèn)測試的一部分，通過直接調(diào)用被測試的接口來確定系統(tǒng)在功能性、可靠性、安全性和性能方面是否能達(dá)到預(yù)期，有些情況是功能測試無法覆蓋的，所以接口測試是非常必要的。

       接口測試分為兩種，一種是webservice接口，走soap協(xié)議通過http傳輸，請求報(bào)文和返回報(bào)文都是xml格式的，測試時(shí)通過工具soapUI進(jìn)行測試。使用情況比較少；另一種http api接口，走h(yuǎn)ttp傳輸協(xié)議，通過路徑來區(qū)分調(diào)用的方法，最常用的是get和post請求。

　　get請求和post請求的區(qū)別在哪里呢？網(wǎng)上的答案為：

　　1、get請求可以在瀏覽器中請求到，post請求的測試需要借助工具

　　2、get請求使用url和cookie傳參，post的數(shù)據(jù)放在body中

　　3、post比get更安全，因?yàn)閭鬟f的參數(shù)在url上是看不到的

　　4、get請求的url會有限制，而post請求的數(shù)據(jù)可以非常大

　　5、一般get請求是來獲取數(shù)據(jù)，post請求是傳遞數(shù)據(jù)的

　　其實(shí)，對于現(xiàn)在飛速發(fā)展的 互聯(lián)網(wǎng)來說，上面的說法已經(jīng)不嚴(yán)謹(jǐn)了。首先，post請求的參數(shù)也可以寫在url里，但是這種情況不多見；其次表面上看起來，post利用body傳參，比get的url傳參安全，但其實(shí)只要用抓包工具（fiddler，Charles等），post的參數(shù)也是一覽無余；再次，現(xiàn)在的瀏覽器非常強(qiáng)大，可以輸入支持很長的URL，所以也不再有限制一說了。這么說來，種種區(qū)別只有最后一條是最根本的了。

　   怎么來測試接口呢？根據(jù)什么來測呢？這就需要開發(fā)提供的接口文檔了，接口文檔和功能測試的需求說明書的功能是一樣的。包括：接口說明、調(diào)用的url，請求方式（get or post），請求參數(shù)、參數(shù)類型、請求參數(shù)說明，返回結(jié)果說明。這里接口文檔生成可以使用apipost接口文檔生成工具。有了接口文檔后，我們就可以設(shè)計(jì)用例了，一般接口測試的用例分為以下幾種：

      1、通過性驗(yàn)證，說白了就是傳遞正確的參數(shù)，是否返回正常的結(jié)果

      2、參數(shù)組合，因?yàn)閰?shù)有必傳和非必傳，參數(shù)的類型和長度，以及傳遞時(shí)可能業(yè)務(wù)上的一些限制，所以在設(shè)計(jì)用例時(shí)，就要排列組合這些情況，保證所有情況都能覆蓋到

      3、接口的安全性，這個(gè)又分為幾種情況：

　　1 ) 繞過驗(yàn)證，比如提交訂單時(shí)，在傳遞商品價(jià)格參數(shù)時(shí)，修改商品價(jià)格，就要看后端有沒有驗(yàn)證了。或者我支付時(shí)，抓個(gè)包將訂單金額一改，如果能以我改后的金額支付，那這個(gè)借口就有問題了。

　　2）繞過身份驗(yàn)證，就是某個(gè)功能只有有特殊權(quán)限的用戶才能操作，那我傳遞一個(gè)普通的用戶，是不是也能操作呢

　　3）參數(shù)是否加密，這個(gè)關(guān)系到一些賬戶的安全，比如我們在登錄一些網(wǎng)站時(shí)，它要將我們的登錄信息進(jìn)行加密，如果不加密我們的信息就會暴露，危害性極大。

　　4 ) 密碼安全規(guī)則，設(shè)置密碼時(shí)復(fù)雜程度的校驗(yàn)。

      4、根據(jù)業(yè)務(wù)邏輯來設(shè)計(jì)用例

       用例設(shè)計(jì)完了，用什么來測試接口呢？我們可以借助一些工具，比如apipost和jmeter。apipost使用比較簡單，可以在列表中選擇請求方式，在輸入框中輸入U(xiǎn)RL，如果是get請求，直接點(diǎn)擊發(fā)送就可以看返回結(jié)果了。

　　如果是post請求，會涉及到幾種參數(shù)的上傳方式和添加請求頭、權(quán)限驗(yàn)證還有添加cookie等操作。apipost都可以簡單實(shí)現(xiàn)。

　　還有一種測試接口的工具是jmeter，用途比較廣泛，不但能測接口的功能，還能對接口進(jìn)行性能測試。比如：壓力測試、負(fù)載測試等。