為什麼互聯網公司不開除測試，轉而讓大眾來測，找到一個bug給100元？

12-25

我一時腦洞大開，請做測試的大牛來說道說道。

我的角度是，測試絕對是產品團隊里一個重要的角色（注意，不是自然人，創業團隊可能就是產品經理來做這個角色），沒了他們還真的不行，回答如下：

00. 默認前提是，開發已經做了單元測試和冒煙測試（原則上冒煙應該測試來做，但，人家都被你們開除了啊，只好讓開發來做了，至少保證交給大眾的是一個能跑起來的產品），這兩項總不至於期望大眾來幫忙做吧；

01. 很多Bug其實並不是非此即彼的，產品就這麼設計的，內部的測試知道，但外部的大眾不知道，覺得用的不爽，提了，這錢是給還是不給？哪怕公司內，測試發現此類問題（比如為了安全考慮，密碼第二次輸入確認的框不允許複製黏貼），開發說這是一個需求/特性，大家還得再把產品叫過來一起討論下，外部可做不到；

02. 專業的測試是需要測試用例（Test Case，更不要說TC評審了）的，常見的測試用例（臨界值相關、內存會不會泄露、特殊字元什麼的……專業測試玩起來一套一套的，分分鐘把開發認為沒問題的程序搞掛），在大眾那裡可沒有，不踏實，感覺……有點像西醫和中醫的區別，敏感話題不展開；

03. 專業測試提的Bug是分級的（成熟的產品也應該分級標準和規範），幾級以上必須全部close才能發布希么的，開發也會按照級別來確定修復順序，大眾提交上來的，還得安排人去分級review；

04. 專業測試會把Bug指定給特定的開發或產品經理，背後的邏輯是知道技術角度的模塊劃分，以及對應的負責人，方便流程往下，大眾提交上來的，還得安排人去做assign to這個動作；

05. 專業測試懂得用開發明白的語言描述，說清楚是什麼機器、什麼系統、什麼版本……特別是「如何重現」這件事，大眾提上來的，Bug重現不了，急死你；

06.內部經常有針對Bug的討論，部分Bug可以defer或reject，那麼問題來了，誰來牽頭組織討論，確定Bug狀態的流轉與控制？可不要指望大眾會「跟進」自己提交的Bug；

07. 如果開發比較牛逼，理解了，修完了，是否修復的驗證誰來做，誰來close這個Bug，確認修復？整體的回歸測試誰來做？

08. 以上還只說了狹義的功能測試，性能測試、壓力測試怎麼辦？大眾沒法幫你模擬10萬人同時XXX；還有，自動化測試誰來做？

09. QA相關的還沒說呢；

10. 其實，這個在方法論裡面接近於「UAT，用戶接受度測試」，有的也叫驗收測試，經常由產品經理代表用戶做（當然，有資源最好讓用戶親自來），不是找Bug，而是看產品是否滿足用戶需求、設計是否符合用戶認知什麼的；

11. 這事兒很好，有條件都做吧，但更多的目的是找個理由和用戶互動；

好問題，幫我複習了一遍和測試有關的概念，暫時想到這麼多，大家可以補充。

這麼說吧，以你們這些「大眾」的技術素質，別說什麼都測不出來，開發能不被你們氣死已經是奇蹟了。

我明白了，你們黑完程序猿黑產品經理，黑完產品經理黑UED，現在終於輪到測試了嗎？

-------------2016-08-23-------------------
看到另一個問題下面的答案，覺得能很好地回答這個問題。
微軟Windows團隊的程序員質量在下降嗎？ - 叛逆者的回答

--------------------原答案-----------------

我是在朋友圈看到同事轉發了這個，跑來嘗試回答一下這個問題。

看評論，有人說「你不怕只會測試不會寫代碼的測試殺了你嗎？」，還有人說「測試跟你有仇啊？」。總之有人開始不冷靜了，開始義憤填膺卷街了。這樣，是不好的……

有問題就問，是好習慣嘛~

好了，扯淡完畢。讓我們拋開各種私心雜念，客觀冷靜的看看這個問題。

題主這個問題問得很好，我很早以前也這樣想過。但是後來發現，這個問法本身就是有問題的。

我嘗試從幾個角度來分析，在正式分析開始前，我們先把範圍劃定在軟體開發這個圈子裡頭，再來看題主的問題有哪些問題，並且對這些問題進行解釋：

這部分包括這幾點誤解：

將開發階段、測試階段完全剝離。
對測試的理解有些偏差，誤認為測試只是在產品做出來之後，使用它，然後挑毛病，找bug。
誤認為測試只有功能性的校驗。

下頭對這3點逐一解釋：

1. 將開發階段、測試階段完全剝離。

