- 接口自動化測試與界面自動化測試

- 接口自動化測試比界面自動化測試收益高,優(yōu)先級高。
- 界面開發(fā)、后臺業(yè)務(wù)邏輯的開發(fā)是不同的人,前后臺開發(fā)的進度不一樣。接口測試讓測試前移,在界面尚未開發(fā)出來時,測試人員能投入測試。投入越早,發(fā)現(xiàn)缺陷修復(fù)成本越低。
- 接口測試可以發(fā)現(xiàn)一些界面發(fā)現(xiàn)不了的問題。
- 界面對參數(shù)做了檢查,非法的值限制輸入。通過接口可以做一些異常測試。
- 一些場景比較復(fù)雜,通過界面很難構(gòu)造出來。
- 淘寶:APP版本、小程序版本、網(wǎng)頁版本、平板、IOS,功能一樣,對應(yīng)后臺服務(wù)是一樣的。
- 數(shù)據(jù)存儲、業(yè)務(wù)邏輯的處理在服務(wù)端完成,通過接口測試可以模擬更多場景。
- 接口測試成本低,收益高。界面是頻繁變化的。后臺的接口一旦固定,很好變化。
- 接口測試原理
- 用工具或代碼模擬客戶端向服務(wù)器發(fā)送請求報文,服務(wù)器接收請求報文后,對相應(yīng)的報文做處理并將處理的結(jié)果返回給工具或代碼,工具或代碼對返回的結(jié)果進行校驗。
- 接口測試點(重點)
- 參數(shù)測試
- 必填的參數(shù)、可選參數(shù),必填參數(shù)不填,或者必填與可選之間參數(shù)組合
- 參數(shù)的默認(rèn)值是不是正確,是不是合理。
- 業(yè)務(wù)邏輯
- 業(yè)務(wù)交互的測試:提交訂單,先去校驗用戶有沒有登錄。
- 返回值的測試
- 查詢類的接口,可能沒有參數(shù)。比如說查詢用戶列表
- 報表類的接口,數(shù)據(jù)庫中有大量數(shù)據(jù),通過(算法)接口生成一個報表/趨勢圖,如何測試
- 通過構(gòu)造不同的數(shù)據(jù),看生成的圖表是否正確
- 安全測試
- 敏感信息是否加密,密碼、簡單的加密,同一個密碼每次加密后的字符串是相同的。
- 敏感信息不能記錄到日志。pwd(操作日志、系統(tǒng)日志)
- 接口防攻擊的處理,在1分鐘內(nèi)調(diào)用100次以上的話,認(rèn)為受到攻擊,限制IP/用戶訪問系統(tǒng)。
- 參數(shù)前后臺都要去校驗。
- 前臺的校驗(界面測試)是為了提示給用戶,防止用戶輸入不合法的數(shù)據(jù),且出錯時能有提示,
- 后臺的校驗(接口測試)是防止黑客繞過前臺,通過接口直接訪問后臺,如果后臺不校驗,非法數(shù)據(jù)可以直接寫入數(shù)據(jù)庫,且遭到攻擊。
- HTTP協(xié)議
- 協(xié)議特點:
- 無連接
- C/S 結(jié)構(gòu),基于TCP/UDP,長連接的,登錄后,保持連接的狀態(tài)。
- B/S結(jié)構(gòu),基于HTTP,短連接,連接只在一發(fā)一收時保持,收發(fā)結(jié)束的時候連接斷開。
- 媒體獨立
- 發(fā)送給中類型的數(shù)據(jù):文本、圖片、音頻、視頻……
- 無狀態(tài)
- 因為時短連接,本次發(fā)送請求前,不知道以前發(fā)送過什么。
- 請求
- 請求報文
- 請求行,方法,url(get請求的參數(shù)在url中),協(xié)議版本
- 示例
- post請求,百度翻譯
- Content-Type: application/x-www-form-urlencoded; charset=UTF-8
- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36
- 請求方法
- get與post差別
- 傳參的方式不一樣
- get把參數(shù)放到請求頭中,url?key=value&key=value&key=value
- get請求不安全,post請求安全
- get請求的參數(shù)在url中,url有長度的限制,但是post參數(shù)在請求體,沒有參數(shù)的限制。
- get請求傳的參數(shù)是key=value格式的,post可以傳任意類型的參數(shù),content-type設(shè)置參數(shù)的類型。
- get請求和參數(shù)可以保存成瀏覽器的歷史記錄,post的參數(shù)保存不到歷史記錄中。
- Cookie與Session
- HTTP是無連接、無狀態(tài)的
- 比如訪問淘寶,A用戶瀏覽商品,B用戶將商品加購物車。系統(tǒng)怎么判斷把商品加到B的購物車,而不是A的購物車。
- 用戶識別的技術(shù):Cookie、Session、Token
- Cookie:識別客戶身份的信息記錄在客戶端的。(身份證)

- 過期時間:如果不設(shè)置過期時間,稱作會話Cookie,瀏覽器關(guān)閉的時候失效;設(shè)置過期時間后,稱作持久Cookie,等到過期時間時失效。
- 其他
- Set-Cookie:服務(wù)器響應(yīng)頭中帶的
- Cookie存放在客戶端的本地,同一個用戶多次登錄、多臺機器上登錄,服務(wù)器分配的Cookie信息不同。
- Session:識別客戶身份的信息記錄在服務(wù)器端,客戶端有一個SessionId(比如某個工廠,大門處的客戶列表,來訪的人在列表中可以進入)
- Cookie與Session對比
- Cookie保存在客戶端,Session在服務(wù)器,Session更加安全。
- Session在服務(wù)器的內(nèi)存中、數(shù)據(jù)庫、文件,如果用戶量比較大,會占用服務(wù)器的資源。
- Cookie有效期比較長,Session有效期短。
- Token:
- 客戶端頻繁登錄服務(wù)器,服務(wù)器每次判斷用戶名密碼是否正確,查詢比較頻繁,服務(wù)器壓力大。
- HTTP與HTTPs的差別
- 使用HTTPs的網(wǎng)站要去數(shù)字認(rèn)證機構(gòu)申請CA證書,證明服務(wù)器與瀏覽器的身份。證書需要年費。
- 默認(rèn)端口號不一樣。HTTP端口號是80,HTTPs端口號是443。
- HTTPs加重了服務(wù)端的負擔(dān),降低了用戶的訪問速度。
- Fiddler
- 對Requests加斷點:比如注冊接口,界面對密碼做了限制,只能輸入5~18位的密碼,超過這個范圍的不能輸入。要測試密碼異常的場景,可以用Fiddler先抓到正常的報文,然后將參數(shù)的值修改為非法的,比如19位的密碼后,再發(fā)送??捶?wù)器是否能正常處理。
|