REST API接口測試

背景介紹

爲何要作藉口測試?
不少系統關聯都是基於接口來實現的,接口測試能夠將複雜的系統關聯進行簡化.
接口功能比較單一,可以比較好的進行測試覆蓋,也相對容易實現自動化持續集成.
接口至關於界面功能,會更底層一些,測試覆蓋會更容易.

軟件開發生命週期?
接口測試在單口測試後,UI測試以後
接口測試能夠得到較高的投資回報(接口測試比單元測試的粒度要粗一些)

什麼是接口測試? (什麼是接口: 電梯、開車剎車、搜索引擎,不用關注內部,只關注外部應用)
接口測試又稱爲API測試 Application Programming Interface
接口測試是測試系統組件間接口的一種測試. 重點關注數據傳遞.
接口測試通常會用於多系統間交互開發,或者擁有多個子系統的應用系統開發的測試.

Web Service
一種跨編程語言和跨操做系統平臺的遠程調用技術
    最重要的兩種實現方式: SOAP(只支持xml格式,但擁有良好的安全性.銀行項目,能夠考慮使用SOAP協議) & REST(http: json或其餘格式,是一種設計規範)
    Web2.0時代,REST方法的普遍普及.

SOAP & REST
SOAP - Simple Object Access Protocol
    交換數據一種協議規範,是一種輕量的、簡單的、基於XML的協議.
REST - Representational State Transfer
    一種軟件架構風格,能夠下降開發的複雜性,提升系統的可伸縮性.

二者的區別:
    安全性: SOAP會好於REST
    效率和易用性: REST更勝一籌
    成熟度: 總的來講SOAP(存在時間比較長)在成熟度上因爲REST

REST or RESTFUL 區別:
    RESTful是REST的形容詞形式
    RESTful API指的是REST風格的接口
    通常來講REST等於RESTful,區別一個是名詞一個是形容詞

REST API (基於http的)
    出現: REST最先是由Roy Fielding博士發表的論文中提到的
    定義: 簡單來講REST是一種系統架構設計風格(而非標準),一種分佈式系統的應用層解決方案
    目的: Client和Server端進一步解耦
    應用: 最爲經典的莫過於github API

核心思想是資源
    資源:
        建立資源 - HTTP POST (Create)   至關於數據庫的CRUD
        獲取資源 - HTTP GET (Retrieve)
        更新資源 - HTTP PUT (Update)
        刪除資源 - HTTP DELETE (Delete)


REST特色總結:
    面向資源的接口設計
    抽象操做爲基礎的CRUD
    Http是應用協議而非傳輸協議


REST支持的方法:

        Verd                    描述
    HEAD(SELECT)        只獲取某個資源的頭部信息
    GET(SELECT)         獲取資源
    POST(CREATE)        建立資源
    PATCH(UPDATE)       更新資源的部分屬性(不多用,通常用POST代替)
    PUT(UPDATE)         更新資源,客戶端須要提供新建資源的全部屬性
    DELETE(DELETE)      刪除資源


補充一些概念:
    冪等性(Idempotent):
        是一個數學上的概念,在這裏表示發送一次或屢次請求引發的邊界效應是一致的.Post是不冪等方法
    安全性: 
        GET、HEAD和OPTIONS均被認爲是安全的方法,由於它們旨在實現對數據的獲取,並不具備「邊界效應(Side Effect)」


設計規範:
    協議: 使用HTTPs協議,確保交互數據的傳輸安全.
    域名: 應該儘可能將API部署在專用域名之下.
        https://api.example.com
    版本控制: 將版本號放在URL或者Header中
    路徑: 只能包含路徑,不能包括動詞
    過濾信息: ?limit=10  ?offset=10  ?page=1  ?sortby=name
    Hypermedia API: 在返回結果中提供相關資源的連接,連向其餘API方法
    驗證(Authentication): 肯定用戶是其申明的身份,好比提供帳戶的密碼.

常見的HTTP status code狀態碼:
    200(OK) - 若是如今資源已被更改
    201(created) - 若是新資源被建立
    202(accepted) - 已接受處理請求但還沒有完成(異步處理)
    301(Moved Permanently) - 資源的URL被更新
    303(See Other) - 其餘(如,均衡負載)
    400(bad request) - 指代壞請求
    406(no acceptable) - 服務端不支持所需表示
    409(conflict) - 通用衝突
    412(Precondition Failed) - 前置條件失敗(如執行條件更新時的衝突)
    415(unsupported media type) - 接受到的表示不受支持
    500(internal server error) - 通用錯誤響應
    503(Service Unavailable) - 服務當前沒法處理請求 


返回結果設計:
    通用錯誤碼, 具體產品由具體產品api文檔給出
    {
        "msg":"uri_not_found",
        "code":1001,
        "request":"GET Vv2VphotoV132"
    }

REST API接口實例
    GET /producet: 列出全部產品
    POST /product: 新建一個商品
    GET /product/ID: 獲取某個指定商品的信息
    PUT /product/ID: 更新某個指定商品的信息
    DELETE /product/ID: 刪除某個商品
    GET /product/ID/purchase: 列出某個指定商品的全部投資者
    GET /product/ID/purchase/ID: 獲取某個指定商品的指定投資者信息





手動測試
    測試方法:
        藉助工具來完成
        拼接參數執行請求

自動化測試
    測試方法:
        編寫自動化腳本實現
        一勞永逸,加入迴歸測試集合(天天能夠按期啓動)
        須要必定編碼經驗



常見的測試工具:
    Postman
    JMeter 性能測試,壓力測試工具,也能夠作RestAPI的測試
    RestClient 等等





功能測試:
    測試覆蓋:
        業務流程。支付功能
        邊界值,特殊字符(0-255),特殊字符的驗證(中日文,雙字符)
        參數類型,必選項,可選項等

性能測試:
    測試覆蓋:
    併發數: 同一時間,同時發給用戶的數量, 好比說:能夠支持50個併發,100個併發,咱們能夠採用逐步加壓的方式,找到系統支持的最大併發量
    吞吐量,tps(性能指標)
    錯誤率等


安全型測試
    測試覆蓋:
        敏感數據加密
        惡意攻擊


REST API的測試步驟
    瞭解接口格式
    編寫測試用例
    測試用例評審(測試團隊和開發團隊一塊評審)
    開始測試
    完成測試報告(中間要通過屢次的迭代)
    結束


Postman介紹
    Postman是Google開發的一款功能強大的網頁調試與發送網頁HTTP請求,並能運行測試用例的Chrome插件.

主要功能包括:
    模擬各類HTTP requests
    Collection功能(測試集合)
    人性化的Response整理
    內置測試腳本語言
    設定變量與環境

HTTP Header:
    Accept: 指定客戶端可以接收的內容類型
    Accpet-Charset: 瀏覽器能夠接受的字符編碼集
    Authorization: HTTP受權的受權證書
    Content-Type: 請求的與實體對應的MIME信息
    Referer: 先前網頁的地址,當前請求網頁緊隨其後,指來路(引流)


contect-type:
    application/x-www-form-urlencoded: 請求默認方式,數據是簡單、平面的key-value鍵值對
    application/json: 數據是複雜的嵌套關係,有多層數據
    multipart/form-data: 既能夠發送文本數據也支持二進制數據上載