讓我們來看看題主的問題：

為什麼互聯網公司不開除測試，轉而讓大眾來測，找到一個bug給100元？

這個問題有個假設，就是開發階段、測試階段完全剝離開了。開發階段單純地就是開發人員敲代碼，然後出來的東西交給測試人員去做測試。

我不否認，現在依然存在這樣的實踐方式。但是，這不是一個好的方式。因為這種流程，把發現bug的時間點推遲了。而發現bug的時間點越靠後，修復它所要付出的代價就越大。

這點應該很容易理解，比如你敲釘子，如果一口氣敲完了才發現，敲歪了，那就得拔出來重新來，可是東西上已經有一個很深的洞了。所以，好的方式是敲一敲，檢查一下，隨時糾正方向，確保前進的大方向是正確的。

軟體更是如此，某個bug可能是在最底層的地方發生的，如果早期發現，定位也容易，修復起來被牽扯到的地方也少，付出的代價可以接受。因為bug的產生可能是多個原因，有可能是功能性的，也有可能是對業務理解的偏差導致開始就做錯了。

如果在產品做出來，發布給最終用戶之後才發現。那個時候再排查到底哪裡出了問題，就不是一時半會能做到的了，代價很大。

所以比較好的實踐方式，是由專業的業務人員把要做的東西切割成足夠小的、彼此獨立的、可單獨交付的模塊，開發、測試以及業務人員及時溝通、及時反饋，一個一個小模塊完成，隨時做隨時測。把發現bug的時間點盡量往前推，這樣就可以把修復它的代價降得儘可能小。

當然，小模塊都通過測試，並不意味著所有小模塊拼裝起來組成的系統一定正確，還需要進行層次高一點的集成測試。這就引出了第2點。

2. 對測試的理解有些偏差，誤認為測試只是在產品做出來之後，使用它，然後挑毛病，找bug。

有這樣的偏差並不奇怪，因為執這樣想法的人太多了，甚至包括一些軟體行業的從業人員。比如有這樣的說法：

開發就是敲代碼的，測試就是找bug的

如果是業外人士，我覺得有這樣的誤解沒什麼。畢竟，隔行如隔山，但業內人士這樣理解的話，真的不知道該說什麼好了。開發是不是只管敲代碼，這裡不談。這裡我們要談的，是，測試不是單純的找bug。

現在我們承接第1點，來說說為什麼測試不是在產品做出來之後，單純的找bug。

先科普的一個東西，就是測試金字塔。

這是Martin Fowler的一篇博客中提到的，原文鏈接在這裡（TestPyramid）。

看不懂這個圖沒關係，我來慢慢解釋。

測試是分層的，它真的不是只有在產品做出來後才開始的，並且也不能那個時候才開始。原因在第1點裡已經解釋過了。一個工程級別的軟體產品，它的測試大致覆蓋了代碼級別的單元測試，模塊級別的API測試，還有端到端的集成測試。這並不全面，還有很多其他類型，這裡我們只是大概分成這3種，便於解釋、理解。

底部那層，就是代碼級別的單元測試。它是發現bug的最前沿陣地，能在這個層級抓住的bug，修復起來的代價，會小很多。而且這部分測試數量很大，驗證的東西也不是最終用戶所能理解的，通常都是自動化運行，有很多種框架可供選擇。只有這層的測試全部通過，才會運行後面更上層的測試。

中間那層，是service級別的測試，大概可以理解成模塊間的API測試。到這一層，基本每個模塊的功能都得到了保障，但是他們彼此的協作不一定正常，所以這層集中要測的就是不同模塊間的協作、通信了。這部分測試數量第二多，也是自動化運行。通過之後，就可以開始最上面那層的測試了。

頂部那層，這部分測試的數量最少，是UI級別的測試。測試的過程大致可以認為是，模擬使用產品的過程，最終用戶也能理解了。比如從註冊用戶開始，到註冊成功，登錄成功，頁面正確載入。這種校驗最基本功能的測試，叫冒煙測試，確保產品可以正確運行，沒有無法啟動之類的重大缺陷。除此之外，還有部分不便自動化的測試，需要手動測試，同時還會校驗一些邊角的情形。

即便上面說的測試全部通過，也不能確保產品萬無一失沒有bug，這是不可能的。只能說，通過了那麼多層的測試，產品處在一個穩定狀態了，最終用戶的使用體驗良好，絕大部分需求都可以滿足。

3. 誤認為測試只有功能性的校驗。

題主之所以這樣問，可能在一定程度上會誤認為，測試只是在使用產品的過程中，發現了功能上、界面上不合理的地方，報告給開發，他們修復，就結束了。

