扔掉 Postman，一個(gè)工具全部搞定，真香！

Postman介紹

Postman是google開發(fā)的一款功能強(qiáng)大的網(wǎng)頁調(diào)試與發(fā)送網(wǎng)頁HTTP請求，并能運(yùn)行測試用例的的Chrome插件。其主要功能包括：

模擬各種HTTP requests

從常用的 GET、POST 到 RESTful 的 PUT 、 DELETE …等等。甚至還可以發(fā)送文件、送出額外的 header。

Collection 功能（測試集合）

Collection 是 requests的集合，在做完一個(gè)測試的時(shí)候， 你可以把這次的 request 存到特定的 Collection 里面，如此一來，下次要做同樣的測試時(shí)，就不需要重新輸入。而且一個(gè)collection可以包含多條request，如果我們把一個(gè)request當(dāng)成一個(gè)test case，那collection就可以看成是一個(gè)test suite。通過collection的歸類，我們可以良好的分類測試軟件所提供的API.而且 Collection 還可以 Import 或是 Share 出來，讓團(tuán)隊(duì)里面的所有人共享你建立起來的 Collection。

人性化的Response整理

一般在用其他工具來測試的時(shí)候，response的內(nèi)容通常都是純文字的 raw， 但如果是 JSON ，就是塞成一整行的 JSON。這會造成閱讀的障礙 ，而 Postman 可以針對response內(nèi)容的格式自動(dòng)美化。JSON、 XML 或是 HTML 都會整理成我們可以閱讀的格式

內(nèi)置測試腳本語言

Postman支持編寫測試腳本，可以快速的檢查request的結(jié)果，并返回測試結(jié)果

設(shè)定變量與環(huán)境

Postman 可以自由 設(shè)定變量與Environment，一般我們在編輯request，校驗(yàn)response的時(shí)候，總會需要重復(fù)輸入某些字符，比如url，postman允許我們設(shè)定變量來保存這些值。并且把變量保存在不同的環(huán)境中。比如，我們可能會有多種環(huán)境， development 、 staging 或 local， 而這幾種環(huán)境中的 request URL 也各不相同，但我們可以在不同的環(huán)境中設(shè)定同樣的變量，只是變量的值不一樣，這樣我們就不用修改我們的測試腳本，而測試不同的環(huán)境。

安裝Postman

Postman作為一個(gè)chrome的插件，你可以打開chrome，在chrome webstore里面找到。當(dāng)然，如果是在國內(nèi)，你需要翻墻，否則的話，你只能百度一下，搜索postman的安裝包自己安裝到chrome上（這里就不贅述了，有很多類似的文章）。這里需要提一下的是，你可以不用打開chrome而直接使用Postman，具體的方法是：

選項(xiàng)->更多工具->擴(kuò)展程序

詳細(xì)信息->創(chuàng)建快捷方式->‘全部勾上’

這樣你就可以在任何地方啟動(dòng)你的Postman了

Postman sending requests

安裝好之后，我們先打開Postman，可以看到界面分成左右兩個(gè)部分，右邊是我們后頭要講的collection，左邊是現(xiàn)在要講的request builder。在request builder中，我們可以通過Postman快速的隨意組裝出我們希望的request。一般來說，所有的HTTP Request都分成4個(gè)部分，URL, method, headers和body。而Postman針對這幾部分都有針對性的工具。

URL

要組裝一條Request, URL永遠(yuǎn)是你首先要填的內(nèi)容，在Postman里面你曾輸入過的URL是可以通過下拉自動(dòng)補(bǔ)全的哦。如果你點(diǎn)擊Params按鈕，Postman會彈出一個(gè)鍵值編輯器，你可以在哪里輸入U(xiǎn)RL的Parameter，Postman會幫你自動(dòng)加入到URL當(dāng)中，反之，如果你的URL當(dāng)中已經(jīng)有了參數(shù)，那Postman會在你打開鍵值編輯器的時(shí)候把參數(shù)自動(dòng)載入

Headers

點(diǎn)擊’Headers’按鈕，Postman同樣會彈出一個(gè)鍵值編輯器。在這里，你可以隨意添加你想要的Header attribute，同樣Postman為我們通過了很貼心的auto-complete功能，敲入一個(gè)字母，你可以從下拉菜單里選擇你想要的標(biāo)準(zhǔn)atrribute

