通用技术 Charles 断点调试的一个应用实例

Michael_Wang · 2015年03月01日 · 1429 次阅读

公司过年前提交了一个版本到 app store 上面,审核通过后发现友盟统计崩溃率上升到了 10-15‰之间(之前是 3-4‰)。

然后我们针对此问题进行了测试,从用户反馈和 log 来看是启动程序的时候崩溃,然后我们就通过不断重复的杀掉客户端进程然后打开客户端,发现可以很低概率的复现。毕竟才 1% 的概率,开发也针对此问题进行了修复,但是由于复现概率低,所以很难确认是否修改成功了。

针对此问题还咨询过@Monkey,并给出了建议可能是缓存或初始化方面的问题。

我们这个版本确实加入了缓存功能,看过的文章能够被缓存下来。但与开发沟通后,在启动程序的时候混存这块的代码根本就没有调用,所以排除了是缓存造成的问题。
然后就是初始化数据加载方面。我们的客户端在打开进入首页时,异步请求了两个接口:
1、首页 Banner 图片接口
2、首页列表文章接口

然后就用 Charles 工具中的断点功能对两个接口分别进行了控制,才发现当控制 Banner 接口时,启动程序进入首页后就直接崩溃。
然后这个问题的复现步骤就明确了:如果首页列表文章接口请求成功了,但是 Banner 图片接口 2 秒内没有返回数据,程序就会崩溃。

最后这个问题算是最终解决了。

但是我感觉这种崩溃,在测试阶段的时候真的很难发现。有了这么个经验,以后这方面测试可以加强一些了。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 1 条回复 时间 点赞

这类 bug 手工测试确实比较难发现(手工测试一般不会老是去重装应用),但优先级却比较高(影响用户体验)。
可以试试把安装测试放在弱网络中进行来尽早发现这类问题。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册