筆者在別的貼子里面曾提過，自己所在部門的自動化測試經歷了幾次步進式的建設，都具有階段性的成果，但是總的看來卻不是一個成功的案例。因為趕進度，倉促的投入讓一大堆的腳本質量比較低下，有幾個測試組由于沒有人力投入自動化開發而又不得不完成自動化的KPI，只好聘請外包來幫忙完成自動化。理智地想一想，咱們花的那點錢請到過真正精通自動化技術又肯主動深入考察我們公司業務系統特征的外包么？況且外包終究還是要離開的，所以我們不得不接收一堆沒有經過精心設計、沒有組織性的腳本——尤其是在沒有通用測試框架的情況下。且不說UI測試的自動化腳本本身就運行不了多久就會面臨界面變更，單單是要讓我們接收別人迥然不同的設計風格就是一件很難的事情。結果呢？要么延續這種無組織性，讓腳本數量更加龐大、更加雜亂無章，要么就是放棄對這些腳本的維護，任其自生自滅，最終變成一堆廢材。

再想一想如今我們有幾個人在利用自動化腳本幫助自己的測試？高通過率的腳本是否就一定有它存在的意義呢？會不會出現為了應付指標數據，我們讓我們的腳本設計和驗證得盡可能地簡單、盡可能地能運行通過的情況呢？他們可能即便不放心自動化測試結果，也可以手工再回歸測試一遍……這種滑稽的現象表明自動化測試已經徹底的成了包袱！雖然我們公司崇尚結果導向，但是我覺得我們應該首先從根本上弄清楚什么目標才是我們最終想達到的。KPI考核的導向性作用很強，但是如果KPI并沒有能夠幫助我們得到我們想要的結果，那么KPI的設定就不是SMART的，持續改進意識不僅僅是流程規范，還有我們的KPI，對于自動化測試來說尤其重要。

我們有一部分同事宣稱：“我知道自動化能給我帶來便利，但是我實在沒有時間投入腳本開發”，其實就是骨子里抵觸自動化測試，抵觸工作方式的改變。另一部分人則很狂熱，看到自動化的些許好處就開始盲目崇拜自動化測試，也正是由于這種急功近利的心態，讓他們在“看到”一些失敗之后就將矛頭直指測試工具，而并不去反思自己在整個實施過程中采用的方法。攻擊某種工具是如何的不好，另一種工具如何的優秀，但是不去分析其中的差異，武斷地對大家宣稱換一種測試工具能夠節省成本、提高測試有效性。其實各種測試工具各有優點側重，其應用范圍和方法都有所不同，還是要理性地去看待這些問題。我本可以把別的測試工具數落一番，但我又不敢，因為我著實還沒有精通它們的使用方法，所以也不是非常明了它們的弱點，單就大家常說的QTP的弱點來說：

1. 需要付出昂貴的工具許可費用，的確是很大一筆費用。但是買都買了，莫非我們還要找廠商去退貨？再者，我們省掉的可能是工具許可費用，但是要付出的則是培訓人員新技能的費用、開發測試管理工具和新測試工具接口的費用和為仍然可能出現的失敗買單的代價；

2. 需要大批的運行客戶端，情況的確是這樣，但是做真實的頁面模擬測試，并且不能繞開我們系統的SSO認證，用什么工具都是一樣的，不信的話可以自己去驗證一下；

3. 對象經常不能識別，凡以此為由貶低QTP的人都可以回去面壁了，那么簡單的技術都用不好又何必再言其他？我相信也有一些QTP粉絲們在對開源測試工具的易用性不斷地腹誹，論壇上甚至還有謾罵聲；

4. 運行經常莫名其妙的失敗，這是測試環境問題、運行客戶端問題、腳本健壯性問題，這些問題可以得到解決，我們也可以通過解決這些問題來更加深入的了解我們的測試工具。

這些現象從根本上反映了人在出發點的心態和對工具的認知水平才是決定自動化測試實施成敗的關鍵。對自動化測試工具的使用來說，我很慶幸自己選擇了一個由簡單到復雜的學習過程；如果先學習了較為復雜的，再去使用這些所謂“簡單”的商業工具，很容易產生剛入門就輕視的情緒。正是為了避免自己“半瓶水瞎晃蕩”，我們試圖努力地去學習、了解別人的所思所想，可結果是，越學越迷茫、越學越恐慌——以前眼中的小小領域竟然包含如此之多的知識，學海無涯一說實誠不我欺也！而在學習的同時也深深的為我所看到的一些現狀擔憂，正是由于這種擔憂，即便知道自己只是半瓶水，但還是忍不住站出來，東一榔頭、西一棒槌的“晃蕩”幾下，繼續扮演領導眼中一個不明真相的圍觀群眾的角色。

別試圖用底層測試取代頁面測試

