說明：該篇博客是博主一字一碼編寫的，實屬不易，請尊重原創，謝謝大家！

一、分層的自動化測試

1.傳統自動化測試

• 基於產品 UI 層的自動化測試，它是將黑盒功能測試轉化爲由程序或工具執行的一種自動化測試。
  ✔     在目前的大多數研發組織當中，都存在開發與測試團隊割裂（部門牆）、質量職責錯配（測試主要對質量負責）的問題，在這種狀態下，測試團隊的一個「正常」反應就是試圖在測試團隊能夠掌控的黑盒測試環節進行儘可能全面的覆蓋，甚至是儘可能全面的 UI 自動化測試。
  ✔     這導致，一方面測試團隊規模急劇膨脹；另一方面，因爲 UI 是非常易變的，所以 UI 自動化測試維護成本相對較高。

2.測試金字塔

由敏捷大師 Mike Cohn 在他的 Succeeding with Agile 一書中首次提出。他的基本觀點是：我們應該有更多低級別的單元測試，而不僅僅是通過用戶界面運行高層端到端的測試。

3.分層自動化測試

• Martin Fowler 在測試金字塔模型的基礎上提出分層自動化測試的概念。在自動化測試之前加了一個「分層」的修飾，用來區別於「傳統的」自動化測試。
• 分層自動化測試倡導的是從黑盒（UI）單層到黑白盒多層的自動化測試體系，從全面黑盒自動化測試到對系統的不同層次進行自動化測試。
  

二、接口測試基礎知識

1.接口的含義

• 接口也叫 API（Application Programming Interface，應用程序編程接口）
  ✔     是一組定義、程序及協議的集合
  ✔     它提供訪問一組例程的能力，無需訪問源碼或理解內部工作機制的細節。

2.接口的分類

• 第一種是代碼內部的接口或稱程序接口
  ✔     是程序模塊間的接口，代碼 A 與代碼 B 在組合的時候，必然需要定義一些名稱以及參數、類型。
  ✔     對於程序接口的測試，一般需要使用與開發程序接口相同的編程語言，通過對類、方法和函數的調用，驗證其返回結果是否正確來進行測試。
  ✔     這種測試一般劃分在白盒測試中，也算是集成測試階段，既可以由開發人員自己完成，也可以由有良好編程能力的測試人員來做。

• 第二種接口是協議接口
  ✔     是系統與系統之間，通過網絡數據的傳遞進行交互，這種類型的接口對底層代碼做了封裝，系統通過不同的協議提供接口對外提供調用。
  ✔     此類測試一般不涉及底層程序，也看不到代碼，屬於黑盒層面，可以通過各種手段將網絡數據發送到接口從而得到接口的響應信息，達到測試的目標。
  ✔     這一類測試工作多數情況下由測試人員完成。通常所說的的接口測試主要是對協議接口的測試。

3.接口測試

3.1 接口測試的含義

• 接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。
• 測試的重點是要檢查數據的交換，傳遞和控制管理過程以及系統間的相互邏輯依賴關係等。

3.2 接口測試的意義

3.2.1 爲什麼測試接口

• 接口其實就是前端頁面或 APP 等調用與後端做交互用的，但是功能測試都測了，爲什麼還要測接口呢？
  ✔     如測試用戶註冊功能，規定用戶名爲 6~18 個字符，包含字母（區分大小寫）、數字、下劃線。
         ★     功能測試
                 ■     對用戶名規則進行測試，比如輸入 20 個字符、輸入特殊字符等
                 ■     但這些可能只是在前端做了校驗，後端可能沒做校驗，如果用戶名和密碼未在後端做校驗，而有人又繞過前端校驗的話，那用戶名和密碼不就可以隨便輸了嗎？如果是登錄可能會通過 SQL 注入等手段來隨意登錄，甚至可以獲取管理員權限，那這樣不是很恐怖？

3.2.2 接口測試的意義

