在國外，資深的軟體測試人員大多是手動測試，他們厲害之處在於測試用例的設計，但在國內，很多測試人員都把自動化測試當成很厲害的資本，為什麼？

01-19

我比較贊同前者

手工與自動化只是一種形式，真正的核心是測試用例、業務模型和測試分析。

當企業的產品規模開始膨脹的時候，尤其是產品迭代加快是不是能及時得到測試驗證支持是很重要的。這些靠手工測試是基本無法實現的，手工測試會嚴重的拖慢產品進度，而且無法保證全局質量。

沒有對覆蓋率，測試分析等進一步的數據挖掘，一切深入的問題也無法被手工測試人員發現。

手工測試與簡單的操作自動化只是測試的初級階段，將來也許會有雲測試與智能化測試，大數據測試，這些新的測試手段都是圍繞測試用例，業務模型與測試分析來做的。沒有良好的coding能力，就無法發揮電腦的潛能，也無法做更深入的數據挖掘。

目前的很多公司的測試是有問題的。

大部分的自動化測試的問題是成本高，只是簡單的check，沒有綁定覆蓋率，沒有做測試建模、盲目的追求case數量，自動化分層不合理，ui自動化測試比重太大，導致作用有限。

而手工測試也是只覆蓋基本的業務，根本不了解細節上的風險。bug不僅僅是因為需求和業務引起的，還可能由設計，架構，代碼以及操作系統特性引起的。而且測試人員的執行是否到位也是值得考察的。我在阿里百度都遇到過手工測試人員因為工期緊張，用例太多，草草結束測試的事情。

所以，手工測試重要，但是不能重點依靠。自動化能夠提供全局的把控和質量驗證，價值還是很可觀的。而做好自動化還需要更多的深入的工作。毫不諱言，我們整個國內還沒有幾家公司能真正做到測試建模，目前只是做到了最基礎的測試用例+自動化+覆蓋率而已。

對於手工測試，我舉個最簡單的例子，百度的一些產品，需要在chrome瀏覽器，firefox瀏覽器，ie6/7/8/9，360瀏覽器，搜狗高速瀏覽器上做測試。如果開發只修改了幾行代碼，在不依賴新測試模式，新技術和自動化的情況下，只靠手工測試，幾乎是不能避免bug的。

在銀行，金融，國企，以及傳統企業裡面，經常會看到工作了七八年的手工測試人員，而且他們的產品更新很慢，體驗很差。而在互聯網裡面，則很少看到，但是互聯網的產品體驗要比傳統企業優秀的多。

不可否認，手工測試裡面有不少高手，但是缺乏了自動化，缺乏了大數據分析，缺乏了測試建模，將很難為產品線帶來更多的價值。所以自動化是很重要的資本。只是整個行業，懂業務，懂測試，懂開發的人太少了。大多數的人，都是其中的兩者結合體。

作為測試人員，從業6-7年，我第一次有衝動想回答一下這個問題，也和大家做個探討。

我想這個問題很顯而易見：

1，我現在工作的公司是純正的IT技術型企業，說白了Coding技術是王道，因此--》

a) 公司的小領導，領導的領導基本上都是開發出生（Coding被重視）

因此-》

領導會提拔，喜愛技術牛B的測試或者開發人員。不怎麼懂coding的測試人員只能被鄙視。

結論：所以大家都去鑽研技術，鑽研自動化測試

2. 我絕對屬於不懂技術，手工測試成長起來的人員，在我測試的很多產品里裡面，通過手工測試，設計了一些非常精妙的測試用例，從而發現了bug，但是我手工測試能力不會得到領導的認可，衡量我測試水平的標準也不是基於我發現一些奇怪但是重要的bug。

我對產品的了解，設計用例的發散思維和能力無法被具象衡量，而搭建自動化測試框架以及編寫自動化測試腳本是多麼具象的能力啊。

因此，我每天也在研究自動化測試，對於手工測試我也從心底厭惡，反正手工測了，測出來bug也沒人認可，大家都覺得手工測試很簡單，很傻。

