先說說為什么做測試的人喜歡搞自動化。
第一，自尊心。計算機科班出身的人都喜歡作開發(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".
omomo
有需求才會有程序.測試自動化也是. 樓主是一個很有分析能力的測試人員,而且編程能力也不弱,所以才說出讀程序+測試小工具+測試的經驗.但你這樣的牛人仍然只能保證你的模塊的質量,如果我們需要讓你保證更多的人的模塊的質量,總歸要從自動化測試上面來打主意了.否則你的這種測試經驗沒有辦法容易的被人拷貝學習.而你的測試代碼是很容易被人拷貝學習的.呵呵
所以一種情況是,你想出來的測試用例,可以利用自動化測試框架自動運用到各個模塊中去.比如,你想出來界面上不能有重復的hotkey,那么一個好的自動化測試框架應該允許你迅速把這類測試用例運用到各個UI上去測試.
另外一種情況是,人沒有辦法做的,比如并發的壓力測試,像gamerrob提到的那種.
其次說到,regression test,我覺得也是有用處的:"軟件做對了一次,以后就永遠不會錯?", 這話說得太離譜,很多看似沒有關聯的改動,往往會導致隱藏的bug的出現,有一個完整的自動化測試集的好處是,至少當你的開發人員改動了基類或者基本底層API的時候,可以通過運行上層功能的自動化測試集保證改動沒有破壞功能.否則,難道他的改動要求所有測試人員把所有功能手工的全部跑一便?光協調通知各個測試組,恐怕就得花一周時間.
自動化測試的分工本來就是慢慢將寫自動化測試工具的人和手工測試的人分開,難道樓主以為寫VS里面的webtest工具和code coverage不需要時間,不值得做?手工測試將慢慢外包,而公司培養的自動化測試工程師將通過積累和篩選,最終有些人會去主導那些重量級測試工具的開發. 這和程序員也沒有什么區別. 微軟的程序員,也有寫簡單的代碼,基本屬于把人家基類的接口實現一下的. 也有真正牛比的大師.只不過在不同的職業階段.
樓主有一個觀點,我非常認同:理解產品,找到缺陷才是測試人員的本質.任何時候,沉浸在自動化測試中的人,都不是合格的測試人員.所以在我的團隊里,我把理解產品功能放在編程能力之上.只有一個非常理解產品功能知道用戶會怎么用這個產品的人,才能寫出有效的測試用例.樓主說的很好:不懂內部程序的人，可能會設計三十個test cases, 才能找到一個bug. 懂程序的人每個test case都可能發現一個或多個bug.
發表時間：2007-07-17 16:46:29 4 樓：peking2toronto 駁斥）迷信自動化是測試人員的誤區 （1）
今天七月四號美國國慶節，有時間坐下來總結一下過去幾年在微軟的測試經驗，談談對測試自動化的看法。
[comments]今天看到這篇關于自動化測試的文章，有很大的誤導作用，我也談一下對自動化測試的看法。首先，作者是一個在微軟工作了幾年的一個測試人員，總結的是在微軟的測試經驗�？墒撬偨Y的并不是典型的微軟公司的測試觀點，而是自己個人的測試觀點。因此，他的觀點實際上是與微軟公司沒有太大關系的。這點，大家還是不要被誤導。眾所周知，微軟在幾年前對測試有一個大的改變。以前微軟有兩種職位，STE和SDET，前者是手工測試，后者是自動化測試。微軟把STE基本cut掉了，因此STE要不走人，要不轉SDET。轉過來的，因為以前主要是手工測試，因此就對自動化測試產生很大的抵抗情緒。這種情緒是team lead很不愿意看到的。因此，STE的困境是比較大的。還有就是在微軟里做幾年如一日的測試人員大有人在，因為能力問題，級別得不到提升。因此，幾年還是junior。所以，在微軟做幾年測試，也不代表就是一個級別很高的人。
另外要說明一點，從文章的title里可以看到，這篇文章是說給迷信自動化測試人員的。作者以前本身就是一個迷信自動化測試的人，可是后來從迷信變得不相信自動化測試了�？梢娮髡呤且粋�很容易走極端的人，從頭到尾都沒有用一個公平理性的態度去面對自動化測試。還有就是，這個文章如果給迷信自動化測試的人看，還是有一定意義的�？墒�，我們當中有幾個人像作者以前那樣迷信自動化呢？大部分看了可能會覺得是針對整個自動化來講的，而且作者確實也偏離了他的title，因此我也需要澄清一下。
先說說為什么做測試的人喜歡搞自動化。
第一，自尊心。計算機科班出身的人都喜歡作開發(Dev)。做測試工作經常是身不由己，可是測試工作很多時間不需要編程，于是做測試的人想方設法寫些程序，以顯示自己也會編程。結果往往是欲罷不能，測試自動化程序越寫越多，越寫越復雜。后面我會談談測試自動化框架復雜的代價。
第二，為了出成績。很多測試組為了向管理層展示成績，往往要拿出例如測試自動化達到80%，程序覆蓋率達到90%。要我說，這些都是Bull Shit. 就象小平同志說的“實踐是檢驗真理的唯一標準”，我認為在測試中“用戶不出問題是檢驗質量的唯一標準”。自動化做的再多，用戶出了問題，也是白搭。另外，一個人就可以做的測試，自動化往往需要兩個，三個。倒是解決就業的好方法。
[comments]我想作者漏掉了一個最重要的方面，那就是自動化可以解決我們的測試問題。兩個方面，一是自動化可以完成手工不能完成的任務，二是自動化可以替代手工重復的勞動。這才是我們搞自動化最重要的原因。關于自尊心的問題是有的�？墒亲髡呓忉尩暮孟穸疾辉诶�。計算機科班出身的人都喜歡做開發？這個觀點從何而來？計算機出身的人可以做開發，測試，dba，support，銷售，市場，自己創業。各種工作都有可能，怎么能說都喜歡做開發呢？以我的個人經驗來看，喜歡做開發的是少數。做測試經常是身不由己？我認為做開發也很多是身不由己。測試工作很多時間不需要編程？開發人員很多時間也不需要編程。后邊的就不說了�？傊�，給人的感覺都是作者的心理。好像作者自己喜歡做開發，身不由己作了測試，發現不需要什么編程，然后就想方設法寫程序，以顯示自己也會編程，結果出了大問題了。這里可以提供兩點信息，一是作者想做開發沒有做成�？梢娮髡叩拈_發能力有限，老板不給提供這個機會，因為老板是要給產品負責的。還有就是，做了幾年的程序，而且一直想轉開發而轉不過去的話，我真的不能suppose他水平有多高了。另外就是，把自己的心理，心態，引申到整體，不是很有道理。
用戶不出問題是唯一標準？你可以認為它是一個標準，可是你怎么衡量？用戶，半年不出問題，一年不出問題，還是五年不出問題，永遠不出問題？還有就是，難道只能在用戶的使用上才能衡量一個軟件的質量嗎？我們做測試的首要目的就是在用戶拿到產品之前就要保證好產品的質量。難道，自動化測試，程序覆蓋率不是實現這個目標的解決方法嗎？一個人做的測試，自動化需要兩，三個。這又是從何而來？以我的經驗，三四個人的測試，我一個人做自動化就可以完成了。我前不久的工作成績就是，本來需要3個星期手工測試的，經過我的自動化，變成1個星期完成了。也就是說，本來需要三個手工測試人員，現在只需要一個自動化測試人員了。還有就是，我們的軟件需要在不同平臺下，不同環境下測試，沒有自動化怎么行？比如，我們要在2000，XP，XP+sp1,XP+sp2, 2003, 2003+sp1，2003+sp2,vista。這還不包括，這種cpu，windows的不同版本呢。手工測試得需要多少人呢？
發表時間：2007-07-17 16:46:59 5 樓：peking2toronto (駁斥）迷信自動化是測試人員的誤區 （2）
[comments]在進行第二部分的時候，我想簡單說一個問題。以我個人的看法，功能測試根據被測試對象主要可以分三種類型：UI測試，Command line測試和API測試。我認為后兩部分是非常適合用自動化來作為主要方法進行測試的。作者只是提到了UI自動化，然后就推廣到整個的自動化。我認為這不是很reasonable的。如果誰要是認為API和command line的測試不適合自動化，我們可以單獨討論。不過這里，我們就要把topic nail down了。我們只談UI的自動化。如果我們要談整個的自動化，作者的觀點一下子就錯了，沒必要繼續談下去了。
我對測試自動化的認識也有一個變化的過程。剛剛入行時也是很相信自動化，想方設法寫一些從頭到尾自動化的框架，覺得自動測試很過癮。到微軟的Portal Media Center組后也是和另外兩個人做了一個相當復雜的用戶界面的自動測試。其實現在想想，用自動測試發現的問題基本上可以一個人用手工測試完成，最多寫些簡單的測試輔助工具就可以完成。有些人可能會說自動化可以為產品的下一個版本節省測試時間。其實Portal Media Center 下一個版本出來時，所有戶界面完全變了，80%以上的自動測試程序都需要改動。做完第一個版本，我們三個人全都走掉了。后面來的人往往寧可自己再寫一套，也懶得改以前人的程序。自動化的浪費就是這樣造成的。想說服別人用你開發的自動測試框架是很難的，所有人都想另搞一套。
[comments] 作者在自動化過程中發現的問題，和犯下的錯誤是初學自動化的人很容易出現的。剛開始的時候，很多人都想把自己的自動化做的多么fancy,想100%的automation.把目標定得很高，結果又相差很大。因此，就動搖了自動化的信心。我做自動化總是強調的一點是，“怎樣合理的進行自動化？”。什么應該自動化，什么不應該自動化，怎樣進行自動化，這都是有一定學問的，也是一個senior測試人員應該具備的基本能力。因為作者的能力問題，使得后來的測試人員不愿意用他們的代碼，寧可另起爐灶。這完全不能說明自動化有什么不好的。你想想看，如果你設計，實現了一套非常好的，非常靈活的自動化系統，后來的人很輕松的能夠上手，他為什么還要自己重新來過呢？以我個人的經驗來看，想另起爐灶的最根本的原因是因為以前人留下的代碼太濫了。這個不光測試有這個問題，開發中同樣普遍。我設計的自動化框架，到我辭職后一年還沒有替代品的出現，大家都是在我的基礎上進行新的開發和利用，以及擴展。這又說明了什么？我從來沒有試圖去說服別人一定要用我的。好的東西，別人一定會看到的。
下面分幾點講講為什么要放棄對測試自動化的幻想，和怎樣進行低成本的有效測試。如果你還不能同意我對測試自動化的看法，可以去這個微軟員工的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萬美元。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
