接口測試入門基礎

1.接口測試概述

1.1 什麼是接口測試

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

 

1.2 爲何要作接口測試

　  a) 現在的系統複雜度不斷上升，傳統的測試方法成本急劇增長且測試效率大幅降低，接口測試能夠提供這種狀況下的解決方案。

　　b)  接口測試相對容易實現自動化持續集成，且相對UI自動化也比較穩定，能夠減小人工迴歸測試人力成本與時間，縮短測試周期，支持後端快速發版需求。接口持續集成是爲何能低成本高收益的根源。

　　c)   如今不少系統先後端架構是分離的，從安全層面來講：

        　一、只依賴前端進行限制已經徹底不能知足系統的安全要求（繞過前面實在太容易）， 須要後端一樣進行控制，在這種狀況下就須要從接口層面進行驗證。

　        二、先後端傳輸、日誌打印等信息是否加密傳輸也是須要驗證的，特別是涉及到用戶的隱私信息，如身份證，銀行卡等。

 

1.3 接口測試分類

接口測試大致分爲兩類：模塊接口測試和web接口測試。

模塊接口測試

模塊接口測試是單元測試的基礎,它主要測試模塊的調用與返回。常常須要編寫一些樁模塊與驅動模塊。
主要測試要點以下：
檢查接口返回的數據是否與預期結果一致。
檢查接口的容錯性，假如傳遞數據的類型錯誤時是否能夠處理。
接口參數的邊界值。例如，傳遞的參數足夠大或爲負數時，接口是否能夠正常處理。
接口的性能，接口處理數據的時間也是測試的一個方法。牽扯到內部就是算法與代碼的優化。
接口的安全性

 

Web接口測試

web接口測試又可分爲兩類：服務器接口測試和外部接口測試。
服務器接口測試：是測試瀏覽器與服務器的接口。用戶輸入的數據是輸入到的前端頁面上，怎樣把這些數據傳遞的後臺的呢？經過http協議的get與post請求來實現先後端的數據傳遞。這也可認爲是接口測試。
外部接口測試：這個很典型的例子就是第三方支付，好比在咱們應用中在充流量時，交話費時，都會調用第三方支付接口。
主要測試要點以下：
請求是否正確，默認請求成功是200，若是請求錯誤也能返回40四、500等。
檢查返回數據的正確性與格式；json是一種很是常見的格式。
接口的安全性，通常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、需求評審，熟悉業務和需求

2、開發提供接口文檔

3、編寫接口測試用例

4、用例評審

5、提測後開始測試

6、提交測試報告

 

1.8 接口用例模板

接口測試用例模板 （可根據項目實際狀況設計增減）

一、項目            測試針對哪一個項目

二、模塊            哪一個功能模塊

三、用例id

四、接口名稱

五、用例標題      測試用途歸納

六、請求方式      GET/POST

七、請求url        URL地址

八、請求參數

九、前置條件       執行當前請求依賴的條件，不知足就不能正確執行

十、結果驗證     預期結果

十一、請求報文     能夠不寫

十二、返回報文 　必定要寫，這裏應該是你請求返回的真實結果

1三、測試結果    經過/失敗

1四、測試人員   

 

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自己會有一個狀態碼，來標示這個請求是否成功，常見的狀態碼有如下幾種：

一、200 2開頭的都表示這個請求發送成功，最多見的就是200，就表明這個請求是ok的，服務器也返回了。

二、300 3開頭的表明重定向，最多見的是302，把這個請求重定向到別的地方了，302重定向，至關電話呼叫轉移

點擊一個頁面，跳轉到另一個頁面

三、400 400表明客戶端發送的請求有語法錯誤，401表明訪問的頁面沒有受權，403表示沒有權限訪問這個頁面，404表明沒有這個頁面，404路徑不存在

四、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方法好。

 

由以上比較，提供建議以下：

一、      get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數據提交方式

二、      在作數據查詢時，建議用Get方式；而在作數據添加、修改或刪除時，建議用Post方式；

 

 

3. 接口測試工具簡述

3.1 jmeter工具

3.1.1 簡介

Apache JMeter是100%純JAVA桌面應用程序，被設計爲用於測試客戶端/服務端結構的軟件(例如web應用程序)；能知足接口功能自動化、批量數據準備、性能測試等多重需求；當前業界最主流的接口測試工具之一，不少公司的接口自動化平臺和性能測試平臺都是基於其內核擴展的，不只適合我的學習和使用，更適合規模化和團隊化使用。

 

3.1.2 jmeter優點與缺點

  優點:

1. 開源，他是一款開源的免費軟件，使用它你不須要支付任何費用
2. 小巧，相比LR的龐大（最新LR12將近4GB），它很是小巧，不須要安裝，但須要JDK環境，由於它是使用java開發的工具。
3. 支持功能擴展開發。
4. 學習成本比較低，容易上手。
5. 驗證功能時候，可以跳過前端頁面數據限制，驗證服務端對數據是否有限制等

缺點：

1. 支持想協議沒有loadrunner多，不過目前主流協議基本上都支持
2. 壓測的結果分析報表沒有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中去，進行必定修改而後便可完成大量腳本的開發工做。

具體使用方法此處就不介紹了，至關簡單，須要用到的時候自行查找教程就行了。