結論：手工測試的設計測試用例的能力真不好衡量，但是寫腳本寫代碼的能力確實直觀好衡量的，在崇尚技術的公司更是如此，所以我要學習代碼。

P.S. 能告訴你們，我是學英語出生的嗎，個中辛酸苦辣只有自己知道。

另外，補充一下，一些邏輯非常複雜的senario（非常規業務流程）很難用自動化腳本實現，因為太費時費力了，用手工測試來執行一些奇葩的senario更靈活方便可以發現很多問題。另外表態一下，手工和自動化缺一不可，手工是基礎，自動化是錦上添花，等待產品穩定之後需要添加自動化。

作為一名曾經的測試管理者，我也被問過無數次這類問題，我的看法很簡單：

1、無論是自動化測試還是手工測試，其核心永遠是測試用例。無效的用例，用任何方法去測試，都不會達到良好的測試目的。

2、自動化測試的目的是節約人力成本及時間成本，把枯燥的回歸測試自動化起來，縮短項目周期。任何為了自動化測試而自動化的項目，都是耍流氓。

3、我見過資深的測試人員，對業務，對行業的了解不亞於我這名產品經理，可以輕易指出設計中的不足以及邏輯盲點。也見過號稱牛逼哄哄的自動化測試人員，連TCP和UDP的都區分不來，遇到WebService就束手無策。企業需要各式各樣的人才，自動化測試人員不比任何其他測試人員更高一等，大家只是分工不同。

我還是用供求關係來解釋吧！首先，我們將產品分為兩類吧！對質量要求非常的產品（比如，電信行業或者金融行業）；另外一種是對發布速度要求非常高的，這樣才能更好的搶佔用戶和流量（典型的就是互聯網企業了）。兩個代表企業就是華為和騰訊，相信樓主應該是沒有參加過第一類產品的測試。

第一類因為對產品的質量非常高（基本是追求零缺陷），所以，對於測試分析，業務能力和行業知識的要求肯定是高於自動化的（當然，有自動化就更牛逼了）。但是，你只會自動化肯定不行，因為可能你做的都是無效測試。

在這樣的企業自動化能力可以作為一個基本要求，但是肯定不會僅僅因為你會自動化就覺得你很牛逼了！（而且一般情況下自動化會作為基本需求）。至少個人從來沒有覺得自動化有多牛逼。

第二類產品因為更加追求發布速度（也不是說質量不重要），基本上每個月都要發幾個版本，還需要快速迭代。這樣自動化的優勢就體現出來了，所以對於這樣的企業來說，對於自動化的人員需求更多，而剛好當前做自動化的測試人員比例還不是很高，所以需求大於供給。就讓大家感覺到好像自動化很吃香的現象。

好吧，說了這麼多，還是用一句話總結一下：適合自己的才是最好的，不要太浮躁。

自動化測試和手動測試都是不可缺少的，兩者相輔相成，簡單說說我對自動化測試和手動測試的體會：

首先，我認為自動化測試的主要目的並不是為了發現產品的BUG。它一個重要的目的是為了確保軟體產品在開發和維護過程中，團隊對產品有更直觀的掌握，消除代碼中的錯誤，即make the system run properly, eliminate bug earlier, which in result raises confidence of the development and the whole team。而手動測試是為了break the system，即發現BUG。

我始終認為最好的測試是將軟體缺陷消滅在搖籃里，測試的根基、金字塔的底座是獨立的單元測試，由開發人員負責，可以最小成本的發現潛在的BUG，也就是說DEV是最好的QA。自動化測試和持續集成是重要的手段，確保對產品質量的可控性。版本控制軟體也非常重要。極大提高我們的工作效率。

簡單所以下我工作的情況：

之前在BlackBerry Enterprise Service實習，負責BES產品發布之前的測試，BES是面向企業的產品，產品質量和穩定性是產品賴以生存的根本，因為我們非常重視軟體測試。我的主要工作是以手動測試和fix verification為主，不和產品代碼打交道。可以說雖然是發布前最後一關，但依然發現很多產品中BUG，任何一個BUG都直接影響客戶體驗。由於各種限制，手動測試不可能覆蓋產品所有方面，因此對產品的了解、豐富的測試經驗、制定詳細的測試用例對於手動測試非常重要，也是考察一個手動測試工程師主要的方面。對產品的了解可以更容易找到產品的薄弱環節；豐富的測試經驗可以更快的發現BUG；而詳細的測試計劃可以幫助我們發現更多的BUG。我認為手動測試發現了產品中的大部分BUG。