• 更早地發現問題
  ✔     測試工作應該更早地介入到項目開發中，因爲越早發現 bug，修復的成本越低。
         ★     功能測試必須要等到系統提供可測試的界面後才能進行。
  ✔     單元測試和接口測試是更早介入測試的兩個方面。
         ★     接口測試可以在功能界面未開發出來之前對系統的接口進行測試，從而可以更早地發現問題並以更低的成本修復問題。
         ★     在一些實際項目開發過程中，開發人員並沒有充足的時間去編寫單元測試，並且他們往往對自己編寫的代碼有足夠的信心，不願意將時間「浪費」在單元測試的編寫上。這個時候接口測試就會變得更加重要。

• 縮短產品研發週期
  ✔     接口測試的介入可以更早地發現並解決 bug，使得留到功能測試階段被修復的 bug 減少，從而縮短整個項目的上線時間。

• 發現更底層的問題
  ✔     系統中的有些 bug 如果想通過 UI 層功能測試會比較困難，或者構造測試條件非常複雜。通過接口測試可以更簡單更全面地覆蓋到底層的代碼邏輯，從而可以發現一些隱藏的 bug。
  ✔     通常把 UI 層的驗證稱爲弱驗證，這是因爲它很容易被繞過。如果只針對 UI 層的功能進行測試，就很難發現後端系統對一些異常情況的處理能力，而接口測試可以很容易地驗證這些異常情況。

• 前端隨便變，接口測好了，後端不用變
  ✔     前端與後端的分離，是近年來 Web 應用開發的一個發展趨勢。
  ✔     這種模式的優勢
         ★     前端的專業性越來越高，通過調用 Web 接口獲取數據，從而專注於數據展示和頁面交互的設計。
         ★     後端不必精通前端技術（HTML5/JavaScript/CSS），只專注於數據的處理並提供 Web 接口即可。
                 ■     由後端開發的接口既可以提供給 Web 頁面調用，也可以提供給移動APP 調用；
                 ■     既可以提供給公司內部系統調用，也可以提供給公司外部系統調用。

• 檢查系統的安全性、穩定性

3.3 協議接口的分類

3.3.1 按系統不同的調用方式進行分類

• 系統與系統之間的接口
  ✔     系統與系統之間的接口，既可以是公司內部不同系統之間調用的接口，也可以是不同公司不同系統之間調用的接口。
         ★     後者如微信、微博所提供的第三方登錄接口，如果你開發的系統不想自建用戶體系，那麼完全可以調用這些接口來實現用戶的登錄。

• 系統內部，服務與服務之間的調用
  ✔     大多情況下是指程序之間的調用。
         ★     假設系統開發一個用戶查詢接口，輸入用戶名，返回用戶信息（性別、年齡、手機號、郵箱地址等），如果用戶不存在則返回 null。
         ★     現在需要新開發一個用戶抽獎的接口，該接口需要用戶名和抽獎活動 id，抽獎接口得到用戶名後可以調用用戶查詢接口，如果用戶查詢接口返回null，那麼抽獎接口就可以直接返回用戶不存在了。
         ★     這個例子中，用戶抽獎接口調用的就是用戶查詢接口。用戶查詢接口和抽獎接口本質上就是程序開發的函數或方法，提供入參與返回值。

• 下層服務對上層服務的接口
  ✔     應用層
         ★     可以認爲是系統所提供的 UI 層功能。對於 Web 系統來說，就是瀏覽器頁面上所提供的功能，如登錄、註冊、查詢、刪除等。
  ✔     Service 層
         ★     可以理解爲服務器所提供數據的處理。
  ✔     DB 層
         ★     數據庫（DataBase）主要用來存放數據。
  ✔     各層之間的調用過程
         ★     首先應用層實現了一個用戶查詢的功能，需要用戶輸入查詢的關鍵字，並顯示查詢結果。
         ★     當用戶使用查詢功能時，首先底層調用 Service 層所提供的查詢接口，查詢接口得到應用層調用的查詢數據；然後再通過 DAO 訪問數據庫，根據用戶輸入的查詢數據，查詢數據庫中的數據。
         ★     最後，將查詢到的數據庫數據返回給應用層，用戶在應用層看到查詢結果。
         ★     在這個過程中，各層之間的交互就是通過接口，應用層與 Service 主要通過HTTP 接口，Service 層與 DB 層主要通過 DAO（Data Access Object）數據庫訪問接口。

