接口測試-賀威棟-2021.03.17

• 接口分類：
  
  • 系統(tǒng)之間的接口
    
  • 服務(wù)之間的接口
    
  • 系統(tǒng)內(nèi)部的接口
    
• 接口的作用：傳遞數(shù)據(jù)
• 接口的本質(zhì)：數(shù)據(jù)的輸入和輸出
• 接口測試：單元測試（投入最少，unit）、服務(wù)/接口測試（API）、界面測試（GUI）
  
  • 接口自動化測試與界面自動化測試
    
    • 
      
  • 接口自動化測試比界面自動化測試收益高，優(yōu)先級高
    
    • 界面開發(fā)、后臺業(yè)務(wù)邏輯的開發(fā)是不同的人，前后臺的開發(fā)進(jìn)度不一樣。接口測試讓測試遷移，在界面尚未開發(fā)出來時，測試人員就能投入測試，投入越早，發(fā)現(xiàn)缺陷修復(fù)的成本越低
      
    • 接口測試可以發(fā)現(xiàn)一些界面發(fā)現(xiàn)不了的問題
      
      • 界面對參數(shù)做了檢查，非法的值限制輸入，通過接口可以做一些異常測試
        
      • 一些場景比較復(fù)雜，通過界面很難構(gòu)造出來
        
      • 淘寶：APP版本、小程序版本、網(wǎng)頁版本、平板、IOS，功能一樣，對應(yīng)后臺的數(shù)據(jù)一樣
        
        • 數(shù)據(jù)存儲、業(yè)務(wù)邏輯的處理在服務(wù)端完成，通過接口測試可以模擬更多場景
          
        • 前臺只是負(fù)責(zé)頁面的展示
          
      • 接口測試的成本低、收益高、界面是頻繁變換的。后臺的接口一旦固定，很少變化
        
• 接口測試流程：
  
  • 獲取接口文檔：
    
    • 接口功能
      
    • 接口URL
      
    • 請求方法
      
    • 請求參數(shù)
      
    • 返回包數(shù)據(jù)的實例
      
    • 返回碼的解釋
      
  • 分析文檔及需求
    
  • 設(shè)計接口測試方案
    
  • 設(shè)計接口測試用例
    
  • 開發(fā)測試腳本
    
  • 接口測試執(zhí)行
    
  • 輸出接口測試報告
    
• 接口測試原理：
  
  • 用工具或代碼模擬客戶端向服務(wù)器發(fā)送請求報文，服務(wù)器接收請求報文后，對相應(yīng)的報文做處理并將處理的結(jié)果返回給工具或代碼，工具或代碼對返回的結(jié)果進(jìn)行校驗。
    
  • 接口測試是黑盒測試
    