目前我在一家北美某遊戲公司溫哥華分舵，team主要是負責為公司大部分遊戲提供online service,遊戲整合online service SDK 使其與server交互。簡單說說QA team的情況，一個senior dev負責開發和維護測試框架，兩個senior QA帶一群QA，還有一個做build系統的。我們的日常工作基本屬於自動化測試，手動測試可能交給有遊戲TEAM了吧。由於產品太複雜、公司沒錢等一系列因素，還未實現完全的持續集成，基本上還在依靠nightly regression，因此還是以天為單位，而不是以敏捷測試中每次code checkin為單位。更可惡的事情是xbox, ps的自動化測試還沒有整合到build系統里，所以本屌絲要經常要手動load測試程序。

吐槽一些對現在工作中的感悟：

1、大家都知道，用c++寫的產品編譯時間都非常長，即使我們有incredibuild這種NB的TOOL, build一次完整的產品和自動化測試的工具也要半小時左右，如果產品或者測試工具出現以下編譯錯誤就會BLOCK所有的工作。產品壞了我們可以revert，但是測試工具壞了有可能是產品code改變，或者是工具本身的問題。 investigate要花時間，fix也花時間。這一點非常影響工作效率。

2、不是說自動化測試就不會發現BUG，每次回歸測試結果都一堆錯誤。但重點是！！！！！你要花時間分析到底是測試用例的問題，測試框架的問題，還是真是產品的BUG，每天看Log簡直把眼睛都看瞎了。

3、自動化測試用例不是一層不變，產品feature變了，測試用例要改變。很多時候測試用例fail了，很有可能是測試用例沒有更新。

4、我認為我們目前最重要的問題是DEV沒有寫單元測試的習慣！

所以自動化測試系統並非神器，它非常嬌貴的，你要花時間是維護它、呵護它、關愛它，它才是成為你手中的利器。

最後，簡單說一下招聘過程。雖然我們的工作是QA，但面試的基本內容是C++的概念、演算法、編碼能力。僅僅會問一些簡單的測試概念。這也從一個側面反映出QA不要懂產品邏輯，還要懂產品代碼！

PS：深感國內軟體測試發展的不成熟，以後回國可咋找工作啊，好了不吐槽了，第一次回答問題，流水賬請見諒，洗洗睡吧，明天繼續上班。

這個其實很正常。國內國外國情不同。我舉幾個例子打假就知道了。

國外：可以有很多鑽研軟體測試直到60,70歲的。他們善於鑽研軟體設計，善於總結，並且能夠最終能夠發布一套自己領悟出來的設計方法。並造福於各個個人，企業，領域。

國內：對於軟體測試的認知的錯誤，越來越多的年輕人湧入這個圈子。但是結果就是做了2,3年開始轉管理，或者打退堂鼓。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

國外：國家，企業，個人大部分能夠清楚的認識到測試的根本價值在於何處，能夠滿足dev，test最基本的溫飽，從而讓大家更自由的，更發散的進行思考問題

國內：國家，企業，個人大部分就不知道軟體測試是幹嘛的，價值在哪裡。並且薪資也不能滿足最基本的溫飽，大家都是為了工作，為了錢而去學習，去奮鬥。根本就沒有人生可言。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

開發學習代碼是為了更好的做好產品，調整性能。

測試學習代碼不是為了去寫產品，不是為了去和開發比或者為了體現自己多少的厲害。測試學習代碼的本質在於更好的理解產品，理解邏輯，然後能夠深入的去設計case。

我一直強調，你去測試一個東西，你不了解業務，不了解產品。如何進行測試呢？一個產品不是你肉眼看到的所有就代表你知道怎麼去測試了！

