標籤：
知乎上有一篇文章： 軟體測試員比軟體開發員要求低些嗎？ http://www.zhihu.com/question/20156659
其中有段回答：
“
陳甫鵃，生長於閩，求學入秦，漂泊適燕，實秦人也。聊天、莫雙、iamhaha 等人贊同現實地說，我得承認@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.：關於我的一些狀態變化的解釋。
我承認我前一陣子剛剛從測試轉到了開發。雖然在這個背景下為測試說話貌似在打自己的耳光，但確實值得說道說道。我必須得說我轉崗位的理由和@馮東 老兄所說的理由不符。我之前負責的是伺服器相關，現在轉到了語音。這兩個部門的差別恰恰滿足我之前分析中提到的一個關鍵差異，即從一個對應用情境和部署要求非常複雜而演算法要求相對較低的部門，轉到了一個對部署要求非常簡單而對演算法要求很高的部門。平心而論，這個新崗位對測試的要求以及發揮空間其實比原來的部門要低很多。對我來說我兩者都可以做得不差，那麼我當然會希望找一個更有挑戰性的職位來試試看。另一方面是作為一個五年的測試，我也希望換一個角度看看自己之前的崗位是什麼樣子。對於這個選擇，我多少也是遺憾的。
所以我換了一個崗位，但是我換崗位的前提是我兩者都能做，而且領導也願意給我這個機會。這和兩個崗位孰高孰低並無干係。
”
------------------------------------------------------------------------------------------------------------
我的思考
從開發人員角度講，開發人員對自己寫的代碼的品質負有不可推卸的責任，必須自己擔起品質的重任。
從測試者角度講，測試的主要目的是提供一個監視軟體品質的功能，一定程度上降低在快速開發的時候引入bug數量，防止對已有穩定的代碼造成負面影響，提高開發效率。
從管理者角度講，提高軟體品質關鍵還在於提高開發人員的技術水平和素質，可以從幾個方面入手：
1.減少測試人員的數量。
不能讓開發人員對測試人員形成依賴，比例要控制在一定的範圍之內，比如Google的開發人員和測試人員比例為10：1，怎麼做到的呢？
“
經過與段念先生的交流，我瞭解到Google中國的測試工程師只有十多個，外包大約二十多個。從絕對數量上看，測試工程師的數量確實不多。但，在Google，測試有一個721的原則：70%的測試工作在底層介面測試和單元測試；20%的測試工作在整合測試；10%的測試工作在介面測試。之所以做這樣的選擇，源於Google工程師對測試的一些看法。Google工程師認為底層介面測試及單元測試的自動化成本比較低，自動化的程度高、穩定性好。在段念先生看來，基於介面的自動化測試時最難的（他反覆向我強調這個觀點）。我基本上認同這個觀點。然而，關鍵的問題在於，這與1:10之間有什麼關係呢？
從軟體產品品質控制來看，開發工程師提交的代碼品質越高，測試成本也會相對變小。首先，高品質代碼的可測試性強，自動化成本低，測試成本會明顯降低；其次，高品質的代碼會使系統bug絕對數量減少，測試工程師消耗在bug上的時間減少，因而與開發之間的溝通成本明顯降低；再次，高品質代碼的返工率會降低，研發流程更加順暢，效率更高；最後，單元測試和介面測試的自動化持續整合也可以有效降低迴歸測試的成本。Google工程師的價值在於將70%的工作花在提高系統架構和代碼品質上。因此，1:10也不難解釋了。
”（摘自http://www.taobaotest.com/blogs/show/1171）
2.提高開發人員的能力和素質，怎麼提高呢？
一方面招人的門檻要高些，起碼有潛質，且做人方面踏實認真負責；
二，在團隊內部”懲惡揚善“，褒獎好的，樹立學習的榜樣，懲罰最不好的，杜絕懈怠心理，但是懲罰的方式有很多種，扣錢屬於最下等，最好是比較有意思一些的懲罰。
三，多搞一些團隊一起參與的活動，增加同事間工作之外的聯絡，互相信任對方，把團隊的力量擰起來，要讓團隊成員內部知道，一個成員做事做不好整個團隊會受到影響，接受懲罰，只有大家互相協助，整體提高才是目標，有人不認同這種方式要離開也沒關係，尋找合適的人，組建一個強大的團隊而不是參差不齊的團隊成員。等等。尊重並滿足員工的合理要求，關懷員工，這是公司對員工的好，“懲惡揚善”，光明磊落，不要讓你的員工對公司產生怨氣，員工自然從心裡更認同公司，從而對激發員工從內心真正的想要做好這樣一件事的心態有協助。
軟體測試員比軟體開發員
