第一，自尊心。計算機科班出身的人都喜歡作開發(Dev)。做測試工作經常是身不由己，可是測試工作很多時間不需要編程，于是做測試的人想方設法寫些程序，以顯示自己也會編程。結果往往是欲罷不能，測試自動化程序越寫越多，越寫越復雜。后面我會談談測試自動化框架復雜的代價。
第二，為了出成績。很多測試組為了向管理層展示成績，往往要拿出例如測試自動化達到80%，程序覆蓋率達到90%。要我說，這些都是Bull Shit。就象小平同志說的“實踐是檢驗真理的唯一標準”，我認為在測試中“用戶不出問題是檢驗質量的唯一標準”。自動化做的再多，用戶出了問題，也是白搭。另外，一個人就可以做的測試，自動化往往需要兩個，三個。倒是解決就業的好方法。
我對測試自動化的認識也有一個變化的過程。剛剛入行時也是很相信自動化，想方設法寫一些從頭到尾自動化的框架，覺得自動測試很過癮。到微軟的Portal Media Center組后也是和另外兩個人做了一個相當復雜的用戶界面的自動測試。其實現在想想，用自動測試發現的問題基本上可以一個人用手工測試完成，最多寫些簡單的測試輔助工具就可以完成。有些人可能會說自動化可以為產品的下一個版本節省測試時間。其實Portal Media Center 下一個版本出來時，所有戶界面完全變了，80%以上的自動測試程序都需要改動。做完第一個版本，我們三個人全都走掉了。后面來的人往往寧可自己再寫一套，也懶得改以前人的程序。自動化的浪費就是這樣造成的。想說服別人用你開發的自動測試框架是很難的，所有人都想另搞一套。
下面分幾點講講為什么要放棄對測試自動化的幻想，和怎樣進行低成本的有效測試。如果你還不能同意我對測試自動化的看法，可以去微軟員工的Blog看看為什么Windows測試組用的WTT測試框架被稱作“Waste of Tester Time"。我最基本的觀點不是說測試自動化不能測出bug，而是想問：一個比較復雜的測試自動化框架所造成的人力浪費，值不值得最終的結果?如果不做測試自動化，能不能達到同樣的效果。以我的親身經歷，去年我的測試組兩個人對應開發組五個人，項目經理三個人的工作量，去年做了好幾個Release，Hotfix只有兩三個。我們旁邊的測試組七八個人對應五六個Dev。他們又是自動化，又是搞程序覆蓋率，好不熱鬧，Hotfix 也不少。按一個人的人工成本12萬美元，我們組省至少三個人的成本36萬美元。
第一，不要指望自動化能幫你找bug。軟件bug和生物的bug很像，測試的規律是bug少的地方bug越少，bug多地方越找越多。做測試自動化，往往在開發自動化的時候，該發現的bug就發現了。自動化開發完成，再想發現更多bug就很難了。這是無論你怎樣跑你的自動化，也不會發現新的bug。
第二，不要指望自動化對Regression Test的測試的貢獻。軟件的特點是如果一次做對了，以后永遠不會出錯。當程序出現變動時，只要針對變動的部分測試就可以了，以前測過的東西，如果和變動沒有關聯就不會出錯。相反如果，程序出現很大變化，自動化可能完全不能用了。
第三，自動化不如測試工具加手工測試。我不建議測試人員作全面自動化，相反我建議測試人員多做小巧靈活的測試工具。自動化往往需要自動判Pass或Fail。 很多東西是動態產生的，你很難確認所有的內容的正確性。如果你自己用這個產品手工做個頁面，用肉眼很容易判斷所有相關和不相關的內容生成的正確性。我就是用這個方法在工作中發現了網頁上誰也想不到的bug, 如果用自動化很難在測試階段發現這個bug。
第四，軟件項目的生命周期就定了自動化的無用�，F在很多網絡應用項目的生命周期都很短，一個項目從生到死不過兩三年。死的定義是項目進入Sustain Engineering維持狀態。自動化原來的一個主要目的是使軟件測試的未來階段越來越容易，成本越來越低�？墒钱斠粋�項目死掉了，自動化還有什么用。而且最新的敏捷開發，軟件的要求，程序，接口，界面在不斷變化，自動化怎么可能跟得上變化。與其去搞自動化，不如多理解變化，直接測試變化的東西。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