其實不然，測試除了功能性的校驗，還有安全方面的測試、性能方面的測試、兼容性的測試，等等等等。一個負責任的企業，不可能把包含安全漏洞、性能奇差、對運行系統有各種吹毛求疵嚴酷要求的產品發布給普通用戶，就算他們敢發布，用戶也會選擇唾棄他們。所以在發布產品之前，肯定有這方面的測試，而這方面的測試，不是普通用戶所能勝任的。

喏，現在看到了吧。其實測試也是一個複雜的工程，並非單純的使用最終產品，找到其中的缺陷和問題，再提交這麼簡單的事情。

-----------------分割線----------------------

說到這裡，我猜想，題主所說的讓大眾去測試，去找bug，很大程度應該是指測試金字塔中，位於頂層的那部分。讓用戶通過自己的使用，遇到bug直接報。

而且，前面也有人回答了，單元測試那些是開發做的。對於那些測試金字塔中層級較低的測試，可以由開發人員或者其他相應的技術人員在產品發布前解決。對於那些層級高的，比如UI級別的測試，可以分發出去，讓最終用戶來測試，並且獎錢！

OK，沒問題。那就依照這個說法，我再來解釋為什麼UI級別的測試也不能不管不顧的直接扔給最終用戶。前面有人也提到了相關的東西，我在這裡依舊分幾點來說，先來個summary，主要是這幾個點：

測試是一項工程，需要計劃、策略。不能無腦亂來。
對於bug的描述和修復，是有相應要求的。普通用戶做不來。

詳細解釋如下：

1. 測試是一項工程，需要計劃、策略。不能無腦亂來。

即便對於大家認為沒有技術含量的手動測試，也要制定相應的測試策略、測試計劃。確定使用什麼方法去測試產品，如何測試，開展測試時如何組織測試用例，人員如何分配，團隊如何分工合作。如果沒有這些綱領性、指導性的東西，面對產品那麼多的功能，全憑腦子想，用到哪裡測到哪裡？這個真有點天方夜譚了。蘇傑的回答中已經提到不少。

要構建這麼多測試，是需要團隊內的人員一起努力、合作的。要考慮哪些東西需要提前注意，哪些情況需要單獨拿出來測試，哪些東西不重要可以不測。在開發的過程中就盡量避免出現問題，而不是等它出現再修。

2. 對於bug的描述和修復，是有相應要求的。

還是那句話，測試是一項工程。發現了bug，需要把它用合理的形式記錄下來，反饋給開發方，再經過多方人員的溝通，修復，回歸測試，才能確認修復好了，再次發布產品。

對於記錄bug也有一些要求，比如要闡明在運行什麼系統下、系統的版本、產品的版本、如果是瀏覽器中打開還要標明瀏覽器版本、重現步驟、提供截圖、提供測試賬號。

開發人員拿到bug後，可以根據那些信息嘗試快速地復現bug，再定位，再修復。如果中間出現問題，需要跟報bug的人員溝通、確認，是產品本身就如此設計的？是偶然發生無法復現的？是優先順序很低暫且不用管的？

這些事情，如果是在團隊內，很好實施。如果需要跟用戶做這樣的溝通，那真是……費死牛勁了。

所以，即便大家都認為沒有技術含量的UI測試，也不能直接扔給用戶去做。

最後，最重要的一點在這裡：

用戶使用產品，享受的是體驗，目的是高效舒服地解決自己的問題。

如果沒有任何測試，直接把產品扔出去，讓用戶負責測試。前面提到的安全、性能、兼容性還有功能上的各種問題，任何一個都會導致用戶崩潰。

別的不說，如果12306在發布後，你的身份證號、買票的銀行卡號、密碼會被隨意泄露，你會用嗎？你願意用一下，冒這麼大的風險去賺那100塊錢嗎？

就算安全足夠好，但是性能差，12306在高峰期卡成什麼樣，罵的人少嗎？

還有使用過程的體驗，不少文章也批過12306的購票體驗差吧，還說搶票插件的體驗真不錯！

這些東西都是測試過程中可以發現、避免和修復的。但直接放到最終用戶使用的階段再處理，市場那麼多競爭對手，你的公司敢這麼玩嗎？你以為就你一家搞壟斷業務啊？啊，不對，好像說錯了什麼……

澄清一下，我沒有黑12306的意思。畢竟高峰期買票的人那麼多，購票的流程又是那麼複雜，網上也有不少帖子分析過，還是阿里的工程師寫的。我們祝12306能吸取大家提的有益意見，及時改進，越辦越好！

所以，無論如何都不能把質量沒有保障的產品，直接扔給最終用戶去做測試。

-----------分割線----------

最後感慨一下，大家普遍對測試有一定程度的誤解，覺得測試就是在界面點點點，找幾個茬，就算完事了。

