軟體測試員比軟體開發員要求低些嗎？

12-30

在學校的時候，老師說女生以後如果從事不了開發，可以去做測試，有次面試，我問在公司一般程序員未來幾年的發展，他說看個人能力發展，如果水平差點可以去做測試。

從很多公司的實際操作來講，樓主的問題答案是"是的"，應屆生招聘經常達不到開發要求的人轉測試看看! 但是應屆生開發和測試的起薪一般是一樣的。假如是去大公司，測試的前景還可以，職業階梯常見是轉管理，系統工程師，產品經理等。小公司千萬別去干測試了，干出來就是個打雜的。

測試的素質非常重要，假如覺得不重要，那是因為你沒有看過真正好的測試。

公司的測試部門也有幾個相當不錯的人。公司的年度之星研發中心有測試評上了一個人，但是開發沒有。這都可以說明測試的重要性。

測試對於耐心、溝通、條理性等相對偏重，綜合素質要求比較高; 開發的話，要求從低了說，要對寫程序這個事情有興趣，否則那麼多的知識，那麼多的要求你記不住也用不來，到頭只是個平庸的開發而已，往高了走，開發的思維，耐心毅力溝通等也很重要。但是一個主要的問題是開發的基礎要求比較"硬"，coding基礎和能力是比較好評估的，而測試的一些綜合能力偏軟技能, 對於應屆生不太好評估，所以出現了樓主說的情況。

在招聘操作裡面，主要是尊重個人的意願，在應屆生招聘的時候，常見的方式也是發現開發技能不行就看看測試部門是否要，說不定別人其它素質不錯呢，女生去測試比例較高，這也和女生的個人傾向有關，實話說開發常常也比較苦一點，加班多一點。

另外樓主問題里那個人(也許是HR吧)說的話有問題，「問在公司一般程序員未來幾年的發展，他說看個人能力發展，如果水平差點可以去做測試」，開發技能不夠可以轉測試，這只是個人特長的一個問題，但是假如是一個人的綜合水平差，比如做事不細心，缺乏溝通能力，他幹啥都不行的。

------------------------

BTW, 本人並非測試，而是開發部門的頭，也和測試部門老大一起招過幾次人，感覺目前國內目前對測試人員還是重視不夠，測試人員的薪資漲幅和找工作容易程度的確是不如開發，而且8年以上的測試人員假如不轉型，職業出路還是窄了點，這都是現狀。這個現狀有部分合理性，雖然要開發測試都好才能出好產品，但是假如是難度高的項目，條件限制只能選擇開發強測試一般或者開發一般測試強，大部分人會選擇開發強。

準確的說是測試入職時的技術門檻低。

開發入職時技術門檻高一些，但是其實也高不了多少。（就應屆計算機畢業生而言）

測試往往基於業務。

比如做會計軟體的，測試人員一般選擇會計專業畢業的人。

測試做基於技術的測試一般比較少，因為開發組自己會review，版本組、平台組、構架組也會分別組review的。

所以，測試只是技術門檻低，對業務、溝通、邏輯等要求會高一些。

開發的技術門檻高，但是對業務、溝通相對來說要求低一些。

開發和測試是兩個工種，沒有對誰要求比誰低這一說的。

就像你不能說對學會計的比對學計算機的要求低一樣。

要求大致一樣，但側重不同。我在微軟干過4年，對測試工程師的要求也是比較高的，開發要精通某個點，測試要高度熟悉某個面。另外，我所在的項目里，基本1測試對1開發。工資上同級別的，測試會少點。

現實地說，我得承認@pansz 的看法很有代表性。我所知的很多公司的看法都是這樣。但這不是我認同的看法。水平差點可以做測試，實際上就是把測試部門當作垃圾收容所。但是實際上說這些話的人，我相信並不理解測試究竟是什麼。

