大家好，我是陳哥。

不知道大家看沒看過這個問題：

既然測試也要求寫代碼，那乾脆讓開發兼任測試不就好了嗎？

這句話聽上去像是測試人員被要求寫代碼的氣話，但我之前在《做軟件測試需要懂代碼嗎？》一文中討論過為什麼現在各個公司都開始要求測試寫代碼，大家感興趣的話可以去看看。

藉着這個問題，我想和大家繼續聊聊：為什麼不直接讓開發兼任測試？

説句實在話，對於大部分企業來説，這想法太理想化，真落地準出亂子。

開發和測試的核心價值和工作邏輯壓根不是一回事，硬把倆角色捏一塊兒，最終虧的是產品質量。

先聲明我的觀點，開發可以做單元測試、參與集成測試，但絕對替代不了專職測試。

一、思維慣性是道繞不過的坎

開發和測試最大的區別，不是會不會寫代碼，而是思維方式的根本對立。

開發是建設性思維，拿到需求就琢磨怎麼實現，怎麼把邏輯搭得通順，怎麼讓代碼跑得高效。

我們禪道團隊有一套自己的產品研發流程，我們會要求開發在迭代時進行自測。

但在這種思維下，開發在自測時會不自覺地按照自己的實現路徑去測試，很難跳出既定框架。

測試不一樣，他們是破壞性思維，核心目標就是找出軟件的漏洞。

我本身是測試出身，我當年做測試的時候，拿到一個功能一般先想的不是怎麼用，而是怎麼用才能把它搞崩。

就像一個登錄按鈕，開發自測的話一般確定賬號密碼正確能登、錯誤登不上就覺得完事了，但測試可能會測連續點五十次按鈕會不會卡頓，測用空字符、超長字符串當賬號會怎麼樣，測在弱網環境下登錄失敗會不會提示錯亂。

這些場景開發根本想不到，不是能力問題，是思維慣性的必然結果。

二、測試的核心價值不止於寫代碼

現在很多人覺得測試要求寫代碼，就和開發沒區別了。

這話只説對了一半，寫代碼只是測試的工具，不是測試的全部。

測試的核心能力是場景設計和質量把控，這些能力和開發的技術實現能力完全是兩碼事。

就拿自動化測試來説，開發寫自動化腳本可能比測試快，但測試寫的腳本更有針對性。開發寫腳本會聚焦於功能實現邏輯，而測試寫腳本會覆蓋邊界場景、異常流程。

我們團隊之前做性能測試，一個開發寫的腳本只測了正常併發下的響應時間，而測試補充了峯值併發、突發流量、長時間運行後的性能衰減等場景，最後發現的內存泄漏問題，正是在長時間運行的場景下才出現的。如果只靠開發的腳本，這個問題到上線都發現不了。

測試還要懂業務、懂用户。再説回禪道產品研發流程，正是基於這點，我們在計劃會階段會要求測試人員去做需求的測試實例化。

我們讓測試人員立足於用户操作場景，以“在什麼情況下、做了什麼操作、產生什麼結果”的形式澄清需求，從而轉化為測試用例，最終通過測試驗證需求。

這種對用户的理解，不是會寫代碼就能具備的，是測試長期站在用户角度思考積累的能力。

而且測試要對整個產品的質量負責，這種全局觀開發沒有。

開發通常只關注自己負責的模塊，而測試要打通整個業務流程。

舉個網購下單流程的例子，這涉及商品庫存、購物車、支付、物流四個模塊，每個模塊的開發只測自己的部分，但測試要從選商品、加購物車、下單、付款到查物流整個流程走一遍，還要測其中某個模塊出問題時，其他模塊會不會受影響。

這種跨模塊的質量把控，開發根本沒時間也沒精力去做，他們的核心精力必須放在代碼實現上。

三、獨立測試是團隊協作的壓艙石

有人説讓開發兼測試能提高效率，其實恰恰相反，會嚴重影響團隊效率。

開發的核心任務是寫代碼，讓他們兼測試，必然會分散精力。

更重要的是，獨立測試能形成有效的監督機制。這就像我們在學生時代檢查不出來自己做錯的題目，寫代碼也是一樣。這種監督不是挑刺，是對產品負責。

當然，現在行業裏的確有一些大公司搞開發兼測試，比如Facebook。

眾所周知，Facebook程序員的水平高於業界平均水平，他們有足夠的能力同時做好開發和測試工作。

再這，Facebook在功能發佈之前，會先發布到內部環境中，幾千內部員工先測試。這看着是沒有專職測試，但本質上是把測試的能力拆分到了不同角色裏。

我們中小團隊沒這個條件，最靠譜的還是讓專業的人做專業的事。

開發和測試不是替代關係，是協作關係。

開發負責把功能做出來，測試負責把好質量關，兩者目標一致，都是為了做出好產品。

現在測試要求寫代碼，不是為了變成開發，而是為了更好地履行測試職責；開發參與單元測試，也不是為了替代測試，而是為了提高自己的代碼質量。

真要是把兩個角色合二為一，看似省了人力，實則丟了質量，最終只會撿了芝麻丟了西瓜。

如何劃分開發和測試之間的職責，這就是另外一個我們值得探討的課題。

希望我的分享可以幫助到你，也歡迎給我留言與我討論。