1樓：ECGZ
首先要明白開發是否誤解了你的Bug,比如嚴重程度，重現概率之類的，這些可以多與開發溝通解決；
如果確認開發沒誤解，那就走流程吧，你列舉應該要改的理由，開發列舉不需要改的理由，由專案經理之類的高層決定，而且比較正規的話，作決定那個人也不是口頭說說就算的，要有記錄；
經過幾次之後就應該對產品有些認知，某些bug可能在專案經理的心目中優先順序不高，以後再碰到這種bug時就要降低級別，或者不報bug都好，也要在測試用例集中做好備註說明不報bug的原因
2樓：任衛
這個，這是很正常的社會現象。
特別是特別說了，不同問題會有不同的處理結果，我認為這個非常好，說明開發團隊是較為認真權衡後的結果。
可容忍的、不重要的、不可復現的、投入很大收益又太低的、需要延遲修改的等等，都有可能是原因，特別是很多時候還有互相衝突的需求/issue，開發人員也很難辦啊。
有需求有bug，流到開發組後，第一步就是進行研究分析，會出分析報告，會說明故障原因、修改的初步方案、預估時間等等，特別是若需要拒絕，在報告裡會更詳細地說明原因的。這個分析報告儲存在issue系統裡由專案組決策就完事兒了。提完bug後一般不需要測試人員再介入了，好不，當然，測試人員要在文件裡詳細說明故障復現步驟的。
最後，你想，不可能測試人員提交的任何bug都得被接收進行修改啊，這樣的話，你豈不擁有了比需求方、比專案經理更大的職權了，凡事都提個bug就行了，爽不爽。還有比如你提乙個類似ubuntu的1號bug那樣的，無限將軟體邊界擴大怎麼辦？對不對
流程，讓規範的流程來解決這個事就行了，不上火。
若真想讓bug接收率高一些，就在bug報告裡更詳細地說明原因說明影響，對比競品等等，寫乙份無法拒絕的issue。
3樓：茫茫丶
拒絕修改？
懟ta！
1.明顯與需求不符的@PM就行！
2.明顯功能問題，直接找他領導！
3.技術有限的，換個人就行了！
就這麼簡單～！
4樓：乙隻小蟲子
找相關人士確認，做好記錄存檔備查。（不好聽一點稱之為甩鍋）
bug錄入
1.必須使用可以備查的系統：禪道，bugzilla，jira等錄入bug
2.bug描述要清晰，步驟要準確，寫明bug發生的環境，賬號資訊
bug處理
1.測試人員提出bug後，開發會確認是否為bug，修改後由測試人員驗證，通過後關閉，不通過則打回，迴圈往復，如果迴圈很多次，這個開發可能要被掛出來示眾了
2.bug處理結果：已修改，重複bug，無法重現，不予修改，暫不處理
好了，其中無法重現，不予修改，暫不處理都屬於不修改的情況，分別分析：
無法重現：測試人員想辦法重現，可以整個專案組約定，比如1個月都無法重現的，bug關閉，再次出現時開啟
暫不處理：開發不可以自己確定為暫不處理，必須產品或更高一級的負責人來確認bug暫不處理，並說明何時處理完成，設定時間，由測試產品跟蹤。
至於如何善後，嗯，所有是bug而不改的bug，在最後由除了你自己和對應開發之外的乙個相關人士，比如產品，負責人等確認，並郵件全體。當然，當出了問題時，給你機會說，你能講清楚，不然該背的鍋是逃不掉的。
5樓：千鋒軟體測試學院
題主的態度看起來還是蠻中立的, 這是蠻好的工作態度, 贊乙個.
其實並沒有那麼多的陰謀論, 拒絕修改是表象, 需要我們去溝通背後的原因是什麼, 無外乎就幾種:
缺陷步驟描述不清晰, 開發無法重現缺陷
你和開發人員對需求的理解不一致, 他堅持認為自己的理解是對的, 因為會拒絕修改你的缺陷
時間太趕, 來不及修改這些缺陷, 這些缺陷有可能是嚴重程度不高的缺陷;
修改該缺陷的風險太大, 有可能會引起更多的缺陷
以上是不修改缺陷的場景, 那麼針對每種場景, 給你建議對應如下:
如果是步驟描述不清楚的話, 那麼打回去描述清楚再指派給開發
拿出需求文件或者向產品經理確認, 誰的理解正確, 再來確定缺陷是否需要修改
如果原因屬實, 那麼測試人員確認缺陷不修改對產品影響不大, 那麼不改就不改咯
如果缺陷的嚴重程度不高, 修改之後回歸測試工作量太大的話, 那麼保持原樣吧, 畢竟會帶來的後果不確定.
6樓：
1.一方面應當馬上告知測試負責人，並檢查問題的log、問題的操作步驟/路徑等是否有儲存並詳細；另一方面可以請測試負責人來協助完成問題定位，進一步確認問題的原因，是否是開發側的問題。
2. 如果是開發側的問題，說明分析/定位問題的思路和結論，再轉給開發，依舊拒絕的話，可以請專案PM協調解決。
7樓：怪咖啡
首先要開發說明不修改的原因。
如果是需求設計如此：拉上產品一起確認是否要修改如果真的是bug，必須要修改，最好是定位到bug原因，讓開發無言以對。
定位bug原因也是測試人員能力之一，越清晰原因越好，也意味著測試能力越強。
8樓：JTHH
測試過程中每乙個bug都需要有人負責。
一般bug處理流程：
提交bug
開發拒絕，並備註理由（在bug管理系統內）測試人員不認同拒絕理由
與開發當面或IM或郵件等方式溝通
開發認同bug？bug管理系統備註理由，以及確認結果，重新指派會開發開發不認同？找到專案負責人（對專案或版本能拍板的人）說明原因和開發溝通結果，並說明自己認為是bug的理由，有最終負責人決定處理意見，並將bug指派給該負責人，由他備註理由後測試人員再確定是關閉還是指派給開發
（bug的具體流轉細節每個公司不同，但大致流程如上。如果你不是妹子或情商不高，切記不要和開發發生爭論或爭吵，和開發站在平等的高度闡述理由即可）
9樓：
非問題:說明白為什麼不是問題，回歸。
是問題:說明白為什麼不改，回歸。
否則還能怎麼辦？掛起，出FAQ唄。
總之，大家講道理。
10樓：捉蟲布道人
開發人員說不是bug，拒絕修改，其原因一般不會是開發故意不改，無非有兩種原因：
1、就是需求沒有明確，這麼做是可以的，這時我們可以找產品經理來確認，3方商量確認後明確改與不改；
2、開發會認為這種bug不可能發生，所以不需要修改，這時候我們可以盡可能地指出bug可能引起的後果，盡量說服開發去改，如果不能達成一致，則需要測試經理和開發經理進行確認。如果有些確實不是很明顯的bug，我們可以提建議級別bug。
如果開發人員不修改也沒有大問題。如果認為是bug就一定要堅持，並最終要得到確認，最好是錄入到bug庫，這點其實很重要。提了開發改不改是一回事，如果不提的話，上線出了問題，那一定是你的問題，為了保護好自己，感覺是問題的就一定要提，如果開發認為沒必要，也不要聽他口頭回覆，一定要走bug流程，讓他在bug單中填寫不修復理由就行。
只能幫你到這了。
11樓：annimy
1.首先自己先核對需求文件或者跟產品經理確認自己所提交的問題是否是bug且是否能夠重現
2.如果確認清楚確實是bug且可重現，則繼續將該bug重新指派給對應的開發，且嘗試將自己確認的結果與開發溝通，如果開發仍然拒絕修改則將bug掛起，並向上一級領導或者研發經理反饋或者在晨會、測試報告中指出遺留bug風險，待上級領導們決策是否需要修復，是否在該版本解決，或者是將將該bug作為遺留bug在下個版本解決
12樓：智鴉
將bug錄入缺陷管理系統，並按每週一次的形式進行專案負責人、研發、測試的三方確認。經由專案經理確認後，方可把不做修改的bug關閉並保留記錄。說白了就是把鍋甩出去給專案經理，一會上線出事了，bug記錄一翻，我測試提了bug，你研發不改，經理允許的，這鍋我測試就不背了。
13樓：智障十五
根據基本的缺陷生命週期：缺陷發現，開發確認並修改，發布新版本，回歸測試，缺陷關閉
現在只看前兩個階段：
缺陷發現：預設發現的缺陷是合理的缺陷，不符合業務需求，提交給開發確認
開發確認：開發不認為是缺陷，並打回
說實話，開發和測試雖然是不容水火，但是面對生產上線那都是一條線上的螞蚱。靠著缺陷流轉來溝通，效率太低了吧？提交之前為什麼不和開發確認呢？
如果開發和測試意見不統一，先拉業務和產品經理，再不行就拉測試經理，再不行還有開發經理和測試經理的溝通會。
這個是從人的上面統一意見，下面是從事上面
開發認為不是缺陷，那就拿需求書說話，需求書搞不定，拉需求制定者確認
開發人力不足，老樣子，上級決定，可以的話那就下個版本，不行的話...大家一起受累
原開發不在崗，老樣子，上級決定
不管怎麼說，這個事的預設是有乙個支援你的測試領導，因為有靠山才有公升級一說。
14樓：二水
確實是缺陷嗎？
確實是這個開發的缺陷嗎？
缺陷的嚴重性足夠高嗎？
缺陷的觸發概率+後果大過修改代價嗎？
此缺陷上線是不可忍受的嗎？
如果以上皆為是，那麼你有以下幾個選擇（高階排列）：
與此開發溝通，擺事實講道理；
尋求產品仲裁；
尋求你上級仲裁。
15樓：雷神VeryYoung
這個問題在測試過程中確實蠻經常遇到的，首先看問題的影響大小，確實不影響的比如一些介面問題，可以忽略，如果涉及需求或者功能，就需要拉上研發負責人、產品、需求人員、測試負責人等相關干係人一同確認是否修復！相應的公司都會有這一方面的處理流程規範的！我在的公司都有此類bug流轉規範！
16樓：李子夏
這個應該是幾個步驟：1.測試和開發兩個部門一起確認是不是問題；2.專案管理層根據版本發布計畫確定要不要改。3.開發部門修改並由測試部門閉環。
確實是問題，不修改的，應該通過規範的流程來控制，而不是測試人員和開發人員直接來懟。確認問題流程走完，改不改是產品經理和開發經理、測試經理來一起考慮的事情。看你問的問題，應該是沒有規範化這些流程和職責，就算是乙個人的測試部門，該不該改bug這個事情也應該是高一層來裁決和指派的。
初級測試人員的未來？
測試小盒 首先，初級測試人員現在雖然很多，但是仍然占有人才市場的需求其次，現在根據現在公司的需求，建議多去提公升下自己的技能，比如效能測試，或者是自動化測試方向，就算是外包，現在也是會要求這些的，雖然實際工作中可能用到的很少，但是不會也是對自己以後發展的一種侷限 第三，如果短時間無法提公升自身技能，...
開發測試人員對搜尋引擎的是如何測試的？
不同的測試方法有不同的測試用例設計方法。常用的測試方法 白盒法測試物件是源程式，依據的是程式內部的邏輯結構來發現軟體的程式設計錯誤 結構錯誤和資料錯誤。結構錯誤包括邏輯 資料流 初始化等錯誤。黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模組輸出和輸入介面。白盒法和黑盒法依據的是軟體的功能或軟體行為描...
好的軟體測試人員簡歷是什麼樣子的？
渡北川 乙個好的軟體測試工程師是什麼樣子的？他的簡歷一定是非常全面。只是掌握的很紮實。各種測試方法全部了解，而且在實戰經驗中出現的任何問題都有解決的方案，能在簡歷中及時的體現出來。當你真正了解自己行業成為專家以後，那麼你的簡歷一樣可以脫穎而出，成為最優秀的簡歷。你對測試工程師的崗位真正的了解嗎？黑盒...