关于后端 bug 由谁复现问题?

2020-10-23 16:25:10 +08:00
 whyrookie

摸鱼之际想说下这个问题。前端包括移动端发现 Bug 的时候都是需要自己复现 bug,但很多时候花了很多时间复现排查最终发现是后端的问题。相当于前端帮后端排查定位到具体接口和返回的错误数据(相当于给后端节省了很多时间,没做过后端,这样改起来是不是容易很多?),经常这样的话,作为前端还是比较烦躁的。不知道其他 V 友是否有同感.

3067 次点击
所在节点    程序员
22 条回复
lxk11153
2020-10-23 16:27:00 +08:00
谁踢出谁复现?[doge]
anonydmer
2020-10-23 16:29:20 +08:00
测试人员复现
whyrookie
2020-10-23 16:32:12 +08:00
@anonydmer #2 测试是会复现的,那就得看测试的能力了,有些测试只会点点,告诉你的怎么操作才能复现
speedofstephen
2020-10-23 16:32:25 +08:00
“花了很多时间复现排查最终发现是后端的问题” 那你不花时间怎么知道是后端问题呢?你的意思前端发现 bug 还得后端来排查么?
我个人的看法,你可以不定位到接口和返回错误数据。但是至少得提出充分的证据证明不是前端的问题。而且花了很多时间才定位到具体接口和返回的错误数据。一定程度也说明你对自己写的代码了解不充分。不然直接打开调试台 Network 看一下后端返回数据是否符合预期应该花不了多少时间。
speedofstephen
2020-10-23 16:34:27 +08:00
但是如果这种问题很频繁的话,那说明后端的开发写的接口质量不高。这就是另一个问题了。可以直接要求后端的 leader 整改一下。
wolfie
2020-10-23 16:34:31 +08:00
这跟前后端没关系,测试提给后端,排查发现是前端问题的情况怎么说。
jintianfengda
2020-10-23 16:48:19 +08:00
一般测试会直接定位到是前端还是后端
不过把 bug 指给后端最后定位到前端的 bug 不也一样吗,不过如果你是想吐槽后端 bug 太多,测试看也不看都指给前端的话,这种情况可以跟测试沟通
jeeyong
2020-10-23 16:54:37 +08:00
自动化测试, 玩烂后端程序员...
jeizas
2020-10-23 16:57:03 +08:00
自动化测试 修复
unco020511
2020-10-23 17:19:59 +08:00
这个是测试定位问题,然后再分发啊,是接口问题就是提给后台开发,是前端的问题就提起前端开发
liujialongstar
2020-10-23 17:33:35 +08:00
上一个项目新来个前端, 测试提了几个后端接口抛出异常的 bug, 项目经理就安排后端人员排查, 最终发现前端未按照接口文档正确传入参数
norz
2020-10-23 17:48:41 +08:00
这是没有办法的事,你要排除前端的锅,那就需要证明
wysnylc
2020-10-23 18:30:08 +08:00
发现问题和解决问题是两码事
qwerthhusn
2020-10-23 18:32:51 +08:00
有个好方法,如果是接口问题,直接复制出来个 curl,直接甩给后端,后端也可以直接执行个命令测试接口
raaaaaar
2020-10-23 19:32:09 +08:00
自动化测试,没有吗?
iTanX
2020-10-23 22:22:13 +08:00
那把问题都给后端处理好不好?一个 bug 在页面表达出来,谁来确定这是一个前端问题还是后端问题?如果你们测试无法定性,显然,页面问题应该先由前端定位,前端最多也就定位到是后端返回数据的问题,然后这个问题转到后端继续处理,后端定位发现是后端代码的问题,继而修正,这不是各施其职的事情吗?你也不想想一群后端发现你们前端特么传错参数是不是很烦躁
fansangg
2020-10-23 23:33:09 +08:00
测试人员测出 bug 复现给前端看,前端 debug 后发现是接口返回数据问题,然后发出的接口和参数对照一下接口文档,如果没问题的话就把 bug 转给后端,然后群里 @他

这难道不是,在正常不过的流程吗??
IvanLi127
2020-10-24 00:47:42 +08:00
@iTanX #16 一群前端测了半天发现是后端问题,不也挺烦躁的? 你说的流程没啥问题,但借口不成立吧。
freakxx
2020-10-24 01:26:53 +08:00
我感觉这不是一个单一的问题。

如果只是从 api 的角度的话,这个是好解决的,
你只需要在 bug 的页面或者截(没打错)面,直接向 api 复现请求,结果是对的,那么这个就在前端做,不是直接丢给后端去处理。(“二分法”找 bug )


正常来说,假如不是开发(而是测试,项目)提出的 bug,那么一般是流给前端,我觉得这个是没问题的。
我在前公司的时候很认同这个理念,就是无论哪一端,都认真为上下游考虑。这种情况下,整个事情就很容易解决,到了要甩锅的地步,那么只能说,这不是代码或者 bug 的问题。

----------------

前端处于后端的下游,现在测试吐了,或者用户吐了,回溯到你,你查出不是你的问题,你回溯到后端,这是正常的事,
或者在我看来。


----------------

但我也见过比较“恶心”的后端,接口是指负责满足表面的需求,前端拿到这样的东西当然会恶心。
这种情况,你要么能再向上反馈,要么就只能想法子斗智斗勇,也是挺累的事。

这种情况也有可能是你标题说的这种,
但最后可能也是前端接的锅。

这从写代码开始,前端就已经承担帮后端擦屁股的风险。

---------------


总的来说,前后端(或者合作方)实力悬殊的情况下,总有一方要给另一方擦屁股,这是不可避免的事。
freakxx
2020-10-24 01:36:10 +08:00
@iTanX #16
@IvanLi127 #18

我觉得这里面其实不是谁来接锅的问题,是前端后分离,交界处(权责)在哪的问题。

正常来说,在接接口时,如果接口不行,好一些是做法把 request 和 response 反馈给后端去处理,这当然最简单。
很多时候,文档简陋乃至于无,只能大家好好做饭,别把炉搞塌了。

但有些问题,后端参与在里面是比较简单处理的,不是丢给谁去处理的问题。
有些逻辑问题,后端给出来的,参与进去肯定比较快能定位到。


前端在这里主要是能快速定位到问题连接处,如果定位能力差,解决起来也是很痛苦的事。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/717917

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX