先說說為什么做測試的人喜歡搞自動化。
第一，自尊心。計算機科班出身的人都喜歡作開發(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萬美元。
[comments] 作者自己在自動化中出現了很多問題之后，并不是積極地想辦法去解決這些問題，而是消極地放棄了自動化測試，實在是令人感到可惜。要知道，發現問題是最能提高人的能力的時候，你把這些問題解決了，你的水平，能力，經驗就相應的得到了提高。并且，作者從一個極端走到另一個極端以后，就想方設法找一些證據來支持自己的觀點。比如，通過微軟員工的blog。一個員工blog里的觀點能證明什么呢？你有沒有去問過windows 測試組對WTT的觀點呢？別人一說，你就相信？可以看出作者不是一個嚴謹的人，吸收東西總是從自己的思想角度出發，而沒有經過驗證。作者在自動化過程受到挫折后，竟然與當今測試的發展背道而馳，實在是令人費解。
作者的問題是，一個復雜自動化框架值不值得去做？如果不做自動化，能不能達到同樣效果。從這里我們又一次看到了作者走了極端。復雜的自動化不值得做，就要拋棄自動化。首先，我不想辯論到底什么是復雜的自動化，是它本身復雜，還是你自己給搞復雜了。這里我假設，它不值得做�？墒�，這樣就拋棄自動化嗎？我的問題是，如果復雜的自動化不值得做，那么相對簡單的自動化值不值得做？合理的自動化值不值得做？是不是一定就要拋棄自動化？接下來，作者用自己的經歷來說明，自動化沒有必要，并且和其他的team進行了比較。從數據上看，好像自動化測試真的不如他的手工測試。我想這種比較意義不大，因為我可以給你舉出更多的例子，自動化比手工測試效果好。并且，你hotfix少也不能說明什么，說不定你要用合理的自動化，都沒有hotfix呢。別人如果不用自動化，hotfix更多呢。產品不一樣，都很難進行公平比較。另外，既然公司給他們配備了更多的測試，本身就說明了其他組的項目復雜度比較高。你們少的測試，說明了復雜度比較低。最后質疑一下工資成本，12萬美金的年薪？你真有那么多嗎？如果是的話，也不代表普遍的測試人員的工資。不知道你這個數字從何而來？如果你拿著這么高的年薪而不能搞定自動化的一些基本問題，那么我還有點為你擔心了。
發表時間：2007-07-17 16:47:24 6 樓：peking2toronto (駁斥）迷信自動化是測試人員的誤區 （３）
第一，不要指望自動化能幫你找bug. 軟件bug和生物的bug很像，測試的規律是bug少的地方bug越少，bug多地方越找越多。做測試自動化，往往在開發自動化的時候，該發現的bug就發現了。自動化開發完成，再想發現更多bug就很難了。這是無論你怎樣跑你的自動化，也不會發現新的bug.
[comments]我承認大部分的ｂｕｇ都是通過手工測試來找到的，我也相信很少會有人把找ｂｕｇ完全依賴于自動化�？墒�，你也提到了，在開發自動化的過程中，該發現的ｂｕｇ就發現了。這也就是說，如果沒有開發自動化，這些ｂｕｇ還未必能被發現。這里邊的意思就是，自動化開發完了，可能找不到什么ｂｕｇ，可是在開發過程中還是對找ｂｕｇ做出了貢獻。我們總是說要注重過程，因此從過程來說，自動化對找ｂｕｇ還是有它的必要性．對于作者后面的問題，我得先說說什么是自動化測試的目的了（在找ｂｕｇ方面）．我們知道，很多模塊是要跟其他模塊來合作工作的，即使你自己的模塊沒有任何變動，也有可能因為其他模塊的變動被ｆａｉｌ掉。比如最近的Ｎｏｒｔｏｎ的問題。Ｗｉｎｄｏｗｓ的ｕｐｄａｔｅ引致了Ｎｏｒｔｏｎ的誤報。因此，自動化測試的非常重要的一個目的就是保證沒有ｒｅｇｒｅｓｓｉｏｎ的問題。也就是說，我們不指望ａｕｔｏｍａｔｉｏｎ找到新的ｂｕｇ，可是以前能夠ｗｏｒｋ的一定要保證繼續ｗｏｒｋ。我工作過不少公司，很多產品都是一天一個ｂｕｉｌｄ，請問沒有ａｕｔｏｍａｔｉｏｎ的話，你怎么能夠手工的運行一遍你的ｃａｓｅ呢？而且，每天運行一遍的話，你煩不煩呢？
還有就是，作者說的不會發現新的ｂｕｇ還是太絕對了。我的自動化可是發現了不少新ｂｕｇ呢。有的是因為開發人員改動代碼造成的，有的是因為其他ｔｅａｍ的模塊發生變動造成的。有的是測試工具本身的ｂｕｇ造成的�？傊@種各樣，并且每種問題，我都是要報ｂｕｇ的。最后，無論對自己的ｔｅａｍ還是其他的ｔｅａｍ都做出了自動化測試的貢獻。
第二，不要指望自動化對Regression Test的測試的貢獻。軟件的特點是如果一次做對了，以后永遠不會出錯。當程序出現變動時，只要針對變動的部分測試就可以了，以前測過的東西，如果和變動沒有關聯就不會出錯。相反如果，程序出現很大變化，自動化可能完全不能用了。
[comments]我想這種觀點也不需要我反駁了吧？任何有個有一定測試經驗的人很難說出這種話來。這里邊每一句話都是錯的，如果有人提出不明白，我再來解釋。這里我假設大家都清楚怎么回事。
第三，自動化不如測試工具加手工測試。我不建議測試人員作全面自動化，相反我建議測試人員多做小巧靈活的測試工具。自動化往往需要自動判Pass或Fail. 想想你如果測試用于生成www.microsoft.com的頁面的產品，你如何判斷頁面框架生成的正確？很多東西是動態產生的，你很難確認所有的內容的正確性。如果你自己用這個產品手工做個頁面，用肉眼很容易判斷所有相關和不相關的內容生成的正確性。我就是用這個方法在工作中發現了網頁上誰也想不到的bug, 如果用自動化很難在測試階段發現這個bug.
[comments]又一次以一個例子引申到整體自動化�？赡苣愕倪@個例子沒有什么問題，可是根據這個例子，我實在不能得出自動化不如測試工具加手工測試的結論。還有就是多做小巧靈活的測試工具？這個最好能具體談談。什么是多做？什么是小巧？什么是靈活？作者從一個自動化工程師發展到現在用肉眼來測網頁，還拿著１２萬美金的年薪，我實在是懷疑作者的測試發展軌跡了。這個工資應該是很ｓｅｎｉｏｒ的了，怎么還在肉眼測網頁呢？這種工作在ｇｏｏｇｌｅ是最低級的。都是合同工來做，根本不可能那么高人工。
第四，軟件項目的生命周期就定了自動化的無用�，F在很多網絡應用項目的生命周期都很短，一個項目從生到死不過兩三年。死的定義是項目進入Sustain Engineering維持狀態。自動化原來的一個主要目的是使軟件測試的未來階段越來越容易，成本越來越低�？墒钱斠粋�項目死掉了，自動化還有什么用。而且最新的敏捷開發，軟件的要求，程序，接口，界面在不斷變化，自動化怎么可能跟得上變化。與其去搞自動化，不如多理解變化，直接測試變化的東西。
[comments]又一次從網絡應用的生命周期短，引申到了整個的軟件項目。ｗｉｎｄｏｗｓ存活多少年了？Ｏｆｆｉｃｅ多少年了？有沒有死掉？就算是網絡應用，Ｇｏｏｇｌｅ�。樱澹幔颍悖瓒嗌倌炅�？有沒有死掉？Ｇｏｏｇｌｅ的界面這么多年變化也不大吧？可能你做了一些項目很快死掉，但是不能代表整個的軟件行業。軟件的要求，程序，接口，界面在不斷變化？我真懷疑當初是怎么設計的？如果這樣的話，你手工也沒法測。這個問題好像不是自動化測試的問題，而是產品設計的問題吧？
發表時間：2007-07-17 16:47:41 7 樓：peking2toronto (駁斥）迷信自動化是測試人員的誤區 （４）
第一，測試人員的自信心可以建立在讀程序的能力上。在一個項目中，開發人員的工作是研究新技術，寫出最好的程序。測試人員應該在開發人員研究的基礎之上，更好的理解新技術，讀懂程序�？炊绦蚩梢允箿y試工作非常高效。不懂內部程序的人，可能會設計三十個test cases, 才能找到一個bug. 懂程序的人每個test case都可能發現一個或多個bug. 我有30%的bug都是讀程序讀出來的。由于對開發人員的程序有很深的理解，即使release后出了問題，也能很快理解問題出在什么地方，是否是bug.
[comments]讀程序也算是測試人員的一個基本技能了．可是沒有任何理由說讀程序就能代替自動化測試呀．我承認讀程序是一個非常好的測試方法，可是我們更需要其他好的方法來對軟件進行全面的測試．自動化測試難道不是其中一種嗎？通過一種測試方法來貶低另外一種，不是很客觀和有意義．
第二，測試人員寫測試程序的時間應該盡量最小化。測試人員測試的時間分配應該是, 30%讀程序，20%寫測試程序，50%寫Test Cases和運行Test Cases. 好的測試員的工作重點應該放在理解要求，理解客戶需要，思考在什么條件下程序會出錯，而不是思考如何去自動化。如果時間都放在設計自動化上了，必然會影響測試，分散測試資源。測試人員應該邊讀程序邊測試，讀程序幫助找到好的Test Case，測試幫助驗證理解和猜測。
[comments]我們今天的主題本來是在討論自動化測試方面,你現在卻跳到了白盒測試方面。我想白盒測試可以單獨作為一個ｔｏｐｉｃ來討論。還是那句話，用一種測試方法來貶低另外一種，沒有意義，也沒有說服性。畢竟大家搞自動化大多數都是從黑盒測試的角度出發的。
第三，測試人員要學會討價還價。很多時候項目經理，開發人員搞得東西不是客戶馬上需要的，或許是永遠用不到的。測試人員可以和項目經理研究先測什么，后測什么，那些不測。比如，我做的一個項目，我發現30%的功能是現在用處不大，所以我直接告訴項目經理那些東西我不會去測的。事實證明，這樣做節省了很多人力。
[comments]這不是偷工減料嗎？用戶不用為什么還要設計呢，還要實現呢？你應該在設計階段就進行質疑。對用戶的需求方面是項目經理的責任。你的目的是監督項目經理的工作。如果你認為這些東西沒用，應該在設計階段就ｃｕｔ掉。而不是等到測試階段才發現，并且不進行測試。你現在沒有節約成本，你浪費了很多ｐｍ和ｄｅｖ的時間，加大了他們的成本開銷。你現在是拿ＰＭ的錯誤來跟他們討價還價，他們也沒辦法。但是，作為一個優秀得測試人員，最好的辦法還是應該在設計階段發現這些問題。還有就是，既然已經實現了，如果你不進行測試，里邊的風險是很大的，是絕對的不應該的。這里我不想多講，因為道理還是很簡單的。如果有人不明白我再解釋？
第四，測試人員要多花時間參與設計。測試人員一定要緊跟項目經理和開發人員的要求變化和設計。理解每一個要求的影響。在每個項目周期中，去比較當前版本和以前版本的所有程序變化。重點測試變化。
總之，少做自動化，多寫小工具，讀懂程序，是高效省錢的測試方法，除非你錢多得沒地方花。下次有誰建議搞什么測試自動化構架，告訴他"That is bullshit".
[comments]不想多說了，自己自動化不行，別說臟話。你要是參與了設計，怎么還出現了第三里面的問題呢？
最后想說的是，這個作者的觀點絕對不代表著微軟的觀點。作為前輩傳授經驗是好事，不過千萬不要誤導。作為晚輩學習前輩的經驗也不要全盤接受，要學會思考，有自己的理解和ｉｄｅａ。
發表時間：2007-07-18 13:41:30 8 樓：dlele
寫了這篇文章，惹得有些人很生氣，后果很嚴重。所以再寫一些，闡明我的一些觀點。首先要說的就是歡迎大家的爭論，其次我當然不代表微軟的觀點J 其實我想微軟對我討論的問題也沒有什么官方觀點。學術問題本來就是應該各抒己見。我只是想談談我個人對自動化的感覺，至于感覺是否科學，大家可以批評。但測試本身就是Art，還不是科學（這話不是我發明的，是書上說的。）
有人質疑我的能力和Credibility，首先我做SDET有六年了，之所以寫這篇文章就是想總結一下有效測試的經驗。反思一下為什么近三年自動化做得少了，反而工作成效大了。另外，我的工作涉及網絡安全認證與授權，是公認相當復雜的項目。為什么我們可以較少的人力比較出色地完成項目。所謂出色，我認為我們做到了PM和Dev的雙滿意。
測試人員和PM, Dev的關系。測試人員最直接的打交道的人是PM和Dev。相對而言，測試人員較少和客戶直接打交道。當然，PM滿意應該和客戶滿意是一致的。PM和Dev關心測試自動化嗎。No！PM 最關心是進度，其次是質量。Dev有幾類，有一類最高興的就是測試的人別找他們麻煩，當然測試人員的工作就是找他們的麻煩。還有一類比較通情理，知道測試人員是在幫助他們把工作做好。當然，bug找得少，產品在用戶出問題，Dev會覺得測試人員的工作不夠。所以Dev首先討厭測試人員做無用功，效率不高。其次，Dev最討厭的就是測試人員亂挑毛病。就像針灸一樣，如果扎得不是地方，只會惹人煩。如果一針扎到病灶，Dev會很滿意。所以Dev關心的并不是測試人員否是搞了自動化，只要能找到問題。黑貓白貓，抓到耗子就是好貓。
什么是自動化我定義的自動化是指較大的框架。舉例說，如果你要測一個API，這個API的其中一個參數是C# String，如果有必要測很多不同的Unicode值，當然寫個程序測最快，最可靠。另外Stree/Performance測試都要寫程序。我覺得這個不叫自動化，這是SDET的基本功。我也反對沒有必要的自動化。比如，有些測試要檢驗Event Log的內容，有些人把.NET中讀Event Log的庫函數再打包寫個自動化庫，認為這樣把原來需要五行完成的動作一行完成很酷。其實，你想想自動化庫帶來的維護問題比解決的問題還多。本來，.NET的文檔很清楚，你的自動化庫文檔又不全，出了問題還得找源程序，還得有人改自動化庫。麻煩不知道是少了還是多了。另外，我所說的手工測試包括寫測試程序，但測試程序側重的不是自動化，而是探索測試Exploratory Test.
自動化在測試中的地位下降
另外我觀察自動化在測試中的地位下降。測試人員的大忌就是在測試開始把自動化作為首要目標。一般來講，過去我們把測試自動化作為目標之一，總是想完成手工測試后，在有時間要做自動化�？墒菍嶋H情況是，項目進度太快，根本沒有時間做自動化。一般手工測試完成后，產品就發布了。
測什么不測什么
和PM討價還價不是偷工減料。一般講，在項目開始階段，測試人員的發言權最低。很多東西測試人員是沒法控制的。PM總想多加功能，即使現在沒用，想著將來會有用。有的項目，Dev有很大的支配權，Dev可以加入很多他喜歡的東西。（很吃驚嗎，現實就是這樣）。測試人員只有在測試階段討價還價的份兒。
有人認為我說“軟件的特點是如果一次做對了，以后永遠不會出錯�！焙芑闹�。我承認有點極端。我的意思是，你在測試時肯定要假設有些東西是對的，不用測的。比如.NET的庫。測試完成了投入使用了一段時間后，就可以假定當前的軟件基本符合要求，不需要進一步測試了。必須學會畫一條測與不測的線，否則測試會無休無止。我們大多數人接受的項目肯定是前人基礎之上的項目，新的版本出來了，我們肯定要假定沒有變動的，沒有涉及程序不會出錯，重點測試變動的部分，分析可能會涉及的部分。具體講可以用Beyond Compare比較程序的變化。
當然，這個假定在一定程度上是錯的。前人做得程序可能會出錯，.NET庫函數也有錯，如果不在當前測試人員的工作范圍，這種錯誤是可以接受的。如果你能找出前人的錯誤，發現.NET庫函數的錯，說明你確實出色。但從往往時間上講，你能做到這步的機會有限。當然，我發現的最得意的bug就是在產品中隱藏了五年之久，我講出來都替微軟丟人的安全漏洞。我發現這個bug就是讀程序偶然讀出來的。讀的時候，腦子里多打了幾個問號，然后動手一測，果然如我所料。
WhiteBox Test + Exploratory Test
我的測試哲學是WhiteBox + Exploratory Test。測試開始階段要讀懂要求，理解設計。然后是讀懂程序，在程序中找問題。這就是WhiteBox Test。然后動手寫一些測試程序，測試程序的原則一定要簡單靈活但自動化程度不高。測試程序的主要目的是探索，手工探索，目測探索軟件那里會出錯。之所以要做探索測試，就是因為自動化要求對輸入輸出都要很準確的定義。輸入好控制，可是沒有探索測試，很難準確知道輸出是否正確。自動化必須建立在探索測試的基礎之上。就像用一只單發的步槍，一發一發精確打擊敵人防御的弱點，不是用機關槍盲目掃射。單發的好處是，每打一槍你都要目測效果，然后調整子彈大小，射擊的遠近。如果像機關槍打出一百多發子彈，你會視覺疲勞，無所適從。自動化就像一只機關槍。
我的觀點只是一家經驗之談，不是理論，大家可以借鑒，不要照搬。
關于，美國軟件業大公司的人工成本是公開的，新聞里可以查到，平均大概是十一到十五萬，當然包括各種福利，和管理成本。
本回復于：2007-07-18 14:35:26 被【dlele】修改
發表時間：2007-07-18 14:12:09 9 樓：dlele
自動化是理想，手工測試是現實，我講的是理想與現實的差距。這個差距不是我個人能力的差距，而是敏捷開發，產品周期加速，復雜度增加，相對人力資源有限所帶來的現實造成的差距。
發表時間：2007-07-18 15:34:38 10 樓：dlele說個具體的實例，最近在工作中遇到一個很頭疼的bug。我們有個API，GetXXXURL(xxx, string locale, yyy)，locale 是語言的字符串代碼，Dev搞成了GetXXXURL(xxx, int lcid, yyy).。Lcid 是語言的整數代碼。比如，中文的字符串代碼是 "zh-CN"，整數代碼是2025。Web Service端只認字符串代碼，結果2025被解釋成為不支持的語言，URL返回默認英文1033. 由于系統設計是三層，每層都要改，很頭疼。
這個測試是我們一個新來的員工測得，他是用VSTS寫了一個自動測試，每次運行都通過了。原因就是他可能花太多時間搞自動化，沒有認真理解要求，對要驗證的返回值也不了解。自動化自然發現不了問題。如果他當初寫了一個很簡單靈活web based的測試工具，多做探索測試，我也可以很容易的幫他作些探索測試，問題可能早就發現了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