3.3.2 按協議的不同進行分類

• webService 接口
  ✔     使用 soap 協議
  ✔     通過 http 傳輸，請求報文和返回報文都是 xml 格式的
  ✔     通常使用的工具 SoapUI、jmeter、loadrunner 等

• http api 接口
  ✔     使用 http 協議
         ★     HTTP 是 Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫，是從萬維網（www，World Wide Web）服務器傳輸超文本到本地瀏覽器的傳送協議。
         ★     HTTP 基於 TCP/IP 通信協議來傳遞數據（HTML 文件、圖片文件、媒體等）。
         ★     HTTP 協議工作於客戶端-服務端架構上。瀏覽器作爲 HTTP 客戶端通過 URL向HTTP 服務端（即 Web 服務器）發送請求。
  ✔     通過路徑來區分調用的方法，請求報文都是 key-value 形式的，返回報文一般都是 json 串
  ✔     最常用的兩種請求方式是 get 和 post 等方法
  ✔     通常使用的工具有 postman、RESTClient、jmeter、loadrunner 等

3.4 接口測試的原理

模擬客戶端向服務器發送請求報文，服務器接收請求報文後對相應的報文做處理並向客戶端返回應答，客戶端再接收應答的一個過程。

4.接口的組成

4.1 接口文檔的內容

• 接口說明
• 調用 url
• 請求方法（get/post）
• 請求參數、參數類型、請求參數說明、請求頭 header
• 返回參數說明、請求響應的代碼、響應內容

4.2 http 請求方法與請求參數

• 參數是客戶端向服務器發送的數據，有的可見，有的不可見。

• GET 請求
  ✔     發送指定參數的請求來取得服務器上的某一資源
  ✔     提交的數據會放在 URL 之後，以?分割 URL 和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456
  ✔     get 請求數據不會出現在 body 中

• POST 請求
  ✔     向指定資源提交數據，數據被包含在請求體中（提交的數據放在 HTTP 包的 Body 中）
  ✔     不在 url 中出現

• GET 請求和 POST 請求的區別
  ✔     GET 使用 URL 或 Cookie 傳參，而 POST 將數據放在 BODY 中。
  ✔     GET 的 URL 會有長度上的限制，而 POST 的數據則可以非常大。
         ★     不同瀏覽器要求不同，如 IE6 要求最大 256
  ✔     POST 比 GET 安全。
         ★     get 請求能夠被緩存，請求會保存在瀏覽器的瀏覽（歷史）記錄中，請求的數據會顯示在地址欄中，不安全，請求的 url 能夠保存爲瀏覽器書籤（收藏夾）
         ★     post 請求不能被緩存，請求不會保存在瀏覽器瀏覽記錄中；請求的數據不會顯示的地址欄中，相對安全；請求的 url 無法保存爲瀏覽器書籤
  ✔     一般 get 請求用來獲取數據，post 請求用來發送數據。
  ✔     get 請求數據只支持 ASCII 類型，post 請求數據類型沒有限制，支持二進制數據。

4.3 header

• 標頭 (header) 是服務器以 HTTP 協議傳 HTML 資料到瀏覽器前所送出的字串，一般存放cookie、token 等信息。
  ✔     header 和入參的關係
         ★     它們都是發送到服務器裏的參數，但它們是有區別的，header 裏存放的參數一般存放的是一些校驗信息，比如 cookie，它是爲了校驗這個請求是否有權限請求服務器，如果有，它才能請求服務器，然後把請求地址連同入參一起發送到服務器，然後服務器會根據地址和入參來返回出參。也就是說，服務器是先接受 header 信息進行判斷該請求是否有權限請求，判斷有權限後，纔會接受請求地址和入參的。
  ✔     Cookie
         ★     萬維網站點使用 Cookie 來跟蹤用戶。
         ★     Cookie 表示在 HTTP 服務器和客戶之間傳遞的狀態信息。
         ★     使用 Cookie 的網站服務器爲用戶產生一個唯一的識別碼。利用此識別碼，網站就能夠跟蹤該用戶在該網站的活動。
  ✔     Session
         ★     Session 是指一個終端用戶與交互系統進行通信的時間間隔，通常指從註冊進入系統到註銷退出系統之間所經過的時間，以及如果需要的話，可能還有一定的操作空間。
         ★     Session 是用於保持狀態的基於 Web 服務器的方法。
         ★     Session 允許通過將對象存儲在 Web 服務器的內存中在整個用戶會話過程中保持任何對象。