總而言之，國家的浮躁帶動了個人的浮躁，個人的浮躁推動了國家的浮躁。這個國家就是中國

業務邏輯測試最重要，只有所有的功能測試完成，才會做大數據測試如自動化和性能

這跟好的程序員都因為自己代碼寫的好而覺得自己好，而不好的程序員要裝B都得說「我用了xyz所以我牛逼」的事情我覺得是完全一致的……至於說測試這個事情，為什麼國內跟國外差距太明顯，說白了就是因為我們窮啊。dev和test需要的人數和花的時間是差不多的，如果他們不肯付出雙倍代價，自然就沒有什麼人給他【安心】做自動化測試了。自動化測試是需要積累的，不是一個項目要上就上，另一個項目重頭來的。

說點自己的不成熟看法。

將自動化測試當成很了不起的資本，源於國內對Coding的崇拜，譬如一個Dev跟一個QA放在一起，大家的第一直觀印象就是——前者的技術能力比較強。

實際上，這個問題分兩面看：

1. 自動化測試能力是不是資本？

是，當然是。測試自動化是軟體測試的大方向。作為其核心組件的自動化測試的引入將QA從繁重的重複勞動中解放出來，完成靠人力難以組織的測試，優化測試資源，提高測試效率。優秀的自動化測試框架、完備的自動化測試腳本集、豐富的自動化測試工具將使得測試的效率倍增，對產品質量保證起到積極作用。一個有自動化測試腳本、框架、工具開發能力的QA，更有競爭力是一件無可厚非的事情。從招聘方的角度看，就如同兩台配置差不多的筆記本，一台多出倆USB口並有一個HDMI，當然會優先選了，雖然他也不一定用得到。

2. 自動化測試人員一定強於手工測試人員？

不一定。我接觸過的自動化測試的QA大致有兩種：其一，專職automation，他們從進公司開始就定位為自動化測試人員，有的公司的automation team甚至都不隸屬於測試團隊，他們從進公司開始就幾乎只接觸腳本和工具，自動化的需求對於他們就等於一個開發需求。這類的測試人員對產品本身了解並不多，且不深。更傾向於一個開發人員的工作方式。其二，既做手工，也寫過一些自動化腳本。這一類人實際上仍然算是手工測試人員，但會小範圍參與到一些簡單腳本開發，多數是在已有的測試框架上進行的搭積木的工作，缺乏創新空間。對於這兩類QA，前者因為很大程度上仍工作在一個Dev的模式下，可能存在的缺陷主要在測試的方法、感覺和思維方面，後者則完全可以作為一個手工測試人員去做橫向比較。國內自動化測試的現狀，使得投放入市場的自動化測試人員，以第二種類型的居多，且目前國內普遍的測試情況仍然是手工測試比例為重，所以如果招聘方簡單地用是否做過自動化測試來過濾人才的話，也許會錯過真正適合職位的測試人才。而測試人員如果單純為博取一個名頭而局限於第二種狀態的話，對自身真正的自動化測試能力的提高也沒有太多好處。

關於手工測試順便說點，必須肯定手工測試對於一個測試人員成長的重要性，參與手工測試可以了解架構、熟悉產品、培養測試的感覺。測試感覺和思維，說起來貌似很浮雲，但從事過測試的人應該很清楚，同樣的一個測試任務，交給一個具有良好的測試感覺、思維縝密的人和交給一個把測試當成體力勞動的人會有什麼樣的產出差異。手工測試不應該只被等同為手工執行測試，其更重要的部分應該是測試的架構和用例設計。所有的測試執行都是以測試用例為基礎，測試用例設計的好壞，對測試效率、測試覆蓋率、defect發現幾率產生直接影響。測試用例設計中會用到很多方法去優化和評估，涉及到離散數學、概率等領域知識的應用，是個挺值得下功夫的領域，對於一個手工測試人員的自我增值也是有幫助的。

不好意思。。。跑題了。。。

這個問題也能上升到「國家的浮躁」和「個人的浮躁」，我對此深表佩服。

先從問題說起吧。「在國外，資深的軟體測試人員大多是手動測試」這句話的描述就非常有意思。怎麼定義「資深」？如果說「資深」是指工作年限長，在社區混的臉熟的人，那這種情況再正常不過了。國外的軟體測試起步比國內早的多，自動化測試是90年代以後才真正開始逐步成熟，那些年限長的，混得臉熟的自然是早早進入這個行業，並以手工測試為主的人。當然，各種測試的認證機構和組織的慣性自然也為這一情景貢獻了力量。

要說到測試這個行業的知名人士，James Whittaker算吧，你覺得他是「以手工測試為主」嗎？別因為他寫了本《探索式測試》就認為他只懂手工測試。Google的Copeland算吧，同樣，你肯定沒法斷言他只會做手工測試。

一個個人單獨拿到討論沒什麼意義，看看公司吧。Google的測試工程師有手工測試技能，但是肯定不是以手工測試為主的；Facebook沒有專職的測試工程師，也肯定不是以手工測試為主的；Microsoft算是在軟體測試方向上偏傳統，而且建立測試隊伍的念頭足夠長了，你猜他們是以手工測試為主嗎？

國內的軟體測試行業是從90年後後期才開始真正發展起來的（記得我98年進入測試行業時，有測試團隊的國內公司都屈指可數），90年代後期正好是自動化測試開始蓬勃發展的時候，從這一點上來說，國內的軟體測試行業其實是站到了一個好的起點上（當然，由於缺乏積澱和對自動化測試的理解不足，很多企業內的所謂的自動化測試進行得並不順利，這些故事有時候我可以給大家講講講我的經歷）。

測試的價值不在於體現測試工程師的厲害，也不在於通過發現缺陷尋求滿足感。在我看來，測試的價值就和其他所有組織內的崗位一樣，是看你能否為組織產生可見的價值。動不動就拉出兩條線，國外：xxxxx，國內：xxxxx，這樣的比較其實毫無意義，先不說國內測試方向做的好的企業雖少卻不是沒有，單說一點：測試在不產出被認可的價值時，如何能被公司和組織認可？

擁有手工測試技能，想要做一輩子手工測試，在國內並非不可能。只要你真的夠牛B，能夠快速進入任何一個行業，能夠搞出你的理論並能真正產生價值，我不相信你不會被接受（題外話，如果那位手工測試工程師能讓我折服於你的技能，我保證給你不比任何開發工程師差的薪水）。

怨天尤人沒有用，路是自己選的，大回報需要大投入，大投入未必能產生大回報。這不決定於環境，只決定於你能不能讓自己的努力產生被人認可的回報。

測試最重要的還是對系統以及需求的理解吧。至於是不是自動化，更多是取決於產品的生命有多長，以及自動化後成本有沒有減少。

關於對系統以及需求的理解，這個是測試工程師最基本的要求，但是很多測試工程師現在都只是知道怎麼跑case，把自己變成一個自動化測試腳本，而不是去理解整個系統。好比你搞web測試，只是測那些頁面跳轉會如何之類的，那基本上測不出什麼bug來的。即便能測出，也不過是運氣問題。但是如果你理解了後台和前台的交互，有哪些數據，哪些地方可能會溢出之類的，那會更容易找到bug。

對需求的理解，也是很重要的，我見過做性能測試，有些測試工程師不理解產品需要的開機時間是多少，覺得反正沒有具體的要求就沒所謂。而有些則覺得很重要，拚命提CQ要求修改的。最後在客戶驗證的時候，發現後者的理解是正確的。這些很模糊的東西，更多需要個人理解才可以獲得。或者說，這叫經驗。

自動化測試的目的更多是減少測試時間，把更多的時間放在設計用例，以及理解需求和系統的階段上。但是如果做一個以後都不會再做的產品，還開發了一堆自動化測試的腳本，並且在軟體裡面寫了一堆log，那基本上是費時費力卻得不到任何實質上的幫助，因為開發這堆腳本和log的時間，已經夠測試幾輪了。

國內對自動化測試的嚮往，無非是因為國內測試人員玩的都是苦力活，而不是技術活。你隨便找一個測試的，你問他對系統了解多少，多半是只會執行case的人而已。甚至乎，這些人在完成了任務之後，基本上就不再學習了。

