在瀏覽器中打開頁面并加以判斷，無疑是測試一個(gè)Web應(yīng)用程序最直接的方式。借助一款合適的自動(dòng)測試工具或框架，測試人員就可以在一定程度上從繁重的手動(dòng)測試工作中解放出來。Ruby平臺(tái)下的Watir無疑是這方面的姣姣者，因此被大量用于Web應(yīng)用程序的回歸測試或驗(yàn)收測試。不過對(duì)于使用.NET Framework的技術(shù)團(tuán)隊(duì)來說，Watir不一定是***的選擇。目前社區(qū)中已經(jīng)出現(xiàn)了幾款.NET平臺(tái)下的Web測試框架，測試人員現(xiàn)在就可以使用自己最熟悉的語言來實(shí)現(xiàn)同樣的功能，并與自己的開發(fā)環(huán)境無縫集成。

WatiN

WatiN是Watir的“應(yīng)對(duì)之作”，使用C#語言開發(fā)，不過能夠使用任意.NET語言編寫測試代碼。WatiN 1.0只支持IE瀏覽器，不過從2.0版本開始也能自動(dòng)操作FireFox（需安裝插件）瀏覽器了。其***版本是2月19日發(fā)布的2.0 CTP3，對(duì)面向FireFox的相關(guān)功能進(jìn)行了增強(qiáng)并修改了一些bug。其附屬項(xiàng)目WatiN Test Recorder支持對(duì)瀏覽器操作的捕獲，并自動(dòng)生成測試代碼。WatiN Test Recorder目前剛發(fā)布了alpha版本，您可以從它的主頁上跟進(jìn)其***消息。WatiN是一個(gè)開源項(xiàng)目，使用Apache License 2.0協(xié)議發(fā)布。

Selenium

嚴(yán)格說來，Selenium是一套完整的Web應(yīng)用程序測試系統(tǒng)，它包含了測試的錄制（Selenium IDE）、編寫及運(yùn)行（Selenium Remote Control）和測試的并行處理（Selenium Grid）。Selenium的核心Selenium Core基于JsUnit，完全由JavaScript編寫，因此可運(yùn)行于任何支持JavaScript的瀏覽器上。

Selenium Core由一種指定格式的HTML文件驅(qū)動(dòng)，在一定程度上增強(qiáng)了測試套件（Test Suite）的可讀性。Selenium Remote Control允許測試人員使用常見的語言（自然包括C#等.NET語言）編寫測試代碼，并支持不同操作系統(tǒng)下的各種主流瀏覽器。Selenium Grid的作用是將測試分發(fā)至多臺(tái)機(jī)器，這樣便可大大加快測試速度。與WatiN相同，Selenium也是一款同樣使用Apache License 2.0協(xié)議發(fā)布的開源框架。

LTAF

Lightweight Test Automation Framework for ASP.NET（輕量級(jí)ASP.NET自動(dòng)測試框架，下文簡稱為LTAF）是一款由ASP.NET QA團(tuán)隊(duì)開發(fā)的框架，并用于產(chǎn)品的回歸測試。測試人員能夠使用任意.NET代碼編寫測試，并使用內(nèi)置的API操作DOM元素。LTAF最近發(fā)布了April Update并包含了框架代碼，它的Release Note記錄了框架的使用方式。趙劼最近在博客中談到了利用LTAF對(duì)ASP.NET MVC應(yīng)用程序中的視圖作獨(dú)立的單元測試，他在文章中對(duì)LTAF有這樣的評(píng)價(jià)：

雖然在某些方面（例如DOM元素的選?。┎蝗缙洹案偁帉?duì)手”，但是LTAF自有其獨(dú)到之處：

由于直接在瀏覽器中運(yùn)行，它天生便支持現(xiàn)有的——以及未來可能出現(xiàn)的任意瀏覽器。

由于直接部署在被測試的網(wǎng)站中，因此測試代碼和網(wǎng)站頁面是在同一個(gè)進(jìn)程中。

***點(diǎn)優(yōu)勢(shì)自不必說，而第二點(diǎn)更是關(guān)鍵。試想WaitN和Selenium，都是通過編寫代碼在瀏覽器中打開頁面。這意味著我們的在測試代碼和被測試的網(wǎng)頁分別在不同的進(jìn)程中。在這個(gè)前提下，如果我們要將測試代碼中定義的數(shù)據(jù)傳遞給被測試的網(wǎng)頁（也就是視圖對(duì)象），我們就必須進(jìn)行跨進(jìn)程的通信。而無論怎么實(shí)現(xiàn)，都逃不過“序列化”一途，這無疑增加了復(fù)雜度。而使用LTAF之后，這個(gè)問題瞬間煙消云散了，因?yàn)槲覀兛梢灾苯釉趦?nèi)存中“傳遞”測試數(shù)據(jù)，一切都只是個(gè)引用而已。

不過任何事物都具有兩面性，LTAF也有一些難以天生的，而且是永遠(yuǎn)無法彌補(bǔ)的缺點(diǎn)。例如：

由于LTAF將待測試的頁面放置在Frame中，因此該頁面上的window.top等基于瀏覽器frame結(jié)構(gòu)的屬性會(huì)被改變。

由于LTAF的本質(zhì)是使用JavaScript來操作DOM，這意味著任何會(huì)阻塞程序進(jìn)行的操作（例如alert）都不能使用，否則將阻塞整個(gè)測試過程。

幸運(yùn)的是，這兩點(diǎn)都不會(huì)成為嚴(yán)重的問題。對(duì)于***種情況，我們只需要編寫一個(gè)自定的getTop方法來替換直接訪問windows.top的做法即可。而第二種情況——老趙從來不喜歡alert或confirm這種“純?yōu)g覽器功能”，因?yàn)樗鼈儠?huì)帶來很差的用戶體驗(yàn)，更何況現(xiàn)在的JavaScript類庫/框架都能很輕松的做出這種效果，您覺得呢？

比較

雖然老趙推薦使用LTAF，不過究竟哪款測試框架最適合您的項(xiàng)目，還需要讀者根據(jù)需要自己的需要做出判斷。以下表格列出了他們的橫向比較。

【編輯推薦】

1. 微軟MVP教你如何看懂.NET CLR基本術(shù)語
2. 詳解.NET 2.0開發(fā)Winform程序經(jīng)驗(yàn)
3. 詳解在ASP.NET中用LINQ實(shí)現(xiàn)數(shù)據(jù)處理