接口測試--轉自測試百曉生微信公衆號

區分概念

測試：我想了解下接口，你能給我講講這個系統中的幾個重要接口嗎？

JAVA開發：這裏面有幾百個接口，都很重要的，你想看哪個？

測試工程師：~這~~~

 

很明顯，這兩個初級工程師對接口的理解，顯然出現了誤差，JAVA工程師理解的接口是指JAVA中的interface,而測試工程師所理解的接口，是指多系統間進行數據交互、通訊的接口。爲了讓你們不出現理解誤差，咱們今天來統一口徑，瞭解一下什麼是測試行業通用的接口測試。

 

我眼中的接口測試

某百科：

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

 

通俗的講，接口是指系統模塊與模塊或系統與系統間進行交互。以下圖所示：

 

 

再舉個實際的栗子：

 

 

有一個新聞客戶端：

在手機上打開新聞客戶端按住屏幕往下拉時，頁面會刷新，會有新的新聞展現出來，這就是一個請求獲取數據的接口。服務端返回：

 

 

客戶端根據返回值，進行渲染，而後展現給用戶。

因此對於新手而言，接口測試就是要作到以下兩個基本點：

一、保證服務端有響應，有返回值

二、保證返回值的正確性，若是newsId與title匹配不上，則表示接口返回錯誤

 

 

接口的類型

 

因爲通訊協議太多，之後咱們把最經常使用http協議的接口做爲主要例子。

 

目前咱們所說的接口中，用的最多的是RPC，webservice，restful的接口。但如今流行的是基於HTTP協議的rest風格的接口，爲何只強調rest風格的接口呢？在這裏介紹一下rest 接口，rest接口在使用過程當中不受調用客戶端語言的限制，在網絡傳輸過程當中不須要傳遞強類型的對象，僅僅經過網絡傳遞字符串，也就是說rest是一組約束條件和原則，你們都遵照這些條件與原則，因而乎，交互的數據就具備通用可解析的特色了。更通俗點說，rest風格的接口就是指返回值是json串的接口。如今restful風格類型的接口已經愈來愈成爲互聯網行業通用的接口表現形式。

 

到底什麼是接口測試

 

經過上面的概念的理解，咱們大體能夠知道了，接口測試通常就是指基於HTTP協議的返回值是JSON串的測試(也有多是一個字符串\XML)，那其本質就是客戶端發送一個request給服務端，服務端響應後返回一個response，而後咱們分析response是否是符合預期，這便是接口測試。你們先這麼理解吧。

 

接口測試的前景

 

 

因爲接口傳輸的主要是數據，數據的準確性、安全性應該是被首先保障的。因此，通常的接口測試比UI功能測試 優先級要高一些。

 

因爲接口只是單純的數據交互，無界面，與傳統的UI測試相比，更接近底層一些，更容易發現底層的問題，且難度相對UI測試要低不少，因此接口測試號稱測試界的「短平快」，更加符合如今敏捷開發，快速迭代的開發模式。

 

同時在自動化方面接口自動化測試也是最容易看到成效的，更容易得到你老大的支持喲。

 

 

 

接口的生命週期

 

 

 

其中測試人員一直貫穿到整個生命週期，具體是這樣的：

 

 

 

測試人員都是全能的，職責幾乎貫穿了整個接口生命週期。那到底從哪裏開始測試呢？可能100我的有100個本身的理解。

 

天然是越早開始越好，如今測試人員的價值早不是之前找多少個BUG。在「專一、極致、口碑、快」的今天，能幫開發越快迭代的測試才越值錢。

 

 

該怎麼辦呢？

 

 

當接口定義完之後，就進入了開發設計階段，這時候，後臺接口開發人員須要設計數據庫表等方面的工做，提供出這個接口最快得兩三天左右，但終端可能馬上就須要這個接口的數據從而進行下面的功能的開發，前端開發人員不可能等着。OK，機會來了，測試人員就能夠介入了，說的沒錯，就是測試人員提供mock，使接口可以正確的返回，從而使前端開發可以接着往下進行。

 

測試界的軍規，缺陷發現越晚，代價就越高。

 

 

就讓我們開始吧

 

咱們先分析一下接口請求的過程：

 

 

 

接口開發語言不少，好比php/python/java，甭管 PHP是否是世界上最好的語言，它們的接口請求的過程都是如上圖所示，因此，既然咱們要mock，只能是在」執行方法/函數並將數據返回終端」這一環節來操做了，咱們能夠提供一個方法，將終端所須要的數據寫死在方法體中，並返回給終端，這樣，終端就可以拿到的數據並進行下面的開發。

 

好比這樣一個接口定義：

 

路徑：/api/v1/getUserInfo

請求方式：GET

請求參數：userid=1

返回正確值：

{    "redCode": 200,

    "redMsg": "success",

    "data": {

        "id": 1,

        "name": "zhangsan",

        "age": 18}}

返回異常值：

