测试过程中遇到开发人员不认为是bug的bug怎么办？

最新推荐文章于 2025-03-14 17:56:22 发布

转载最新推荐文章于 2025-03-14 17:56:22 发布 · 3.6k 阅读

31 ·

CC 4.0 BY-SA版权

原文链接：https://blog.youkuaiyun.com/weixin_40388283/article/details/82749163

文章标签：

#软件测试

软件测试专栏收录该内容

2 篇文章

订阅专栏

本文介绍了两种处理开发人员否认的Bug的有效策略。一种侧重于明确开发人员否认的理由，并通过产品经理确认需求变更；另一种则强调了校验开发人员理由的过程，包括参照需求文档和与产品经理沟通确认。最终目标都是确保产品的质量。

说法一：

1、首先明确开发说不是bug的理由。

2、如果是需求变更，那就找产品经理确认是否是需求变更。

3、如果开发说测试环境问题，让他说明清楚测试环境问题是什么，按照他说的验证一遍，如果确实如他所说，关闭bug，但是不是他说的那样，继续激活bug给开发解决，确保产品质量。

4、如果开发说用户不存在这种使用场景，但是我们不认可他说的，把这个bug 知会到测试经理，让测试经理去判定。

说法二：

1.告知开发bug的判断依据，同时明确开发说不是bug的理由。

2.对开发的理由进行校验，校验依据1.参照需求文档，2.跟产品经理进行沟通确认。

校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

SOX_L

关注关注

0
点赞
踩
31

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

分享下3年工作经验下的社招面经（详细总结）

S11035762的博客

10-21

3271

这次就不长篇论道了，直接进入主题！测试题问：你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？首先，将问题提交到缺陷管理库里面进行备案。然后，要获取判断的依据和标准：根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；根据用户的一般使用习惯，来确认是否是缺陷；与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺.

你在测试中发现了一个bug，但是开发认为这不是一个bug，你应该怎样解决？

fengyupotest的博客

03-02

2894

测试、bug 协调合作

参与评论您还未登录，请先登录后发表或查看评论

测试提交的bug开发不认可怎么办？

伤心的辣条

12-01

1493

当测试提交的Bug开发不认可时，可以采取以下步骤来解决问题： 1. 澄清沟通：首先，与开发人员进行详细的沟通，确保对Bug的描述清晰准确，并提供相关的复现步骤、截图或日志等支持材料。确保开发人员对Bug的具体情况有充分的了解。

测试过程中，遇到开发不认为是bug的bug,该怎么办

qq_42643422的博客

06-28

4277

这是软件测试员面试时经常被问到的问题。看了很多答案，个人觉得作为有工作经验的测试人员回答时不能完全照搬标准答案，技术面试官想听的当然不止如此。毕竟这种情况在实际工作中也常常出现，具体问题要具体分析，你的答案最好能妥善解决开发认为不是bug的问题，这也能侧面反映测试人员的自我判断能力和独立解决问题的能力。能代入自己的想法和测试理念的候选人更有优势，所以整理了这个问题的答案。（当然，这也不是唯一答案）不足之处，欢迎留言补充。在面经里的参考答案通常是酱紫滴，如下： 开发人员说不是bug，有2种情况， 1、需求不

你发现了一个bug，开发认为不是bug，该怎么处理？

后街女孩的博客

04-11

6608

一、先从自身 1、反复确认bug，保证发现的确实是一个bug。 2、bug描述不明确 3、开发和自己对需求的理解不一致，找产品确认需求二、开发 1、开发可能最近工作比较忙，没有时间改，协调时间，但是不能不改 2、开发情绪不对（个人原因），向自己的上司反馈 ...

开发不认可BUG时，该怎么做？

weixin_43533308的博客

12-07

6618

开发不认可BUG时，做为测试人员，应该怎么做：第一步：作为测试人员，先是要积极和开发进行沟通，开发是否对BUG的描述已清楚，是否为测试提出的问题？（尽量先让开发明白这个问题表现（测试环境上复现问题，详细说明出现的测试步骤）说服开发认可这个BUG。第二步：如果开发仍是不认可BUG，有以下场景：（1）BUG是偶现的，开发要求你复现时复现不了，开发可能不认可，因为问题复现不了，他没有办法定位 -------尽量找到必现路径，提供详细的问题信息（录屏、日志信息、截图信息） -------如果仍复现不

bug复现不了开发人员不解决，遇到疑难bug该如何排查，这两个方法你需要知道。

雨滴测试博客

03-15

1824