• ☆☆☆接口測試點（重點）：
  
  • 參數(shù)測試：
    
    • 參數(shù)的邊界值、等價類
      
    • 必填的參數(shù)、可選參數(shù)、異常：必填的參數(shù)不填，或者必填和可選之間參數(shù)組合
      
    • 參數(shù)為空、參數(shù)值為空
      
    • 多參數(shù)、少參數(shù)
      
    • 參數(shù)的默認(rèn)值是不是正確，是不是合理
      
  • 業(yè)務(wù)邏輯：
    
    • 單接口
      
    • 業(yè)務(wù)交互的測試：提交訂單，先去校驗用戶有沒有登錄
      
      • 登錄>>提交訂單，成功
        
      • 用戶未登陸>>提交訂單，報錯
        
    • 返回值的測試
      
      • 各種錯誤碼
        
      • 查詢類的接口，可能沒有參數(shù)。比如說查詢用戶列表
        
        • 0條數(shù)據(jù)
          
        • 1條數(shù)據(jù)
          
        • 100000條數(shù)據(jù)
          
        • 1000000條數(shù)據(jù)
          
      • 報表類的接口，大數(shù)據(jù)，數(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é)議
  
  • 特點：
    
    • 媒體獨立
      
      • 發(fā)送給種類型的數(shù)據(jù)：文本、圖片、音視頻...
        
    • 無連接
      
      • C/S結(jié)構(gòu)，基于TCP/UDP，長鏈接的，登錄后保持連接的狀態(tài)
        
      • B/S結(jié)構(gòu)，基于HTTP，短連接，連接只在一發(fā)一收時保持，收發(fā)結(jié)束的時候連接斷開
        
    • 無狀態(tài)
      
      • 因為是短連接，本次發(fā)送請求前，不知道以前發(fā)送過什么
        
  • 傳輸內(nèi)容：HTTP請求：
    
    • 請求報文：
      
      • 請求行，方法，url（get請求的參數(shù)在url中）、協(xié)議版本號
        
      • 請求頭部
        
      • 空行
        
      • 請求體，post請求帶的參數(shù)
        
    • get請求：百度搜索
      
      • http://www.baidu.com/s?wd=hello
        
    • post請求：百度翻譯
      
      • https://fanyi.baidu.com/langdetect
        
      • Content-Type: application/x-www-form-urlencoded; charset=UTF-8
        
      • Content-Length: 17
        
      • 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ù)
    
  • post：增刪改查資源
    
  • get和post區(qū)別：
    
    • 傳參的方式不一樣
      
      • get把參數(shù)放到請求中，url？key=value&key=value&key=value
        
      • post請求吧參數(shù)放到請求體中
        
    • get請求不安全，post請求安全
      
      • get請求參數(shù)暴露在url中
        
      • get請求的參數(shù)在url中，url有長度的限制，但是post參數(shù)在請求體，沒有參數(shù)的限制。
        
      • get請求傳的參數(shù)是key=value格式的，post可以傳任意類型的參數(shù)，content-type設(shè)置參數(shù)的類型。
        
      • get請求和參數(shù)可以保存成瀏覽器的歷史記錄，post的參數(shù)保存不到歷史記錄中。
        
      • get請求可以保存為書簽，post請求不可以。
        
• Cookie與Session
  
  • HTTP是無連接、無狀態(tài)的
    
    • 比如訪問淘寶，A用戶瀏覽商戶，B用戶將商品加購物車?yán)?。系統(tǒng)怎么判斷把商品加到B的購物車，而不是A的購物車
      
  • 用戶識別的功能，Cookie、Session、Token技術(shù)
    
    • Cookie：識別客戶身份的信息記錄在客戶端。（身份證）
      
      • 存儲在客戶端
        
      • 不可跨域
        
      • 名字：就是給Cookie起一個名字。
        
      • 值：Cookie中記錄的信息內(nèi)容。
        
      • 路徑與域：Cookie的作用范圍。
        
      • 過期時間：如果不設(shè)置過期時間，稱作會話Cookie，瀏覽器關(guān)閉的時候失效；設(shè)置過期時間后，稱作持久Cookie，等到過期時間時失效。
        
      • 其他
        
        • Set-Cookie：服務(wù)器響應(yīng)頭中帶的
          
        • Cookie：客戶端請求頭中帶的。
          
        • Cookie存放在客戶端的本地，同一個用戶多次登錄、多臺機(jī)器上登錄，服務(wù)器分配的Cookie信息不同。
          
      • 
        
  • Session：識別客戶身份的信息記錄在服務(wù)器端，客戶端有一個Sessionld（比如工廠來訪的人在客戶列表才可進(jìn)入）
    
  • 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)證機(jī)構(gòu)申請CA證書，證明服務(wù)器與瀏覽器的身份。證書需要年費。
      
    • 默認(rèn)端口號不一樣。HTTP端口號是80，HTTPs端口號是443。
      
    • HTTPs的技術(shù)門檻較高。
      
    • HTTPs加重了服務(wù)端的負(fù)擔(dān)，降低了用戶的訪問速度。
      
• Fiddler
  
  • 對Requests加斷點：比如注冊接口，界面對密碼做了限制，只能輸入5~18位的密碼，超過這個范圍的不能輸入。要測試密碼異常的場景，可以用Fiddler先抓到正常的報文，然后將參數(shù)的值修改為非法的，比如19位的密碼后，再發(fā)送?？捶?wù)器是否能正常處理。
    
    • 增加斷點：bpu https://www.baidu.com/s   （https://www.baidu.com/s 是百度搜索的接口地址）
      
    • 取消斷點：bpu
      
  • 對Response加斷點
    
    • 增加斷點：bpafter https://www.baidu.com/s  
      
    • 取消斷點：bpafter