其實，測試需要專業的人士，需要對產品的透徹理解，需要對用戶的同理心，需要對市場的把握，需要足夠好的大局觀，需要足夠的耐心，需要一定的技術功底，需要寬泛的知識面，需要良好的溝通能力，需要能夠協調團隊中不同角色。

說的好像很高級，好多事情是產品經理或者項目經理乾的活，但是，說實話，想做一個好的測試人員，這些東西真的都需要。

當然，如果願意踏踏實實做一個點界面的人，那就不需要這些。

-----------又是分割線----------

說句題外話，從另一個角度看，題主這個建議其實很好，企業可以發布產品後，懸賞bug。對提出合理bug的用戶予以一定的金錢獎勵，這倒是一個不錯的營銷手段。

再響應一下現在很熱的口號，「工匠精神」，作為一個有工匠精神和責任心的企業，怎麼能容許自己的產品質量沒有保障就直接交付給用戶呢？

-----------還是分割線----------

既然說了好多測試相關的東西，不如多說一點，跟題主的問題關係不大。Google出過一本書，叫《Google軟體測試之道》，裡面提到過一些觀點，原話記不清了。我說說我的理解：

盡量把測試往前推，儘早發現，降低修復成本；
測試的目的不是發現bug，而是預防bug的發生；
當各種測試做的足夠好的時候，即發布的產品質量有足夠保障時，一些不重要、影響小的問題可以不考慮，直接發布產品，用戶發現提出反饋後，酌情修復；
通過各種技術手段和流程改進，逐步的解放公司內部測試人員，讓他們把精力放在對產品的把握上。

---------------最重要的----------

第一次回答問題，知乎的編輯器真的好難用，可不可以支持markdown啊？

這樣是不行的。因為不同人對軟體完成度的忍受能力是不一樣的。內部版本的那種軟體質量，往往只有測試人員的心理素質能承受。

為什麼軟體測試要分自測，內測，公測？為什麼要有單元測試，集成測試，用戶測試？為什麼要用阿爾法測試，貝塔測試？

題主的意思是把阿爾法版直接發到公眾，然後你猜會得到什麼結果呢？

這軟體能用？這軟體真爛，這麼爛還好意思放出來，滾粗，一生黑，誰用誰傻叉。

一言以蔽之，阿爾法版本軟體質量較低，直接開放給公眾會極大的降低口碑，造成該軟體見光死。

所以，無論叫什麼名字，軟體質量以及穩定性必須達到一定程度，才能夠開放給公眾，如果過早的開放給公眾，要麼公眾完全不感興趣，要麼會受到過多的負評價導致口碑下降，對營銷有強烈負面影響。

那麼，如何評價「這個軟體的質量與穩定性達到了可以發放給公眾測試的程度」呢？

答案是：你還是要靠測試人員。

眾測的門檻沒那麼低的，給幾個網站給你看看，你也可以註冊去看看，看看需要什麼門檻才能開始測試以及獲得較高的報酬。

Software testing services | Crowdsourced testing
We test mobile apps and websites. We call that crowdtesting.
Crowdsourced testing

另外，眾測的定義：
Crowdsourced testing

眾測不是說你隨便把產品給個隨便什麼都不懂的用戶，就叫做眾測。更不是說沒有計劃的測試。Google 都在用眾測，在 How google tests software 裡面，James Whittaker 都說了。

一般是 team裡面的 Test Lead 制定測試計劃，交給眾測平台，眾測平台再給符合資質的測試人員分派測試任務，最後根據 Bug 的數量或者測試任務的獎勵方式給予報酬。測試的內容是有嚴格要求的。

google 給出的理由是，他們發現自己的手工測試人員的效率沒有眾測平台高，從性價比來說，眾測平台比手工測試人員要好，因為眾測有更多 Variant 和 Scale，一個公司頂天了給你一個產品幾十個測試人員，也比不上一次過給幾萬人啊，況且你手機或者電腦的環境，幾萬人就有幾萬種環境啊，一個公司頂天幾百部手機，還沒那麼多不同的 ROM。Source: https://books.google.com/books?id=VrAx1ATf-RoCpg=PA107lpg=PA107dq=crowd+testing+google+james+how+google+test+softwaresource=blots=0_xsPPp9cRsig=B-m0A1YVDtXW26t09TeocMi2hUghl=zh-CNsa=Xei=YoqbVIz4NLLdsATH0IKYDAved=0CDoQ6AEwAw#v=onepageq=crowd%20testing%20google%20james%20how%20google%20test%20softwaref=false

看到有答案說是黑測試什麼的，覺得挺好笑的，這完全是分工的改變和業界的潮流啊。換句話說，這也是一種測試方法論，測試不只是什麼探索性測試那堆老套的理論。