如果我們不打算做深入的分析，其實要駁倒這個所謂的理論只需要一個例子就可以了。很多程序員不是總喜歡用架構來形容程序么？架構這個概念來自建築行業。可是我相信很多人都知道建築需要專門的人負責質量管理的，也就是保證交付建築的質量滿足需要。我們不會允許建築公司自己做完工程自己驗收然後直接交付使用的。我們都知道測試本身存在的目的是為了保證軟體的質量滿足需要，那麼為什麼樂於用架構對比軟體的程序員們卻認為軟體可以不需要測試人員？顯然這是荒謬的。

當然，我知道這種對比是駁不倒驕傲的程序員們的。我們從數學家那裡繼承了高傲的本性，天真地自以為演算法就是一切（當然，他們中間的許多人其實多數時間用的演算法都不曾超出過大學二年級那一年的課覆蓋的內容），卻不曾真正接受工程師的嚴謹。所以我們還是需要詳細的分析。

首先，測試是什麼？保證產品質量，這個過於模糊的說法說明不了問題。最直接的方法就是數一數測試究竟需要做什麼：

監控產品流程。從時間控制的角度來說，開發新功能和修bug是一個平衡。開發得太快就可能把交付給下一個階段一個問題較多的版本，從而使得後面的問題更難處理。我們如何知曉每個階段軟體質量怎麼樣？具體的方法很多，回歸測試，代碼覆蓋、壓力測試等等。但是這些信息誰來收集和分析，怎麼分析？能得出什麼樣的結論？有多少程序員會自己做這些？
搭建複雜的應用場景。誰能知道測試一個完整的Active Directory伺服器的回歸測試環境需要多少台域控？我搭建的紀錄是11台，還不包括中間可能動態加入和刪除的客戶端。其中包含大量故意的毀壞性操作。每一次毀壞之後都必須恢復現場進行下一個測試。有多少程序員構造過這種場景？
簡化問題報告。當發生用戶報告時，他們最初給出的步驟往往過於簡化或者過於繁瑣，缺乏直指問題所在的步驟描述。很多時候由於步驟不清楚，導致分析過程中存在很多彎路。這個時候需要有一個人來不停地和客戶打交道並定位關鍵步驟。這個步驟總是必須完成的，那麼誰來處置？有多少開發人員真正負責處理過這些？

當然我知道很多程序員們會高傲地昂起頭：這些我們都不需要。只要我保證每個函數是對的，最後的軟體必然是對的，所以只要單元測試就夠了。這種理論我不止聽一個人說起過了，也實在是沒法說清楚。我只能說這些信息是有很多人需要的，既然有人需要，就得有人做。

我承認，有些情況下我們確實不需要專門測試。這種典型場景實際上有一個很簡單的前提，即軟體本身不包含複雜的應用場景。比如單機軟體，比如單伺服器網站。但是這不包括那些本身需要複雜使用場景的軟體，比如Exchange、比如Active Directory。這類包含集群和分散式要求的軟體系統不是一個人花一個小時坐在一台電腦前試一試就能做好的。

當然，對於開源軟體來說還有一個方法，就是可以通過大量的發布讓使用者做小白鼠。但是這不適用於所有的軟體公司。對於一個app，也許崩潰就崩潰了，反正也許無非就是一條微博沒發出去；可對於股票軟體的伺服器系統，你敢崩潰下試試看？我不知道在這裡侃侃而談水平不行就可以做測試的人，是不是確實長時間負責過此類複雜系統。

說了這麼多，總結起來就是一句話：測試和開發需要的技能有交集，但基本上是兩個要求不同的崗位。開發技術不行去做測試，不等於你能成為一個好測試人員。

當然，我也得承認一點。現在開發和測試分離的做法其實助長了一個傾向，就是開發部門的一些程序員越來越不關注自己的程序質量，也不關心自己的程序是被如何使用的。我記得當初曾經在CSDN的微軟測試專家群論壇上看過有人如此發言，他說一個產品到發布的那個時候對他來說就是死掉了，他就不再關心了。時間太久，我不記得說這話的人究竟是誰。但是我得說這代表了我認識的一部分程序員的看法。但這不是程序員的錯，也不是分工的錯。該指責的是無能的領導，他們設置測試這個職位就是為了丟垃圾的，而沒有能力把握兩個角色的關係改進產品。這種無能的另一種傾向就是僱用大量的測試人員，以為用人去堆就能堆出好產品。他們忘記了，測試人員起到的是監控質量變化的作用，而不是提高質量。提高質量的唯一辦法是開發。

