1、腾讯 Bugly
以下摘自官网介绍：
腾讯 Bugly，为移动开发者提供专业的异常上报和运营统计，帮助开发者快速发现并解决异常，同时掌握产品运营动态，及时跟进用户反馈。
腾讯 Bugly 确实是一款非常优秀的产品。帮助我们客户端同学能快捷收集并排查各类问题提供助力。
2、问题复盘
我们的 Android 客户端开发同学为了能使用腾讯 Bugly 这款优秀的产品来帮助自己解决开发中遇到的各类问题。于是没有任何报备的情况下把腾讯 Bugly 集成到了项目当中。在我们 App 新版本上线之后，在 OPPO、VIVO 特定的 Android 8.1.0 出现了一个兼容 BUG，导致采用 Bugly 上报异常的时候，后续代码停止运行了。
BUG 表现情况
当时 OPPO 与 VIVO 用户（Android 系统 8.1.0），通过 App 内嵌的 H5 页面跳转到合作方的 H5 页面的时候，死活打不开合作方的页面。导致我们用户无法提现充值。影响非常恶劣。
2.1 确定影响范围
当问题发生的时候，我们首先进行了主要版本的覆盖测试。排除了是 H5 写法兼容问题以及用户网络问题。于是，我们通过请求日志，拿到了用户的系统版本。通过对反馈的几个用户日志进行对比，发现了一个共同的特征：Android 8.1.0。
刚好我们测试团队有一款 VIVO Android 8.1.0 的手机。于是，进行验证。发现可以百分百重现问题。同时，通过阿里云的云真机进行对版本测试，发现小米、三星同样有这个问题。
我们把问题反馈给了客户端的同事。于是客户端的同事进行了代码诊断。
2.2 客户端确诊 BUG
当问题刚爆发的时候，给客户端反馈这个问题。他们坚称他们代码没问题。因为在测试小组的真机上都通过了验收。而 H5 的同学也坚称他们的代码也没有问题，因为他们写法未使用一些新特性。所以，也不存在兼容性问题。
于是，我跟客户端的同学说。既然内嵌 H5 是采用系统的 webkit，那么 App 一定可以监控这个请求的过程。可以把请求的过程进行分解，把错误的状态找出来。
同时，我们的测试团队也没有闲着。使用旧 Android 版本对该特定 Android 8.1.0 进行测试。发现没问题。那么，一切就很明朗了。这一定是客户端这边的问题。
当所有“证据”都指向 Android 客户端开发同学的时候。他们痛定思痛终于肯低下自己倔强的头颅认真分析代码 BUG。于是他们回忆了这个版本他们到底是哪个手动了这该死的代码。
结果发现，是我们的客户端同学在这个版本加入了腾讯的 Bugly。
App Webkit 内核在加载 URL 的时候会触发一系统页面错误。Android 开发同学会在这个错误的重写方法里面把错误信息通过 Bugly 上报记录。于是，在这该死的特定版本出现了兼容问题。于是，后续的加载操作将自动停止运行。
2.3 修复 BUG
BUG 终于确诊。目前修复的办法就是任何加载过程中页面 JS 报错不进行任何的错误信息上报即可。说白了，这过程中不使用 Bugly 就好了。
3、怎样规避此类问题？
说实话，此类兼容性问题，对于测试来说是一个不小的挑战。毕竟，Android 厂商比较多，并且 Android 版本也非常之多。假如，厂商有 10 个，核心版本有 10 个，那么就要回归测试 100 次。这工作量不小。并且，对于小公司来说，在不考虑测试人力的情况下，也需要一大笔钱购买各个厂商不同系列不同版本的手机。
通过此次事件我提出了以下几点来保证问题：
- Android/iOS 任何类库的加入必须报备。
- Android/iOS 第三方类库的使用细节必须主动邮件整理说明。便于测试验收。
- Android/iOS 任何使用的类库或框架更新或移除必须报备。并注明影响的模块。
- 测试团队必须对当前用户群使用频率最高的 Android 系统进行专项测试。
- 测试团队必须对新增/更新/移除之后受影响的模块百分百回归测试旧版本。
4、总结
我作为开发团队负责人，必须要做好协调以及紧急预案的工作。在遇到这种紧急 BUG 引发的恶劣影响要及时做出响应，并推动问题的解决。同时，也要复盘问题产生的原因。找到合适的方案规避同一问题二次发生的情况。
网友评论