回答這個問題前，我們可能需要先理一下測試工程師是什麼。

度娘說：

測試工程師，軟體質量的把關者，目前傳統的軟體行業還是以軟體測試工程師為主，但是在新興的互聯網行業大多還是以QA來命名這個職位，也就是質量保證。

以互聯網產品的工作流程圖為例

可以看到，測試的工作在開發之後，是產品上線前的最後一步。一般來說，當開發按照產品需求、交互設計、視覺設計完成軟體開發後，就把完成版本提交給測試，測試人員再根據既定的測試用例進行功能測試、兼容性測試、性能測試等，逐漸收斂BUG，最後才能正式上線。

測試的工作主要由四部分組成

功能測試：功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。

兼容性測試：指對所設計程序與硬體、軟體之間的兼容性的測試，包括軟體能否在不同操作系統、不同機型、不同應用軟體上、以及向前向後等兼容性能。

性能測試：通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試，以保證產品在大流量前提下都能正常運行，像我們熟知的負載測試和壓力測試都屬於性能測試，

安全測試：以發現安全隱患為目標，防止產品上線後被攻擊。

完成這些測試的步驟後，一款互聯網產品就可以正式上線了。

因此，測試既是產品的第一個體驗者（最早從開發手中接過成型的產品），也是產品質量的最後一道防線守衛者（做各種測試，保證用戶拿到的最終成品可用、易用）。因為測試的工作特性，他需要從用戶的角度出發體驗產品，這也決定了測試與開發、策劃、設計等崗位交流、溝通的時間也會成為工作的一部分，甚至承擔起整個產品的協調工作。這樣看來，把測試稱為QA（質量保證人員）也就一點不奇怪了。

測試無用論？

即使前面廢話了很多，對測試有偏見的人依然會說，

「測試的工作其實開發也能做啊，何必再設一個測試呢？」

會產生這種想法也並不奇怪，畢竟隔行如隔山，不過這裡我還是要指出，上面的論述的錯誤之處在於

（1）完全割裂了測試與開發工作

（2）測試的工作被簡化成找BUG

事實上，找BUG只是測試最初級的階段，雖然必須承認，測試的門檻低於開發，但優秀的測試人員工作量之大，專業度之高，絕非一般用戶能替代。

就像我們每個人都會接觸到的kpi指標一樣，測試的每塊工作內容也都有不同的能力等級劃分：

（1）手工測試，發現BUG

（2）通過各種手段，確認這個BUG是一個需要解決問題，然後確定該BUG的重現步驟並儘可能簡化

（3）了解被測產品框架，能從代碼中定位BUG源頭，並能給出可能的解決方法

（4）嘗試找出該BUG發生的原因，並能找出檢測同類BUG的方法（標準化）

（5）能在保障產品質量的基礎上，協調起整個項目上線的時間和流程

以上能力，是從授人以魚向授人以漁遞進的。

當你在執行前人的測試用例時，找BUG固然是工作要求，但最主要的用意是學慣用例的編寫思路和方法，從案例中總結出規律，進而開始自己編寫標準化測試用例，以免同類問題生出千萬條不同用例。

一個測試的能力，能達到的層級越高，團隊中的開發、策劃就能節省更多時間，團隊運行也會更高效。而專業的測試，正常來說應該比開發對產品有更深入的理解，對於可能影響測試的因素，像Tomcat配置、資料庫索引、多線程等都會有豐富的經驗。

從入門到精通測試，距離有多遠？

我始終認為，每個專業的學習與進步，都有賴於三個因素：

（1）堅持

（2）資源

（3）天賦

以第一個最重要，但第一個和第三個都不是外部可控因素，全靠自己，所以這邊也只能列一些可以參考的資源。

1、書

《軟體測試》

軟體測試 (豆瓣)

這本書可以幫你快速了解測試的工作內容，像理論概念、測試流程、Bug管理、自動化測試等書中都有詳細講解，看完後應該會對「測試人員の一天」有大致了解，入門級必備吧。

《軟體測試經驗與教訓》

軟體測試經驗與教訓 (豆瓣)

測試界領軍人物James Bach寫的，從測試的角色入手，全方位剖析測試的方法技巧、職業發展，文中有很多話都被奉為測試界的經典箴言，不愧是一路被坑之後撰寫而成的血淚史，不僅是測試入門的讀物，更適合搭配實際工作經驗一起食用，字字珠璣，常看常新。

《鳥哥的Linux私房菜.基礎學習篇（第三版）》

鳥哥的Linux私房菜.基礎學習篇（第三版） (豆瓣)