丟包袱能讓人輕裝前進，但是只知道丟包袱是丟不出好產品的。

——我，現在。

最後推薦一篇文章作為註腳：http://www.aqee.net/on-testers-and-testing/

=== 對@馮東老哥增補回答的回應 ===

從我的經驗上看，我承認測試人員對編碼和演算法的要求可以比開發低一些（現實告訴我，我這種成天直接給開發扔fix的測試即便在微軟不是多數派），但我強調的是對編碼能力的要求較低，不表示開發人員可以自動成為一個合格的測試。就像隨便拉一個戰鬥部隊的人讓他去負責炊事班，他不可能自動地做得很好一樣。

測試這個崗位有測試的能力要求，它和開發的主要差異是在於分析和統計的能力。測試的基本能力是能夠嚴格地按步驟執行測試，這個確實是很容易入門的。但好的測試要求的絕對不僅僅是這個。當一個人在測試到達一定程度的時候，他/她就必須開始注意很多流程上的分析工作。我說的流程不是很多人想像的一個老闆坐在那裡要求手下人做事之前必須做這個做那個，而是對整個開發周期里質量變化趨勢的把握，以及如何用合理的技術手段支持這種趨勢的分析（比如回歸，比如fuzzing，比如壓力測試）。從這個意義上說，我承認測試本身是一個相對容易向管理轉化的職位。但這本身是可以理解的，就像建築質量檢查員必須了解建築學常識，但不需要自己去畫藍圖一樣。反過來，他們需要強化交流和溝通能力以備出問題的時候可以有效地要求開發商承認問題，這不等於誰都能做這些事。

其實開發在這個位置上也是一樣的。最開始面試的時候，只要是計算機科班出身大學又大學四年不太混事的，寫個排序之類的演算法都不是難事。但一個好的開發不是只會這些就夠的。當入行時間長了，開發就必須開始注意領域知識（比如東哥最近剛發布的Adaptive Wide Angle濾鏡）、架構、設計（比如互操作性，微軟已經被人罵了很多年了）等等東西。這些東西都和編碼本身無關，但是成為一個好的開發必須掌握這些。這兩個職位也許開始時能力要求接近，隨著時間的發展則差異會越來越大。但這不是開發部門可以用來鄙視測試部門的理由。

另一方面，也正是因為有了兩個職位的差異，所以才會有興趣愛好方面的區別。有的人一開始不理解測試這個職位，慢慢地越做越喜歡；有人試了之後還是覺得不符合自己的興趣，所以選擇離開。這都很正常。人各有志，這東西勉強不來。

所以再次重申，測試不是開發的垃圾桶。不是說編碼技術不行的人就該搞測試去。如果一個人希望把開發作為自己的事業卻能力不足，那麼他能做的只能是提高開發技術，而不是靠測試混飯吃。

當然了，如果確實是想在微軟這樣的公司做開發卻發現暫時能力不足，申請做測試也是一種為自己爭取機會的權宜之計。但是如果這樣則更需端正自己的心態，要是覺得做測試是委屈了自己，那麼接下來引發的就不是技術問題，而是人事問題了。如果剛開始就抱著一個混飯吃的心態，最後到哪裡都是混不下去的。

P.S.：關於我的一些狀態變化的解釋。

我承認我前一陣子剛剛從測試轉到了開發。雖然在這個背景下為測試說話貌似在打自己的耳光，但確實值得說道說道。我必須得說我轉崗位的理由和@馮東老兄所說的理由不符。我之前負責的是伺服器相關，現在轉到了語音。這兩個部門的差別恰恰滿足我之前分析中提到的一個關鍵差異，即從一個對應用場景和部署要求非常複雜而演算法要求相對較低的部門，轉到了一個對部署要求非常簡單而對演算法要求很高的部門。平心而論，這個新崗位對測試的要求以及發揮空間其實比原來的部門要低很多。對我來說我兩者都可以做得不差，那麼我當然會希望找一個更有挑戰性的職位來試試看。另一方面是作為一個五年的測試，我也希望換一個角度看看自己之前的崗位是什麼樣子。對於這個選擇，我多少也是遺憾的。

所以我換了一個崗位，但是我換崗位的前提是我兩者都能做，而且領導也願意給我這個機會。這和兩個崗位孰高孰低並無干係。

大部分企業都不需要高端測試人員，一般都是點滑鼠黑盒測試即可。【我說的是一般情況，高端測試朋友勿怪】

測試比開發門檻低、起薪低，自然不能吸引好的應屆生，試想一個計算機應屆生自身水平足夠的話，會選擇起薪高而且發展路線清晰的開發崗位，還是起薪低且公認較低端的測試崗位？

人都有逐利性，有能力者必然會盡量選擇一個略靠譜且工資高的崗位，所以按平均素質來說，測試人員必然會低於開發人員的。

下面是騰訊的待遇信息，來源於分智網

這幾天買了 Kindle 再重讀 Joel on Software。Joel 很喜歡用 Big Mac 和餐飲業來類比軟體開發。所以我突然覺得這是一個很貼切的比喻。

結論就是，如果你真的非常非常非常喜歡在一個餐廳工作，廚師這個角色是你唯一要追求的。

你想做很好的老闆？那麼你祇是碰巧在一個餐廳。你可以向任何領域投資。你想做很好的 waiter？真正尊貴的客人都是由廚師接待。你想做美食家？你應該屬於媒體而不是這個餐廳。我們不要求每個人都成為廚師，但是只有一個角色屬於餐廳。

以下是原來的答案：

贏得一場戰爭，每個人都很重要。只是，讀讀克勞塞維茨《戰爭論》的開篇你就有答案。

看到 @陳甫鵃的答案，不能不說一些。甫鵃的技術水平是有目共睹的，但是如果因為測試隊伍中有這樣的人才，就認為測試和開發是同一個境地，那就錯了。

在一場戰爭中，特別是現代戰爭中，有無數的人員支持戰鬥人員和指揮鏈上的指揮人員。沒有這些支持人員，戰鬥人員和指揮人員就是瞎子，聾子。但是，即使有人把這些支持人員做到最好，一個沒有戰鬥指揮人員的軍隊就等於零。雖然在雙方的戰鬥指揮人員旗鼓相當的情況下，支持人員的優劣可以決定勝負，但是另一方面，戰爭是千變萬化的，在某些極端時刻，戰鬥指揮人員甚至可以分出一部分精力來執行支持人員的功能，甚至在局部短時間可以放棄支持。而支持人員一刻離開戰鬥指揮人員，他的功能就是零。

好，我們可以說這兩者各有分工，他們的技能完全不同，他們的角色都不可或缺。但是作為一個把軍事作為最高追求而不是勉強靠服役獲取福利的人，你選擇哪種角色？作為一個資源有限的團體，你會先照顧哪種角色？我們不是生活在真空里，就用有人提出的造炸彈和拆炸彈的比喻，如果你只能招一個人，你會招哪個（造炸彈的起碼可以當半個拆炸彈的，因為這是他的工作本質決定的）。如果你非要說拆炸彈的也會造炸彈，我只能說你給他的 title 錯了（因為這不是他的工作本質決定的，而是他的興趣決定的，@陳甫鵃的興趣十分廣泛）。

在這個軟體工業里，只有開發者旗鼓相當的公司，才能拼測試。而實際上，開發者的生產力可能會相差到十幾倍。

目前國內軟體測試工程師的職業發展普遍不如軟體開發工程師，這是不爭的事實。

入職要求，對應屆來說的確比開發低一些。但對高級人材要求其實也不低，干哪一行，深入進去都不是那麼簡單的。

