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

最新推荐文章于 2025-06-10 16:54:36 发布
原创 最新推荐文章于 2025-06-10 16:54:36 发布 · 4k 阅读 · 6 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#软件测试 #面试

本文详细阐述了软件测试的基本流程，包括确认环境问题、脏数据处理、依据产品需求文档进行测试，以及在文档未明确说明情况下的个人经验判断。通过具体实例解释了如何判断和处理潜在的软件缺陷。

1.先确认是不是如开发说的那样，环境问题/脏数据，是的话，关闭bug；

2.不是的话，根据产品需求文档来，一般有分歧都是一些小问题（交互、UI、样式、展示顺序等问题），产品经理拍板或者拿出数分数据支持，这样开发的产品更容易引导用户，促进成交；

3.若产品需求文档没有提及，需要凭借个人经验判断（比如登录的时候，第一次输入验证码，不小心输错了，重新输入。这个时候，验证码输入框不提供删除原先输错的验证码。虽然需求没有提到，但是基于自己的经验，这也就是bug）

面试题004-当开发人员说不是BUG时，你如何应付
yinyiyi978520的博客
11-10 1688
当开发人员说不是BUG时，你如何应付
分享下3年工作经验下的 社招面经（详细总结）
S11035762的博客
10-21 3271
这次就不长篇论道了，直接进入主题！ 测试题 问：你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺.
你在测试中发现了一个bug，但是开发认为这不是一个bug，你应该怎样解决？
fengyupotest的博客
03-02 2902
测试、bug 协调合作
你发现了一个bug，开发认为不是bug，该怎么处理？
后街女孩的博客
04-11 6609
一、先从自身 1、反复确认bug，保证发现的确实是一个bug。 2、bug描述不明确 3、开发和自己对需求的理解不一致，找产品确认需求 二、开发 1、开发可能最近工作比较忙，没有时间改，协调时间，但是不能不改 2、开发情绪不对（个人原因），向自己的上司反馈 ...
测试工作中发现一个bug，而开发人员说不是一个bug，你该怎么处理？
热门推荐
weixin_40388283的博客
09-17 5万+
  说法一： 1、首先明确开发说不是bug的理由。 2、如果是需求变更， 那就找产品经理确认是否是需求变更。 3、如果开发说测试环境问题， 让他说明清楚测试环境问题是什么，按照他说的验证一遍， 如果确实如他所说， 关闭bug，但是不是他说的那样，继续激活bug给开发解决，确保产品质量。 4、如果开发说用户不存在这种使用场景， 但是我们不认可他说的，把这个bug 知会到测试经理，让测试经理...
