Fitnesse使用系列八

結束篇：

Fitnesse是一個有著非常好的創意的軟件。它試圖拉近開發者與用戶的距離。通過前面的介紹，大家可能也看出來了，其實最終還是要落實到編碼（fixture）上。這些編碼一般來說要由測試人員來寫。那么就引發了我的一些思考：

一、有沒有必要對每個需求都制定驗收“表格”。如果這樣做，就意味著要寫非常非常多的fixture。寫這些代碼需要花費相當的時間，而時間是昂貴的成本。在能取得大體相同的效果時，有沒有成本更少的辦法？

二、這些代碼本身是否存在bug，調試這些代碼以及日后維護這些代碼是否還要付出更多的成本？——我曾經很熱衷于自動化測試工作的推進，但是后來我觀察到，如果一段自動化測試代碼寫出來僅僅執行幾次就完了，那么這種自動化我認為完全沒有意義。

三、所以，我的觀點是自動化只用在那些需要大量回歸、功能固定、相對底層的測試上就好了，測試代碼要盡量的簡單；盡量不要增加復雜的邏輯；盡量通用以提高利用率；所花費的時間要盡量少。

基于以上理解，我這里給出一個通用的fixture和fitnesse表格，此表格在我公司主要用于接口測試，當然也可以用于一般性的頁面檢查。實際運行將近兩年了，效果還可以。fitnesse內置的一些fixture應該有類似功能，但我覺得查找和學習使用的時間可能比自己寫更長，就自己寫了。

package calis.http;

import org.apache.http.impl.client.*;
import org.apache.http.client.methods.*;
import org.apache.http.HttpEntity;
import org.apache.http.HttpResponse;
import org.apache.http.util.EntityUtils;

public class Exist {
	private String url=null;
	private String key=null;
	private String keys[]=null;
	private String reponseStr;
	private String result="NotExist";
	
	public void setStartUrl(String url){
		this.url=url;
	}
	public void setKeyWords(String s){
		key=s;
		if(key.charAt(0)!='/'){
			key="/"+key;
		}
		keys=key.split("/");
	}
	public String verify(){
		return result;
	}
	public void execute(){
		DefaultHttpClient httpclient = new DefaultHttpClient();
		HttpGet httpget = new HttpGet(url);
		try{
			HttpResponse response = httpclient.execute(httpget);
			HttpEntity entity = response.getEntity();
			if (entity != null) {
				reponseStr=EntityUtils.toString(entity,"UTF-8");
				if(keys.length>1){
					boolean judge=true;
					for(int i=1;i<keys.length;i++){
						if(reponseStr.contains(keys[i])){
							judge=judge&&true;
						}else judge=false;
					}
					if(judge){
						result="ok";
					}
				}
			}
		}catch(Exception e){
			result="NoExist";
		}finally{
			httpclient.getConnectionManager().shutdown();
		}
	}
	public void reset(){
		result="NoExist";
	}
}

表格是這樣的：

使用也很簡單，在start url輸入地址，檢查返回的字符串中是否全部包含了key words指定的字符串。每個字符串用/分隔。如果全部包含了返回ok，未全部包含返回NoExist。盡管很簡單，但非常通用，可以用于檢測一切支持get請求而返回的html、xml、json等多種格式數據。

上述代碼中已知的問題有：

1.對非utf-8格式的返回不支持

2.只支持“與”檢查，不支持關鍵字的其他邏輯關系

3.未對html上的轉義符做處理，比如在頁面上顯示為<，其實編碼是&lt，那么需要檢查&lt而不是<

4.由于關鍵字是由/分隔，那么檢測返回值中是否含有/是做不到的。

鑒于我一向堅持的觀點——測試代碼要盡量簡單，我無意改進這些內容。