• 請求頭信息
  ✔     請求報頭允許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。
  ✔     常用的請求報頭如下：
         ★     Accept：瀏覽器可接受的 MIME 類型。
                 ■     MIME 用於設定某種擴展名的文件用哪種應用程序來打開的方式類型，當該擴展名文件被訪問的時候，瀏覽器會自動使用指定應用程序來打開。
         ★     Accept-Encoding：瀏覽器能夠進行解碼的數據編碼方式，比如 gzip。
         ★     Accept-Language：瀏覽器所希望的語言種類，當服務器能夠提供一種以上的語言版本時會用到。
         ★     Connection：表示是否需要持久連接。從 HTTP/1.1 起，默認都開啓了 Keep-Alive，保持連接特性。
         ★     Host：初始 URL 中的主機和端口，它通常是從 HTTPURL 中提取出來的。
         ★     User-Agent：請求報頭域允許客戶端將它的操作系統、瀏覽器和其他屬性告訴服務器。

• 響應頭信息
  ✔     響應報頭允許服務器傳遞不能放在狀態行中的附加響應信息，以及關於服務器的信息和對 Request-URI 所標識的資源進行下一步訪問的信息。
  ✔     常用的響應報頭如下：
         ★     Content-Type：表示後面的文檔屬於哪種 MIME 類型。
         ★     Date：當前的 GMT（國際時）時間。
         ★     Server：包含了服務器用來處理請求的軟件信息。
         ★     X-Frame-Options：用來給瀏覽器指示允許一個頁面可否在<frame>、<iframe>或者<object>中展現的標記。網站可以使用此功能，來確保自己網站的內容沒有被嵌到別人的網站中去，從而也避免了點擊劫持（click jacking）的攻擊。

4.4 http 響應狀態碼

• 每發出一個 http 請求之後，都會有一個響應，http 本身會有一個狀態碼，來標示這個請求是否成功。
• 常見的狀態碼有以下幾種：
  ✔     1**
         ★     表示服務器收到請求，需要請求者繼續執行操作。
  ✔     200
         ★     2 開頭的都表示這個請求發送成功
         ★     最常見的是 200，代表這個請求是 ok 的，服務器也返回了。
  ✔     300
         ★     3 開頭的代表重定向，最常見的是 302，把這個請求重定向到別的地方了。
  ✔     400
         ★     400 代表客戶端發送的請求有語法錯誤，401 代表訪問的頁面沒有授權，403表示沒有權限訪問這個頁面，404 代表沒有這個頁面。
  ✔     500
         ★     5 開頭的代表服務器有異常，500 代表服務器內部異常，503 代表由於超載或系統維護，服務器暫時無法處理客戶端請求，504 代表服務器端超時，沒返回結果。

4.5 響應數據

• 當我們在請求一個頁面的時候，會顯示服務器返回的資源，其中包含了 HTML、CSS 和JavaScript，除此之外，服務器還可以返回圖片、視頻、字體和插件等類型的資源。這些資源全部使用 HTTP 協議傳輸。

• 如果把 HTTP 協議看作是高速公路的話，那麼在高速公路上跑的各種拉滿不同貨物的車輛就是資源。不同的車輛裝載的貨物不一樣，因此它們的目的地也不一樣。
  ✔     如有些車輛拉的是生豬，是要送到屠宰場的；有些車輛拉的是西瓜，是要送到水果批發市場的。