-----------分割一下，一些內容和題目有關係，但是不是太大。寫得也很亂。------------

近年來國外有個叫做SBMT(Session based test management)的東西，建議大家看看。有條件的公司建議實行一下。這種測試方法嚴格得區分開了checking跟testing，對測試人員的要求很高。並且SBMT裡面不存在固定的所謂的測試用例。

現存的測試用例的測試方法是按照ieee以及幾本一九七幾年寫的老書確立起來的，雖然名曰為Best Practice，但是實際上是效率很低的。因為一個測試用例測過幾遍之後，其信息量幾乎為0。根據資訊理論，越確定的東西，其信息量越低。我實在搞不懂一個check了幾百遍都沒問題的東西為啥要用人來check而不用機器來check。

嚴格意義上來講，自動化測試應該叫做自動化檢查。它只是checking而已。什麼叫做checking？checking就是按照需求文檔一條條打勾。什麼叫做testing？testing就是探索產品本身的結構以及分析產品可能的問題。

SBMT是通過認知論的方法，觸發測試人員的思考，讓測試人員自己去了解系統。

一般SBMT會有一個charter(即要測的功能)，幾個Mission（想要達到的目標）和一份note。格式如下：

Charter:

To test WORD

Mission:

1. To find out memory leak scenario in word.

2. To find out several boundary values of word.

Note:

1. I blah blah...

通過Mission，一般測試人員需要為了達到這個目標而想一些測試用例，而這些測試用例的建立則不得不依賴于思考，而不是之前已經寫好的腳本。測試人員必須把自己的思考和測試步驟寫成Note。當然這也解決了測試工作無聊的這個事實。

另外，testing的本質目的只是提供產品的信息而已，是一個「輔助」功能，不是一個生產功能。產品的質量完全不能通過testing來保證，所以才需要用到工具和流程，這才是測試需要進化的方向：想辦法給工具和流程提意見，改進（或創造）有利的工具和流程，把測試本身提供的信息Build進產品裡面去。

測試這個職業，這幾十年來幾乎沒有啥進步，所有提升軟體質量的方法都是dev提出來的。如果測試工程師再不把自己的testing build into code，我感覺這個職業很快會被dev或者某些工具所兼顧，平均薪水會越來越低（現在已經不高了）。

現在對測試人員的開發技術能力要求越來越高了，互聯網時代全面到來一個影響吧。

（1）提高測試效率，縮短上線響應時間的需要；

（2）測試對象複雜，理解設計和業務場景的需要；

（3）解決不可測問題的需要；

其實測試人員是做測試的程序員，這個是不是會得到大家的認可呢？我覺得現在好像還沒有，慢慢的會明白，測試人員就是做測試的程序員，本質上面也是開發工程師

這兩者不衝突，設計測試用例自然是最重要的，但是同等重要的還有貫徹執行這個測試用例。換句話說就是所謂執行力。

在中國的很多 IT 企業，工作強度以及工作量遠勝國外，所以你需要在短期內執行大量的測試案例，如果你只會手動測試，那麼你很可能根本就沒有時間把所有案例都測試一遍。手動測試員要麼是把大部分的時間將消耗在執行測試案例，而非設計測試案例上，要麼就是每輪都憑自己的經驗判斷而漏測很多點。

而對於自動測試來說，測試的案例是日積月累的，測試過的案例在以後每輪測試中都被反覆使用，你只需要專註與設計新的測試案例，而舊的測試案例已經進入了自動測試，它在每次迭代中都會被自動執行了，換句話說，自動測試的測試人員可以用更少的精力去執行測試，於是就可以把更多的精力放在設計測試案例上。這樣，自動測試往往就可以意味著更好的測試案例設計。

人的精力是有限的。無論對於自動測試還是手動測試人員，測試案例的設計都重要，他們只是在執行測試案例這個環節具有不同的技能而已。但對於迭代開發來說，一個軟體如果你需要測試 50-100 次甚至更多的次數，自動測試凡是設計過一次的案例以後都可以直接執行，自動測試可以專註於新測試案例的開發以及實現，而手動測試每次都得手動執行以前設計過的所有案例，效率上明顯降低，而且漏測的情況基本上難免。