Method

要選擇Request的Method是很簡單的，Postman支持所有的Method，而一旦你選擇了Method，Postman的request body編輯器會根據(jù)的你選擇，自動(dòng)的發(fā)生改變

Request Body

如果我們要?jiǎng)?chuàng)建的request是類似于POST，那我們就需要編輯Request Body，Postman根據(jù)body type的不同，提供了4中編輯方式：

form-data

x-www-form-urlencoded

raw

binary

（我們這里是可以傳文件的哦）

演示

我這里創(chuàng)建一條發(fā)送給google geocode的request，看看是啥結(jié)果：

注意，在URL里面我使用了變量googleMaps，并用{{}}調(diào)用它，這里是類似于AngulaJs的語法（果然是同一家人），其返回值是：http://maps.googleapis.com/maps/api/geocode/json。而這個(gè)變量我是定義在我的環(huán)境GoogleApiTest里面的。這部分的內(nèi)容會在接下來的文章里面講到。

點(diǎn)擊了Send之后，可以在Postman上直接看到response的內(nèi)容，內(nèi)容很漂亮，Postman根據(jù)內(nèi)容檢索自動(dòng)按JSON的格式顯示出來，同時(shí)我們可以清楚的看到status code和花費(fèi)的時(shí)間。

寫到這，我想大家已經(jīng)能夠了解如何用Postman組裝Request并且查看Response的內(nèi)容了，那我們怎么用Postman去做測試呢，且聽下回分解

發(fā)現(xiàn)了痛點(diǎn)就要去找解決方案。解決方案用的人多了，就成了標(biāo)準(zhǔn)的規(guī)范，這就是Swagger的由來。通過這套規(guī)范，你只需要按照它的規(guī)范去定義接口及接口相關(guān)的信息。再通過Swagger衍生出來的一系列項(xiàng)目和工具，就可以做到生成各種格式的接口文檔，生成多種語言的客戶端和服務(wù)端的代碼，以及在線接口調(diào)試頁面等等。這樣，如果按照新的開發(fā)模式，在開發(fā)新版本或者迭代版本的時(shí)候，只需要更新Swagger描述文件，就可以自動(dòng)生成接口文檔和客戶端服務(wù)端代碼，做到調(diào)用端代碼、服務(wù)端代碼以及接口文檔的一致性。

但即便如此，對于許多開發(fā)來說，編寫這個(gè)yml或json格式的描述文件，本身也是有一定負(fù)擔(dān)的工作，特別是在后面持續(xù)迭代開發(fā)的時(shí)候，往往會忽略更新這個(gè)描述文件，直接更改代碼。久而久之，這個(gè)描述文件也和實(shí)際項(xiàng)目漸行漸遠(yuǎn)，基于該描述文件生成的接口文檔也失去了參考意義。所以作為Java屆服務(wù)端的大一統(tǒng)框架Spring，迅速將Swagger規(guī)范納入自身的標(biāo)準(zhǔn)，建立了Spring-swagger項(xiàng)目，后面改成了現(xiàn)在的Springfox。通過在項(xiàng)目中引入Springfox，可以掃描相關(guān)的代碼，生成該描述文件，進(jìn)而生成與代碼一致的接口文檔和客戶端代碼。這種通過代碼生成接口文檔的形式，在后面需求持續(xù)迭代的項(xiàng)目中，顯得尤為重要和高效。

框架說明及使用

1.說明

現(xiàn)在SWAGGER官網(wǎng)主要提供了幾種開源工具，提供相應(yīng)的功能。可以通過配置甚至是修改源碼以達(dá)到你想要的效果。

image.png

Swagger Codegen: 通過Codegen 可以將描述文件生成html格式和cwiki形式的接口文檔，同時(shí)也能生成多鐘語言的服務(wù)端和客戶端的代碼。支持通過jar包，docker，node等方式在本地化執(zhí)行生成。也可以在后面的Swagger Editor中在線生成。

Swagger UI:提供了一個(gè)可視化的UI頁面展示描述文件。接口的調(diào)用方、測試、項(xiàng)目經(jīng)理等都可以在該頁面中對相關(guān)接口進(jìn)行查閱和做一些簡單的接口請求。該項(xiàng)目支持在線導(dǎo)入描述文件和本地部署UI項(xiàng)目。