前面也提到，因為測試的特殊性，必須對開發環境、程序語言也了解透徹，因此除了了解測試之外，也可以去看看其他著作。《鳥哥的Linux私房菜.基礎學習篇（第三版）》作為遐邇聞名的 Linux 中文入門教材，行文淺顯生動，深入淺出，讀之往往令人慾罷不能，對於不喜歡啃晦澀大部頭巨作，但又想入門Linux操作系統的，都可以去嘗試。

《深入淺出Java》

深入淺出Java (豆瓣)

別看近700頁的大部頭，但因為是基礎書籍，翻來覆去都在用簡單通俗的語言將概念理清楚。能把書寫長不難，但能風趣幽默地把一堆概念準確明白的告訴小白讀者，這才是最厲害的，對於JAVA初級入門者，強推此書。

2、網路資源

TesterHome：TesterHome

51testing：51Testing軟體測試論壇

測試之道：軟體測試網-測試之道

三個測試交流的社區論壇，TesterHome更專註於移動App自動化測試，51testing比較老，有很多老牌測試，但不免與老版論壇一樣變得平庸化，測試之道比較新。論壇的好處在於可以分享交流，還有很多經驗之談，雖然測試用例在變，在努力的方式往往相似。

如果想快速上手，可以直接去網易雲課堂、慕課網等搜索測試課程，前者的《測試工程師》微專業（測試工程師微專業）是網易自己出品的，課程編排成體系化，授課老師是一線測試工程師，強調實踐能力，而且會定期考核節課，有預算、且缺乏自制力的同學可以考慮。後者上的課程都是免費的，但比較零散，適合想要長線作戰的同學入手。

另外，大公司的測試部門和測試大牛的博客都推薦大家去關注，大公司規範的流程、經驗大部分都是經過了項目錘鍊，能讓新人學會很多。而大牛，也有很多經驗之談，避免走彎路，已經是成功的捷徑了。

谷歌測試部門博客（英文）：http://googletesting.blogspot.com/

網易測試部門博客：http://qa.blog.163.com/

阿里測試專家公直博客：All about Testing

51testing優秀版主陳永達博客：陳永達的軟體測試

51CTO博客之星柳記：http://eilfei2000.blog.51cto.com/

著名測試專家邰曉梅博客：taixiaomei

專註於ios單元測試的優秀國外獨立博客（英文）：iOS Unit Testing

3、多練勤思

這大概是小學教師前經常會貼的一句話，但用在測試入門上也分毫不差，對於接受能力強的年輕人來說，本身門檻較低的測試入門不是難事。

有計算機基礎的可以先去啃啃書考個軟考，也可以去投投簡歷實習，大小公司都先可以，對重複的手動的測試工作上點心，總結規律，逐步提高，也跟前輩多多學習。

先入門，再入行就不難了。

軟體如果在交付後發現的修復成本遠遠大於剛開始的修復成本，所以測試要貫穿軟體的開發周期，而不是交付給用戶測試。

作為測試行業從業人員，軟體測試的組織者和管理者，我覺得這個問題很有意思，因此嘗試回答。

其實題主提出的這個問題，已經通過更加精巧的設計，作為正式測試的補充，融合在項目實施過程中了。

例如，業務人員或關鍵用戶的確認（UAT），商業Beta，RC版本，上線試用期等等，都會引入更多的利益相關者來對軟體實施測試。

但是，這種測試到底是否可以取代專業的測試人員呢？答案是，從成本和效率上來看，都很難。

從「發現軟體的更多功能缺陷」這個角度來說，如果賞金很高，那麼大眾的參與熱情也會相對較高，那麼缺陷肯定會被挖掘得更加充分——因為會有專業的測試人員夾雜在大眾中對軟體實施測試。可是，請不要忽略這一點：發現缺陷不等於該缺陷能被及時解決，更不等於該缺陷不造成損失。

舉個例子：如果是涉及到嚴重的漏洞，例如注入式漏洞，0day，交易邏輯錯誤，我不會選擇去賺那100塊，我會選擇等待你正式運營，然後套利。

中國的銀行們在處理預授權業務時，系統出現漏洞，被套利「很多」，造成了「一定」損失。

你要知道，黑客的道德水平是很高的，因為黑客發現漏洞後會選擇使用一種溫和的手段暴露它，提醒技術團隊去修復。而普通大眾，則是利用該漏洞進行破壞和套利。

另一方面，那些不值100塊的缺陷則會被大量的發現，在缺陷被發現一直到在某個發布中修復的過程中，將會有無數人重複提交該缺陷，並一直得到：該缺陷已經被發現的回應。你要為這個事情安排很多人去處理，你還要忍受這些失望的人們的咒罵和報復。

