你應該知道的自動化測試的“ABC”

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

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

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

　　測試套件Suit

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

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

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

　　①錄制腳本可能會帶來冗余、公用元素不可調用、腳本調試復雜等問題。專業化的建議是以錄制為參考,以編寫腳本為主要行為。 當每一個測試用例所形成的腳本通過測試后，并不意味著執行多個甚至所有的測試用例就不會出錯。

　?、谳斎霐祿驕y試環境的改變，都會導致測試結果受到影響甚至失敗。而如果僅是一個個執行測試用例，也只能被稱作是半自動化測試，極大的影響自動化測試的效率。

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

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

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

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

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

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

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

　　七、小結

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