这是一个创建于 1380 天前的主题，其中的信息可能已经有所发展或是发生改变。
有没有测试岗位的朋友，想讨论一个问题
问题起因是前段时间，公司项目由于前期问题太多，压缩了后面的测试周期
这就导致了开发与测试身上都肩负着比较大的压力，开发要尽量解决所有的 bug ，测试要尽量找出所有的 bug ，让项目质量在短时间内趋于稳定
然后开发与测试之间就出现了一个不小的矛盾，那就是：测试提的偶现 bug 数量太多了
然后这些所谓的偶现 bug 实际上大部分都是有规律的可复现 bug ，在一定条件下必现
现在的矛盾就是，测试在测试过程中，偶然发现了一些异常问题之后，立刻就截图导日志，然后简单重试一两次，发现无法复现之后就立刻提了 bug ，然后标记为偶现问题
然后开发在处理这些缺陷的时候，只能自己反复尝试复现再找出原因去解决，比较耗时间
如果测试能够准确的提供复现路径的话，开发解决缺陷的速度能够大幅提升。而且其实有比较多的所谓的偶现 bug ，复现路径并不难发现，但是依然被标记为偶现
那么现在的问题就是，对于这些一定条件下必现的 bug ，测试有没有义务去找出复现路径？
努力尝试找出复现路径，算不算测试的本职工作？
该问题仅作讨论，请各位理性分析，感谢。
 | 1 Nevermore1234 2022-01-05 15:08:13 +08:00 测试有责任找出复现路径，同时时间不够是 PM 的责任 |
 | 2 5boy 2022-01-05 15:08:36 +08:00 那还要测试有啥用？ |
 | 3 guyeu 2022-01-05 15:09:31 +08:00 这不是测试职责的问题，这是拉垮的项目经理和拉垮的排期的问题 |
 | 4 Leonard 2022-01-05 15:11:26 +08:00 单说“找出复现路径这点”肯定是测试的职责。 |
 | 5 2i2Re2PLMaDnghL 2022-01-05 15:15:21 +08:00 这样的测试还不如 sentry |
 | 6 paradoxs 2022-01-05 15:15:51 +08:00 有专门的测试人员已经很好了 其实公司完全可以把测试任务压到开发身上，直接 996 ，不愿意干就。。 |
 | 7 coderluan 2022-01-05 15:22:50 +08:00 ”那么现在的问题就是，对于这些一定条件下必现的 bug ，测试有没有义务去找出复现路径？“ 毫无意义是由义务的，但是在未为保证对方权利（合理的测试周期）的前提下，指望对方好好的完成义务是不现实的。 |
 | 8 RiceNoodle 2022-01-05 15:30:26 +08:00  3 “努力尝试找出复现路径”，在我看来，是开发和测试的共同本职工作。因为有的偶现问题，确实从代码可以分析逻辑，然后手动制造条件复现。 如果开发很难复现和解决的话，我之前一般是把 bug 转入"挂起"状态，责任人流转给测试。 测试会在后续的版本中，间隔一段时间把挂起问题尝试复现，如果仍然没法复现就转为关闭。 把 bug 转入"挂起"的过程，需要和测试同学沟通好，说明开发的确努力找过问题（分析过代码，也尝试过复现），没法复现。如果有争议，可以把问题知会到测试和开发的 leader ，看看是否要花时间继续投入复现解决。 其时测试的主要工作是保障交付质量，而不是找到并消灭每一个 bug 。 因此如果特性的偶现 bug 很少，测试对发布版本有信心的话，就可以宽松的允许 bug 转入挂起状态。 如果特性的偶现 bug 很多，测试对发布版本质量没信心的话，则可以据理力争，让开发投入更多精力尝试解决偶现 bug 。 |
 | 9 66beta 2022-01-05 15:33:20 +08:00 7 老板成功把排期矛盾，转移为开发与测试的内部矛盾 |
 | 10 ah64zzpk 2022-01-05 15:40:26 +08:00 正常情况下是有这个责任的，但是在版本交付压力非常大的情况下，往往会出现这样的情况，有可能是测试的覆盖并不达标赶进度，或者是测试人员有 bug 数量的考核指标等等，这种情况我建议你找你的老大去和测试的老大谈。 其次，对于偶现的 bug ，开发需要有能力去分析问题出现的时候发生了什么，这需要详尽合理的错误日志，以及一些其他可以辅助你定位问题的工具，你现在可以要求测试人员帮忙复现 bug ，如果一旦问题在线上被客户发现，你没法去问客户这个问题是不是偶现，必现的规律是什么，定位分析就全靠你自己了。 |
 | 11 c8c 2022-01-05 16:45:44 +08:00 1 Q: 努力尝试找出复现路径，算不算测试的本职工作？ A: 当然算了 |
 | 12 lagoon 2022-01-05 16:51:41 +08:00 作为开发，我觉得“复现”这事，是共同有责任的。 至于是不是测试的工作，我觉得是的。 不过，也是开发的本职工作，毕竟测试已经截图留证，证明代码有 bug 。 另外很多时候，就是一环压一环。 比如时间很赶，以前甚至遇到过，那开发甚至直接写个假代码，到时候测试提 bug ，再具体实现。 然后最终的情况就是，开发一周，测试一个月。 所以我深刻的觉得，领导，很重要。 如何平衡这些矛盾，让项目比较好的展开。 可惜如今的领导，都是官僚，不进行管理，只进行命令。 我不管你们怎么搞，我就要结果。 |
 | 13 ahsjs 2022-01-05 17:02:54 +08:00 偶现的要开发和测试配合测试所有情况下的，费时间是正常的 |
 | 14 bluexsky 2022-01-05 17:12:21 +08:00 发现无法复现之后就立刻提了 bug ，然后标记为偶现问题 那这样提出来的 bug 级别较低，开发可以暂时不理会，状态标注为已知，然后开放的精力放在解决优先级高的 bug 上。 如果是必现的 bug,级别就会开得很高，这时候开发就需要关注了 开发空闲的时候可以解决优先级低的 bug,这时候如果复现问题很困难，可以把 bug 打回给测试“无法复现”，让测试再去重现问题。 |
 | 15 ctro15547 2022-01-05 17:28:07 +08:00 偶现 bug 一般会标记复现率：1/10 、1/3 、测试过程只出现 1 次，这样，不是一直要试到有绝对路径（因为有些问题确实没有太固定的路径，有可能是网络波动 机器性能 特定的数据被录入后才出现，但数据又不能被重现），这样很浪费测试时间 ，发报告的时候就可以跟大家伙评估下优先级，让产品开发来定延迟解决还是需要立马处理（丢锅），毕竟东西不是自己写出来的 不清楚会牵连到其他功能，报告以后需要开发他们讨论 测试过程中 有时间的前提下 ，能接触到源码 或者看得到后台数据或者 log ，可以尝试分析下 |
 | 16 liuhuansir 2022-01-05 17:31:34 +08:00 复现当然是测试的职责，但是在不懂代码的情况下，想要快速复现偶现的问题真的很费时间，测试和开发合作才是最快的，我们组现阶段就是这样 |
 | 17 fangcan 2022-01-05 18:18:03 +08:00 说个题外话， 后端跟测试和前端真的是做不了朋友，利益冲突，互相甩锅，双方都想少做点事情 |
 | 18 hideonwhere 2022-01-05 18:21:50 +08:00 之前在一家公司测试是有专门摄像头记录仪来记录测试操作的，记录仪有时间戳 然后出现 bug 测试把那一段时间的视频和日志上次到特定地方 管理再判断是那个开发在下发出去 最终开发收到再去修改 |
 | 19 zhangshine 2022-01-05 19:43:43 +08:00 > 而且其实有比较多的所谓的偶现 bug ，复现路径并不难发现，但是依然被标记为偶现 开发觉得不难发现并不能说明测试也可以不难发现。开发对整体代码有一定的了解，对于一些 bug 猜都可以猜出来，也算是一些发现 bug 的隐形加成。但是对于测试来说就是黑盒，前后逻辑可能联系不起来。 我觉得开发和测试之间不必互怼，问题还是在于“公司项目由于前期问题太多，压缩了后面的测试周期”，莫要底层互耗。 |
 | 20 Lanayaaa 2022-01-05 20:04:56 +08:00 哎，都是矛盾转移之后的受害者... |
 | 21 iyaozhen 2022-01-05 22:32:47 +08:00 多年 QA 老油条 测试有没有义务去找出复现路径？ 有，但其实开发也有 努力尝试找出复现路径，算不算测试的本职工作？ 算，但也是开发的工作 楼上说的对，就是周期压的太紧了，测试和开发都顶不住了，因为每个人的能力还是有限的。你觉得 QA 提的 bug 垃圾，QA 还觉得你代码写的垃圾呢。 有些 bug 确实，很可能定位都得 1-3 天，而且需要高工投入。 建议就是先把 bug 按一定标准分级，要看实际影响，比如有些偶现的，但出现了影响非常大，就提高 bug 优先级。我觉得时间那么赶，P0 的都不一定修的完 |
 | 22 kieoo 2022-01-05 23:31:51 +08:00 我认为测试无法复现,可以记录, 但不能记录为 bug; 无法复现的问题数量: QA 的能力问题 bug 的数量: RD 的能力问题 至于工期赶, 那就 RD QA 坐到一起结对开发测试吧, 效率会高些, 冲突也小些 |
 | 23 MsHan 2022-01-06 00:26:07 +08:00 对我们测试也很无语，版本烂成那样都能过。 用例我看过，按照描述的步骤都执行不下去，无语。 |
 | 24 msg7086 2022-01-06 06:41:23 +08:00 问题超纲了，我们这边都有自动化测试，不怎么需要测试人员。出问题都是程序员的锅，测试没写好。 |
 | 25 IvanLi127 2022-01-06 08:30:04 +08:00 via Android QA 要尽力复现，或者说可以让开发帮忙复现，但是没能复现是 QA 的锅，估计也算不了 BUG 了。正常测试要有用例，测到这步前，操作都比较确定，重置环境再测到这步一般也能复现呐 |
 | 26 hanswu 2022-01-06 11:29:21 +08:00 emmm, 就我自己而言 ， 每次测试出现偶现 bug 的话， 如果在测试三遍以上后，不能复现但是当时已经抓到 log 的话，会提出一个优先级低的 bug 单，并且会跟开发那边沟通 。如果有时间的话就会再次尝试复现，项目时间紧的话这个 bug 会一直被拖到下个版本再去碰，超过三个版本没有再次复现的话，这个 bug 就会被关闭。 主要是 我们公司对偶现 bug 定级也比较低 ，只有客户投诉的时候才要求去一直复现 |
 | 27 comoyi 2022-01-06 13:34:14 +08:00 压缩开发 /测试时间就要接受一定的出 BUG 的风险，这是话事人作出的选择（妥协） |
 | 28 toast 2022-01-06 13:37:03 +08:00 测试报过来，我看完能猜出大概原因的直接处理，猜不出我也复现不了的请 QA 同学继续复现； 相互体谅~ |
 | 29 dundun1 2022-01-06 14:39:37 +08:00 科学的开发团队，把开发跟测试合二为一。这样就没办法甩锅了。 只要是开发跟测试分开，这种问题永远避免不了。 |
 | 30 751327 2022-01-06 19:53:19 +08:00 客户反馈的问题都是直接反馈给开发的，因为反馈给测试，测试大概率复现不了也解决不了 如果是影响比较大的 bug ，责任都是开发承担，说实话，我不知道我们公司的测试有什么用 |
| 31 751327 2022-01-06 19:53:54 +08:00 或者说就不应该有测试这个职位 |
 | 32 wsseo 2022-01-07 11:56:08 +08:00 我朋友公司的测试就是打杂的，测试新版本跟开发周旋，敦促开发人员，需求文档不清楚给开发提建议，处理客户反馈问题，跟踪解决，端茶送水，装系统修电脑。 |
Select Language