1樓：牛鷺軟體測試
平常心對待。能吐槽的多了去了。
測試的工作在公司不被重視，測試定義的測試標準完全被無視；
環境差異，測試環境沒問題，但是在生產環境就各種問題；
沒有明確的需求，總是說改就改；
沒有測試流程概念，需求評審階段因為沒做到及時溝通，導致產品經理、開發、測試需求理解不一致；
測試完全沒有上線的話語權，沒有版本概念，說上線就上線，不通過測試直接上線，有遺留問題還是需要測試背鍋；
開發因為自己開發時間不夠，壓縮測試時間；這種建議直接寫測試點，確保本次上線主流程沒問題，本次主功能各種場景以及異常情況都要覆蓋到，一些不影響主流程的bug(例如UI細節，頁面展示等可以下一版本進行修復)。
一句話需求，沒有明確的需求文件和原型圖，開發未理解透徹，直接開始幹了，幹著幹著開發覺得需求不合理私自改了，大多數在不影響大功能情況下是默許的；
乙個人負責多個專案，少則四個，多則8到10個，很多專案一旦衝突並行，難免漏測，畢竟乙個人精力有限，我想說的是，老闆，咋那麼扣呢，就不能多請個人？
也有測試同學自身原因的，比如業務理解不透徹、用例設計覆蓋不全等等。每次出現漏測的問題及時總結覆盤，漏測情況會越來越少。
公司環境改變不了的情況下，只能盡量改正、提公升自己，自己沒問題的話該甩鍋就甩鍋。
最後對於做業務測試的同學來說：業務測試無非涉及到系統的增、刪、改、查，設計測試用例增刪改查結合需求，結合業務場景及自己經驗及各種異常情況，可以在一定程度上降低漏測。
2樓：Jamie.Wang
漏測bug是正常的，連阿波羅太空梭都有bug。不過所有漏測的bug都要分析，以改進測試的方法、流程、規範，以免以後再次漏測
3樓：睡不著的包子
公司和制度問題，很多公司對測試理解都是點點加背鍋
像我的公司，制度就挺完善，每乙個需求改動開發必須註明改動地方，你所測得測試點也要備註，最後出了問題這些都是證據咯，當然一般小紕漏漏了，你沒測那就挨批咯，但是不存在什麼事都是測試背鍋了，現在測試行業發展迅速，對測定人員要求越來越高，但隨之待遇也越來越好，地位也越來愈高了
測試還是比較朝陽的行業了感覺
4樓：永遠的優
作為乙個專業坑開發的測試，很有慾望回答這個問題。
首先測試一般都會寫乙個測試用例吧(Д)ノ
版本測試時測試的內容範圍什麼的都有確定……如果是必現的情況，重現方式也是用例裡面有明確寫出的操作……那真的是測試的鍋6……其他的情況最多也只是總結經驗下不為例而已……畢竟乙個人是幹不過成千上萬的使用者的害怕
或者……老闆單純想找個背鍋的←_←
5樓：張敬峰
瀉藥我們先來說說什麼算是漏測，在當前團隊的技術能力範圍內及測試流程內應該發現而沒有發現的問題，這樣才算是漏測，對吧？對於漏測我覺得承擔責任天經地義，畢竟你吃這碗飯啊。
重要的是要總結經驗教訓，同樣的坑別踩第二次。技術不足的學習補齊，流程不足的規範流程。
你怎麼看待軟體測試這個工作的？
POPTEST研學圈 前幾年軟體測試行業還是乙個風口，隨著不斷的轉行人員以及畢業的大學生也都瘋狂的湧入軟體測試行業，就目前軟體測試行業的 缺口 已經基本飽和。當然我說的是最基礎的功能測試的崗位需求其實已經很少了，而自動化 效能 安全乃至於以後可能出現的大資料測試 AI測試仍然存在著非常多的機會。很多...
測試qa一枚，當發現bug後，怎麼回懟程式設計師的 如果沒有bug 你們不就下崗了？
乙個專案組的人，合作才是關鍵，何必抱著對立的心態？從需求到發布的每乙個環節都是為了保證專案符合預期，那麼如果換個合作態度，QA跟程式設計師一起梳理哪一類問題較多，大家應該多關注哪些方面，如何去改善Bug率，而不是這樣互懟，難道不更好嗎？ 不辣的皮皮 講道理就行了唄，誰還不是個憑技術吃飯的工程師了？如...
軟體測試面試題 專案上線後出現bug怎麼處理？
凹凸曼啊 先測試復現後提交BUG管理工具，考慮BUG的優先順序，在考慮修復的影響範圍和難易度，然後出對應的補丁包。再分析BUG的原因，判斷是什麼因素導致的問題，再前往BUG內容對相近的模組和類似的介面處進行複查，出現問題進行風險預防 瘋狂蘿蔔 專案上線後，出現bug，測試應馬上評估該bug所帶來的影...