測試基礎理論告訴我們：缺陷發現的越早，修復所花的成本越低；所以對于自動化測試來說，如果應用的越早，它的收益就應該越多。所以現在很多公司都在推行集成測試、單元測試的自動化建設，我們也不例外。我們把這些自動化測試工作納入測試部門的日常工作中來，試圖在每日回歸自動化中使用這些測試，而同時測試環境和版本管理非常嚴格，那么這部分的自動化測試執行還是要等到版本一板一眼的把流程走完，部署到測試環境之后才能開始。如此一來，這部分集成測試和單元測試的自動化的執行時間并沒有被提前，和敏捷更是掛不上邊。我們的版本流程清晰的從時間上分開了單元測試、集成和系統測試，也從流程上基本上消滅了在測試環境做非系統功能、性能測試的可能性。所以，如果說要開展以贏得更多效益為目的的底層的自動化測試，還是需要推動編碼人員去實施這部分測試內容或者變革版本流程，做到將底層的自動化測試在開發環境進行運行，達到測試出口之后再進入系統測試階段。

單元測試和集成測試全部通過完成之后是否就意味著本次構建測試就是通過的呢？當然不是。在很多夾雜著復雜業務邏輯的軟件中，復雜的操作場景和數據邏輯的正確性驗證還是要依賴大量的UI層面上的驗證測試。所以對于有些形態（例如金融類）的軟件產品的自動化測試來說，有足夠強大的UI層自動化測試支持也是必需的。早已有很多人已經給底層測試覆蓋的作用蓋棺定論：并不是每一個功能點和每一個分支測試通過就意味著軟件質量是合格的，因為對于不同結構的系統來說，有些程序邏輯很依賴前端，有些程序邏輯更偏向于倚重核心，加上數據的復雜業務特性也不允許我們忽略復雜場景組合帶來的一些新問題。也就是網友所說的“代碼覆蓋只能告訴你什么沒有測試，卻不能告訴你軟件是否通過了有效測試”，正是基于這點，如果傾向于用單元測試或者集成用例測試來豐富自動化回歸測試范圍的話，我們能夠理解；但是如果想用單元測試或者集成測試用例來替代回歸測試中對應的內容，那么就沒有什么意義了。而且筆者提倡如果某個功能如果同時能夠通過頁面和底層去驗證的話，就盡量不要去做底層的測試，至少在非敏捷的項目中或者在測試部門的系統測試工作中，不要去這么做。不知道這種說法是不是顛覆了一些人心中的觀念，且不要急著拍磚，下面我們繼續討論。

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

首先要贊揚Selenium和WebDriver這些開源WEB自動化測試工具的靈活性（注：WebDriver就是基于Selenium的一個自動化測試類庫，但它不再是運行在瀏覽器內的JS程序，而是自己可以控制瀏覽器），這些工具在與大多數測試平臺的整合以及其所支持的腳本語言種類上都有很大優勢（Java、dotNET、Perl、Python、Ruby、C#等）。由于它們是專一的WEB自動化測試工具，它們在處理WEB應用的問題上顯得非常專業，結合一些Hook程序的使用，使得它們的運行速度明顯快于QTP。而同QTP一樣，他們在處理一些第三方插件的時候都需要借助另外的插件和程序，這一點也正好印證了開源工具的特征：為了解決我們需要的需求，可以采取一些額外的手段來協助。不過商業工具也不是就甘心這樣讓出他們的市場的，HP為QTP10.0及以上的版本增加了Extensibility Accelerator組件，專門用來為測試人員自定義開發與發布插件類庫。該組件在其易用性在還沒有被廣泛驗證之前一直顯得比較低調，通過對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米寬的圓環型跑道尋找遺失的物品，無論單次走的是內圈還是外圈，都應該走到頭，否則達成你的目標就只能靠碰運氣了。如果你們在開展大規模的自動化建設，并且你們發現根本無法在跨越目前的瓶頸了，那么可能真的需要嘗試一些新的工具或者框架了。

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

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

#FormatImgID_0#

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

自動化測試平臺的搭建需要考慮其各方面的表現，因為它是一個較為通用的應用程序，故而，它的兼容性和健壯性要求很高。在一個測試組織或者一個公司內部，一般自動化測試平臺應該可以做到通用于所有的系統測試，即便它們所采用的技術乃至理念會有所不同。就像我們通過測試平臺STAF可以實現調度像QTP、SELENIUM這種UI層的自動化測試，也可以完成對JUNIT測試用例的運行調度和管理。而測試結果的分析也可以通過相應的報表系統來完成，按照我們自己的需求，把調度管理和分析管理等其他功能模塊有機組合在一起，形成一個功能較為完整的測試平臺。平臺建設得好，無論是單純的UI層驗證測試還是敏捷測試，我們應該都能夠支持得好。

