若干年前，我在知乎上看到一個很有趣的問題：
- 為什么互聯網公司不開除測驗，轉而讓大眾來測，找到一個Bug給100元？
答：大家的討論很有意思，不少都是圍繞100塊夠不夠、給不給、怎么給來說的，我的角度是，測驗是產品團隊里一個重要的角色（團隊早期可能由產品經理來兼任這個角色），沒了他們還真的不行，
- 默認前提是，開發已經做了單元測驗和冒煙測驗（原則上冒煙測驗應該測驗來做，但人家都被你們開除了啊，只好讓開發來做了，至少要保證交給大眾的是一個能跑起來的產品），這兩項總不至于期望大眾來幫忙做吧，
- 很多Bug其實并不是非黑即白，也許產品就是這么設計的，這些內部的測驗知道，但外部的大眾不知道，他們用起來覺得不爽，當Bug提了，這錢是給還是不給？哪怕公司內部，當測驗發現此類問題（比如為了安全考慮，第二次輸入密碼的確認框不允許復制粘貼），開發說這是一個需求/特性，還得再把產品經理叫過來一起討論，外部可做不到，
- 專業的測驗需要測驗用例（Test Case），但常見的測驗用例（臨界值相關、記憶體會不會泄露、特殊字符等……專業測驗人員玩起來一套一套的，分分鐘把開發認為沒問題的程式掛掉）在大眾那里可做不到，更不要說TC評審了，或者說，大眾永遠是知其然不知其所以然，所以只能做黑盒測驗，沒有辦法做白盒測驗，
- 專業測驗提的Bug是分級的（成熟的產品應該有Bug分級標準和規范），研發流程里應該有相應規定，幾級以上的Bug必須全部close才能發布；開發也會按照級別來確定修復順序，并不是所有的Bug都需要馬上修復，而大眾提交上來的Bug，還得額外安排人去做分級Review，
- 專業測驗會把Bug指定給特定的開發或產品經理，背后的邏輯是這些特定人員知道技術角度的模塊劃分，以及對應的負責人，只有這樣才能方便流程向下執行，而大眾提交上來的Bug，還得安排人去做assign to這個動作，
- 專業測驗懂得用開發明白的語言描述Bug，能說清楚是什么機器、什么系統、什么版本，特別是能說清楚“如何重現”，而大眾提上來的Bug，出錯環境不明確，Bug重現不了，急死你，
- 內部經常有針對Bug的討論，部分Bug可以defer或reject，那么問題來了，誰來牽頭組織討論，以確定Bug狀態的流轉與控制？可不要指望大眾會“跟進”自己提交的Bug，
- 如果開發比較牛，能理解大眾提的Bug，但改完后誰來確認是否修復，誰來close這個Bug，整體的回歸測驗誰來做？
- 以上還只說了狹義的功能測驗，性能測驗、壓力測驗怎么辦？大眾沒法幫你模擬10萬人同時做某個操作，還有，自動化測驗誰來做？
- QA——質量控制相關的事情還沒說呢，
- 其實，這個做法接近于UAT（用戶接受度測驗），也有人叫驗收測驗，經常由產品經理代表用戶做（當然，有資源最好讓用戶親自來），不是找Bug，而是看產品是否滿足用戶需求、設計是否符合用戶認知，等等，
- 這事兒很好，有條件都做吧，但更多的目的是找個理由和用戶互動，而不是找Bug，
所以，測驗還是很重要的吧，雖然在早期團隊中，經常“全民測驗”，但這個角色與產品經理截然不同的思維方式（產品抓大放小，測驗關注特例），對團隊是個很有必要的補充，
最后給大家準備了一份測驗人福利！
對想要進階自動化測驗的同學來說是非常有幫助的，關注我微信公眾號：程式員二黑，免費獲取！
想進大廠，想升職加薪，想改變現狀，那就請抓住每一次人生揚帆起航的機會，在寶貴的青春年華抓緊學習~
推薦閱讀：進了位元組跳動之后，才發現師兄給的這份資料有多重要！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/328993.html
標籤：其他
上一篇：Chrome擴展::試圖理解chrome.runtime.sendmessage到chrome.runtime.onMessage的語法