Swagger Editor: 類似于markendown編輯器的編輯Swagger描述文件的編輯器，該編輯支持實(shí)時(shí)預(yù)覽描述文件的更新效果。也提供了在線編輯器和本地部署編輯器兩種方式。

Swagger Inspector: 感覺和postman差不多，是一個(gè)可以對接口進(jìn)行測試的在線版的postman。比在Swagger UI里面做接口請求，會返回更多的信息，也會保存你請求的實(shí)際請求參數(shù)等數(shù)據(jù)。

Swagger Hub：集成了上面所有項(xiàng)目的各個(gè)功能，你可以以項(xiàng)目和版本為單位，將你的描述文件上傳到Swagger Hub中。在Swagger Hub中可以完成上面項(xiàng)目的所有工作，需要注冊賬號，分免費(fèi)版和收費(fèi)版。

PS：

Springfox Swagger: Spring 基于swagger規(guī)范，可以將基于SpringMVC和Spring Boot項(xiàng)目的項(xiàng)目代碼，自動(dòng)生成JSON格式的描述文件。本身不是屬于Swagger官網(wǎng)提供的，在這里列出來做個(gè)說明，方便后面作一個(gè)使用的展開。

2.基于Spring框架的Swagger流程應(yīng)用

這里不會介紹Swagger的工具具體如何使用，不會講yml或者json格式描述文件的語法規(guī)范，也不會講如何在SpringMVC或者Spring Boot中配置Springfox－swagger。這些都能從網(wǎng)上找到，而且配置起來都非常的簡單。

這里想講的是如何結(jié)合現(xiàn)有的工具和功能，設(shè)計(jì)一個(gè)流程，去保證一個(gè)項(xiàng)目從開始開發(fā)到后面持續(xù)迭代的時(shí)候，以最小代價(jià)去維護(hù)代碼、接口文檔以及Swagger描述文件。

2.1 項(xiàng)目開始階段

一般來說，接口文檔都是由服務(wù)端來編寫的。在項(xiàng)目開發(fā)階段的時(shí)候，服務(wù)端開發(fā)可以視情況來決定是直接編寫服務(wù)端調(diào)用層代碼，還是寫Swagger描述文件。建議是如果項(xiàng)目啟動(dòng)階段，就已經(jīng)搭好了后臺框架，那可以直接編寫服務(wù)端被調(diào)用層的代碼（即controller及其入?yún)⒊鰠ο螅?，然后通過Springfox－swagger 生成swagger json描述文件。如果項(xiàng)目啟動(dòng)階段并沒有相關(guān)后臺框架，而前端對接口文檔追得緊，那就建議先編寫swagger描述文件，通過該描述文件生成接口文檔。后續(xù)后臺框架搭好了，也可以生成相關(guān)的服務(wù)端代碼。

2.1 項(xiàng)目迭代階段

到這個(gè)階段，事情就簡單很多了。后續(xù)后臺人員，無需關(guān)注Swagger描述文件和接口文檔，有需求變更導(dǎo)致接口變化，直接寫代碼就好了。把調(diào)用層的代碼做個(gè)修改，然后生成新的描述文件和接口文檔后，給到前端即可。真正做到了一勞永逸。

2.3流程

總結(jié)一下就是通過下面這兩種流程中的一種，可以做到代碼和接口文檔的一致性，服務(wù)端開發(fā)再也不用花費(fèi)精力去維護(hù)接口文檔。

流程一

image.png

流程二

image.png

給Mock系統(tǒng)的正常請求及響應(yīng)全流程數(shù)據(jù)

很多時(shí)候，如果你能在提供接口文檔的同時(shí)，把所有接口的模擬請求響應(yīng)數(shù)據(jù)也提供給前端。或者有Mock系統(tǒng)，直接將這些模擬數(shù)據(jù)錄入到Mock系統(tǒng)中，那將會提高前端的開發(fā)效率，減少許多發(fā)生在聯(lián)調(diào)時(shí)候才會發(fā)生的問題。

通過適當(dāng)?shù)卦诖a中加入swagger的注解，可以讓你的接口文檔描述信息更加詳細(xì)，如果你把每個(gè)出入?yún)?shù)的示例值都配上，那前端就可以直接在接口文檔中拿到模擬數(shù)據(jù)。相關(guān)的注解類及參數(shù)配置可以參考文末他人寫的技術(shù)文章，這里也不作展開了。