接口
1、接口又稱API(Application Programming Interface,應用程式程式設計接口)：是一些預先定義的函數，為友善應用程式或開發人員在無需通路其源碼，或了解其内部工作機制的情況下就能通路對應函數功能的入口
⑴接口是後端設計的一套供給第三方使用的方法(第三方指前端/後端)
⑵兩個不同的系統或者一個系統中兩個不同的功能，它們之間互相連接配接的部分稱為接口
2、軟體項目中，接口是系統與系統之間，子產品與子產品之間或者服務與服務之間互相調用的入口
⑴從開發者角度，接口是分工協作的産物，不同開發者實作自己的功能之後，封裝成接口，供其他開發者調用
⑵其他開發者隻要按規定格式發送一些必要參數，就能使用該功能
3、接口通過網絡協定來調用，我們最常用的協定是HTTP協定(不同系統之間)
4、在定義一個接口時，會寫好接口路徑和接口方法名的映射，然後前端通過接口路徑來調用方法(不同系統之間)
⑴舉個例子：一個擷取商品清單的接口，接口路徑是：/api/getMerchantList，接口方法名是：getMerchantList
⑵前端通過請求/api/getMerchantList來調用getMerchantList方法，接着後端會做相關邏輯處理，比如查詢資料庫，最後傳回商品資料
5、簡單概括為以下3點：
⑴程式代碼（函數方法）
⑵屏蔽實作細節
⑶可以被通路/調用來擷取資訊或實作某些功能(提供通路位址，定義了通路規則)
接口自述(通俗的來說)
1、首先我有一些功能（功能函數）
2、你不用關心我怎麼實作的（屏蔽細節）
3、我會給你一個我的位址（接口位址）
4、你按照位址找到我，按照我規定的格式（請求類型）告訴我所需要的資訊（參數）就行
5、我會給你個回報（相應資訊）
接口分類
1、依據所遵循的協定不同，常見的接口可以分為以下3類：
⑴HTTP接口：它是基于超文本傳輸協定(HTTP)開發的接口
⑵Web Service接口：它是系統對外的接口。比如你要從别的網站或者伺服器上擷取資源，别人不會把資料庫共享給你，他們會提供一個寫好的方法，讓你來擷取資料
⑶RESTful接口：簡稱REST，其描述了一個架構樣式的網絡系統，核心是面向資源。REST專門針對網絡應用設計和開發方式，降低開發的複雜性，提高系統的可伸縮性
2、按照使用場景也可以簡單的劃分為：
⑴系統與系統之間的調用，比如銀行會提供接口供電子商務網站調用，或者說，支付寶會提供接口給淘寶調用(對外接口)
⑵子產品與子產品之間的調用，比如注冊使用者時，會先調用使用者查詢的服務，檢視該使用者是否已經注冊(内部接口)
注：
1、基于浏覽器/伺服器模式(B/S)的軟體系統接口大多數為HTTP接口
2、一般情況下子產品與子產品之間的接口都是由開發完成的(單元測試等)
⑴接口調用方式為：方法名(函數)、參數
3、測試人員測試的基本上都是系統對外接口
⑴是以這裡介紹系統對外接口的測試流程
接口組成
1、一個完整的對外接口一般由以下部分組成：
⑴請求位址：也就是URL位址
⑵請求方法：GET、POST等
⑶請求header：部分接口需要header資訊(有些可能不需要)
⑷請求參數：發送請求時需要傳遞的資料(參數)，如parmas、body
①參數類型：比如JOSN、表單等
②請求參數說明：參數描述、參數類型(字元串、整形等)
接口測試
1、接口測試是項目測試的一部分，正如其名，主要測試系統對外部系統提供的接口，驗證其正确性和穩定性
2、一般來說接口測試按測試對象分為兩種類型：
⑴子產品接口測試：子產品接口測試其實就是單元測試的基礎，适用于分别開發一些功能子產品
⑵外部接口測試：就是測試用戶端(第三方使用者)與服務端之間的接口
3、接口測試是一種完整的測試體系，也分為接口功能測試、接口性能測試、接口穩定性測試、接口安全性測試
為什麼要做接口測試
1、接口測試能使測試團隊更早、更深入地介入項目：初期就能發現系統深層次的問題，降低問題修複的時間成本
2、接口是各種系統功能的基礎：接口測試介于單元測試與系統測試之間(單元測試一般由開發完成，不要相信開發)
3、接口的變更機率遠遠小于使用者界面的變更機率
⑴接口測試自動化維護成本比UI自動化維護成本更低，接口測試相對于更容易實作自動化測試持續內建
⑵減少回歸測試的人力和時間成本，縮短測試周期(持續內建是接口測試的靈魂)
4、可以發現很多在頁面上操作發現不了的bug
⑴可能隻是在前端做了校驗，後端可能沒做校驗，可通過工具繞過前端校驗發送請求到後端
接口測試的原理
1、測試人員借助工具模拟用戶端向伺服器端發送請求封包，伺服器端接收請求封包後，對相應的封包做出處理并向用戶端傳回應答，工具模拟用戶端接收應答，然後測試人員檢查應答是否正确
2、比如服務端http接口測試，常用的工具有jmeter、postman、httpclient等
接口測試的範圍
關于接口測試的範圍，主要從以下兩個方面進行介紹：
1、是否所有的接口都需要測試
⑴随着系統複雜度越來越高，接口越來越多，想要完全覆寫所有的接口是一件非常困難的事
⑵通常情況下，主要測試最外層的兩類接口：資料進入系統的接口(調用外部系統的參數為本系統使用)和資料流出系統的接口(驗證系統處理後的資料是否正确)
2、被測試接口需要測試哪些方面
⑴測試人員需要關注被測試接口的功能是否實作，性能是否達标，安全性是否滿足。重點關注資料的交換、傳遞、處理次數以及控制管理過程
注：
1、上面說的測試範圍是對于整個項目而言的。實際中的測試範圍還是根據需求文檔上來的。需求文檔上說要測試什麼就測試什麼
接口測試流程
1、接口測試也是屬于功能測試，是以跟以往的功 能測試流程并沒有太大差別，測試流程依舊是：
⑴需求文檔評審：需求人員編寫需求文檔後組織需求評審
⑵詳細設計文檔評審：開發人員根據提供的需求文檔編寫對應的功能詳細設計文檔并組織評審
⑶編寫測試計劃：測試人員根據需求、是情況等編寫測試計劃文檔
⑷編寫測試用例：測試人員根據需求文檔、詳細設計文檔編寫測試用例并組織評審
⑸搭建測試環境：功能提測之後，測試人員根據項目、功能搭建對應的測試環境
⑹執行冒煙測試用例：測試人員進行冒煙測試，保證功能主流程是通暢的
⑺執行用例：測試人員編寫測試用例
⑻缺陷管理：測試人員、開發管理BUG
⑼測試報告：測試人員編寫測試報告
需求文檔評審
1、需求人員講解需求：需要實作哪些功能
2、參與人員對需求提出問題等
詳細設計文檔評審
1、開發人員根據需求文檔編寫的功能設計文檔，主要包括以下方面：
⑴功能主要實作方式
⑵功能(接口)詳細說明
2、這裡的詳細設計文檔其實就是API文檔了：API文檔是接口測試中最重要的一個文檔
⑴如果沒有接口文檔，可能測試都無法展開
⑵接口文檔最好詳細到接口涉及的每一處
3、一個接口文檔主要包含以下部分：
⑴接口說明：接口實作什麼功能，如何實作(功能邏輯)
⑵接口位址：接口URL
⑶請求方法：GET、POST等
⑷請求header：部分接口需要header資訊(有些可能不需要)
⑸請求參數：發送請求時需要傳遞的資料(參數)，如parmas、body
①參數類型：比如查詢字元串參數、JOSN、表單等
②請求參數說明：參數描述、參數類型(字元串、整形等)、參數是否可選等
⑹傳回資料說明
①傳回資料格式
②需要傳回哪些字段
③傳回字段的說明：類型等
④傳回字段的資料源：對應哪張表中的哪個字段
4、接口文檔越詳細越好，感覺特别是接口說明、請求參數、傳回資料等一定要清楚
⑴比如一個查詢接口：查詢了哪些表、哪些字段、查詢邏輯、傳回字段與資料庫字段的對應關系等
⑵比如一個新增、更新接口：新增到哪張表、新增、更新邏輯、傳入參數與資料庫字段的對應關系等
⑶查詢邏輯：比如多表查詢時根據哪些字段關聯等
⑷新增、更新邏輯：比如傳入的參數是直接入庫還是根據參數在其他表中查詢後，将查詢結果入庫等
編寫測試計劃
1、接口測試計劃與功能測試計劃的目标一緻，都是為了确認需求、确定測試環境以及測試方法，為設計測試用例做準備，初步制定接口測試進度方案
2、一般來說，接口測試計劃包含概述、測試資源、測試功能以及重點，測試政策、測試風險、測試标準等
編寫測試用例
1、接口測試用例的設計方法其實和功能測試用例的設計方法是類似的，因為接口是需要滿足需求的
⑴根據需求文檔、接口文檔等項目相關文檔編寫并評審接口測試用例
2、接口測試思路如下圖
⑴設計測試用例還是需要熟悉業務、功能邏輯，然後根據兩者結合來設計、提取測試點
搭建測試環境
1、根據項目實際需要來搭建測試環境
2、現在我們項目主要使用的是Linux系統，伺服器包類型是war包和jar包
⑴war包：需要放到Tomcat中啟動
⑵jar包：包内置了Tomcat，是以可以直接驅動
⑶是以就需要對需要用到的Linux指令熟悉了
執行用例
1、執行用例前還需要準備測試資料
⑴這個的話主要還是根據實際用例場景來準備測試資料
⑵我們接口都是操作資料庫的，是以查詢類接口都是直接使用SQL在資料庫中插入測試資料
⑶也可以使用相應的增加資料接口來向資料庫中插入對應資料
2、執行接口測試用例的話，我們手工執行用例的話使用的是Postman
⑴這個工具還是挺簡單的，熟悉熟悉就會用例
3、自動化執行測試用例，我們使用的是Python+RF
4、測試過程中可能會使用到mock方法：mock測試就是在測試過程中，對于某些不容易構造或者不容易擷取的對象，用一個虛拟的對象來建立以便測試的測試方法
接口測試品質評估标準
1、接口覆寫率是否達到要求
2、業務規則覆寫是否完整
3、參數驗證是否達到要求(邊界、業務規則)
4、接口異常場景覆寫是否完整
5、代碼覆寫率是否達到要求
6、性能名額是否滿足要求
7、安全名額是否滿足要求
接口自動化
1、目前項目中我負責的業務有封包(XML、JSON封包)解析入庫、HTTP接口。這兩部分業務的自動化都使用的是Python+RF的方式
⑴手工測試完成之後，将對應的手工測試用例轉為自動化測試用例
⑵RF架構其實還是挺簡單的，其業務層還是使用Python編寫的：通過Python代碼将業務邏輯實作(類、函數)
①在RF層将Python函數封裝成對應關鍵字，然後通過關鍵字來組裝測試用例
②用例流程基本上就是手工測試步驟了
2、其目的主要還是用于回歸：在新功能提測之後都要跑一邊以前版本的自動化用例(保證以前的功能是正确的)
封包解析自動化流程
HTTP接口自動化流程
注：
1、整個自動化流程中還有其他的一些需要注意：
⑴資料庫的連接配接：RF中雖然提供了資料庫連接配接的關鍵字，但是我們使用的連接配接方法、查詢方法等都是自己寫的
①RF中其實也提供了requests對應的關鍵字，但是感覺不好用，是以發送請求的方法也是自己封裝的
⑵資料的處理：
①比如查詢資料、請求參數的合并、替換等
㈠請求參數中有兩個字段，但是入庫時是将兩個字段合并後入庫的
㈡請求參數中傳遞的是事件代碼，但是實際入庫的是經代碼查詢的描述資訊
②一定需要将資料處理好，這樣在對比時才不會出現問題
2、資料對比：主要使用的是集合的對稱差屬性來進行對比的
⑴一般情況下都是将查詢結果、請求參數等整理成一個字典{}或者是嵌套了字典的清單[{},{}...]，然後使用集合對稱差屬性來進行對比
⑵在對比時首先需要保證兩個對比資料中鍵名得是一樣的：鍵名都不一樣對比結果肯定不一樣
⑶如果是兩個字典{}資料對比的話，就簡單的多：直接将字典轉為集合，然後使用集合的對稱屬性來比較
⑷如果是兩個嵌套了字典的清單[{},{}...]資料對比的話，就會麻煩得多：
①首先從兩個資料源中擷取出需要對比的兩個字典：這裡使用的是資料庫主鍵及其值(如ID)來擷取兩個需要對比的字典，畢竟主鍵:值是不可能重複的，這樣就确定了兩個資料源中的唯一字典
②然後對比擷取到的兩個字典
③然後循環擷取下一組需要對比的字典，直到對比完全部字典資料，然後傳回最終對比結果
接口自動化測試持續內建的要點
進行項目測試時，接口會增加、減少或變更，測試用例也會相應更新，是以需要借助工具(如GitHub等)來維護測試用例進行持續內建，通過自動化測試實時監控項目接口運作情況。對接口測試而言，持續內建是核心内容，通過自動化的手段才能做到低成本、高收益。接口自動化測試持續內建主要包括以下内容：
1、流程方面：在回歸階段加強接口異常場景的覆寫，并逐漸向系統測試、冒煙測試階段延伸，最終達到全流程自動化
2、結果展示：更加豐富的結果展示，趨勢分析、品質統計和分析等
3、問題定位：報錯資訊、日志更加精确，友善問題的複現和定位
4、結果校驗：加強自動化校驗能力，如資料庫資訊校驗
5、代碼覆寫率：不斷嘗試由目前的黑盒向白盒下探，提高代碼覆寫率
6、性能需求：完善性能測試體系，通過自動化的手段監控接口性能名額是否正常