接口在聯調階段須要一些方便快捷的工具來檢驗咱們的接口開發效果,目前接口請求工具也是五花八門,有瀏覽器插件型的,如firefox上的poster插件,chrome上的postman插件,有工具界面型的,如jmeter等等。如何選擇一款接口請求工具?其實選擇工具就若是咱們出去吃飯同樣,哪家人多去哪家,準差不離,因而postman就成爲了擺在咱們面前的那道菜,我將爲你們介紹如何去品嚐這道菜。
從流程圖中咱們能夠看出,一個接口請求須要設置:請求URL,請求方法,請求頭,請求參數。一樣的,在postman中,咱們也只須要設置這四項便可完成一次請求。
說明:GET請求的參數在URL連接上,因此,GET請求的請求頭與請求參數如在接口文檔中無特別聲明時,能夠不填。
說明:特別標註出了響應HTTP狀態碼與響應正文,還有請求的耗時。需特別注意的是注意區別HTTP狀態碼與響應正文中的狀態碼,只有HTTP狀態碼是200時,才表明這個接口請求是正確的,這個是HTTP協議定義的,而響應正文的狀態碼,是程序員自已定義的,能夠是200,也能夠定義爲其它值,是爲了讓接口使用者去區分正常數據與異常數據,好比:
上圖示例中設置了請求方法,請求URL,請求參數,但沒有設置請求頭。有一個要明確的點是,請求頭中的Content-Type與請求參數的格式之間是有關聯關係的:
當選擇x-www-form-urlencoded的參數方式後,postman自動的幫咱們設置了Content-Type,因此不須要咱們人工干預,這就是使用一款流行工具的好處,把一些基礎點都幫咱們處理了。
上圖中,當咱們選擇了JSON(application/json)時,postman一樣幫咱們自動設置了Content-Type,能夠自行的去查看一個Headers.
HTTP的POST請求的參數,都是放在請求正文中的,只是根據Content-Type來判斷請求正文的格式,那麼咱們一樣能夠在表單提交時,選擇raw,而後自行設置Content-Type爲application/x-www-form-urlencoded。
一個完整的接口測試,包括:請求->獲取響應正文->斷言,咱們已經知道了請求與獲取響應正文,接下來將會告訴你們如何用postman進行斷言。
這個」Tests」就是咱們須要處理斷言的地方,postman很人性化的幫咱們把斷言所用的函數全給準備好了:
雖然都是英文,但看懂應該並不懂。OK,英文看着煩,不想看,是吧,那好,咱們來設置一個斷言場景,根據這個斷言場景,來教你們如何來用postman的斷言,場景以下:
1. 判斷HTTP返回狀態碼爲200
2. 判斷響應正文中是否包含:"statusCode":200
3. 解析響應正文,並判斷statusCode的值是200,message的值是」Success.」
在SNIPPETS中,往下拉,有一項」Status code:Code is 200」,這個就是爲場景中的第一條準備的,就是判斷HTTP返回狀態碼是否爲200。點擊這一項,能夠看到在其左邊出現了:
解釋一下這句代碼的意思:
tests["Status code is 200"]中的tests是一個內置對象,tests["Status code is 200"]是指爲這個斷言起個名稱叫」Status code is 200」,這個名稱能夠自行修改。
responseCode.code === 200 中的responseCode是內置對象,responseCode對象中有個屬性是code,是指HTTP狀態碼的code,判斷code是否爲200.
綜合起來,這句代碼的意思是:名稱爲」Status code is 200」的斷言中,判斷responseCode對象的code屬性值是否爲200。
一樣在SNIPPETS中,找到一項」Response body:Contains string」,顧名思義,這條就是爲場景中的第二條準備的,點擊後,在其左邊出現了:
場景中的第三條,很顯然,咱們須要解析JSON串了,因此,在SNIPPETS中找到」Response body:JSON value check」並點擊,在其左邊出現了:
咱們能夠看出,這裏面實際上是JS代碼,jsonData變量實際上是解析完JSON後的對象,在JS中,一個JSON對象獲取其屬性的值,直接是用jsonData.value,因而,咱們把代碼給修改一下:
這樣一來,咱們能夠看到一共有tests的斷言4個,點擊Send,發送請求,在響應區內能夠看到以下圖:
SNIPPETS中還有不少的函數提供給咱們了,你們能夠自行去體驗一番。師父領進門,修行靠我的!努力吧,測試君!
postman的基本使用,已經跟你們講了,並收到了一些反饋,但願能講講postman如何一次運行多個接口請求。歪果仁的技術思想不得不佩服,想用者之所想,把管理用例與運行用例集成在了一塊兒。讓咱們一塊兒去歪果仁的技術思想中浪裏個浪去吧!
Collections,集合。也就是將多個接口請求能夠放在一塊兒,並管理起來。什麼樣的接口請求能夠放在同一個collection裏?在這裏告訴你們能夠這樣:一個工程一個Collection,這樣方便查找及統一處理數據。也能夠這樣理解:collection即工程。
第一步,建立一個Collections
點擊上圖中的帶+號的圖標
輸入Name:」demo」,Description:」demo for baixiaosheng」,點擊Create按鈕即建立成功一個Collections.
按上圖選擇好Collection及填寫好Request name後,點擊右下角的Add to collection按鈕,即將一個請求添加進了Collection。
在前面講到了collection即工程的概念,工程是能夠管理,也是能夠模塊化的。隨着放入Collection的請求愈來愈多,混亂就又出現了,在找一個請求時,要找半天,因而將collection中的請求分門類別就很重要了,歪果仁也想到了,因而,在collection中就能夠添加Folder了,將相同場景的請求放入同一個Folder中,因而就實現了模塊化的管理了。
添加上Folder name,即模塊名稱後,點擊Create,建立成功一個Folder。
接下來,只須要把相同場景的請求拖入相同的Folder便可,這樣就實現了模塊化的管理了。模塊化之後的結構:
將工程模塊化的用例管理起來後,藉着這個管理起來的東風,也能夠將工程模塊化的用例執行起來,即一次執行一整個collection裏的用例,或者執行一個collection裏的某一個Folder裏的用例。
點擊Runner,
上圖中的」Choose collection or folder」,若是選擇demo,表示運行demo這一整個collection的用例,若是選擇GET,即只運行demo下的GET模塊下的用例。
Environment,即運行環境,是開發環境仍是測試環境,需事先配置,你們能夠下去自已嘗試一下。
Iterations,即重複運行次數。會將選擇好的collection中folder重複運行。
Delay,間隔時間。用例與用例間的間隔時間。
Data,外部數據加載,即用例的參數化,能夠與Iterations結合起來用,實現參數化,也就是數據驅動。
Start Test Run,點擊運行,運行完成後,便可得出一個簡易的聚合報告。
在Iterations重複運行時,若是某個用例但願每次運行時,使用不一樣的數據,那麼應該知足以下2個條件:
-
腳本中要用到數據的地方參數化,即用一個變量來代替,每次運行時,從新獲取當前的運行數據。
-
須要有一個數據池,這個數據池裏的數據條數,要與重複運行的次數相同。
Postman的runner給咱們提供了Iterations的輸入項,也提供了Data的文件選擇項,也就是意味着數據池是一個外部文件。若是Iterations裏的值爲2,那麼,這個外部文件裏也應該有兩條數據,postman但願咱們這個外部文件裏的數據是一個json(固然也能夠是其它的數據格式),那麼,爲了表示兩條數據,這個json應該是一個list結構,同時,因爲腳本要用到數據的地方須要參數化,須要變量,因此,每一條數據應該就是一個map,map的key對應腳本中的變量.
上圖中表示提供了一個msg的變量,每次運行對應不一樣的值,預示着在腳本中能夠用到msg這個變量,那在腳本中如何用?
如上圖斷言中用data.msg,其中data是個內置對象,即表明每一次運行的那個map數據,因此,能夠用data.msg來獲取每次運行的對應的值,固然,因爲是個map,也能夠用data[‘msg’]來獲取對應的值。
萬萬沒想到,postman居然如此之強大!咱們還有什麼理由去拒絕?介紹完以後,可能新的問題又來了,如何與jenkins結合實現持續集成?歪果仁的技術思想是很強大的,因此,產生了個newman,是個命令行運行postman請求的工具,建議你們自行去研究下,由於那確實就只是個命令行的工具而已!