軟件測試中對測試自動化的看法－來自微軟討論組的爭論
自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計了測試用例并通過評審之后，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，為了節省人力、時間或硬件資源，提高測試效率，便引入了自動化測試的概念。
先說說為什么做測試的人喜歡搞自動化。
第一，自尊心。計算機科班出身的人都喜歡作開發(Dev)。做測試工作經常是身不由己，可是測試工作很多時間不需要編程，于是做測試的人想方設法寫些程序，以顯示自己也會編程。結果往往是欲罷不能，測試自動化程序越寫越多，越寫越復雜。后面我會談談測試自動化框架復雜的代價。
第二，為了出成績。很多測試組為了向管理層展示成績，往往要拿出例如測試自動化達到80%，程序覆蓋率達到90%。要我說，這些都是Bull Shit. 就象小平同志說的“實踐是檢驗真理的唯一標準”，我認為在測試中“用戶不出問題是檢驗質量的唯一標準”。自動化做的再多，用戶出了問題，也是白搭。另外，一個人就可以做的測試，自動化往往需要兩個，三個。倒是解決就業的好方法。
我對測試自動化的認識也有一個變化的過程。剛剛入行時也是很相信自動化，想方設法寫一些從頭到尾自動化的框架，覺得自動測試很過癮。到微軟的Portal Media Center組后也是和另外兩個人做了一個相當復雜的用戶界面的自動測試。其實現在想想，用自動測試發現的問題基本上可以一個人用手工測試完成，最多寫些簡單的測試輔助工具就可以完成。有些人可能會說自動化可以為產品的下一個版本節省測試時間。其實Portal Media Center 下一個版本出來時，所有戶界面完全變了，80%以上的自動測試程序都需要改動。做完第一個版本，我們三個人全都走掉了。后面來的人往往寧可自己再寫一套，也懶得改以前人的程序。自動化的浪費就是這樣造成的。想說服別人用你開發的自動測試框架是很難的，所有人都想另搞一套。
下面分幾點講講為什么要放棄對測試自動化的幻想，和怎樣進行低成本的有效測試。如果你還不能同意我對測試自動化的看法，可以去這個微軟員工的Blog http://minimsft.blogspot.com/2006/08/dev-vs-test-vs-pm.html 去看看為什么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. 想想你如果測試用于生成www.microsoft.com的頁面的產品，你如何判斷頁面框架生成的正確？很多東西是動態產生的，你很難確認所有的內容的正確性。如果你自己用這個產品手工做個頁面，用肉眼很容易判斷所有相關和不相關的內容生成的正確性。我就是用這個方法在工作中發現了網頁上誰也想不到的bug, 如果用自動化很難在測試階段發現這個bug.
第四，軟件項目的生命周期就定了自動化的無用�，F在很多網絡應用項目的生命周期都很短，一個項目從生到死不過兩三年。死的定義是項目進入Sustain Engineering維持狀態。自動化原來的一個主要目的是使軟件測試的未來階段越來越容易，成本越來越低�？墒钱斠粋�項目死掉了，自動化還有什么用。而且最新的敏捷開發，軟件的要求，程序，接口，界面在不斷變化，自動化怎么可能跟得上變化。與其去搞自動化，不如多理解變化，直接測試變化的東西。
如何進行有效測試？
第一，測試人員的自信心可以建立在讀程序的能力上。在一個項目中，開發人員的工作是研究新技術，寫出最好的程序。測試人員應該在開發人員研究的基礎之上，更好的理解新技術，讀懂程序�？炊绦蚩梢允箿y試工作非常高效。不懂內部程序的人，可能會設計三十個test cases, 才能找到一個bug. 懂程序的人每個test case都可能發現一個或多個bug. 我有30%的bug都是讀程序讀出來的。由于對開發人員的程序有很深的理解，即使release后出了問題，也能很快理解問題出在什么地方，是否是bug.
第二，測試人員寫測試程序的時間應該盡量最小化。測試人員測試的時間分配應該是, 30%讀程序，20%寫測試程序，50%寫Test Cases和運行Test Cases. 好的測試員的工作重點應該放在理解要求，理解客戶需要，思考在什么條件下程序會出錯，而不是思考如何去自動化。如果時間都放在設計自動化上了，必然會影響測試，分散測試資源。測試人員應該邊讀程序邊測試，讀程序幫助找到好的Test Case，測試幫助驗證理解和猜測。
第三，測試人員要學會討價還價。很多時候項目經理，開發人員搞得東西不是客戶馬上需要的，或許是永遠用不到的。測試人員可以和項目經理研究先測什么，后測什么，那些不測。比如，我做的一個項目，我發現30%的功能是現在用處不大，所以我直接告訴項目經理那些東西我不會去測的。事實證明，這樣做節省了很多人力。
第四，測試人員要多花時間參與設計。測試人員一定要緊跟項目經理和開發人員的要求變化和設計。理解每一個要求的影響。在每個項目周期中，去比較當前版本和以前版本的所有程序變化。重點測試變化。
總之，少做自動化，多寫小工具，讀懂程序，是高效省錢的測試方法，除非你錢多得沒地方花。下次有誰建議搞什么測試自動化構架，告訴他"That is bullshit".
文章來源于領測軟件測試網 http://www.kjueaiud.com/
