我們的自動化測試為什么這么難？(2)

　　頁面測試工具的選擇有什么規律

　　首先要贊揚Selenium和WebDriver這些開源WEB自動化測試工具的靈活性(注：WebDriver就是基于Selenium的一個自動化測試類庫，但它不再是運行在瀏覽器內的JS程序，而是自己可以控制瀏覽器)，這些工具在與大多數測試平臺的整合以及其所支持的腳本語言種類上都有很大優勢(Java、dotNET、Perl、Python、Ruby、C#等)。由于它們是專一的WEB自動化測試工具，它們在處理WEB應用的問題上顯得非常專業，結合一些Hook程序的使用，使得它們的運行速度明顯快于QTP。而同QTP一樣，他們在處理一些第三方插件的時候都需要借助另外的插件和程序，這一點也正好印證了開源工具的特征：為了解決我們需要的需求，可以采取一些額外的手段來協助。不過商業工具也不是就甘心這樣讓出他們的市場的，HP為QTP10.0及以上的版本增加了ExtensibilityAccelerator組件，專門用來為測試人員自定義開發與發布插件類庫。該組件在其易用性在還沒有被廣泛驗證之前一直顯得比較低調，通過對QTP11的簡單試用，筆者覺得這是開源的沖擊終于讓像HP這樣的廠商不得不放低姿態，開放一些核心的、更有價值的東西給大家使用，其一直鼓吹的傻瓜式關鍵字驅動不再成為其宣傳的核心賣點?？偟膩碚f在易用性和擴展性上，最新版本的商業工具(QTP)和這里提到的兩種開源工具其實是旗鼓相當的;只不過在平臺整合和所支持的腳本語言上，QTP還是顯得比較單純，雖然廠商在不斷地豐富著它所提供的AOM接口方法。

　　其次，單就WEB自動化測試來說，我們選擇任何工具，只要能進行WEB測試，那么它幾乎可以全部應付我們絕大多數的自動化需求;只不過為了自動化實施的更加便利，我們對WEB應用類型還是可以再細分一下。由于Selenium和WebDriver這些開源是基于瀏覽器的測試工具，它們在快速響應UI交互請求和流程性、邏輯較為簡單的應用程序的測試上優勢巨大。但是對于業務邏輯復雜和流程性很強的軟件來說，要是使用他們就必須有足夠強大的測試框架：要處理不同的第三方插件程序，要完成類型眾多的參數Mapping解析和文件操作、數據庫操作等，要處理調度管理和大規模執行的種種條件依賴，要完成復雜的斷言分析設定，定義出錯之后的處理方法……即便是為其專門定制的測試管理工具Bromine也無法很好的滿足我們日常這些復雜的需求。雖然這些組件開發完成之后組裝起來的框架通用性比一般的QTP自動化測試框架要高一些，但是其開發的技術難度顯然比后者高很多，必須要考慮員工技能現狀，這就需要我們仔細地考慮清楚其開發成本是否有足夠的優勢。相較之下，雖然QTP這些商業工具入門簡單，但隨著測試人員不斷地學習和深入，我們會發現它也能夠滿足一些更復雜的邏輯和流程驗證。因為QTP的起點很低，即便起初沒有測試框架，使用QTP+QC提供的一套原始的框架也可以替代管理，完全沒有技術難度可言，用于處理大部分流程性比較復雜的系統來說都足夠了，后續框架建立起自己所需要的框架之后也可以把離散的腳本程序納入新的框架中去管理，其核心問題是對執行環境和測試數據等方面因素要求非常高。而QTP脫離QC的框架也有很多，不過大同小異，開發難度也不高，筆者認為這是在B/S結構的金融軟件UI自動化測試中使用得最多、最為成熟的一種形態。有了這種應用系統特征的區分意識，我們就能夠理解Google和百度這樣的門戶網站為何很少去使用QTP測試，因為這種應用要使用QTP測試實在是讓被測程序委屈(操作慢)、讓測試工具委屈(綜合實力無法體現)，更讓測試人員委屈(得不償失)——如果他們能夠熟練運用Selenium和WebDriver這類開源工具和框架的話。

　　總之，工具的選擇一方面要看被測應用的特征，一方面要看組織內部人員技能水平現狀。如果要追求技術上的行業領先地位，充分利用現有的強大的技術優勢，那么使用開源工具和框架無疑是一種不錯的選擇;而且開源的思想使得工具更加能夠區分體現不同的社會產業領域的軟件在自動化測試上的不同特征，為更加全面的認識自動化測試鋪下堅實的基礎。但是由于開源的自動化測試實施在一開始就要把調度平臺、測試框架相關的內容全部準備好，就從根本上決定了它們不適合在探索性的測試自動化建設中大規模使用。同時我們知道，QTP這種商業工具在初級到中高級水平的自動化測試實施過程中還是比較有優勢的，只不過在實施的過程中所遇到的問題遠遠要比這些開源工具更加鬧心，隨時有讓人想放棄這種工具的感覺。但是在達到一定規模和水平之后，無論任何工具，在界面測試自動化實施上，我們回頭看的時候就將會發現，選擇開源測試工具還是商業測試工具無非是郁悶在起點還是郁悶在過程中的問題，其本質上都是一樣的，沒有什么卓越到讓傻瓜都能變得無比強大的測試工具。通常，互聯網應用和門戶網站的UI測試更推薦使用Selenium和WebDriver這些開源工具;而對于有著復雜業務邏輯和業務流程的B/S結構的企業ERP應用來說，如果自動化測試實施的規模較大、測試人員技能水平一般的話，那么最好還是先使用QTP這種類似的商業工具。

　　我們不妨捫心自問：我們追求的是什么?我們的現狀又是怎么樣的?我們是否已經把我們當前這個自動化測試的建設做到出現瓶頸了?在遇到瓶頸的時候我們還有沒有繼續進行深入的研究呢?如果再三思考之后還是想到可能會有可改進的地方，覺得有可能越過某個點之后就會得到新的效應，那么請不妨回頭繼續把當下的建設做完。就像圍著5米寬的圓環型跑道尋找遺失的物品，無論單次走的是內圈還是外圈，都應該走到頭，否則達成你的目標就只能靠碰運氣了。如果你們在開展大規模的自動化建設，并且你們發現根本無法在跨越目前的瓶頸了，那么可能真的需要嘗試一些新的工具或者框架了。

　　大規模自動化實施也有流程定勢

　　筆者理解，一般的小型項目和系統在快速的測試過程中對測試框架的需求不是很明顯，因為三五十個測試用例的管理對與我們來說不是什么問題。但是如果用例多到幾百上千乃至上萬的話，沒有科學的組織管理方式將會是個災難。我們這里先看看大型項目和系統或者系統群的自動化實施，它們在自動化實現從無到有、由淺入深的過程中都需要關注哪些方面。

　　首先是人員的技能，這是最基本的條件，缺少這個條件，一切后續的工作都沒有辦法繼續下去。所以一個公司要進行自動化實施，在這個實施周期的最初階段就需要解決的是人員技能的問題，一般有人才引進、引入培訓或者聘請顧問咨詢等辦法。自動化測試框架與平臺不能單靠“求同存異”這四個字就能定義的，因為它們需要全部兼容絕大多數類型的系統、解決絕大多數問題。所以調研分析雖說用不著細致入微，但還是應該把所有系統的設計特征和業務流程都了解清楚。所以這對負責人的技能要求非常高，否則會帶來頻繁且不必要的框架、平臺的變更，給測試管理帶來很大不便。就像做接口測試自動化，我們公司的產險業務系統中的業務規則多依賴于JAVA程序，但是養老險則基本都依賴數據庫PACKAGE，拿其中一個做所謂的DEMO去向另一個去推行，阻力就會大到基本不可行的程度。這就是負責人對系統特征理解單一、對整個公司的應用系統的架構特點不了解所導致的。

原文轉自：http://www.anti-gravitydesign.com