如何判断一个bug，是前端还是后端的？
海姐软件测试的博客
06-10 1750
**摘要：**作为测试工程师，精准判断Bug归属（前端/后端）的核心方法包括：1）通过抓包工具分析接口请求/响应数据，请求异常属前端，响应错误属后端；2）验证数据库与日志，数据未更新可能为后端问题；3）DOM操作验证UI层问题。典型前端Bug包括布局错乱、事件失效等，后端Bug多表现为5xx错误或逻辑缺陷。建议结合Mock测试、日志追踪和团队协作模板（如Jira+Swagger），基于数据证据而非主观猜测定位问题。掌握这套方法可高效解决90%的Bug归属问题。
软件测试，随机bug开发敷衍不修改？我.......差点又背锅了
测试人，要卷就卷成最强的！
11-13 736
当找到bug如果开发人员不修改的话，无非就是几个问题。第一个，就是需求不明确，而导致开发说我理解的需求就是这样子的，或者说需求没有明确的写出来，我认为这样子设计就OK了。那么对于需求不明确的问题我们去找谁？我们去找产品经理去进行一个确定，产品经理确定了需求是什么样子的，那开发要改就必须要修改。第二个，就是技术问题，现在的技术无法去修改。或者有一些问题不是通过开发人员就可以去修改的，可能还涉及到一些底层，或者说涉及到第三方公司需要提供的一些技术。
聊一聊上线后出现Bug测试该如何处理？
奇峰卧虎
03-14 1603
成立应急小组：立即召集产品、开发、测试、运维等关键角色，明确分工（如开发定位问题、测试复现、产品评估影响）。如果Bug严重影响核心功能（如支付、登录），测试团队需配合运维快速验证回滚方案，确保旧版本功能正常。作为测试从业者，测试的产品或需求上线后，出现了Bug，作为测试人员应该怎么办，是个值得考虑的问题。若采用热修复（Hotfix），需验证补丁包在真实环境中的兼容性（如不同设备、操作系统版本）。优先验证Bug修复后的功能，同时覆盖关联功能（例如修复支付失败后，需验证退款流程是否正常）。
[测试开发技术] 面试必问：如何快速定位BUG？
10-21
在软件开发领域，BUG定位是一项必不可少的技能。在面试中，如何快速准确地定位BUG，不仅能够体现一个测试人员的专业能力，还能直接影响到开发团队的工作效率和产品的质量。因此，掌握一些BUG定位技巧及策略显得尤为...
当测试人员认为是bug，开发认为不是bug，如何处理？
m0_74038875的博客
01-31 2065
如果还是不行，那可以给这个问题提出来,跟开发经理和测试经理进行确认。如果最终bug被确定不改， 那么就要在测试报告里面记录一下，以便以后查阅。二是这种情况不可能发生，所以不需要修改，这个时候可以先尽可能的说出是BUG的依据是什么？如果 被用户发现或出了问题，会有什么不良结果？一是需求没有确定，所以这个时候可以找来产品经理进行确认，需不需要改动，商量确定好后再看要不 要改。
当测试觉得是bug开发觉得不是bug该怎么做？
chung121的博客
12-12 657
bug
开发认为不是bug，你该如何处理？
07-20 397
这是软件测试员面试时经常被问到的问题。看了很多答案，个人觉得作为有工作经验的测试人员回答时不能完全照搬标准答案，技术面试官想听的当然不止如此。毕竟这种情况在实际工作中也常常出现，具体问题要具体分析，你的答案最好能妥善解决开发认为不是bug的问题，这也能侧面反映测试人员的自我判断能力和独立解决问题的能力。能代入自己的想法和测试理念的候选人更有优势，所以整理了这个问题的答案。（当然，这也不是唯一答案）不足之处，欢迎留言补充。在面经里的参考答案通常是酱紫滴，如下：开发人员说不是bug，有2种情况，
如果你发现了一个bug，开发那边认为不是，你会怎么办？
海姐软件测试的博客
04-20 590
如果遇到开发认为我发现的 Bug 不是问题的情况，我会采取以下步骤来处理：
一个bug，开发不认，怎么办
冰河时代
12-03 1248
一个bug，开发不认，怎么办
你认为的bug,开发并不这样认为，那你咋办！
别人的故事，是参考答案，而不是标准答案
02-22 1007
前言： 在项目过程中，如果开发说这个不是Bug，你的第一反应是什么？ 不同的人有不同的处理方式，也许是如下几点：相信开发说的，开发说什么就是什么，问题关闭；自己不能决定，啥都上升到组长或者领导决定；坚持认为这是一个Bug，但是说不出所以然，与开发死扛； 特别是一些易用性的非功能相关问题，或者用户反馈的问题，也可能是一个隐形需求问题。 不管是不是一个Bug或者无法确定，首先都需要将Bug提交到缺陷管理库中。 如果是你，在项目过程中或者面试过程中遇到这个问题，你会怎么处理呢？ 正文： 下面是一些我处理的方法，也
测试发现bug而开发不认为是bug 你怎么办？
weixin_46183674的博客
11-24 6957
1.找到需求文档或者是原型图进行匹对 2.尝试多种测试环境和多种测试方式来确认是否为bug 3.整理bug的复现的步骤和出现的频率 4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug 5.将客户经理 测试 测试经理和项目经理进行开确认会来判定是否为bug 6.测试人员需要将bug整理并写入测试总结中 ...
面试官问我“当你提了一个bug，开发认为这不是bug”该怎么处理？
海姐软件测试的博客
04-18 884
无论结果如何，我都会复盘：需求文档是否存在歧义？推动完善文档；是否测试用例描述不清？优化用例表达；是否可提前与开发同步测试场景，减少认知偏差？
如果你碰到的bug开发人员不认为是bug的时候你怎么办？
ssl_husband的博客
04-01 964
1.通过不同方式或者是不同的测试环境来对bug进行确认 2.根据需求文档对bug来进行判断 3.将bug的出现的频率，已经出现的方式和对应的操作步骤进行书写，将结果 截图或者是录屏 4.找对应的项目经理或者是客户经理来bug进行评审 5.将bug进行记录到测试总结中 ...
测试过程中遇到 开发人员不认为是bug的bug怎么办？
SOX_L的博客
06-28 3682
说法一： 1、首先明确开发说不是bug的理由。 2、如果是需求变更， 那就找产品经理确认是否是需求变更。 3、如果开发说测试环境问题， 让他说明清楚测试环境问题是什么，按照他说的验证一遍， 如果确实如他所说， 关闭bug，但是不是他说的那样，继续激活bug给开发解决，确保产品质量。 4、如果开发说用户不存在这种使用场景， 但是我们不认可他说的，把这个bug 知会到测试经理，让测试经理去判定。 说法二： 1.告知开发bug的判断依据，同时明确开发说不是bug的理由。 2.对开发的理由进行校验，校
测试认为是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]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值