真正的好測試人員難找，於是時間長了後大家就乾脆不找好測試了

互聯網時代，許多公司為了省錢都把測試丟給志願者了，現在許多軟體的測試版都是免費提供給志願者用的，比如windows 10 insider版。

答案是肯定的，尤其就入門階段的來說。

入門階段的開發做啥呢，修前人留下的bug，寫寫網頁，好歹也是在真的coding

入門階段的測試呢，哈哈非常簡單了，點點這個點點那個，寫報告。不一定很technical

然而這不是永遠都是如此的，不要以為測試就不寫code了，還是要寫的，比如自動化測試的腳本，框架等等。難度基本等同於開發。

測試也分很多種，最基礎的黑盒直接對著UI操作，高級一些的，白盒照著業務代碼覆蓋邏輯。

然後，需要熟悉業務的甚至整體業務邏輯的，然後做白盒測試，這類，是項目組裡，除了pm或者產品以外最熟悉業務邏輯的，甚至一些細節上，更了解。

再之後，還需要編寫測試腳本，實現自動化測試，甚至開發測試工具等等。

如果一個對業務邏輯熟悉又能寫自動化腳本並開發測試工具和框架的測試，那顯然，對他的要求，要大大高於絕大多數開發。

說那麼多廢話有什麼用？

我的回答是：

是

不愛干？

有人願意，你打我？

我不太贊同@pansz的觀點

你的觀點，反映了國內大多數的重視實現，不重視質量的普遍思潮。

試想一下，一個不合格的開發人員，所造成的問題，還能夠在項目內部進行消化，但是一個不合格的測試人員，他沒有能夠及時發現的問題，卻要遺留到客戶面前，輕者造成客戶滿意度下降，重者會是災難性的客戶流失，甚至是潛在客戶的流失。這樣的災難，是不是要比一個不合格的開發人員索造成的問題要大很多？

但是，國內的現狀是，不太重視客戶，只要趕快實現了，拿到客戶的Money就OK了，很少有人去關心後繼的工作。所以，在項目經理們看來，趕快出貨才是關鍵，有一兩個問題沒有發現沒有太大關係，他們的理由是「哪個軟體還不得有一兩個Bug啊」，所以他們更重視開放而輕視測試。

我並不認為對測試人員的要求比開發人員低一些，我認為反而要高一些，這就像拆炸彈，你說是安裝炸彈的水平高呢還是拆卸炸彈的水平高呢？

呵呵....要求低..

我做了5年測試了，從最開始，公司是Java，後來安卓，再後來，網元、存儲

換一家公司，就換一套工具，換一種腳本語言。

自己算把，js/shell/python/perl....

工具，各種benchmark and 各種不同的工具。

這個要求低？？

實際上說就是如此，不管是國內還是國外，沒有什麼需要避諱的

看了很多答案，都說測試門檻低，拿個滑鼠點點點就可以，沒有技術含量。其實這只是測試方法中的一種：隨機測試，即想點哪裡點哪裡，完全不需要考慮每一步操作的邏輯，也許當前在模塊A，下一步就跳到模塊D。而如此測試，極容易產生測試遺漏，測試猿自己都會忘記做了什麼操作，哪些地方測試哪些還沒有，出現BUG時也不易重現，極大地增加開發人員的負擔。

實際上，要做好一個產品或項目的測試，需要了解產品或項目的背景，用戶群，用戶場景，用戶需求，系統架構，系統業務流和數據流，等等。然後再根據這些來編寫相關測試文檔，組織項目組評審文檔，最後才是根據評審通過的文檔對系統進行點點點，提交BUG，編寫測試報告。如此，完成一輪測試。接下來就是若干輪的回歸測試，而測試猿需要在每輪迴歸測試開始前決定測試策略：全部重新測？重點模塊測？只對修改的部分測？這極大地依賴於測試猿對系統、業務的了解程度。所以，很多時候，測試猿比開發人員更熟悉系統，更熟悉業務。

