本文介紹JMeter如何做web service測試，一般來說web服務，一般指的是HTTP請求相關的內容。這裡就介紹一下如何利用JMeter做基於HTTP的web介面測試。介面也叫API(Application Programming Interface)，很多我們使用的各種APP，上面的內容顯示大部分都呼叫後臺web伺服器的介面，有些是網站的介面，有些是solr的介面。

什麼是介面？

       我們這裡舉例一個生活中場景來幫助你理解介面。加入你去餐館點餐，看了選單，告訴服務員，你要一個宮爆雞丁，過一會，服務員就端上宮爆雞丁給你就餐。這個場景，有三個物件，你、服務員，宮爆雞丁，具體關係是，你點了宮爆雞丁，服務員拿著你點的菜，告訴後廚去做這個菜，一段時間，後廚做好了，服務員給你端上宮爆雞丁這個菜。再精簡一點就是，你告訴服務員，你要宮爆雞丁，服務員一會就給你上宮爆雞丁。服務員在這個過程，就是一個介面的作用，你傳送了一個點菜的請求，服務員給你上宮爆雞丁就是一個請求的響應。

       這樣的事情，在軟體中就這樣叫法：你點菜是向服務員傳送了一個請求，具體的菜名就是傳入的引數；服務員給你上菜，就表示已經對你的請求做了響應，響應的內容是，宮爆雞丁。再舉例一個實際應用，我們手機桌面一般有一個天氣預報，你設定了地區，就給你顯示這個地區的天氣預報。這個過程的大致原理是，手機廠商或者天氣預報這個軟體，在一些能提供天氣服務的機構，申請了或者乾脆花了錢，軟體裡面調了人家商業結構的提供的天氣的API。具體天氣的資料都來自這些提供天氣服務的商業機構。今天我們就來測試一個關於天氣的介面。

       介面測試，大致流程是: 拿到一個介面文件，分析好請求方式是什麼，主要有POST和GET方法，請求URL是什麼，請求需要傳入幾個引數，引數的值是多少，檢查請求響應的程式碼是什麼，響應的內容有沒有介面文件裡描述的返回引數。介面測試可以手工做，也可以自動化做，自動化做的難點就是如何去對響應列表進行斷言。

 天氣介面服務準備工作

為了寫這篇文章，花了很多時間，在網上找免費的天氣API，基本上找到了國內的新浪天氣和國外的一個網站。國外的網站，我沒有找到北京這個地區的程式碼，所以通過API獲取不到北京的天氣資訊，這裡就不講國外的。

1. 開啟新浪天氣網站：http://php.weather.sina.com.cn/

2. 在試試輸入框搜北京，點選搜尋按鈕，記住當前URL是：http://php.weather.sina.com.cn/search.php?city=%B1%B1%BE%A9&dpc=1

需要記住的是city=%B1%B1%BE%A9

其實這個看起來像亂碼的欄位就是北京的轉義顯示的一種形式，URI協議的知識，知道就可以。上海就變成和上面類似的亂碼欄位，但是肯定不同。

3. 來看看這個藉口請求地址

http://php.weather.sina.com.cn/xml.php?city=%B1%B1%BE%A9&password=DJOYnieT8234jlsK&day=0

解釋拆分（對照JMeter http 請求介面）：

domain: php.weather.sina.com.cn

path: /xml.php

引數一共有三個，分別是城市，密碼和天，密碼是固定不變的，day=0代表當天，day=1代表明天，以此類推：

引數1：  key:city                   value:%B1%B1%BE%A9

引數2：  key:password         value:DJOYnieT8234jlsK

引數3：  kye:day                   value:0

瞭解了這些之後，我們來看看如何用JMeter來實現這個北京天氣查詢的介面測試。

1）開啟JMeter UI介面

2）新建一個Thread Group

3）新建一個Sampler,選擇HTTP Request

4）新建一個Lisenter，選擇View Result Tree

5 ) HTTP Request介面設定如下圖

6) 點選執行測試

7) 檢視結果

-點選View Results Tree,檢視結果，發現亂碼

-把text改成document，再次看看

你還可以去Sampler result這個tab裡面檢視響應狀態碼是不是200

好了，如何用JMeter做介面測試就介紹到這裡。
---------------------