接口自動化理論引入

• 一.接口測試

  • 理論

    • 定義
      • 功能測試能夠分爲UI層的功能測試與接口層的功能測試。
      • UI層的功能測試，簡單理解的話，就是以用戶的角度，在頁面上直接進行操做行爲。
      • 而接口層的功能測試，是沒有頁面的，它是經過接口規範文檔上的調用地址、請求參數，拼接報文，發送請求，檢查返回結果，因此它只需測入參和出參就好了。
    • 做用
      • 接口測試能夠在功能界面還沒有開發出來以前就進行，從而能夠更早地發現問題並以更低的成本修復問題，由於越早發現bug,修復成本會越低；能夠發現更底層的問題，由於UI層的功能測試很難發現後端系統對一些異常狀況的處理能力。

  • 怎麼作接口測試

    • 工具
      • 抓包工具（好比瀏覽器F12或fiddler）
      • 接口測試工具（好比postman jmeter）
    • 請求與響應（以postman爲例）
      • 發送請求，關注：
        • 1.請求方式
        • 2.請求連接
        • 3.請求頭
        • 4.請求體
      • 接收到響應，關注：
        • 1.狀態碼
        • 2.響應體...

• 二.自動化測試

  • 理論

    • 定義
      • 自動化測試是一種利用代碼或工具來解放雙手，但同時更保證了產品質量的一種行爲。
    • 目的
      • 根本目的依舊是找缺陷,從而保證產品質量。更具體的說，就是讓測試工程師經過自動化測試解放生產力，讓其從重複的迴歸測試中轉而去探尋、研究更深層次的新的缺陷，從而將產品質量再提升一個檔次。
    • 不足
      • 自動化適用於迴歸和冒煙，而不是發現BUG、
      • 不是全部全部系統全部功能都適合作自動化測試。
      • 適用條件：軟件需求變更不頻繁、項目週期較長、自動化測試腳本可重複使用。

  • 爲何是優先選擇接口自動化測試而不是UI自動化測試

    • 因爲接口不易變動，因此作接口自動化的時間成本、維護成本會比UI自動化低不少。

  • 怎麼作接口自動化測試

    • 工具
      • 利用工具自動化好比postman
        • 入門快；幾乎沒有編程語言門檻；
        • 靈活性低；沒法與業務需求相結合；
      • RF框架
        • 有很是豐富的庫,能夠像編程同樣寫測試用例；關鍵字驅動；
        • 自定義 HTML 報告較爲麻煩；須要具有 編程語言的基礎知識；
      • pytest框架
        • 可以支持簡單的單元測試和複雜的功能測試；支持參數化；具備不少第三方插件，且文檔豐富；
        • 編程語言的掌握能力，相對要求較高；
      • httprunner
        • 靈活性高，仍在維護；
        • 調試與用例維護仍是比較麻煩；
      • 等等
    • 測試框架的基本組成
      • 1.工具類、基類封裝：主要包含公共函數及通用操做。
      • 2.配置資源管理：避免了項目中文件對常量的分散使用，讓常量能夠統一修改。
      • 3.測試用例管理：一個功能點對應一個或多個case,儘量的提升覆蓋率。
      • 4.測試數據管理：數據與腳本分離，下降維護成本，提升可移植性。
      • 5.回寫測試結果：日誌的輸出、測試報告的輸出以及即時通知。