testkuaibao|軟體測試自學公眾號
靈魂三問：
第
1
問：
為什麼這個 Bug 測不出來？
第
2
問：
測試怎麼測得？
到底會不會測？
第
3
問：
測試快點啊！
為什麼總是測試拖後腿，最後才報 Bug？
有朋友說：
對測試新人則是“
驚魂三問
”！
如果老闆也這麼問，
更驚魂
！
如果是開發人員問測試人員，則是“
甩鍋三問
”
如果是測試人員
自問
，倒是反思，不是壞事！
也有朋友說，
問了幾萬遍，就是沒有答案
要麼先看看網友如何懟回去的？
by @混子
如果是研發問，直接懟回去
：
1。 這麼簡單功能也出錯？
2。 研發怎麼開發的，會不會開發？
3。 研發能不能快點，為什麼最後才給我們打包？
如果是領導問，馬上認錯
：
對不起！對不起！對不起！
（注：似乎懟得不錯，但開發一定會再懟回來，1。 功能不簡單啊，如果功能不出錯，還要你們測試幹什麼？2。你來開發、寫給我看看？……
可能會引來一場格鬥
）
by @結婚兔子
具體問題具體分析吧：
1。
覆盤下為什麼沒有測出來？
是開發單元測試覆蓋度不夠，用例覆蓋度不夠，還是事實上就是難以覆蓋到，之後改進。
2。
把測試流程分享出來
，邀請業務方、研發、測試等等相關人員，一起完善。
3。
從流程下手
，需求開發測試都要排期，測試排期要有“底線”。實在不行，只能用老辦法，要麼砍掉不核心的需求，要麼延期；另一方面，做測試提效，自動化測試、提測質量准入、測試左移右移那一套都用上。
（注：這樣的態度很好，善於反思，從流程、技術、人等找根因，力求立行立改、息事寧人，但不懟回去，長期下去，地位會不會越來越低？ ）
by @BNN
1。
分析缺陷產生原因、復現條件
：測試環境能否復現？線上環境為什麼沒有復現？沒有復現影響多大？—— 如果是漏測，那就得認；
2。
擺事實
：講清測試方案、設計、方法，確認這個方案當時有沒有獲得一致評審透過？如果當時已經通過了，那就是大家的鍋；如果這些沒做，那測試當然就負主要責任；
3。
看看是不是測試階段總在做一些驗收性的測試？
如果是，驗收性測試本身就比較耗時間，測試時間不足，測試的深度自然也不足；如果本身不是做一些驗收性的測試，測試能夠提前介入，一般不會“最後才報 Bug”，這裡只需要列舉“提前”報的 Bug。
（注：和第二個差不多，首先從自身找原因，進行根因分析，case by case， 擺事實、講道理，解決問題是硬道理 ）
by @Ouroboros
看情況吧。如果是自己問自己，那麼就好好分析下。
如果是開發要甩鍋
，那麼就按 @混子 兄弟說的懟回去。
如果是領導問到了
，那就是時間緊、技術債多、開發不自測、基礎設施差、沉澱差、產品瞎B改，再道個歉，許諾個美好的未來。
最後說要用 TDD，需要一波 Money 或者其它激勵，來償還技術債，比如讓開發自測需要推動，基礎設施需要組織人做，都需要錢和資源。嗯，這麼看，好像還是個增收途徑。
（注：到後面跑題了 ）
by TW 餘同學：
這個問題一定很隱蔽吧？
不然怎麼會單元測試沒發現，自測沒發現，
整合測試也沒發現
，要不要一起分析問題的原因以便日後改進
這部分我上下文不足，可以和你pair一起測嗎？
如果你自己的程式碼有足夠的信心，不給測試留時間也可以，相信你可以控制好自己的程式碼質量
（注：第一個問題懟得挺好。第3個回答，顯得測試是多餘的？ ）
by 盤古 王同學：
目前看到的，我比較贊同評論是：
就在大家相互扯皮的時候，鵝廠又發錢了！
微信支付團隊拿到2019年公司創始人獎，獎金2個億，這還不包括年終獎（年終獎10個月起）。騰訊雲完成100億營收，團隊每人陽光普照，一人一部iPhone 11 Pro。
我們認真思考一下，快節奏的今天，
還拿出這些東西聊個昏天暗地，從本質上其實就在浪費時間，可以說這些都不是問題，是結果
。
原因太多了，大家都知道，但提出這些話題的意義是什麼呢？如果一個測試團隊還在這些東西上面浪費時間，那麼對不起，我們已經輸了，對手的唯一目標是推掉我方水晶！我們的目標在誰來背鍋。
如果這麼幾句嘲諷話語就逼瘋測試，那麼我們真的應該反省一下，自己有多脆弱不堪
，
測試也好開發也罷，共同目標是贏這一局，不是故步自封撇清自己！
最後一個同學，是不是說得很好？我把這段話從我的朋友圈搬到這裡，對我寫這篇文章不利啊，因為她已經批評我們“
還拿出這些東西聊個昏天暗地，從本質上其實就在浪費時間
”，那為什麼還搬過來了？因為有道理。
我們再回頭看那“靈魂三問”：
第
1
問：
為什麼這個 Bug 測不出來？
第
2
問：
測試怎麼測得？
到底會不會測？
第
3
問：
測試快點啊！
為什麼總是測試拖後腿，最後才報 Bug？
第1問
，不管是開發問還是老闆問，不管是為了甩鍋還是追究責任而來，都是需要回答的問題——產品上線後有遺漏的Bug，就需要問“為什麼”？而且不只一個“為什麼？”，按照根因分析方法，最多會
問五個“為什麼？
”，“為什麼這個 Bug 測不出來？”
這是第一問
，答案可能是：
沒有測試用例，會繼續問：為什麼沒有測試用例（案例）？
有測試用例，沒有執行或環境不對，會繼續問：為什麼沒有執行（或環境為什麼不對）？
只有這樣不斷深挖下去，才有可能找到根本原因在流程、在開發身上
。不問為什麼，是沒辦法讓開發和領導知道他們自身存在的問題。雖然我們知道：
測試不能窮盡的
一般軟體測試只是樣本試驗不是數學證明
開發寫出的Bug越多，測試漏掉的Bug越多
這些只是道理，懟起來，力量不夠。用
具體的case或事實來說明問題更好、更有力。如果上面五個“為什麼”追究下去，追到測試自身問題，那也說明測試自己沒做好，需要改善。
第2問
，的確說明問者帶有情緒了，是第一問經常被問住了？還是產品上線後問題比較多？如果是前者，回到“第1問”；如果是後者，這時可以用“開發寫出的Bug越多，測試漏掉的Bug也越多”來懟，最好用資料來說明，例如：
開發寫出1000個缺陷，測試發現Bug的能力是98%，那麼漏掉20個Bug
開發寫出100個缺陷，測試發現Bug的能力還是98%，那麼只漏掉2個Bug
這種帶著情緒的問，如上面王同學說，也可以置之不理。如果對自身能力比較自信的，可以懟過去：
開發有沒有做單元測試？有沒有code review？
咱們看看哪些缺陷是可以透過單元測試、code review能發現的？
要不要我們一個一個bug過，看看這些bug究竟怎樣逃過一關又一關的？
你們怎麼寫出這麼多缺陷？怎麼寫的程式碼？
這麼多缺陷，不都是開發寫出來的？
難道不知道 “質量是構建出來的、不是測試測出來的” 嗎？
咱們換一個位置，你來測，我來寫程式碼，如何？
有實力，才能懟
第3問
，這個問題要一分為二，如果之前前期發現的缺陷少，後期發現的缺陷多，測試的確要反思，沒有很好地採用“基於風險的測試策略”。如果前期也報了比較多問題，但最後也報了幾個缺陷，這比較正常。因為從目前現實情況看，測試常常是瓶頸，這是現實，因為測試人員少，開發：測試比常常是4：1、5：1或更高。其實，測試工作量沒這麼少，測試人員不僅要做新改動的測試，還要做迴歸測試，更何況許多開發沒做好單元測試和code review，如果再加上缺乏程式碼規範、程式碼質量不高，只能是惡性迴圈，沒有“銀彈”能解決這樣的問題。
這時候，如果一定要懟，就自然是：
測試是瓶頸，沒辦法，因為公司的投入就少、開發測試人員配比不合理
咱們換一個位置，你來測，我來寫程式碼，如何？
開發和測試是一個團隊，只有同心協力，才能取得成功。有時“為什麼”（如第1問）還是需要問的，只是更應該自問，
不斷反省，才能提高
。而且
自己有實力、具備有效的測試方法、測試策略，能夠講清測試故事、說明白自己所做的測試工作，就不怕問！
之後需要寫一篇“質量是構建的”，雖然每個人都知道。
如果沒完成了“靈魂三懟”，就算拋磚引玉，歡迎大家留言繼續懟
覺得文章不錯就點個在看唄，轉發就更好了
軟體測試之特殊字元
Web 協議跟抓包都不會也敢說自己是測試人員？
2021年10大流行軟體測試工具
軟體測試之冒煙測試
當我不小心碰了舊程式碼庫
女學霸考692分想當“程式設計師”，網友：快勸勸孩子