我們知道，并不是一個自動化測試框架就能夠應用于所有系統的自動化開發，因為被測程序的特點本身就本不相同，即便在同一個公司，也會因不同的開發風格和開發技術而要求有不同的測試方法。所以自動化測試框架雖不需要每個系統單獨開發一套，但是也很難做到用一個框架支持所有系統的測試，最好的辦法就是根據開發技術劃分所需要使用的測試框架種類，例如QTP測試的純WEB型、GUI型和各種插件開發型（如dotNet、JAVA等）。

關于自動化測試平臺和框架的異同等方面，筆者曾在另外一篇自己的學習總結《軟件測試自動化的探索與管理》中曾有過闡述，這里不再贅述。在完成這些基礎建設之后我們才能夠開始我們的大規模的人力投入，來進行針對每一個項目和系統的具體實施，否則如果先后顛倒或者本末倒置，勢必會讓我們面臨糾結的重復建設和開發投入。而另一方面，在自動化測試實施的過程中，我們可能會隨時面臨很多的問題和困擾，但是在解決這些問題之后，我們測試人員的技能又能夠得到提升。在技能提升的前提下，后續又可以進行新的改進和新需求的達成，這是一個循環的過程，也是自動化測試建設本身的持續優化。

從上圖可以看到，這一系列的過程都是圍繞著一個中心進行的，那就是自動化測試的KPI指標。前文曾簡單提到過KPI的導向作用，我們千萬不要小看那么幾組小小的數字，更不要指望測試人員能夠“跳出考核指標，為真理而奮斗”。所以如果我們的指標指向偏離我們的核心目標，那么自動化建設就會被引入誤區，可能產生形式化、教條化甚至作假問題的產生。我們核心的目標是系統可用率和缺陷消除率（在一個分層扁平式管理的大型IT公司里，考核除了依賴對這些基礎的貢獻度的考察，我們還真沒有想到其他更好的辦法，雖然有敏捷思想的沖擊和新考核建議的提出，但是在體制下和運營方式沒有發生大的變化之前，或許只有這種考核方式才能勉強應付用戶的資金投入和期許了），既然缺陷的消除對我們如此重要，那么我們的自動化測試行為就應該圍繞著應可能多的發現應用缺陷這個主題來進行。所以自動化測試的覆蓋率、運行通過率等指標都只是過程中的參考數據，根本不能用來考核自動化的成果，這些指標的作用在自動化測試實施層面上還不如同行專家評審，雖然它們對中高層管理者來說有一定的參考意義。雖然很多人一再強調，UI自動化測試只是用來驗證系統的正常運行，增加測試人員的信心，但是我始終不以為然。如果一個版本周期只在版本即將封版的時候運行一兩次，或許可以這么說；但是自動化測試是可以投入系統測試階段中使用的，至少可以進行基本的冒煙測試執行。如果在自動化應用于冒煙測試卻發現不了缺陷，而手工執行能夠發現一些嚴重問題，那么這個系統的自動化測試程序絕對是不合格的。依托自動化測試管理平臺，我們適當提高運行頻率，通過大面積自動化的頁面操作，一定能夠發現很多問題——如果我們愿意為腳本灌入足夠多的測試數據，愿意在運行結束之后仔細地分析測試結果，那么自動化測試絕對是有產出的。

自動化測試的指標也是可以持續優化的，通過不同階段的現狀，適當調整自動化測試的KPI，用以指導自動化測試工作的開展。筆者認為無論高層的KPI如何定制，但是拆解到自動化測試實施的過程中，就需要更加有可行性并且具備正確的引導作用。例如我們可以考慮采集如下數據進行分析，來判斷的自動化腳本開發的有效性和自動化測試建設對于我們的系統測試的幫助有多少：

a) 腳本評審通過率：通過評審的測試腳本/所有通過開發、調試的測試腳本

b) 腳本同步及時率：在應用缺陷修復之后指定時間內完成的測試腳本數/所有運行失敗腳本數

c) 測試缺陷發現率：通過自動化測試發現的缺陷數/所有系統測試缺陷數

d) 功能選擇活動率：三個月內涉及功能變更的測試腳本數/所有測試腳本數

e) 資源占用超標率：平均運行時間超過手工測試用例平均執行時間的腳本/所有測試腳本數

如是種種，各位不妨結合自己的實際進行參考或者設置，筆者這里只是簡單舉例，并不具備通用性；只是希望大家可以多參與交流、多思考，組織頭腦風暴神馬的都可以，只是千萬不要閉門造車。

結束語

測試人員需要能夠勝任重復性的工作，但是測試人員絕不需要勝任被引導著去重蹈覆轍的行為，自動化測試建設成功與否，完全取決于參與建設的人的素質。本文標題里有個“要”字，是因為筆者認為自動化測試建設的成敗、自動化測試之路走得是否通順完全在人，而并非測試工具等其他外在因素。