接口測試入門基礎
1.接口測試概述
1.1 什麽是接口測試
接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
1.2 為什麽要做接口測試
a) 如今的系統復雜度不斷上升，傳統的測試方法成本急劇增加且測試效率大幅下降，接口測試可以提供這種情況下的解決方案。
b) 接口測試相對容易實現自動化持續集成，且相對UI自動化也比較穩定，可以減少人工回歸測試人力成本與時間，縮短測試周期，支持後端快速發版需求。接口持續集成是為什麽能低成本高收益的根源。
c) 現在很多系統前後端架構是分離的，從安全層面來說：
1、只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前面實在太容易）， 需要後端同樣進行控制，在這種情況下就需要從接口層面進行驗證。
2、前後端傳輸、日誌打印等信息是否加密傳輸也是需要驗證的，特別是涉及到用戶的隱私信息，如身份證，銀行卡等。
1.3 接口測試分類
接口測試大體分為兩類：模塊接口測試和web接口測試。
模塊接口測試
模塊接口測試是單元測試的基礎,它主要測試模塊的調用與返回。經常需要編寫一些樁模塊與驅動模塊。
主要測試要點如下：
檢查接口返回的數據是否與預期結果一致。
檢查接口的容錯性，假如傳遞數據的類型錯誤時是否可以處理。
接口的性能，接口處理數據的時間也是測試的一個方法。牽扯到內部就是算法與代碼的優化。
接口的安全性
Web接口測試
web接口測試又可分為兩類：服務器接口測試和外部接口測試。
服務器接口測試：是測試瀏覽器與服務器的接口。用戶輸入的數據是輸入到的前端頁面上，怎樣把這些數據傳遞的後臺的呢？通過http協議的get與post請求來實現前後端的數據傳遞。這也可認為是接口測試。
外部接口測試：這個很典型的例子就是第三方支付，比如在我們應用中在充流量時，交話費時，都會調用第三方支付接口。
主要測試要點如下：
請求是否正確，默認請求成功是200，如果請求錯誤也能返回404、500等。
接口的安全性，一般web都不會暴露在網上任意被調用，需要做一些限制，比如鑒權或認證。
接口的性能，這直接影響用戶的使用體驗。
1.4 測試用例設計與原則
因為在實際工作中測試的接口都是基於HTTP協議的，所以下面的測試用例及原則也是針對此類接口。
測試用例
正面測試用例：
a覆蓋所有的必選參數
b.組合可選參數
c.參數邊界值
如果參數的取值範圍是枚舉變量，需要覆蓋所有枚舉值
還應考慮實際業務應用場景，去設計輸入參數的組合。（這些用例可用來測試功能，作為SMOKE用例。也可將來用於壓力測試模擬實際業務場景，但要註意保證用例的獨立性，因為壓力測試是多線程的。比如我們測試ACCOUNT 創建接口，NAME是不能重的，在寫測試用例時，給NAME賦值時可以加一個時間戳, 這樣用例在多線程並發測試時也不會有問題）
負面測試用例：
a.空數據或null
b.包含特殊的字符
c.越界的數據
d.錯誤的數據
驗證點：
1.status code （正常情況下，所有請求都應該返回200）
2.響應信息數據結構（目前大多數情況下，返回信息都是JSON, 我們應該驗證相應的結構當數據信息發生改變時）
3.驗證結點的類型
4.驗證結點的值 （主要是針對固定的值或者值遵循某些規則，我們能知道預期的結果的）
5.對於列表，應該根據請求參數，也應該驗證列表的長度是否與期望值一致
6.負面測試用例，應驗證ERROR INFO是否與實際相匹配
測試基本原則
測試用例應該是獨立的、可讀的、抗變的、可維護的，其實這也是所有自動測試應該遵循的
1.每個測試用例都是獨立的
2.測試用例都是可重復運行的 (這主要是說一些測試數據不能寫死，不同的環境數據可能不同。在實際工作中，解決方案有二：自已創建所需要的數據，比如你要測試接口需要輸入參數ACCOUNTID,你可以先調用創建ACCOUNT API, 然後從響應值拿到ACCOUNTID, 當你3.測試完你要測的接口後，再把新建的ACCOUNT刪除，也就是說一個測試用例分了三步。另外一種方法就是讀取數據庫，從數據庫獲取數據，這種方法在測試開發與測試環境還OK，但如果測線上環境就比較困難了，因為我們不能隨意更新上面的數據，也不能放過多的4.測試數據在上面。因此我個人比較推崇第一種方法，雖然增加開發用例的工作量，但一勞永逸）
5.測試能被運行在不同的環境裏（平常測試環境至少會分DEV/TEST/STAGING/ONLINE，我們在測試過程中，應該把域名，token/apikey等應放在一個變量裏，當切換環境時，我們只需改變變量的值即可
6.測試數據與業務相分離（測試數據包括參數接口數據/ 測試執行所需要的系統數據)
7.盡量統一共用的測試環境變量
8.測試完成後，要刪除不必要的測試數據。
1.5 接口測試持續集成
對接口測試而言，持續集成自動化是核心內容，通過持自動化的手段我們才能做到低成本高收益。目前我們已經實現了接口自動化，主要應用於回歸階段，後續還需要加強自動化的程度，包括但不限於下面的內容：
a) 流程方面：在回歸階段加強接口異常場景的覆蓋度，並逐步向系統測試，冒煙測試階段延伸，最終達到全流程自動化。
b) 結果展示：更加豐富的結果展示、趨勢分析，質量統計和分析等
c) 問題定位：報錯信息、日誌更精準，方便問題復現與定位。
d) 結果校驗：加強自動化校驗能力，如數據庫信息校驗。
e) 代碼覆蓋率：不斷嘗試由目前的黑盒向白盒下探，提高代碼覆蓋率。
f) 性能需求：完善性能測試體系，通過自動化的手段監控接口性能指標是否正常。
1.6 接口測試質量評估標準
a) 業務功能覆蓋是否完整
b) 業務規則覆蓋是否完整
c) 參數驗證是否達到要求（邊界、業務規則）
d) 接口異常場景覆蓋是否完整
e) 接口覆蓋率是否達到要求
f) 代碼覆蓋率是否達到要求
g) 性能指標是否滿足要求
h) 安全指標是否滿足要求
1.7 接口測試流程
一、需求評審，熟悉業務和需求
二、開發提供接口文檔
三、編寫接口測試用例
四、用例評審
五、提測後開始測試
六、提交測試報告
1.8 接口用例模板
接口測試用例模板 （可根據項目實際情況設計增減）
1、項目 測試針對哪個項目
2、模塊 哪個功能模塊
3、用例id
4、接口名稱
5、用例標題 測試用途概括
6、請求方式 GET/POST
7、請求url URL地址
8、請求參數
9、前置條件 執行當前請求依賴的條件，不滿足就不能正確執行
10、結果驗證 預期結果
11、請求報文 可以不寫
12、返回報文 一定要寫，這裏應該是你請求返回的真實結果
13、測試結果 通過/失敗
14、測試人員
2.Http協議簡述
2.1 簡介
HTTP是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫。
HTTP協議是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。
HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。
2.2 請求響應結構圖
2.3 工作流程
一次HTTP操作稱為一個事務，其工作過程可分為四步：
1）首先客戶端與服務器建立連接。
2）建立連接後，客戶端發送一個請求給服務器。
3）服務器接到請求後，給予相應的響應信息。
4）客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然後客戶端與服務器斷開連接。
如果在以上過程中的某一步出現錯誤，那麽產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標點擊，等待信息顯示就可以了。
2.4 主要特點
HTTP協議的主要特點可概括如下：
1.支持客戶/服務器模式。
2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、POST。每種方法規定了客戶與服務器聯系的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4.無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。采用這種方式可以節省傳輸時間。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
HTTP的報文並非是直接交付給用戶去看的，最常見的場合是HTTP協議將超文本交付給瀏覽器或者其他超文本解析的軟件來進行處理，超文本可以使用任意的標簽語言如HTML，XSL，XML，XHTML。
2.5 http狀態碼簡述
每發出一個http請求之後，都會有一個響應，http本身會有一個狀態碼，來標示這個請求是否成功，常見的狀態碼有以下幾種：
1、200 2開頭的都表示這個請求發送成功，最常見的就是200，就代表這個請求是ok的，服務器也返回了。
2、300 3開頭的代表重定向，最常見的是302，把這個請求重定向到別的地方了，302重定向，相當電話呼叫轉移
點擊一個頁面，跳轉到另外一個頁面
3、400 400代表客戶端發送的請求有語法錯誤，401代表訪問的頁面沒有授權，403表示沒有權限訪問這個頁面，404代表沒有這個頁面，404路徑不存在
4、500 5開頭的代表服務器有異常，500代表服務器內部異常，504代表服務器端超時，沒返回結果
2.6 cookie與session的區別：
1）Cookie將狀態保存在客戶端，Session將狀態保存在服務器端；
2）Cookies是服務器在本地機器上存儲的小段文本並隨每一個請求發送至同一個服務器。Cookie最早在RFC2109中實現，後續RFC2965做了增強。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies並將它們保存為一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies。Session並沒有在HTTP的協議中定義；
3）Session是針對每一個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置為由get來返回給服務器；
4）就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在服務器端的SESSION機制更安全些.因為它不會任意讀取客戶存儲的信息。
由以上比較，所以個人建議：
1.將登陸信息等重要信息存放為session
2.其他信息如果需要保留，可以放在cookie中
2.7 GET與POST方法的區別
1.一般來說，get是從服務器上獲取數據，post是向服務器傳送數據。
2. get是把參數數據隊列加到提交表單的ACTION屬性所指的URL中，值和表單內各個字段一一對應，在URL中可以看到。post是通過HTTP post機制，將表單內各個字段與其內容放置在HTML HEADER內一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
3. 對於get方式，服務器端用Request.QueryString獲取變量的值，對於post方式，服務器端用Request.Form獲取提交的數據。
4. get傳送的數據量較小，一般不能大於2KB。post傳送的數據量較大，一般被默認為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。（IIS是一種Web（網頁）服務組件）
5. get安全性非常低，post安全性較高。但是執行效率卻比Post方法好。
由以上比較，提供建議如下：
1、 get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數據提交方式
2、 在做數據查詢時，建議用Get方式；而在做數據添加、修改或刪除時，建議用Post方式；
3. 接口測試工具簡述
3.1 jmeter工具
3.1.1 簡介
Apache JMeter是100%純JAVA桌面應用程序，被設計為用於測試客戶端/服務端結構的軟件(例如web應用程序)；能滿足接口功能自動化、批量數據準備、性能測試等多重需求；當前業界最主流的接口測試工具之一，很多公司的接口自動化平臺和性能測試平臺都是基於其內核擴展的，不僅適合個人學習和使用，更適合規模化和團隊化使用。
3.1.2 jmeter優勢與缺點
優勢:
- 開源，他是一款開源的免費軟件，使用它你不需要支付任何費用
- 小巧，相比LR的龐大（最新LR12將近4GB），它非常小巧，不需要安裝，但需要JDK環境，因為它是使用java開發的工具。
- 支持功能擴展開發。
- 學習成本比較低，容易上手。
- 驗證功能時候，能夠跳過前端頁面數據限制，驗證服務端對數據是否有限制等
缺點：
- 支持想協議沒有loadrunner多，不過目前主流協議基本上都支持
- 壓測的結果分析報表沒有loadrunner詳細豐富，不過一些主要的性能指標都支持生成展示了，比如TPS,QPS,吞吐量等
3.1.3 jmeter簡單使用步驟
前置條件：因為jmeter是純java語言編寫的一款工具，所以運行此工具需要先配置好jdk，具體怎麽配置此處不講解，自己搜索一下配置步驟即可。
1.打開jmeter工具後，右擊Test Plane(測試計劃)，新建一個線程組（Thread Group），如下圖所示（此步驟說明以中文形式界面，需要英文形式的請自行修改語言配置）
2.根據收集到的接口信息（此處以HTTP協議接口為例子講解），右擊線程組，新建個HTTP請求，並填寫請求相關信息：
3.根據實際需要，增加配置文件。
右擊線程組，添加HTTP請求默認值（假如一個線程組中所有接口的協議，ip和端口等數據是一樣的，可以添加這個配置，然後線程組的那些接口請求就可以不用每個單獨去寫協議，ip，端口等數據了，因為它們默認使用了這個HTTP請求默認值配置中的數據）；
還可以增加CSV數據文件設置（給請求中的參數進行參數化的一個配置文件，具體如何配置請自行搜索，很簡單，此處不做講解）
HTTP信息頭管理器（這個配置文件一般都必須添加的，在此配置文件對請求頭信息進行配置）如下圖所示：
4.新增監聽器配置文件
可以右擊線程組或右擊HTTP請求新增查看結果樹（察看結果樹在HTTP請求下面，則只顯示該請求的請求響應情況，在線程組下面，則顯示整個線程組下所有HTTP請求響應結果）
還可以右擊線程組新增聚合報告（用來查看壓測結果的監聽器）
也可以右擊HTTP請求，添加保存響應文件（可以根據實際需要，保存請求失敗的響應結構到指定文件中，壓測完成後便於對失敗請求進行分析查看）
5.添加響應斷言
右擊HTTP請求，添加響應斷言（判斷請求是否成功），便於查看請求是否成功以及統計壓測過後的失敗率。響應斷言僅僅是判斷響應中是否包含某字符串，至於其他斷言可以根據實際需要進行選擇。
6.其他常用插件簡介
邏輯控制器：有時候腳本可能會比較復雜，這時候我們可以利用邏輯控制器，使腳本能夠順利開發出來。
腳本調試請求：
有時候我們開發腳本過程中，存在許多參數，我們要查看參數的取值是否按照我們希望的進行取值，這時候我們可以添加個Debug Sampler:請求，查看每個參數的取值情況。
其他的插件，建議根據實際開發過程中需要用到的時候再去自行查詢用法，反正也是比較簡單的，這裏就不一一說明了。
3.2 badboy錄制工具
有時候我們需要開發大量接口，這時候我們可以先利用badboy工具錄制腳本，然後保存成.jmx文件，再把這個文件導入到jmeter中去，進行一定修改然後即可完成大量腳本的開發工作。
具體使用方法此處就不介紹了，相當簡單，需要用到的時候自行查找教程就好了。
接口測試入門基礎