遇到不可重现问题怎么办?

1回忆操作步骤、尝试重现

  1. 尽量回忆当时的操作步骤,并且最大可能的复原当时的操作环境。

  2. 确认当时的操作步骤是否有误。如果确认无误,可以多次尝试重现;

  3. 即使发现有操作错误的情况,也不要认为没问题了,要思量为什么会操作错误是否用户也会有这种操作?然后和产品讨论自己的想法,很可能这是用户体验上的问题。

  4. 可以把整个操作流程进行分解,逐个步骤进行考虑影响因素,然后进行验证

  5. 视测试时间、严重程度、重要程度而定,要花多久进行重现,既不能一两次就草草了事,也不能无休止的在这一个问题上无限制消耗时间

  6. 如果是崩溃问题,一定要尽可能的抓取log并分析原因,然后提供给开发

2提交bug与开发沟通

  1. 即使不能重现,也一定要提交bug备忘:

    1)有的测试人员经常会因为不能重现,就不提交或忽略提交了,这是错误的

    2)用户那边可能会出现,至少我们测试出现过,所以出于测试责任考虑,也要提交;

    3)当前不能重现,不代表以后不能重现,既然出现问题了,那肯定是有问题,只不过当前无法解释而已。

    4)要把当时出现问题时的环境、步骤,尽可能的在bug上写全,并且附上自己的分析和看法,哪怕是猜测也行,以便后续尝试重现

  2. 开发对自己的程序了解深刻,看到bug后,有可能很容易就能知道问题所在立马就能修改,或者根据现象给测试人员重现上的提示

  3. 对于这类bug,有些开发可能不太乐意让提交,因为没有重现步骤没法改,所以一定要和开发明确说明,这首先是备忘一下,后续可能会重现或想到修改方法;就算最后一直无法解决,也可以置为不可重现关闭。(在搜狗项目中,开发的bug数是不计入绩效统计的,所以开bug对于开发没有什么阻力)

  4. 切忌测试人员把单次发现的bug直接给开发,而不进行多次验证、尝试重现,因为这是不专业的表现,发现问题、多次多角度尝试重现、帮助分析问题原因都是测试人员应该做的。

  5. 虽然重现bug是测试的职责,但初步定位bug也是测试人员需要提高的能力,因为这样可以和开发一起找原因,提高开发对你能力的认可。但一定要注意,测试人员认为的原因,需要用一种建议的形式和开发沟通,否则会让开发认为你太自负,并且一旦你说的原因是错的,更会被认为是自不量力。

  6. 如果直到最后上线前都没有重现,那么就要把这个问题计入上线风险。

3后续回归测试时着重关注

  1. 一轮测试时发现的不可重现问题,在后续回归测试或随机测试时,可以把这类问题重新拿出来分析并尝试重现(所以当即提交bug并详细说明步骤与分析内容的重要性就体现出来了,如果没有这些内容,后续想尝试复现难度都很大)。

  2. 重现问题时,不要仅局限在当前的环境下,换换思路、逆向思维、多发散、甚至带点创造性的做法往往会有较大的惊喜。

  3. 一旦再次重现,一定要保留现场,叫开发人员一起查看

  4. 如果发现了必现步骤,那么就要好好进行分析,为什么测试用例没有覆盖或者常规测试没有发现,及时总结。



原文链接

如需转载该篇文章,请注明来自“搜狗测试”