通过以上的方法，可以大大的提高了我们定位问题的能力，但是有些问题已经涉及到了个人的技术知识盲区了，很多出错的原因都是我们压根就不知道的。所以，你最好还要结合百度来一起排查，尽量扫清你的知识盲区。最后，我们总结一下，针对一些难以复现的bug或者遇到的技术问题，找到根本原因很重要。可以通过以下的思路进行开展。描述具体问题，通过不同的方法(构成条件法和差异比对法)来进行分析可能存在的原因(假设)进行验证假设，如果验证结果符合你的预期，那么根因也就找到了，到这里就结束了。

如何分析软件测试中发现的Bug！

qq_43371695的博客

08-15

1196

假如你是一名软件测试工程师，每天面对的就是那些“刁钻”的Bug，它们像是隐藏在黑暗中的敌人，时不时跳出来给你一个“惊喜”。那么，如何才能有效地分析和处理这些Bug，让你的测试工作变得高效且有趣呢？今天我们就来聊聊这个话题。

聊一聊上线后出现Bug测试该如何处理？

奇峰卧虎

03-14

1596

成立应急小组：立即召集产品、开发、测试、运维等关键角色，明确分工（如开发定位问题、测试复现、产品评估影响）。如果Bug严重影响核心功能（如支付、登录），测试团队需配合运维快速验证回滚方案，确保旧版本功能正常。作为测试从业者，测试的产品或需求上线后，出现了Bug，作为测试人员应该怎么办，是个值得考虑的问题。若采用热修复（Hotfix），需验证补丁包在真实环境中的兼容性（如不同设备、操作系统版本）。优先验证Bug修复后的功能，同时覆盖关联功能（例如修复支付失败后，需验证退款流程是否正常）。

测试过程中如何快速定位一个bug

sik123的博客

06-22

1311

Apipost

测试过程中，测试认为是bug，开发不认为是bug，改如何处理

qq_34258189的博客

08-19

2006

情况一此bug没有在需求文档中，明确描述解决办法我们可以寻求产品经理，沟通一下，是否需要完善或者更改需求文档情况二此bug是需要很复杂的操作步骤，才会出现此bug 解决办法我们可以和开发解释这个为什么是个bug，会产生什么风险，或者不良结果，如果最终开发还是不改，我们可以反馈给产品以及测试组长，如果还是不解决，我们可以把这个问题，记录在测试报告中，方便后续查证 ...

一个bug，开发不认，怎么办

冰河时代

12-03

1248

一个bug，开发不认，怎么办

测试发现bug而开发不认为是bug 你怎么办？

weixin_46183674的博客

11-24

6955

1.找到需求文档或者是原型图进行匹对 2.尝试多种测试环境和多种测试方式来确认是否为bug 3.整理bug的复现的步骤和出现的频率 4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug 5.将客户经理测试测试经理和项目经理进行开确认会来判定是否为bug 6.测试人员需要将bug整理并写入测试总结中 ...

当测试觉得是bug开发觉得不是bug该怎么做？

chung121的博客

12-12

656

bug

如果你碰到的bug开发人员不认为是bug的时候你怎么办？

ssl_husband的博客

04-01

964

1.通过不同方式或者是不同的测试环境来对bug进行确认 2.根据需求文档对bug来进行判断 3.将bug的出现的频率，已经出现的方式和对应的操作步骤进行书写，将结果截图或者是录屏 4.找对应的项目经理或者是客户经理来bug进行评审 5.将bug进行记录到测试总结中 ...

你判断是bug，开发不认为是bug，如何处理？

gh_void的博客

07-22

4096

1.先确认是不是如开发说的那样，环境问题/脏数据，是的话，关闭bug； 2.不是的话，根据产品需求文档来，一般有分歧都是一些小问题（交互、UI、样式、展示顺序等问题），产品经理拍板或者拿出数分数据支持，这样开发的产品更容易引导用户，促进成交； 3.若产品需求文档没有提及，需要凭借个人经验判断（比如登录的时候，第一次输入验证码，不小心输错了，重新输入。这个时候，验证码输入框不提供删除原先输错的验证码。虽然需求没有提到，但是基于自己的经验，这也就是bug） ...

软件测试面试题：当开发人员说不是BUG时，你如何应付?

一亿并发的博客

04-11

1134

当开发人员说不是BUG时，你如何应付? 开发人员说不是BUG，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动。3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的一句是什么?如果被用户发现或出了问题，会有什么不良结果?程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实...

当开发人员说不是BUG时如何应对

m0_52622766的博客

01-10

5112

1.首先确认是不是因为自己对BUG的描述不清晰，导致开发人员难以理解； 2.其次确认开发环境与测试环境是否一致； 3. 确认是否是偶现的难以复现的BUG； 4. 若开发人员说BUG就是设计如此，则要与产品经理确认需求是否发生变化，若需求有变化，则将BUG关闭，并及时更新测试用例； 5. 若意见还不一致，就和开发人员、产品经理一起开会讨论BUG是否需要修改，若不修改，则将BUG关闭，最好保留相关记录，便于后续追溯。 ...

