什麼是接口測試前端
測試人員一般所說的「接口測試」是針對系統各組件之間接口的一種測試,它屬於功能測試。接口能測出普通界面操做難以發現的問題。如,咱們都知道系統是由前端後端組成,一些數據在前端作了校驗,後端一樣也須要校驗才能保證安全,界面操做顯然只能檢查到前端校驗這一層,只有直接面對先後端之間的該接口才能檢驗出後端是否也作了校驗。數據庫
接口測試的必要性後端
能夠發現不少頁面操做發現不了的問題數組
檢查系統的異常處理能力瀏覽器
檢查系統的安全性、穩定性緩存
前端隨便變,接口測好了,後端不用變安全
接口測試的流程服務器
需求評審,熟悉業務和需求工具
開發提供接口文檔post
編寫接口測試用例
用例評審
提測後開始測試
提交測試報告
接口文檔 是接口測試的參照,至少包括:
一、接口說明
二、調用url
三、請求方法(get\post ……)
四、請求參數、參數類型、請求參數說明
五、返回參數說明
接口測試用例設計
經過性驗證:首先保證接口好用,按文檔正常傳入,查看是否能夠返回正確的結果。
參數組合: 按接口文檔中對參數的要求進行有目的的組合,好比必填未填是否經過,標誌類參數值的切換是否能對應正確的功能等。(這部分很關鍵)
接口安全:
一、繞過正常值驗證。
二、繞過身份受權驗證。
三、參數是否加密,加密規則是否容易破解。
四、密碼安全規則,密碼的複雜程度校驗。
異常驗證:不按照接口文檔上的要求輸入參數,來驗證接口對異常狀況的反應。
接口測試用例模板 (可根據項目實際狀況設計增減)
一、項目 測試針對哪一個項目
二、模塊 哪一個功能模塊
三、用例id
四、接口名稱
五、用例標題 測試用途歸納
六、請求方式 GET/POST
七、請求url URL地址
八、請求參數
九、前置條件 執行當前請求依賴的條件,不知足就不能正確執行
十、結果驗證 預期結果
十一、請求報文 能夠不寫
十二、返回報文 必定要寫,這裏應該是你請求返回的真實結果
1三、測試結果 經過/失敗
1四、測試人員
測試http接口
請求常見有Get請求和Post請求。Get請求一般用來接收數據,Post請求一般用來發送數據;測Get請求可用瀏覽器完成,參數均可以寫在URL裏面,測Post請求須要藉助工具如Postman,由於客戶端須要提供給服務器的信息較多,你要寫body傳輸大量數據。
接口調用有兩種傳參方式:key-value形式,Json串傳參形式。
key-value形式能夠把參數拼接在url的後面由?相連,多個參數之間用&相連,如url?parameter1=key1¶meter2=key2…
Json串傳參不能把參數直接連在url中,須要寫在請求的body裏面,可藉助工具Postman,打開請求的body寫入Json格式參數(由花括號括起來的‘鍵:值’對)如
{
「count」: 1,
「start」: 0,
「total」: 1
}
請求發出後,http會返回一個狀態碼錶示請求是否成功,狀態碼有三位,其中開頭一位肯定了狀態類型:
2xx: 表示請求發送成功,常見200。
3xx: 表明重定向,要完成請求必須進行更進一步的操做,或把請求重定向到別的地方了,最多見的是302。
4xx: 客戶端錯誤,請求有語法錯誤或請求沒法實現。400表明客戶端發送的請求有語法錯誤,不能被服務器所理解;401表明訪問的頁面沒有受權;403服務器收到請求,可是拒絕提供服務,好比沒有權限訪問這個頁面;404請求的資源不存在,好比輸入錯的URL沒有這個頁面。
5xx: 表明服務器有異常,500表明服務器內部異常;503服務器當前不能處理客戶端的請求,一段時間後可能恢復正常;504表明服務器端超時,沒返回結果。
測試WebSevice接口
不須要像測http接口那樣拼報文,直接把wsdl地址或wsdl文件(這兩個都由開發人員提供)填寫或導入到工具SoapUI裏面,工具裏可顯示全部相關接口或報文,直接填入參數發送請求參照接口文檔查看結果便可。
Cookie 和 Session
Cookie是存在於本地的一個鍵值對,Session是存在於服務器端的一個鍵值對,一般保存在數據庫或緩存裏。Cookie和Session在第一次發送某個請求時成對生成,兩端都會記錄下生成的時間,超出既定的時限後便會自動刪除。當請求在時限內再次發出後,Cookie和Session二者會相互比對,匹配上了便執行某些操做,匹配不上則不容許執行某些操做,以此實現快速處理,它們並非孤立做用的。