<think>嗯,用户遇到了提交的bug被开发人员拒绝或不认可的情况,这确实是测试工作中常见的痛点。用户可能正处于一种挫败感中,特别是当自己认真发现的bug被轻易驳回时。 从用户身份推测,ta应该是测试工程师或者质量保障人员,日常需要和开发团队紧密协作。这类问题其实涉及技术判断、沟通技巧和流程管理三个维度,需要系统性地解决。 先看技术层面。根据引用[1]提到的原则,测试人员要能清晰描述bug的重现步骤和边界条件。开发拒绝往往是因为无法复现或认为不是缺陷。这时候需要测试人员像侦探一样收集完整证据链:操作系统版本、浏览器类型、网络环境、数据状态等。特别是引用[1]强调的“最少操作步骤重现”和“变化条件”,这能有效说服开发。 沟通策略上,引用[2]指出项目组需要建立通畅的沟通渠道。直接说“你的代码有bug”容易引发防御心理。更好的方式是拿着复现录像问:“这个操作流程下界面出现异常,您觉得可能是什么原因?” 把问题转化为共同的技术探讨。如果争议持续,引用[3]提到任务优先级问题,可以拉上技术负责人评估影响范围。 流程机制方面,引用[2][4]都提到bug跟踪系统的重要性。建议用户推动团队建立规范的缺陷生命周期流程,包括“争议”状态的处理规则。当开发拒绝时,系统自动升级给架构师或产品经理仲裁,避免测试和开发直接对立。 用户可能还隐含担心影响团队关系。其实引用[4]说得很对:“工作就是工作”,用专业态度处理争议反而能赢得尊重。可以建议用户每次提交bug时附带测试用例编号和需求依据,把主观判断转化为客观验证。 最后想到,有些拒绝是因为开发在赶进度(引用[3]提到的排期压力)。这时候测试人员可以灵活分类:阻塞性bug坚持修复,小问题建议计入技术债务文档。既保障质量又不破坏协作。</think>当提交的bug被开发人员拒绝或不认可时,可采取以下系统化处理方式,确保问题得到有效解决: --- ### **一、复核与完善Bug报告** 1. **确认重现步骤** - 检查是否提供清晰的最小化重现步骤,包括: - 测试环境(OS/浏览器/设备版本) - 测试数据(如特定账号、文件) - 操作序列(点击顺序、输入内容) - ✨ **示例**: > *步骤1:登录管理员账号test@demo.com 步骤2:在订单列表页点击"导出"按钮 步骤3:选择时间范围2024-01-01至2024-01-31 → 页面卡死,控制台报TypeError* 2. **补充关键证据** - 附加截图/录屏:突出错误现象 - 日志文件:提供控制台错误日志或服务端异常堆栈 - 网络请求:捕获异常API响应(使用Fiddler/Charles) --- ### **二、技术沟通策略** 1. **定位争议焦点** | 常见拒绝原因 | 应对方案 | |---|---| | "设计如此" | 核对需求文档,标注冲突条款 | | "环境问题" | 提供多环境复现证据(如测试/生产环境) | | "非代码缺陷" | 分析根因(如数据污染/兼容性问题) | 2. **发起技术讨论** - 邀请开发人员共同调试,现场复现问题 - 使用代码片段说明预期与实际差异: ```java // 预期:返回List<Order> List<Order> orders = orderService.query(startDate, endDate); // 实际:endDate=null时抛出NPE(需求未明确边界) ``` --- ### **三、升级处理流程** 若仍未被认可,按流程升级: 1. **提交仲裁委员会** - 组织三方会议(测试+开发+产品经理) - 依据需求文档判定是否为缺陷(引用[4]中的责任归属原则) 2. **记录决策依据** - 在Bug跟踪系统中标注: `[争议] 2024-03-20 产品确认:日期空值需兼容处理 → 转需求优化` --- ### **四、预防性措施** 1. **建立质量共识** - 制定《缺陷认定标准文档》,明确: - 功能与需求文档的偏差范围 - 用户体验基线(如加载超时3秒为缺陷) 2. **自动化辅助验证** - 对争议Bug编写自动化测试脚本: ```python def test_date_boundary(): response = api_call(end_date=None) # 模拟开发拒绝的场景 assert response.status_code != 500 # 明确约定Null应返回400而非500 ``` --- ### **根本原因分析** 根据行业实践,争议常源于以下问题(引用[1][4]): > 1. **需求模糊**:28%的争议因需求文档未覆盖边界场景 > 2. **责任错位**:测试人员越位做设计判断(如"按钮颜色应调整") > 3. **协作断层**:开发未参与测试用例评审(引用[2]的沟通缺失问题
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值