接口測試常見方法與總結(jié)

1、 接口測試常見方法與總結(jié) 一、 常見接口 ： 1、 webService 接口：是走soap協(xié)議通過 傳輸，請求報文和返回報文都是 xml 格式的，我們在 測試的時候都用通過工具才能進(jìn)行調(diào)用,測試?？梢允褂玫墓ぞ哂?SoapUl、jmeter、loadrunner 等； 2、 api接口：是走 協(xié)議，通過路徑來區(qū)分調(diào)用的方法，請求報文都是 key-value 形式的，返回報文一般都是 json串，有g(shù)et和post等方法，這也是最常用的兩種 請求方式?？梢允褂玫墓ぞ哂?postman、RESTClient、jmeter loadrunner 等； 二、 接口組成 接口都有那些局部組成呢？ 首先

2、，接口文檔應(yīng)該包含以下內(nèi)容： 1、 接口說明 2、 調(diào)用url 3、 請求方法(getpost ) 4、 請求參數(shù)、參數(shù)類型、請求參數(shù)說明 5、 返回參數(shù)說明 由接口文檔可知，接口至少應(yīng)有請求地址、請求方法、請求參數(shù)(入?yún)⒑统鰠?組成， 局部接口有請求頭 header 。 標(biāo)頭(header):是效勞器以 協(xié)議傳HTML資料到瀏覽器前所送出的字串,在 標(biāo)頭與HTML文件之間尚需空一行分隔，一般存放 cookie、token等信息 有同學(xué)問我header和入?yún)⒂惺裁搓P(guān)系？它們不都是發(fā)送到效勞器的參數(shù)嗎？ 首先，它們確實都是發(fā)送到效勞器里的參數(shù)，但它們是有區(qū)別的， header里存放的 參數(shù)一般存

3、放的是一些校驗信息，比方 cookie ,它是為了校驗這個請求是否有權(quán)限請求服 務(wù)器，如果有，它才能請求效勞器，然后把請求地址連同入?yún)⒁黄鸢l(fā)送到效勞器，然后服 務(wù)器會根據(jù)地址和入?yún)矸祷爻鰠ⅰＲ簿褪钦f，效勞器是先接受 header信息進(jìn)行判斷該 請求是否有權(quán)限請求，判斷有權(quán)限后，才會接受請求地址和入?yún)⒌摹?三、 為什么要做接口測試： 大家都知道，接口其實就是前端頁面或 APP等調(diào)用與后端做交互用的,所以好多人都 會問，我 功能測試 都測好了、為什么還要測接口呢？ OK,在答復(fù)這個問題之前，先舉個栗 子： 比方測試用戶注冊功能，規(guī)定用戶名為 618個字符，包含字母(區(qū)分大小寫)、數(shù) 字、下劃線。

4、首先功能測試時肯定會對用戶名規(guī)那么進(jìn)行測試時，比方輸入 20個字符、輸 入特殊字符等，但這些可能只是在前端做了校驗，后端可能沒做校驗，如果有人通過抓包 繞過前端校 驗直接發(fā)送到后端怎么辦呢？試想一下，如果用戶名和密碼未在后端做校驗， 而有人又繞過前端校驗的話，那用戶名和密碼不就可以隨便輸了嗎？如果是登錄可能會通 過SQL注入等手段來隨意登錄,甚至可以獲取管理員權(quán)限，那這樣不是很恐怖？ 所以，接口測試的必要性就表達(dá)出來了： 、可以發(fā)現(xiàn)很多在頁面上操作發(fā)現(xiàn)不了的 bug 、檢查系統(tǒng)的異常處理能力 、檢查系統(tǒng)的平安性、穩(wěn)定性 、前端隨便變，接口測好了，后端不用變 四、接口測試怎么測： 在進(jìn)行接口測試

