由于存在同源策略的問題，所以在進行測試部署時，必須將所測試程序部署在服務(wù)器端。 例如你想采用selenium-core來測試用JavaScript寫的www.google.cn,由于不允許向磁盤寫數(shù)據(jù)，所以只能將測試結(jié)果發(fā)送到另外一臺服務(wù)器進行保存。

　　Selenium IDE是對瀏覽器進行擴展，作為FireFox的一個插件。通過監(jiān)聽用戶對html頁面的操作來錄制腳本。 其特點：

　?、俜浅Ｈ菀自陧撁嫔线M行錄制和回放
　?、谀茏詣油ㄟ^id，name和xpath等來定位頁面上的元素
　?、圩詣訄?zhí)行selenium的命令
　　④能夠進行編輯、調(diào)試和設(shè)置斷點
　?、蒌浿茣r自動生成腳本，不但能夠保存，并且能轉(zhuǎn)化成各種語言(C#、JAVA等)
　?、拊诿總€錄制的腳本中能夠加入斷言

　　測試套件Suit

　　要達到對應(yīng)用程序的完全測試覆蓋，通常需要不止一個測試用例。測試套件用于將具有類似功能的一些測試用例編成一組，以便讓它們按順序運行。

　　測試套件和測試用例一樣，都是用簡單的 HTML 表編寫的。但是注意，測試套件使用一個只包含一列的表，表中的每一行指向一個包含某個測試用例的文件，如下例所示：

　　通過以上的分析，我們可以知道10 Selenium比其他的測試工具有著明顯的優(yōu)勢，但是其也有一定的限制：

　?、黉浿颇_本可能會帶來冗余、公用元素不可調(diào)用、腳本調(diào)試復(fù)雜等問題。專業(yè)化的建議是以錄制為參考,以編寫腳本為主要行為。 當(dāng)每一個測試用例所形成的腳本通過測試后，并不意味著執(zhí)行多個甚至所有的測試用例就不會出錯。

　?、谳斎霐?shù)據(jù)或測試環(huán)境的改變，都會導(dǎo)致測試結(jié)果受到影響甚至失敗。而如果僅是一個個執(zhí)行測試用例，也只能被稱作是半自動化測試，極大的影響自動化測試的效率。

　?、跾elenese 有一些嚴格的限制，如它沒有條件(沒有“if”表達式)，沒有循環(huán)(沒有“For”表達式)。這樣會使編寫復(fù)雜的測試變得困難甚至不可能。

　　六、自動化測試的使用范圍

　　1) 軟件需求變動不頻繁
　　不穩(wěn)定的系統(tǒng)也就意味著測試的不穩(wěn)定，我們不知道這次的變動是否會影響到系統(tǒng)其他的功能。那么是否需要在每次迭代完以后都需要對系統(tǒng)進行完整的回歸測試呢?測試腳本的穩(wěn)定性決定了自動化測試的維護成本。如果所花費的成本不低于利用其節(jié)省的測試成本，那么自動化測試便是失敗的。

　　項目中的某些模塊相對穩(wěn)定，而某些模塊需求變動性很大。我們便可對相對穩(wěn)定的模塊進行自動化測試，而變動較大的仍是用手工測試。

　　2) 周期足夠長的項目
　　自動化測試需求的確定、自動化測試框架的設(shè)計、測試腳本的編寫與調(diào)試均需要時間和精力來完成，這樣的過程本身就是一個測試軟件的開發(fā)過程，需要考慮投入成本的問題。

　　如果項目的周期比較短，沒有足夠的時間去支持這樣一個過程，或者說傳統(tǒng)測試所花費的時間和人力資源遠小于采用自動化測試的投入，那么自動化測試便成為笑談。

　　3) 自動化測試腳本可重復(fù)使用
　　如果費盡心力開發(fā)了一套近乎完美的自動化測試腳本，但是腳本的重復(fù)使用率很低，致使其間所耗費的成本大于所創(chuàng)造的經(jīng)濟價值，自動化測試便成為了測試人員的練手之作，而并非是真正可產(chǎn)生效益的測試手段了。

　　七、小結(jié)

　　任何一種產(chǎn)品化的測試自動化工具，都可能存在與某具體項目不甚貼切的地方。再加上，在企業(yè)內(nèi)部通常存在許多不同種類的應(yīng)用平臺，應(yīng)用開發(fā)技術(shù)也不盡相同，甚至在一個應(yīng)用中可能就跨越了多種平臺，或同一應(yīng)用的不同版本之間存在技術(shù)差異。所以選擇軟件測試自動化方案必須深刻理解這一選擇可能帶來的變動、來自諸多方面的風(fēng)險和成本開銷。