不要指望普通大眾會去搜索你的缺陷管理系統確認是否已經重複。專業的測試人員之所以是專業的，就是因為他們擁有這些專業的訓練，他們知道什麼樣的信息是有價值的，他們知道應當如何將最有價值的信息從垃圾中提前篩選出來，交給開發團隊。而如果是被100塊激勵後的大眾，那麼，你光處理這些無效缺陷就足以花掉所有你準備省下的錢。

一個缺陷報告的要求：

說明如何重現
說明為什麼是缺陷
說明影響範圍
不重複

我的團隊在實施UAT的過程中發現，只經過簡單訓練的業務人員提交的缺陷中，最初的幾天幾乎就是在做無用功，而在穩定之後，只有10%是有意義的缺陷，其他的不是已經發現，就是環境問題，就是無法重現，就是需求理解錯誤，就是不會使用，就是把建議當缺陷。

已經上線的項目之所以可以保留少量客服人員和運營人員的前提，是重大缺陷基本都被發現了，並且事實上用戶不太願意報告缺陷，他們寧可放棄你的產品。但是如果他們被物質激勵後，那畫面太美我不敢想。

以前B廠的測試一枚。首先測試的概念很廣啊。比如百度有個眾測平台百度眾測平台，可以看一下裡面還有調查問卷（我也是醉了，剛開始眾測沒這亂七八糟的），另外還有一些「找茬」的任務（我理解一開始就是為這個做眾測的），比如看下某個搜索詞出來的搜索結果是否都合理，比如推薦的相關廣告是否真的相關（這都是B廠主要的業務吧），一套策略寫好了，難免有些bug case，還有些東西需要人的一些主觀感受才能判斷，這種你靠有限的幾個測試想遍歷很多case是很難的，還不如召集大家的力量來做，然後給你獎勵。所以這些如題主所說，我覺得是可以做眾測的，但不是主要業務或代碼的測試，而是對已經發布的產品找些bug case，做些補充

那麼一個完整的測試呢，可能包括了需求理解，測試用例書寫，准入case，code review，功能測試，性能測試，極限測試等，如果走敏捷，免不了要做自動化測試、持續集成這些東西。還需要出測試報告，比如case通過率，千行代碼bug率，bug收斂狀態等等，這一定需要對業務和代碼都有足夠的理解，肯定是要自己團隊做的。加上功能升級後，很多回歸也需要以前的積累，如果眾包出去，換批人一切都要重新熟悉，這個效率和代價都扛不住吧。而且測試在實際項目中最容易被壓榨啊，因為項目經理可以delay，設計可以delay，開發可以delay，最後都壓給測試了，deadline不能變，測試只能對既成事實壓縮自己的工作量，所以靠譜的和強勢的測試都很重要，一個是push前面的流程按時過來（對需求、開發質量的把控力，前期介入的重要性），一個是真的要趕deadline了，也能按時完成。這個也不適合眾測，誰有這個責任心啊。。。

還有種情況，開發代碼質量很高呢，開發兼了測試，然後眾測去做些輔助的回歸行不行。的確很多互聯網公司起步的時候是沒有測試，自己開發自己測，加上開發相互code review一下，就發布了。如果小，可以，畢竟互聯網追求的是快，開發能力強可以這麼搞，而且現在用戶對互聯網產品bug的容忍度也很高了，你及時fix就行。但前面的成立有兩個前提，開發都很牛x靠譜，你也能容忍產品線上的bug對用戶的影響。但是團隊大了，就不行了，沒有那麼多靠譜的開發去自助保證質量，而且用戶多了，每一個bug對用戶群體的影響面也會擴大，所以還是早掉招個測試團隊吧。

所以眾測是有的，更多的是補充，但砍掉測試團隊，讓大眾來測，至少還沒有很好地模式來保證質量和效率

補充一點：提bug也是手藝活，牛逼的測試會告訴你復現步驟，告訴開發哪行代碼報錯，很多時候光看錶象是看不出來哪裡有bug的，做過開發的都知道，定位bug是多麼的痛苦。有時候測試還要安撫開發焦躁的情緒。

看到這個問題突然若有所思，不知道是不是因為在一個小城的問題，自從進了銀行櫃面發覺社會大眾的平均智商真的低到難以想像。每天都有人手裡拿著卡進門就吼，「ATM機拿不出來錢了！」然後我一般會問一句界面提示什麼？百分之七十的人說不出界面提示，百分之二十五的人的不懂提示上「密碼校驗失敗」「機器配鈔失敗」」取款額度超限」這些短語的意思，還有百分之五其他原因。一個功能不超過五個常用功能就一個的機器都能用成這樣我相信一個個軟體放出去會是排山倒海的」軟體用不起來啊！」」軟體用不起來啊！」軟體用不起來啊」

