我理想中的功能測試化工具應該滿足以下基本條件：
- 簡單。測試本來就夠複雜了。測試人員本來就該把精力集中在發現系統錯誤上面。再讓測試人員在測試程式上花費大力氣，實在得不償失。所謂簡單，關鍵在於和瀏覽器使用者的操作同軌。程式碼應該完全屏蔽和使用者無關的細節。比如說，如果網頁上有個叫“遞交”的按鈕，那對應點擊該按鈕的語句應該不比getButton("遞交").click()更複雜。簡而言之，自動化工具的編程模型能讓一個測試員看著使用者的操作寫出對應的代碼。套用現在的流行術語，叫自動化的測試所用的語言應該是和使用者的概念性模型(conceptual model)對應的業務領域專屬語言(Domain Specific Language) 。更嚴重的後果是測試人員為了趕進度，不得寫出低水平的測試代碼，起不到發現系統錯誤的目的。
- 靈活。需求無止境。我們絕對需要一套能隨時擴充，支援複雜編程的自動化工具。也許今天我們只需要搜尋網頁上一條簡單的字串，所以工具提供的字串函數足敷使用，但明天我們可能就得遍曆網頁上所有元素，於是我們需要一套強大的HTML解析器。千萬不要告訴我，這套工具不支援HTML解析。不幸的是，很多上萬刀的工具，就是不支援隨意的HTML解析。再我看來，這已經不是開發人員設計上的過失，更本就是對測試人員水平的挑釁。
- 穩定。本來測試的目的是發現系統的錯誤，結果因為工具不穩定，測試人員發現大量工具的問題，最後不得不花上大量時間來排除於自家系統無關的錯誤。結果開發人員和測試人員摩擦加劇，測試人員精疲力盡，花大錢投資的工具束之高閣，項目費時費力。。。
- 功能強大，有大量的庫供使用。雖說我們可以開發自己的庫，但這種費時費力的工作最好不做。畢竟測試的核心部分不是開發自己的庫。還不用說將來的維護費用。
至於自動記錄操作，圖形化支援什麼的，都屬於錦上添花的東西，如果基本要求不滿足，不要也罷。可惜大多數商業工具，都把測試人員當傻瓜，過分注重自動記錄，圖形化操作等邊角功能。我用過下面的工具做Web應用的功能測試自動化，沒一款讓我滿意的：
- Mercury Interactive的QuickTest Professional。我用的好像是v3和v4。這款工具號稱全面支援圖形化自動記錄測試操作，支援用VBScript編程和定製記錄下的測試操作。號稱擁有強大的測試類別庫和圖形化的定製工具。遺憾的是，這款工具給我們的團隊帶來了無窮無盡的煩惱。它產生的程式碼包含大量底層細節，根本不適合人去修改和維護。它產生的程式碼檔案居然和它的Object Repository（Object Repository用來儲存自動記錄中產生的所有對象，以便日後回放時和回放結果比較）綁定。一不小心，就可能破壞這種綁定，導致產生的檔案失效。我明白Mercury的初衷是利用Object Repository來簡化自動化操作，可惜這個方法完全無效。我們還發現Quick Test Professional回放的時候常常和記錄的不一樣，導致測試虛假失敗。另外，由於測試結果和object repository相比較，直接造成測試回放對GUI敏感。哪怕改變一個按鍵的位置都會引起測試失敗。問題是，功能測試裡我們實在不關心一個按鍵在左上方還是右下角。總而言之，QuickTest Professional沒有做到基本要求裡的1，2，和3，直接使這個安裝空間高達1.2G的軟體淪落為適合小型GUi測試的工具。
- Segue SilkPerformer。我們用過v5和v6.5。這是款相當不錯的效能測試工具。功能強大，效能穩定。為我們部門的效能測試和系統測試立下汗馬功勞。可惜這款工具並不適合大規模複雜的WEB功能測試，儘管它支援功能測試。我們為了用這款工具，在它的基礎上搭建了巨大的測試庫，耗資N個人年，但仍然不能讓眾多的測試人員滿意。首先，SilkPerformer的自動記錄仍然暴露大量細節，比如說我們必須知道一個button是對應的一個簡單連結，還是一段JavaScript。其次，Silkperformer用一種古怪的語言，叫Benchmarking Definition Language。這個語言是標準Pascal和C的混合體，整合了標準pascal的呆板並放棄了C的靈活。這個語言的靈活性之差，以至於它還提供了對COM和JVM的介面，用來支援功能擴充。BTW，對JVM的支援出奇笨拙，比如只有static方法，比如只有一個類。。。最後，SilkPerfomer的BDL在編程上有很多限制。比如它不支援全面HTML解析（6.5開始支援了，但用了一種相當受限的配置方法），也不支援動態資料結構（不要告訴了定長的數組是動態資料結構，更不消說不同長度的數組居然是不同的資料類型）。對了，我提到了BDL的regular expression支援簡直是個笑話嗎？ 所以說，SilkPerformer不能滿足基本條件1, 2, 和4。
- Rational的XDE Tester和Robot。這兩款軟體也用Object Repository，所以自然繼承了Object Repository的各種缺點。儘管Rational採用了一些聰明的演算法來讓Object Repostory變得靈活而穩定，但要我用它提供的Java架構編程，還是饒了俺吧。
- HTTPUnit。這個是免費的開源功能測試架構，接近我的理想。它基本上就是個用代碼控制的瀏覽器（好的功能測試工具就該這麼做），合網頁上的操作簡單對應，相當方便。可惜目前的版本的HTTPUnit僅支援有限的JavaScript，而且對IE支援有限，因為它用的是Mozilla的HTML核心和JavaScript引擎。簡而言之，基本條件4沒有被滿足。
- Samie, Samie的出發點相當不錯：用程式控制IE Automation。也就是說，Samie利用Perl來類比一個瀏覽器的運行。而類比的方法是調用IE的Automation介面。這樣做好最大的好處就是能相對容易地滿足基本條件1。至於後面3個基本條件，Perl加上IE都可以輕易地滿足。不過Samie還在開發中，仍然需要添加大量功能。不過這是款相當有希望的軟體。這也是基本條件4沒有被滿足。
今天隨意瀏覽雜誌，看到一篇減少Watr的的文章。Watr是Ruby寫就的Web測試載入器。這款工具好像不錯。這款工具同樣調用IE Automation的介面。我們可以在Eclipse上調試測試代碼，因為eclipse整合了對Ruby的支援。看來是開始看鐵撬書的時候了。對了，這本書的第一版在網上免費