我個人覺得自動測試對中國的 IT 來說非常重要。至於國外是否重要我不清楚，如果一個測試人員一個星期就那點事情可做，有充分的足夠的時間每次都手動執行所有案例，工作的時間壓力很小，也許他是沒有動力實施自動測試的，但這並不能成為手動測試比自動測試更優的論點跟理由。

對你的問題描述的真實性表示懷疑，能給出案例或者出處嗎？

第2個回答。

國內的測試，並沒有發展到一定的高度。

如何評判一條測試用例的好壞？我想很多人都回答不出來。發現bug就是好的？

是測試效率，也就是單位測試用例覆蓋的測試點。同樣的10條測試用例，你寫的只能覆蓋15個點，而高手寫的能覆蓋30個點，這就是區別。

手工測試，要求的並不是手工，而是測試思維的建立。呵呵，有的人，幹了10年測試，也依然沒有測試思維。

說回題目，在中國，普遍的人認為，剛畢業的人都能幹的測試工作，毫無技術含量，甚至不是計算機專業的都可以干測試。而自動化測試，是要和代碼打交道，自然高人一等，殊不知，自動化測試的核心依然也是測試用例，這才是測試人員需要追求的極致。而不是，一般人寫的測試步驟。

希望我的回答，能給一些迷茫的同學指明道路，想做好測試，一定要有測試思維。

什麼是測試思維，效率，覆蓋度，測試順序都有很多可以深入的部分。

這個結論是如何得到的? 自動化測試在提高測試的工作效率上有著不容置疑的優勢。所以，但是自動化測試也有其局限性，不能靈活的採用測試方法，自主的創造新的測試用例。但是，如果由資深的測試工程師編寫新的自動化測試用例，那麼問題也有改善。

所以，對你問題的結論很感興趣，有相關的研究結論么?

不能一味的說手工好還是自動好，不是說國外的大牛就不自動化。測試用例確實比較重要，經驗豐富的測試人員能考慮到更多測試用例和覆蓋率。現在我們公司就是一味的追求測試的自動化比率和CI的程度，卻忽略了最基本的是測試的用例。。。即使自動化100%了，codecoverage100%了。並不代表產品沒問題。

當然，另外一個就是，應該不斷把手工測試的用例想辦法轉化為自動化。這樣畢竟節省體力啊

手動或自動測試只是方法，關乎效率和覆蓋面；而測試用例的設計是核心，決定是否能發現設計或者實現上的缺陷。根本不是一個層面的東西吧，沒法放在一起比較。

更深層次的問題是測試工程師的資深、厲害與否更在於對系統內在的理解，用戶使用場景的認識，這和測試方法沒有多少關係。

一般來說物以稀為貴，相對於只會重複點點滑鼠的測試人員來說，會寫自動化測試的是較少的，所以貴。

至於你說的那種資深測試，就好比西遊記里的人蔘果，稀到沒有了，就成神話了

1.國內大多數的互聯網公司，還是有一條鄙視鏈的，其中一條就是做開發的鄙視做測試的。我遇到很多人，包括面試過的候選人，以及見過的部分管理者，對於測試這份工作發自肺腑的鄙視都是掩飾不住的。

2.你去問一些測試同行，你為什麼選擇做測試，有些人就會說，呃，我編程不行，又想做互聯網行業，測試好入門啊。

3.跟任何一個工種一樣，測試的分布大概也是個金字塔，下面聚集著一大幫的底層純執行人員，流水一樣的來，流水一樣的走。願意往上走的人不多，能好好走的人就更少了。

4.做事的思路、思考問題的角度、設計方案的制定，有些人不覺得這些也是重要的技術，會寫幾個方法和函數，感覺就牛逼的不得了了。

5.如果一定要跟國外比的話，嗯，國內的壓力確實也要大很多，人力的壓力、薪酬的壓力、產品迭代的壓力，甚至加班的壓力（估計著），可能也是個原因吧。