軟件功能自動化測試工具給我們帶來了什么及來自微軟討論組的爭論

首先說說為什么做測試的人喜歡搞自動化。

第一，自尊心。計算機科班出身的人都喜歡作開發(Dev)。做測試工作經常是身不由己，可是測試工作很多時間不需要編程，于是做測試的人想方設法寫些程序，以顯示自己也會編程。結果往往是欲罷不能，測試自動化程序越寫越多，越寫越復雜。后面我會談談測試自動化框架復雜的代價。

第二，為了出成績。很多測試組為了向管理層展示成績，往往要拿出例如測試自動化達到80%，程序覆蓋率達到90%。要我說，這些都是Bull Shit. 就象小平同志說的“實踐是檢驗真理的唯一標準”，我認為在測試中“用戶不出問題是檢驗質量的唯一標準”。自動化做的再多，用戶出了問題，也是白搭。另外，一個人就可以做的測試，自動化往往需要兩個，三個。倒是解決就業的好方法。

我對測試自動化的認識也有一個變化的過程。剛剛入行時也是很相信自動化，想方設法寫一些從頭到尾自動化的框架，覺得自動測試很過癮。到微軟的Portal Media Center組后也是和另外兩個人做了一個相當復雜的用戶界面的自動測試。其實現在想想，用自動測試發現的問題基本上可以一個人用手工測試完成，最多寫些簡單的測試輔助工具就可以完成。有些人可能會說自動化可以為產品的下一個版本節省測試時間。其實Portal Media Center 下一個版本出來時，所有戶界面完全變了，80%以上的自動測試程序都需要改動。做完第一個版本，我們三個人全都走掉了。后面來的人往往寧可自己再寫一套，也懶得改以前人的程序。自動化的浪費就是這樣造成的。想說服別人用你開發的自動測試框架是很難的，所有人都想另搞一套。
接下來我先以我的多年工作經驗來說一下有關功能自動化測試工具的詳情吧。
功能自動化測試工具給我們帶來了什么?我不知道大家如何看待這個問題，我總覺的很多人把功能的自動化測試工具看的特別的“厲害”，覺得可以完成很多的工作。領導會說，如果我們用工具進行回歸測試，會很快的發現問題，然后減少回歸測試的時間，提高項目的效率，如此這般公司開始推行自動化工具。

　　幸運的，我開始成為自動化工具的推廣者，曾經用過自動化測試工具selenium進行簡單的自動化測試，因為項目是多省系統，進行系統測試時，重復內容比較多，但是程序又相對穩定。于是在測試的間隙，完成自動化測試腳本，在系統測試中運行測試。效果還是比較好的，現在想想當時的腳本真的是非常脆弱而且是簡單的，沒有任何的控制語句，場景回復，腳本的維護量比較大，一旦出現問題，腳本跑不通，只能人工排查原因，自動化測試的部分只在系統測試中站系統測試百分之五十的工作量，但是在整個測試的工作量中百分之十都不到，大家仿似看到此時自動化測試的甜頭，希望在整個公司中推廣自動化測試工具，覺得自動化測試是一種趨勢，一種必然，于是我站在風頭浪尖開始試著完成這項工作。

　　自動化測試同手工測試一樣，都需要有一個計劃，測試的覆蓋率，評估自動化測試工具是否能帶來收益來確定測試的內容，其實，并不是所有項目都適合自動化測試工具的，如果項目周期短，是不適宜做自動化測試的，自動化測試雖然在運行中比較省時間，但是在前期的設計，腳本的編寫和維護都會浪費較多的時間，如果自動化測試腳本不能重復利用多次，自動化對于我們只是一種時間的浪費，只會令整個項目延期。如果你要用qtp這種識別gui屬性的工具必須要等待頁面功能穩定以后才能進行自動化腳本的設計，因為任何一個控件的修改都會導致自動化工具不能識別控件。其次，自動化和手工測試都需要完成用例的設計，手工測試用例有相應的輸入輸出，自動化腳本也需要，最好能參數化進行。

　　自動化測試是否能代替手工測試呢?多少人重復的問這這個問題，答案是不能，自動化測試最大的用處是保證測試的質量，而不是發現問題，而手工測試是發現問題。因為我們每次的回歸測試，如果是手工測試的情況由于時間的關系并不能因為一個模塊的bug，去測試其他的模塊，而自動化測試工具的加入，可以保證所以模塊的基本功能，每次回歸用手工去發現驗證問題，用自動化工具去保證整個軟件的基本功能正常運行，自動化的推廣是逐步的，首先做一些冒煙測試的自動化，隨后把一些主要的功能和測試點也加進來，但是千萬不要太細化，到所有手工測試的點，這樣，會帶來很大的風險，自動化程度越高，風險將越大。

　　自動化的另外一個注意點就是管理，引入一項內容，必然就需要花一定的時間對引入的內容做管理，例如用td管理工具，一定有相應的說明文檔，使他不依賴于某個人，以至于某個人的離職不會對自動化工作造成太大的打擊。