做測試，怎麼測試，要測試什麼，得有依據。功能測試的依據是需求規格說明書，介面測試的依據，通常有需求規格說明書及介面開發文件。但這些文件，並不是每個公司都有的，有的可能沒有介面文件，甚至需求文件都沒有，這個時候，就只能與產品、開發溝通來確定介面的邏輯了。

現在假定有個登入的介面，需求是使用者名稱和密碼長度都是8-16位，且只能數字或字母組成。如果是比較好的需求文件，所有正常及異常的情況都要有所規範，比如使用者登入成功後，程式如何處理，使用者名稱少於8位，要如何提示，有標點符號，要如何提示等等。如果是一般的需求文件，可能就是一句話帶過，使用者名稱8-16位，只能數字或字母組成。至於各種提示語，沒有規範，那麼測試的時候，就可能會出現爭執的情況，一個提示語，開發認為可以，可測試認為不夠人性化，提出要改，開發就不願意改，這樣就比較糾結了。這裡就不去討論這樣的問題了，現在我們用之前部落格中構建的web專案寫一個介面，介面程式碼如下：

package king;

import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


public class Login extends HttpServlet {
	private static final long serialVersionUID = 1L;

	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		
		request.setCharacterEncoding("UTF-8");
		response.setContentType("text/html;charset=UTF-8");
		PrintWriter writer = response.getWriter();
		
		String username = request.getParameter("username");
		String password = request.getParameter("password");
		String result = "";
		
		if(username == null || password == null){
			writer.write("Bad Request");
			return;
		}
		
		username = username.trim();
		password = password.trim();
		int usernameLength = username.length();
		int passwordLength = password.length();
		
		if(usernameLength == 0){
			result = "使用者名稱不能為空！";
		}else if(usernameLength < 8){
			result = "使用者名稱太短了！";
		}else if(usernameLength > 16){
			result = "使用者名稱太長了！";
		}else if(!username.matches("[0-9a-zA-Z]+")){
			result = "使用者名稱只能由數字或字母組成！";
		}else if(passwordLength == 0){
			result = "密碼不能為空！";
		}else if(passwordLength < 8){
			result = "密碼太短了！";
		}else if(passwordLength > 16){
			result = "密碼太長了！";
		}else if(!password.matches("[0-9a-zA-Z]+")){
			result = "密碼只能由數字或字母組成！";
		}else if("qwertyui".equals(username) && "12345678".equals(password)){
			result = "登入成功！";
		}else{
			result = "使用者或密碼不正確！";
		}
		
		writer.write(result);
		writer.flush();
		writer.close();
	}

}
 

當然了，這只是一個模擬的介面，沒有連線資料庫，正確的帳號寫死了，只有一個“qwertyui”，密碼是“12345678”。實際開發中的介面，肯定不是這樣寫的。這個模擬的介面中，判斷還是比較嚴謹的。先獲取前端傳過來的使用者名稱和密碼，然後判斷一下這兩個值，是否為null，如果為null，就響應“Bad Request”，如果是走了這個判斷，很明顯，是有人在呼叫介面，惡意攻擊。如果都不為null，那就兩個值去掉首尾空格，再校驗使用者名稱的格式，密碼的格式，最後兩個分支，本應該是查資料庫的，但這個只是模擬的介面，就不去查資料庫了。

那麼，在介面測試中，開發人員容易犯的錯誤有哪些呢？首先，引數的null值判斷，很多開發不會寫，這個在需求中也不會提及。有些需求，在需求文件中不會寫，但開發人員也要實現。比如程式碼裡不能有觸犯法律的東西，這個在需求文件裡，肯定不會提及的，因為這個是共識。程式在接收前端傳過來的資料時，需要對null值做處理，這個，可以作為程式設計的一個規範，規範並不是強制約束，所以肯定就會有人不遵守或是不知道。如果不做null值的處理，那麼後面的語句，使用這些引數，就可能會空指標異常。另外一個就是去掉首尾空格，很多開發也不會做，當然，有些系統需求就是不用去掉首尾空格的，這個就另當別論了。

現在我們要開始測試這個介面，開發給出的介面地址：http:localhost:8080/Demo/login，引數為username和password。這個介面地址，是開發在自己的電腦上測試時用的，我們測試時，需要將localhost改成需要測試的環境的地址。這個專案，我部署到了我的linux虛擬機器中，假設這個就是測試環境，專案怎麼部署到liunx，可以參考前面的博文：eclipse構建web專案。

進入jmeter安裝目錄下的bin目錄，雙擊jmeter.bat，開啟jmeter，介面如圖：

右擊測試計劃——新增——Threads(Users)——執行緒組

在新新增的執行緒組上右擊，新增——Sampler——HTTP請求

然後，HTTP請求配置頁面，輸入各個配置項

然後右擊執行緒組，新增——監聽器——察看結果樹

這樣，簡單的介面測試指令碼就算完成了，按Ctrl+S儲存。然後，我們執行一下：

執行之後，我們點察看結果樹。

這個就是請求介面的一些資訊了。通常，我們並不會太關注這個，我們關注的是響應資料

可以看到響應的資料為：使用者名稱不能為空！，這個正是我們在後臺定義的響應資料。這樣，我們現在就測試了介面的一種異常情況了，相當於是跑了一條測試用例，使用者名稱和密碼都為空的情況。然後點http請求，username的後面輸入：abc，儲存，執行

檢視響應資料

提起：使用者名稱太短了！，可以看到，上一次的執行結果還在，如果不想看到上一次的執行結果的話，可以按工具欄中掃把樣的按鈕，清除之前的執行的結果。然後，可以依次測試使用者名稱太長、含有標點符號的情況，還有密碼的各種情況。當然還有少引數的情況

比如，現在引數只有username，沒有password引數，儲存，執行，然後檢視結果樹

響應正確。現在是可以實現介面的測試了，不過，很麻煩，每一種情況，都要到HTTP請求中改一下引數，執行一下，再到結果樹中檢視結果。能不能一次執行就把所有的可能都測試到呢，肯定是可以的，笨方法：線上程組中加很多HTTP請求，一個HTTP請求就是一種情況。聰明的方法：加一個HTTP請求，然後引數的值，做成引數化。另一個問題就是可不可以讓指令碼自動判斷響應的結果對不對呢？答案是可以的，引數化和響應斷言，下篇博文再講吧。