你认为的bug,开发并不这样认为，那你咋办！

别人的故事，是参考答案，而不是标准答案

02-22

1006

前言：在项目过程中，如果开发说这个不是Bug，你的第一反应是什么？不同的人有不同的处理方式，也许是如下几点：相信开发说的，开发说什么就是什么，问题关闭；自己不能决定，啥都上升到组长或者领导决定；坚持认为这是一个Bug，但是说不出所以然，与开发死扛；特别是一些易用性的非功能相关问题，或者用户反馈的问题，也可能是一个隐形需求问题。不管是不是一个Bug或者无法确定，首先都需要将Bug提交到缺陷管理库中。如果是你，在项目过程中或者面试过程中遇到这个问题，你会怎么处理呢？正文：下面是一些我处理的方法，也

测试认为是bug开发认为不是怎么办

最新发布

09-22

<think> 首先，用户的问题是关于解决测试人员和开发人员之间对bug认知差异的问题。用户提到测试人员认为是bug，但开发人员认为不是，需要找到解决办法。我需要参考用户提供的引用内容，这些引用讨论了类似的情况： - 引用[1]和[2]提到，需要具体问题具体分析，测试人员应展现自我判断能力和独立解决问题的能力。建议与产品经理讨论需求不确定性，或坚持立场并提供依据。 - 引用[3]建议在bug跟踪系统中记录问题，提供详细信息，并必要时寻求开发经理的帮助。如果影响用户体验，需解释并提供周转方案。 - 引用[4]提到，如果开发无法复现问题，应与开发一起在测试环境演示，确认缺陷有效性。 - 引用[5]讨论了性能测试场景，但核心是关于处理开发经理不认为是bug的情况。用户的需求是：“我想解决测试人员认为是bug而开发人员认为不是的问题”，并问“测试认为是bug开发认为不是的解决办法”。我的回答需要： 1. **遵循系统级指令**： - 使用$...$格式行内数学表达式（如果有必要）。 - 独立公式用$$...$$单独成段。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 在回答中引用的段落末尾添加引用标识，如[^1]。 2. **结构化回答**：由于用户要求“回答结构清晰，帮助用户逐步解决问题”，我应该分步骤或逻辑部分组织回答。 3. **参考用户提供的引用**：在回答中自然地融入引用内容，并在末尾添加引用标识。 4. **生成相关问题**：在回答末尾，添加“相关问题”部分，类似于示例中的“§§相关问题§§”。现在，组织回答结构： - **引言**：简要表述问题，确认这是常见问题，强调测试人员的独立判断能力。 - **逐步解决方案**：基于引用，提供解决步骤。 - 例如： 1. 确认bug复现：确保在测试环境能稳定复现。 2. 提供详细证据：包括日志、截图、重现步骤。 3. 沟通讨论：与开发人员面对面演示。 4. 寻求第三方意见：如产品经理、测试经理或开发经理。 5. 记录并跟踪：在bug跟踪系统中记录。 6. 考虑用户体验：评估影响并提供临时方案。 - **总结**：强调测试人员的立场和避免冲突的策略。 - **相关问题**：生成2-3个相关问题。确保回答真实可靠：基于常见的软件测试实践。处理数学表达式：虽然这个问题与数学无关，但如果提到任何数学概念（如在性能测试中），需使用LaTeX格式。例如，如果有性能指标如响应时间，可以写成$T_{response}$。现在，草拟回答大纲： 1. **引言**：解释问题的常见性，引用[1][2]强调测试人员的判断力。 2. **解决办法步骤**： - **步骤1：复现和确认** – 确保bug可重复，排除环境或数据问题。参考引用[4]。 - **步骤2：收集证据** – 提供截图、日志、重现步骤。基于引用[3]。 - **步骤3：直接沟通** – 与开发人员讨论，演示问题。参考引用[4]。 - **步骤4：寻求共识** – 如果分歧持续，引入产品经理或经理确认需求。参考引用[2][3]。 - **步骤5：文档记录** – 在系统中记录bug，提供依据。参考引用[3]。 - **步骤6：评估影响** – 如果bug影响用户体验，优先处理。参考引用[3]。 - **步骤7：坚持立场** – 如果确信是bug，应坚持但保持专业。 3. **总结建议**：测试人员应基于事实，展示证据力和沟通技巧。 4. **相关问题**：例如： - 测试人员如何提高bug报告的准确性？ - 开发人员拒绝修复bug时，测试团队该如何应对？ - 如何防止测试和开发之间的认知分歧？在回答中，添加引用标识：例如，当提到参考内容时，在句子末尾加[^1]。最后，生成相关问题。 </think> ### 测试人员认为是bug而开发人员认为不是的解决办法在软件测试工作中，测试人员与开发人员对bug认知存在分歧是常见挑战。测试人员应基于事实和证据，展现独立判断能力和解决问题的专业性。以下我将逐步解释解决办法，确保回答清晰、实用。核心策略包括：确认问题可复现、提供充分证据、有效沟通、寻求第三方协助、文档跟踪，以及评估潜在影响。整个过程需要测试人员保持客观、耐心和专业，避免情绪化冲突。 #### 步骤1: 确认bug的可复现性和环境因素（排除无效bug）首先，测试人员需确保所报告的bug能在测试环境中稳定复现。开发人员可能拒绝修复是因为他们无法在自己的环境复现该问题（例如，由于配置差异、测试数据错误或临时故障）。此时，测试人员应： - 重复测试多次，排除随机性干扰。 - 检查测试环境（如操作系统版本、数据库配置）是否一致，必要时邀请开发人员到测试环境现场演示[^4]。 - 如果涉及性能指标（如响应时间），使用工具记录数据，例如平均事务响应时间 $T_{\text{avg}}$ 或错误率 $E_{\text{rate}}$ ，并通过公式如 $T_{\text{avg}} = \frac{\sum_{i=1}^{n} T_i}{n}$ 量化问题。通过这一步，可以区分是有效bug还是由环境/数据导致的无效缺陷。如果是无效bug，直接关闭记录；否则，进入下一步[^4]。 #### 步骤2: 提供详细证据和依据，强化沟通如果bug可复现，测试人员需收集充分证据来支持自己的观点。开发人员可能因不理解问题影响而拒绝修复。测试人员应： - 准备重现步骤、日志文件、截图或视频，清晰展示bug的表现（例如，"点击按钮后界面崩溃"需附截图）。 - 解释bug的潜在影响，包括用户体验损害、系统风险或业务损失（如"这可能导致用户流失率增加10%"）。 - 使用bug跟踪系统（如JIRA或Bugzilla）记录问题，包括环境信息、测试数据和时间戳，便于开发人员审查[^3]。在沟通时，采用协作而非对抗方式： - 面对面与开发人员讨论，演示问题场景。 - 引用需求文档或用户故事，确保分歧源于需求不确定性（如需求模糊时，需产品经理介入）[^2]。 - 如果开发人员提出反驳，测试人员应基于事实回应，例如："依据需求规格书第X条，该行为应为错误状态；如果不修复，用户可能遇到数据丢失风险"[^2]。 #### 步骤3: 寻求第三方介入和团队协作当直接沟通无效时，引入中立第三方以避免僵局： - 如果是需求不明确（例如，功能边界模糊），邀请产品经理或业务分析师确认需求，三方共同决策是否需要修改[^2]。 - 如果开发人员坚持不是bug，升级给测试经理或开发经理评审问题优先级（例如，通过会议讨论影响评估）[^3]。 - 在团队层面，建立bug评审机制（如每日站会），促进集体决策[^1]。测试人员需坚持立场但保持灵活：如果被定性为"非bug"，但影响轻微，可作为建议记录；如果确认是严重缺陷（如安全漏洞），应坚持修复依据[^2]。 #### 步骤4: 文档记录和后续跟踪无论结果如何，确保整个过程可追溯： - 在bug跟踪系统中更新状态，添加沟通记录和决策依据。 - 如果bug被拒绝修复，分析原因并学习（如完善测试用例），避免未来重复[^4]。 - 对于高影响bug（如涉及用户体验），提供临时解决方案（如用户指引），并监控生产环境反馈[^3]。 #### 总结建议解决此类分歧的关键是测试人员的专业性和证据力：通过系统化步骤，测试人员不仅能独立判断问题真伪，还能提升团队协作效率。最终，目标是确保产品质量，而非"赢"得争论。记住，测试人员应基于测试理念（如风险驱动测试），结合实际情况灵活应用[^1][^2]。以下提供一个简单示例流程代码（伪代码），用于bug处理决策： ```python def handle_bug_disagreement(bug, developer_response): if can_reproduce_in_test_env(bug): evidence = gather_evidence(bug) # Includes logs, screenshots if discuss_with_developer(evidence): # Direct communication return "Bug fixed" else: involve_manager = escalate_to_manager(bug) # Test/dev manager if involve_manager.confirm_as_bug(): return "Bug fixed after review" else: document_as_non_bug(bug) # With reasons else: return "Invalid bug, close with notes" # Due to environment issues ``` 通过此方法，测试人员能妥善处理大多数分歧场景，提升自身可信度[^1][^3][^4]。

测试过程中遇到 开发人员不认为是bug的bug怎么办？

测试过程中遇到开发人员不认为是bug的bug怎么办？