{

    "redCode": 201,

    "redMsg": "data null",

    "data": {}

}

 

 

能夠設計兩組請求參數userid=1和userid=2提供給終端，在mock的方法體中這樣寫：

 

 

當接口開發完畢後，撤下咱們的MOCK類，依據MOCK類，完善自動化測試腳本，並對已開發完的接口進行自動化測試。

 

 

優勢

承上啓下，承接終端，啓發服務端，使之平滑過渡。

 

 測試數據已體如今MOCK類中

 

 最重要的一點：更接近底層，利於咱們更好的去了解接口

 

缺點

須要編碼能力教強

從流程上你們還不是足夠的熟悉系統容易漏測

 

接口到底在測什麼

 

在寫接口測試腳本時，對於接口返回值的斷言，有的同窗偏向於鏈接數據庫，取值並將數據進行加工後與接口返回值進行比較，以達到運態指望值的目的，我的認爲這是一種不正確的方式，理由以下：

 

1

 數據加工的過程，就是接口業務邏輯實現的過程，就算測試經過了，你也沒法保證你的代碼沒有BUG。若是提早寫好指望，能夠最大限度的避免這個問題。

 

2

一個穩定的接口，其輸入與輸出都是穩定的，根本不須要所謂的動態指望值，咱們只須要給出參數，將返回值咱們事先設定好的寫死的數據進行斷言便可。

 

3

 若是你真想把控開發業務邏輯的過程，到不如去作白盒測試與單元測試，這樣的收益更大。

 

 

接口測試在每一個人眼中的不一樣

百曉生的接口測試系列也到了尾聲了，陸續收到一些反饋，你們都認爲接口測試是一種相對比較簡單且回報率要相對高些的一種測試手段，特別是在互聯網+的浪潮之下。你們蜂擁而至後，發現接口測試其實並不簡單，也會有心力憔悴的感受，彷佛又回到了UI自動化的怪圈。針對這種狀況，百曉生也是急你們之所急，跟不少測試界大牛交流了這些問題，通過整理，但願能對你們有些幫助。

 

A君：

 

Q：你所理解的接口測試？

A：接口測試自己不難，難的是監控。

 

Q：監控是指監控哪方面？

A：主要2個方面，性能和功能。性能主要是看接口的響應時間，指定告警閥值，告警策略。例如，10分鐘內，平均響應時間超過某個值。這裏的性能是劈開併發。功能主要看接口在灌入正確參數，異常參數的一些返回值，也就是業務邏輯的檢查。

 

Q：那這個監控是指接口測試腳本的執行了？

A：是的，接口測試腳本調試完成後，就能夠丟到執行中心去執行了，也就是監控。

 

Q：驗證是如何作的？也就是指望值是如何產生的？

A：你測試一個接口，連指望值都不知道，怎麼測？因此，指望值你是知道的。

 

Q：指望值，有的人是從數據庫取值，而後與返回值進行比對，有的是直接寫死，而後與返回值比對，大家採用的是哪一種方式？

A：咱們不是寫死的，測試接口的數據大多數是動態生成，也就是說經過調用其餘接口來準備你待測接口的數據， 在接口自動化的過程當中，不操做數據庫。

 

Q：經過調用其餘接口來準備你待測接口的數據，舉個例子說明一下？

A：有些場景，譬如接口B依賴接口A的返回，你在測試接口B的時候，就應該先調用接口A，拿到返回做爲接口B的測試輸入， 而不是直接從數據庫拿一個A數據，或者寫死一個數據。

 

Q：若是這個接口不依賴任何，其指望值是否是寫死就好一些？

A：有些返回裏面永恆不變的，寫死沒問題，有些東西要變的，寫死就不行了，變的狀況通常使用通配來檢查。也就是說，返回值裏，可能分兩部分：變化的，與不變的。那咱們也能夠分兩部分來檢查，變化的，通配檢查，不變的，能夠寫死的進行檢查。

 

Q：執行中心統必定時多長時間運行一次？

A：這個看你的用例規模，執行引擎的數量，若是你的資源不夠，非要1分鐘執行一次，那確定跪。

 

Q：接口平臺會起到什麼做用？

A：平臺只是提供一些用例編寫，維護的便利，執行策略等常規配置，至於沒有平臺，你照樣能夠完成這些事情。

 

 

B君：

 

Q：大家如何作的接口測試？

A：很簡單，用EXCEL來維護用例與數據，寫個執行引摯就能夠了。

 

Q：驗證時，有去查數據庫嗎？

A：分狀況而言，通常不去驗證數據庫。

 

Q：腳本寫完後，如何實施？好比是丟在線上進行不間斷的跑？

A：構建的時候觸發，構建完成->觸發任務->經過。天天也會有BVT測試。

。。。。。。

 

 

 

交流至此，不知道對你們有沒有啓發，也但願你們從迷惑中走出來，真正讓自動化給咱們帶來生產上的效益，而不是成爲咱們去面試 談薪水時的噱頭而已。