用戶不懂方法論，沒效率。然後讓用戶測的部分我們這裡叫uat，不可以點點系統崩潰的，異常退出的，不然用戶噴死你……
偶然聽說也有用戶組織一大批人馬按照實際業務來測的

如果認為測試的作用就是『找BUG』，恐怕它已經說明很多東西了……

90%的用戶反饋是「軟體用不了」、「軟體不好用」、「垃圾軟體死X家」。

然後追著你問為啥不給我100塊錢？

開除了測試，出了問題，誰背鍋？？開發？產品？還是UI？
而且，說實話。有測試多好，管理系統/WIFI/伺服器維護.....+測試工作，都可以交給測試做。（一些中小型公司）一個測試，出了不會開發/產品/UI。其他的都可以喊他去整。多麼省錢？？

最最重要的，你的團隊有測試，投資人不會覺得你好牛逼；但是你的團隊沒有測試？你是想讓投資人覺得你好low逼？

----------以上是從實際利益出發
從技術角度來說，沒有測試...黑盒/自動化/性能/安全....測試工作，誰來做？？
就拿功能測試來說，一個軟體N多條測試用例，誰寫誰維護？設計測試用例，需要你會拆解需求，分析測試點。然後會等價類/邊界值/因果圖....設計方法。
自動化測試，你好歹要會腳本？性能測試，你多少會去看CPU/內存/硬碟消耗？？怎麼去看進程消耗時間？累積數量？軟體結構體中，各個模塊的速率？
安全測試，你至少，抓包/sql注入/敏感欄位排查...要會？？
等等

說了那麼多，你覺得這些工作，開發/產品/UI，哪個願意去做？？

測試拿最少錢，做最雜的事，背最大的鍋。

測試不易，敬每個測試漢子/妹紙。

我覺得這個想法不錯

千萬不要高估大眾的智商，再簡單的功能一定有人不會按著你想的去用；

千萬不要低估大眾的智商，為了100元他們什麼都幹得出來；一個Bug絕對能拆成10個然後讓10個人來同時報。

實際上連專門招的測試工程師測的，有時效果都難以接受，搞得開發恨不得自己上。

現在大部分軟體公司都很重視測試團隊的情況下，大部分軟體的Bug依然不少。如果不用測試團隊，那麼軟體上市可能會被用戶罵死！

即使是免費，多數用戶也不願意為一個漏洞百出的產品當小白鼠，因為用的不爽。

當然，很多平台級別的產品，如Windows，會發布開發者預覽版，這些版本是給第三方的軟體開發公司或者個人用於預覽新特性，提前修改自己的產品的。這種版本早期的Bug通常是相當多的，但是因為利益相關，開發者還是挺願意幫忙找Bug的。

軟體測試也是一門學問。樓主的提問中，把測試交由用戶來做，也只是軟體測試的一部分而已。而僅僅只有這一部分，是完成不了軟體測試的工作的。

1.軟體測試的目的不是為了找bug，而是為了提升軟體的質量，讓用戶拿到一個正常的產品；
2.假定程序的bug是無窮無盡的，軟體測試當然是希望能用最少的成本（用例、時間、人力）找到儘可能多的有價值的bug，這需要專業測試知識，對於一般用戶來說，這個有價值的界定很難很難、能否遍歷產品功能也很難、能找到那麼多專業的用戶也難；
3.除了面向用戶的部分有bug，非面向用戶的部分也需要測試。比如軟體的抗壓能力、是否內存泄漏、互聯網安全、能支持多少並發（並發量大時會怎樣）等等；
4.用戶其實根本不一定能了解這個產品的全部功能，會出現漏掉的情況；

以上僅僅是對於測試的執行來說的。
從另一方面，
1.測試用例的設計。可能很多用戶他們的關注點在一個地方，會導致用戶的無用功。有些測試用例設計不全，有些測試用例又還有冗餘；
2.測試的跟蹤。如果在公司內部，測試人員可以很好的和產品、開發等團隊溝通，用戶測試就沒有這種效果，對於測試出來的問題沒有統一的管理；
3.bug回歸。除了本版本中bug需要回歸，用戶也不一定能很快響應回歸，同時大家都知道軟體一般都是迭代開發的，後面的版本中也有可能再次出現以前的bug，每一次版本的更新都需要將以前的記錄再次回歸一遍；
4.測試依賴於網路環境、軟體環境、硬體環境。用戶發現的問題，公司內部不一定能重現，也需要跟蹤了解用戶的整體環境；
.....

讓用戶測的根本目的不是為了發現bug,而是一種營銷手段，讓更多的人熟悉產品，使用產品，當然有bug反饋和需求反饋更是錦上添花