5、前，還需要了解： 1 、GET 和 POST 請求： 如果是get請求的話，直接在瀏覽器里輸入就行了，只要在瀏覽器里面直接能請求到 的，都是get請求，如果是post的請求的話，就不行了，就得借助工具來發(fā)送。 GET請求和POST請求的區(qū)別： 1、 GET使用URL或Cookie 傳參。而 POST將數(shù)據(jù)放在 BODY中。 2、 GET的URL會有長度上的限制，那么 POST的數(shù)據(jù)那么可以非常大。 3、 POST比GET平安，因為數(shù)據(jù)在地址欄上不可見。 4、 一般get請求用來獲取數(shù)據(jù)，post請求用來發(fā)送數(shù)據(jù)。 其實上面這幾點，只有最后一點說的是比擬靠譜的，第一點 post請求也可以把數(shù)據(jù)

6、放到url里面，get請求其實也沒長度限制， post請求看起來參數(shù)是隱式的，稍微平安那 么一些些，但是那只是對于小白用戶來說的，就算 post請求，你通過抓包也是可以抓到 參數(shù)的。所以上面這些面試的時候你說出來就行了。 2 、 狀態(tài)碼 每發(fā)出一個 請求之后，都會有一個響應(yīng)， 本身會有一個狀態(tài)碼，來標(biāo)示這 個請求是否成功，常見的狀態(tài)碼有以下幾種： 1、 200 2開頭的都表示這個請求發(fā)送成功，最常見的就是 200,就代表這個請求是 ok的，效勞器也返回了。 2、 300 3開頭的代表重定向，最常見的是 302,把這個請求重定向到別的地方了， 3、 400 400代表客戶端發(fā)送的請求有語法錯誤，

7、 401代表訪問的頁面沒有授權(quán)， 403 表示沒有權(quán)限訪問這個頁面， 404代表沒有這個頁面 4、 500 5開頭的代表效勞器有異常， 500代表效勞器內(nèi)部異常，504代表效勞器端超 時，沒返回結(jié)果 接下來再說接口測試怎么測： 1、通用接口用例設(shè)計 、通過性驗證：首先肯定要保證這個接口功能是好使的，也就是正常的通過性測試， 按照接 口文檔上的參數(shù)，正常傳入，是否可以返回正確的結(jié)果。 、參數(shù)組合：現(xiàn)在有一個操作商品的接口，有個字段 type，傳1的時候代表修改商 品，商品id、商品名稱、價格有一個是必傳的， type傳2的時候是刪除商品，商品 id是 必傳的，這樣就要測參數(shù)組合了， type傳1

8、的時候，只傳商品名稱能不能修改成功, 名稱、價格都傳的時候能不能修改成功。 、接口平安： 1、 繞過驗證，比方說購置了一個商品，它的價格是 300元，那我在提交訂單時候， 我把這個商品的價格改成 3元，后端有沒有做驗證，更狠點，我把錢改成 -3,是不是我的 余額還要增加？ 2、 繞過身份授權(quán)，比方說修改商品信息接口，那必須得是賣家才能修改，那我傳一 個普通用戶，能不能修改成功，我傳一個其他的賣家能不能修改成功 3、 參數(shù)是否加密，比方說我登陸的接口，用戶名和密碼是不是加密，如果不加密的 話，別人攔截到你的請求，就能獲取到你的信息了，加密規(guī)那么是否容易破解。 4、 密碼平安規(guī)那么，密碼的復(fù)雜程度

9、校驗 、異常驗證： 所謂異常驗證，也就是我不按照你接口文檔上的要求輸入?yún)?shù)，來驗證接口對異常情 況的校驗。比方說必填的參數(shù)不填，輸入整數(shù)類型的，傳入字符串類型，長度是 10的， 傳11 ,總之就是你說怎么來，我就不怎么來，其實也就這三種，必傳非必傳、參數(shù)類型、 入?yún)㈤L度。 2、根據(jù)業(yè)務(wù)邏輯來設(shè)計用例 根據(jù)業(yè)務(wù)邏輯來設(shè)計的話，就是根據(jù)自己系統(tǒng)的業(yè)務(wù)來設(shè)計用例，這個每個公司的業(yè) 務(wù)不一樣，就得具體的看自己公司的業(yè)務(wù)了，其實這也和功能測試設(shè)計用例是 一樣的。 舉個例子，拿bbs來說，bbs的需求是這樣的： 1、 登錄失敗5次，就需要等待15分鐘之后再登錄 2、 新注冊的用戶需要過了實習(xí)期才能發(fā)帖 3、 刪除帖子扣除