• HTTP 協議上傳輸的資源也是一樣，類型不同，作用也不一樣。數據就是其中的一種資源，數據是接口的本質。
  ✔     可以選擇不同的運輸方式，走高速公路或走鐵路，這就是數據傳輸協議的選擇（如HTTP/SOAP）。
  ✔     西瓜的存放方式，是直接將西瓜堆積到車廂裏，還是把每個西瓜放到盒子裏再裝箱，這就是數據格式的選擇（如 TEXT/XML/JSON/CSV）。

• JSON 格式
  ✔     JSON（JavaScript Object Notation，即 JavaScript 對象表示法）是一種輕量級的數據交換格式。它獨立於語言和平臺，JSON 解析器和 JSON 庫支持不同的編程語言。
  ✔     JSON 具有自我描述性，很容易理解。
  ✔     JSON 格式是當前主流的接口數據格式之一。從接口的調用方式和數據格式來看， JSON 不是直接給普通用戶來使用的，它主要爲其他開發者提供調用。

• JSON 響應數據的格式
  
  ✔     數據在名稱/值對中。
  ✔     數據由逗號分隔。
  ✔     花括號保存對象。
  ✔     方括號保存數組。

5.怎麼做接口測試

5.1 接口測試的流程

• 熟悉業務和需求
• 分析接口文檔
• 編寫接口測試用例
• 提測後開始測試
• 提交測試報告

5.2 編寫接口文檔

• 編寫接口文檔是接口開發中非常重要的一個環節，因爲開發的接口是給其他開發人員調用的，那麼如何知道接口是怎麼調用的呢？當然需要通過參考接口文檔了。那麼接口文檔就必須要做到更新及時，內容準確。
• 案例

接口名稱	添加…	說明
URL	http://127.0.0.1:8000/api/add_event/	測試 add_event 接口
調用方法	POST
傳入參數	eid name limit status(1/0)	參數含義：事件編號 參數含義：事件名字 參數含義：限時 參數含義：開啓狀態
返回值	‘status’:200, ‘message’:‘add event success’
狀態碼	10021:parameter error 10022:event id already exists 10023:event name already exists 200:add event success

5.3 通用接口用例設計

• 通過性驗證
  ✔     首先肯定要保證這個接口功能是正確的，也就是正常的通過性測試，按照接口文檔上的參數，正常傳入，是否可以返回正確的結果。

• 參數組合
  ✔     現在有一個操作商品的接口，有個字段 type
         ★     type 傳 1 的時候代表修改商品，商品 id、商品名稱、價格有一個是必傳的，這樣就要測參數組合了，type 傳 1 的時候，只傳商品名稱能不能修改成功，id、名稱、價格都傳的時候能不能修改成功。

• 接口安全
  ✔     繞過驗證
         ★     如購買了一個商品，它的價格是 300 元，那我在提交訂單時候，我把這個商品的價格改成 3 元，後端有沒有做驗證，更狠點，我把錢改成-3，是不是我的餘額還要增加？
  ✔     繞過身份授權
         ★     如修改商品信息接口，那必須得是賣家才能修改，那我傳一個普通用戶，能不能修改成功，傳一個其他的賣家能不能修改成功。
  ✔     參數是否加密
         ★     如登陸的接口，用戶名和密碼是不是加密，如果不加密的話，別人攔截到你的請求，就能獲取到你的信息。
         ★     加密規則是否容易破解。
  ✔     密碼安全規則
         ★     對密碼的複雜程度校驗。

• 異常驗證
  ✔     就是不按照接口文檔上的要求輸入參數，來驗證接口對異常情況的校驗。
         ★     如必填的參數不填，輸入整數類型的，傳入字符串類型，長度是 10 的，傳 11
         ★     必傳非必傳、參數類型、入參長度。

5.4 根據業務邏輯來設計用例

• 就是根據系統的業務來設計用例，這個每個公司的業務不一樣，就得具體的看自己公司的業務了，其實這也和功能測試設計用例是一樣的。