就是有些 bug 比如闪退比如功能异常发生在特定的某些手机上,但是找来了同型号手机依旧是复现不了那个问题。因为复现不了,虽然有报错日志,但弄起来极其没底没边。因为涉及到隐私和用户不便也不能向客户要来手机 debug ,就很为难,而且有些用户它只是告诉你有问题(当然这样已经比很多用户好了,更多的用户是有 bug 就直接不用了,懒得告诉你),就没然后了,也无法继续联系交流
1
maigebaoer 123 天前 via Android
随缘吧,能修就修,不能就算了
|
2
IsuYww83LvR48EaC 123 天前
崩溃日志上传
|
3
nnegier OP @jiaqizhang 有的
|
4
lakehylia 123 天前
崩溃堆栈收集啊
|
5
opengps 123 天前
这种神级 bug 的分析不能靠自己,多找几个不同开发风格的人来围观评论下
|
6
NoOneNoBody 123 天前
眼不见为净
|
7
iyiluo 123 天前
日志,超详细的日志,碰到很多难复现的 bug 最后都是靠日志里面的蛛丝马迹发现线头的
|
8
mogutouer 123 天前
写好日志,等一个运气不好的
|
9
9c04C5dO01Sw5DNL 123 天前
再想想,捣鼓捣鼓
|
10
402124773 123 天前
学习如何 battle ,降 bug 等级。
|
11
Baymaxbowen 123 天前
先针对这个 bug 的现象打个补丁上去再说😂
|
12
liuhuansir 123 天前
我司复现不了的 bug ,都是直接打回去,让测试复现
|
13
Yesr00 123 天前
让测试去找复现步骤。得复现概率 90%以上的才能整。😂
|
14
xdeng 123 天前
那就不是 bug
|
15
Vindroid 123 天前
能取到客户设备 log 的情况下,在可能的地方加 log ,后续版本持续跟踪。取不到 log ,也没有能复现问题的操作,神仙也难解啊
|
16
gam2046 123 天前
复现不了的 bug = 没有 bug
怨天怨地怨空气,也不能怨你(狗头保命 |
17
NoDataNoBB 123 天前
@gam2046 但是有工单
|
18
wpblank 123 天前 via Android
我们公司之前有联系客户,然后带电脑上门 debug 的
|
19
leeson888 123 天前
复现不了还叫 bug 吗
|
20
messaround 123 天前
检查代码,推敲逻辑
|
21
xueling 123 天前 2
说一下我的看法,这种问题排查不要只从能否复现的角度处理,应该主要从两方面着手,1 是日志,2 是监控。
1 、app 程序层面的问题,分为普通异常日志和崩溃日志,一般来说异常类日志都有较完整的调用链信息,定位问题相对容易。但造成崩溃的原因比较多,可能是内存问题,用户设备问题、也可能只是某个参数校验失败或空指针异常处理不当导致的,不同情况下崩溃日志有可能完整也可能不完整。所以从日志层面上可以添加全局的异常信息捕获,并将全局异常日志上报,防止漏掉异常信息,而导致排查无从下手。 2 、app 的异常监控体系不完善,可以使用我的开源项目,快速搭建起异常监控体系,https://github.com/xl-xueling/xl-lighthouse ,基于通用型流式统计实现,接入方便、使用灵活、性能强大,轻松实现任意细粒度、任意维度的数据监控。将手机型号、手机系统版本号、app 版本号、页面、模块、错误码等关键信息上报。全面监控各类异常的次数和频率等信息(我自己感觉我的开源项目是应对这类问题业内最强大的工具了~~)。 总之,我觉得 app 问题处理,侧重点应在两方面:一是全局异常日志(代表你没有正常处理的异常),二是普遍性错误(比如:某个 app 版本或某个机型错误率或崩溃率在 0.5%以上的异常),公司内部可以对异常阈值确定一个标准,比如灰度时发现影响超过 0.5%的用户的异常必须测试人员复测解决,该版本不能继续发布,而影响范围较小的偶发性问题、不容易复现的问题,可以暂时忽略或陆续解决。要做到应对领导的所有盘问一切以数据说话,只要日志和监控体系建立起来,你对线上故障的驾驭能力会得到极大的提升。 |
22
yb2313 123 天前
这是 feature
|
23
musi 123 天前 via iPhone
复现不了的 bug 就不是 bug
什么?老板找你?你让老板把这个 bug 给你复现了再说 |
24
jeesk 122 天前
要不要看看这个 bug ?
https://github.com/facebook/react-native/issues/37871 ? |