接口測試-(概念理論)

 

第一節 概述

接口的概念從IT的角度出發，主要是子模塊或者子系統間交互並相互作用的部分。從形式上來看各種應用程序的API（最著名的Windows 系統的API），硬件的驅動程序,數據庫系統的訪問接口，再到后來的Webservice接口，http rest接口。雖然接口的形式各有不同，但是從測試角度來說，需要測試的內容大致是相同的，功能，性能，安全。經歷有限，本篇文章主要介紹http REST接口從功能角度出發，怎么做測試。

 

第二節 為什么做接口測試

我們為什么要做接口測試呢？。

我們現在處於移動互聯網時代，接觸過移動客戶端測試的人都知道，我們的移動端的功能是需要大量的后台服務來支撐。 這里說的移動端包括IOS,Android,WP 原生應用以及混合應用。為什么移動端的應用需要大量的后端服務來支撐呢，最主要是兩個原因，我們的手機計算能力有限，另外移動應用必須省電，因此大量的計算，數據存儲，業務處理等活動需要放到服務端由大型服務器來完成。在服務器端完成計算后，通過REST接口來獲取到想要的計算接口，然后展示。所以說服務端的接口的測試就尤其重要，隨時移動互聯網的普及，接口測試會越來越重要。

另外一個需要做接口測試的原因是在互聯網時代，軟件系統的開發不在遵循傳統軟件的開發模式，我們需要的是快速上線，快速發布。由於測試在整個軟件開發流程的最后階段，能不能快速上線，快速發布，測試能不能在保證一定質量的前提下快速完成就成為了很重要的一環。測試的工作量是固定的，要想保證一定的質量，測試的過程大幅縮短的可能是並不高。但是我們知道在移動端產品中，大部分的業務計算是放在服務端的來做的。因此，我們想到了提前測試，也就是不等到客戶端開發完成，提前測試服務端接口，也就是我們說的測試前置。測試前置除了能夠節省測試時間之外，還能夠節省測試成本，由於接口測試階段更接近底層，發現底層的問題的直接性更高，難度相對UI測試要低很多。所以節省測試成本，減少測試時間，也是我們做接口測試的一個重要原因。

可能看到這里會有疑問，為什么接口可以被提前測試呢。這是由接口的開發過程，以及接口的使用方式所決定的。先說接口的開發過程，開發人員在開發接口的過程中基本是按照一個依賴樹的結構來進行的。接口在使用的過程中其實是有依賴的，接口A可能要依賴接口B的輸出參數作為輸入參數。那么開發在開發過程中，要想能夠調試接口A，那就有可能需要先把B接口開發完。以此類推，開發最先開發出來的接口肯定是最基礎，最底層，最沒有依賴的接口。再來說使用方式，我們使用接口都是每次調用一個接口，復雜些的情況無非就是輸入參數是其他接口的輸出參數而已。所以當開發人員開發完成一個接口后，你就可以立即開始測試，而不用等到所有接口都完成才開始測試。基於上述原因，我們基本可以做到完成接口開發的同時，完成接口的測試工作。

 

第三節 http接口

我們為什么只介紹REST接口測試呢?首先來認識一下什么是REST 接口。REST Web 服務（也稱為 RESTful Web API）是一個使用HTTP並遵循REST原則的Web服務。它從以下三個方面資源進行定義：URI，比如：http://example.com/resources/。Web服務接受與返回的互聯網媒體類型，比如：JSON，XML ，YAML 等。Web服務在該資源上所支持的一系列請求方法（比如：POST，GET，PUT或DELETE）。通過上面的定義我們就能准確的知道REST接口其實就是一個Web請求，和你訪問一個Web頁面請求是沒有任何區別的。所以大家在認識接口的時候完全可以把REST接口當做是一個Web頁面請求。因為REST類型的接口已經越來越成為互聯網行業通用的接口表現形式，它在使用過程中不受調用客戶端語言的限制，在網絡傳輸過程中不需要傳遞強類型的對象，僅僅通過網絡傳遞字符串。基於上述特點，REST協議的接口成為了互聯網中接口協議最為常用的接口方式。所以我們在這里主要介紹REST協議的接口測試。在此小結中我們已經知道了REST接口的調用本質是一次http請求。所以在我們的測試過程中，還會碰到其他一些基於MVC模式開發的web接口，這些接口可能不太符合REST要求，但是他們的本質是一致的就是http請求，在測試時候我們可以完全忽略這些表面上的東西。

 

第四節 接口測試的方式

我們怎么測試接口？從測試策略上來說我們測試接口是基於業務來測試，和從UI端做功能測試是一樣的，都是測試功能業務，只不過我們更進一步使用接口來測試。前面小結也已經提到，接口是對業務處理結果的一種展現。測試實現上來說，REST接口是一個Http請求，所以對接口的測試主要是通過發送http請求，通過對比返回值來測試返回的結果是不是和我們期望的一致。不同的語言用來發送http請求的工具，類庫都不太一樣。我們這里以java語言為例，可以用來發送http請求的第三方包有httpclient,httpunit等，大家可以自由的選擇使用。

 

第五節 測什么

我們要測試什么呢？從第四小節，我們已經知道了接口測試的基本方式。其實在我們的具體測試過程中又可以將接口的測試分為兩種。單一接口的測試；多接口組合測試。

單一接口功能的測試主要測試返回的數據結構是否和接口文檔給出的一致，接口的正常功能是否完成，接口的參數檢查測試，接口的異常測試。

多接口組合測試，實際上是在測試一個業務流程。在測試過程中依次調用多個接口，這些接口相互依賴。這種依賴表現為接口A的輸出是接口B的輸入或者接口B需要接口A來修改某個狀態。總之這樣一個業務流程是不可能由單獨的接口來完成。像這種多接口組合類的測試，我們說我們的這個測試場景ok，並不是說這個過程中的所有接口都ok就可以的。這個場景的驗證點我們還是需要根據業務場景來確定。

對於中間接口的正確性卻並不需要驗證，因為在做多接口組合的測試之前，我們應該先保證單一接口的功能是ok的。

在測試接口的時候還是要考慮接口的業務特性，比如接口的某個參數可能有多個類型的值，每個值根據業務含義不同可能接口的返回值也是不一樣的，遇到這種情況一定要根據業務設計測試點。

另外我們在對比返回值的時候一定要注意，不能只是簡單的對比一下返回值了事。現實過程中有些接口的返回可能會簡單到只返回一個code，但是這個接口的功能是不是正確卻不一定有保證。所以我們一定要知道我們是在做測試，而不是在對比返回值。這就是接口最基本的測試方式，下面的小節我會寫下一個相對完整的測試過程，供大家參考。

 

第六節 接口測試前准備

從項目角度來說，接口測試的第一步是要了解清楚和項目相關的信息。這里所說的項目信息包括以下幾個方面：

l  接口開發人員是誰

l  接口開始開發時間

l  接口結束開發時間

l  測試環境信息

l  數據庫相關信息

l  需求文檔，接口API文檔

除了要獲取信息外，還需要和開發人員，產品達成一些共識。這些共識包括：

l  第一次提測接口的時間

l  可測接口的提交頻率

l  Bug解決方式等

我們來說說這些信息，對我們來說有什么用處。開發人員，項目開始結束時間這些信息從項目角度來說，是必須的。你需要知道在測試過程中和誰交互溝通，你需要根據項目開始結束時間來安排資源。測試環境，數據庫信息這些是我們接口測試的基礎。需求文檔，API文檔這是我們接口測試的依據。第一次提測時間，是我們開始投入資源測試的時間，接口提交頻率決定了我們能否在開發完成的同時完成測試。（這里說的同時是指開發在提交最后一批接口時完成了前面所有接口的測試）。開發提交可測接口的頻率過低，會導致測試介入過晚。從而不能完成測試。提測頻率過高，有可能會影響開發的效率.

 

第七節 用例設計方法

我們再從測試的角度來說說在測試開始前應該做哪些事情。我們從文章開始就一直說的是接口測試，而且也說明白了接口測試其實是在做業務的測試。所以接口測試要想做好，有一項工作是基礎。我們必須設計測試用例。設計測試用例的依據對於接口測試來說，主要是根據需求文檔和接口API文檔。前面第5小節已經說了，我們在測試接口的主旨，其實還是在測試業務。所以我們需要根據需求文檔，API接口文檔設計多接口組合的場景用例，單接口功能用例，接口結構檢查用例。

設計好了用例，那么我們就可以開始用代碼實現用例了。具體怎么實現，本文不會涉及。在這主要說說怎么來檢查結果。我們的接口返回值也會有兩種。一種是返回值是個常量或者叫固定值。對於這種類型的接口，我們可以采用直接對比字符串的方式來完成結果校驗。另外一種接口也是最常見的接口，接口的返回值是根據數據庫中的數據來返回，是不固定的。這種接口在測試時，接口的期望值也就不再是固定的而是要根據數據庫的數據來動態生成。因此我們在測試過程中就必須要寫代碼來測試接口。

 

第八節 總結

本篇文章到此結束，到這基本上說了接口測試怎么做。可能很多人關心的是，接口的自動化測試。自動化說簡單點其實就是已經做過的事不需要重復做，接口測試想要自動化那就需要我們保存好我們的接口測試用例，並保證能在任何情況下重復使用。這是自動化的基礎，后續的文章我會來闡述接口自動化應該注意些什么。