以上，只是功能測試的範疇，接下來需要開展的有：性能測試、UI測試、兼容性測試、安全性測試、健壯性測試==如果涉外，還需要做本地化測試。

所以，好的測試猿，想拿高工資的測試猿，需要掌握的技能絕對比開發人員多。開發人員也許掌握JAVA就行，對C++可以不理會（反之亦然），但測試猿不行，需要熟悉多種開發語言和腳本語言（JAVA/JS/C++/C/PHP/PYTHON/SHELL/==），掌握多種資料庫（MSSQL/MYSQL/ORACLE）,因為做白盒測試和介面測試會用到；需要掌握多種測試工具（QTP/SELENIUM/LR/JMETER）,因為自動化測試和性能測試會用到；還需要掌握多種操作系統（WINDOWS/LINUX），多種協議，因為做UI測試、兼容性測試、安全性測試、健壯性測試會用到。

所以，讓開發人員或其他什麼人員兼職做測試，是不可行和不可靠的。

結論：測試猿的技能要求，不比開發人員低，甚至還要高。

不要管老闆們怎麼看，只要老闆不在利益上區分對待即可。

見過有小公司老闆，調薪時點只給開發加薪，單獨不給測試和運維加薪，哈哈。

但是，開發確實是從0到1的過程，其工作創造性高於測試和運維，這一點咱們要承認。

現在流行devops，開發、測試、運維是一體的，一個環節有問題，公司整體版本交付效率肯定做不好，有些技術行業背景的老闆們應該能意識到。

軟體測試，僅僅是產品質量的評估者而已。

@馮東的回答其實是真實的現象。他所論述的，不過就是生產者的重要性。的確，一個餐廳里最重要的是廚師，如果我所有人都雇不起，我至少也要雇個廚子來。一個軟體公司最重要的當然是開發人員，沒有產品，測試人員測個屁。

@陳甫鵃將產品開發工作與傳統建築行業進行類比，提出了質量管控的重要性。但是這個提法是模糊的，混淆了產品質量與過程質量，測試團隊的過程質量管理角色本來是一些更偏重敏捷的團隊使用後置工序督促前置工序的便宜之法，如果這樣也可以，開發人員對設計人員的督促，也可以看作是過程質量管理工作。

但是，題主問的問題是，「軟體測試員比軟體開發員要求低些嗎？」

公司的戰略肯定是要先發展核心力量，提高生產者的能力，這是沒錯的。所以如果在同一個公司里，測試的投入和開發的投入，肯定是後者多。所以體現到行業上，就是測試人員比開發人員要求低一些了。

普遍意義上是這樣的，都被最近幾年國內一些公司把風氣帶壞了。測試在國內給大部分老闆和開發人員的印象就是點滑鼠，跑腳本，寫報告。

因為只要是軟體就會有bug，無論有沒有測試團隊存在，再牛逼的測試團隊也不能保證100%測試出所有的bug。所以很多公司認為不需要特別牛逼的測試人員，主要還是kpi不好衡量，線上出現bug到底是誰的鍋？測試出多少bug算好的測試人員？於是越來越多的公司不想花高薪去找一個好的測試人員，由於不受重視的原因，很多好的測試人員對測試也逐漸失望轉行做開發去了。最後幾年下來的後果就是很多開發人員認為同級別的測試人員工資比自己高心態就失衡。

於是慢慢的測試要求就低了，要求高了也招不到人啊。

不過也有例外，比如滲透測試或者說挖漏洞也是軟體測試的一種，要求就是開發會的都要會，測試會的都要會，還要有智商，還要有毅力。比如像TK教主這樣的牛逼的「軟體測試人員」(大部分情況還是黑盒測試)，年薪和能力難道不是吊打各種開發？

本質不應該是這樣！測試和產品經理本身都是令人尊敬的職業，只是很可惜市場並沒有足夠的人才。更重要的是，測試和產品都是可以「將就」的，低級測試可以「點點點」，低級產品可以「抄抄抄」。而開發如果過於低級，會直接導致無法完成工作產出，所以開發的門檻稍微會「高」那麼一點點。