广大程序猿们还在加班分析Crash修Bug吗? 有想过早点回家陪家人吗?这期Crash实验室,阿不带大家看看鹅(腾)厂(讯)同学是怎样用Bugly提高Crash的修复效率!
先给大家讲个小故事吧!
2011年底,鹅厂内部出现一个“Crash监控”的服务后,开发某App的企鹅们发现了一个真相:原来自以为很稳定的版本,结果上线后竟然……。后来,这些企鹅们就开始默默地修Crash了。再后来,鹅厂的所有App都接入了Crash监控服务。
一般的产品开发过程,都会历经几大阶段。经过多年的经验积累,企鹅们已经将Crash监控充分融入到研发流程的各个阶段。在每个研发阶段充分利用Crash监控服务,让企鹅们的研发效率和质量得到大大的提升。
开发阶段
对于开发哥,发生Crash不是难题,发生Crash又无法分析才是问题。IDE里一闪而过的Log根本不允许你细心分析原因,如果是体验过程中发生Crash那更不可能看到Log。怎么破?
接入Bugly,只要发生了Crash就能实时上报,平时项目组体验和开发自测过程中发生的Crash都会被一一上报,开发哥可以在Bugly监控平台从容分析原因。
“用了Bugly,再也不用担心因为Crash达不到提测标准了,哈哈”,开发哥得意地说道。
测试阶段
在测试妹面前,开发哥的自测要弱爆了,她能想到各种复杂逻辑或边界相关的场景,但追踪和重现起来都比较困难。怎么破?
鹅厂开发哥有破解Crash三件宝:错误堆栈、运行日志、设备信息。
“Crash监控上报的信息已经非常丰富,比如:详情的堆栈信息,设备运行时信息,还有Log,开发哥通过上报的信息就可以快速定位和解决这些问题,不用和测试人员反复沟通,或想办法重现,减少了很多沟通和时间成本。”一位测试MM主动分享道,“在测试阶段就可以解决30%以上的Crash问题啦。”
灰度阶段
经过开发哥和测试妹的调戏(呃,是测试)的App就没问题?好吧,你没遇到过机型导致的Crash?你没遇到过会有网络原因导致的Crash?用户实际场景比测试环境复杂的多,怎么破?
在产品首次上线,或是有重大改动时,都要有灰度版本的发布,也称为“内测”或“公测”。灰度预热阶段,已经开始有大量用户使用产品,一般此刻会暴露出大量机型以及与实际环境相关的Crash问题。
负责项目管理的GG说,“这个时候,应用是否接入Crash监控非常关键。因为通过Crash监控平台的实时监控,可以快速了解灰度过程的Crash问题,项目组同时可以评估Crash的影响程度,确定产品是否可以正常上线。”
“ 还有,解决了灰度阶段发现的Top10问题,相当于解决上线后40%的Crash问题了。”一旁的开发哥补充。
上线阶段
App发布到用户手里谁也不能改代码,开发哥总算可以安心回家了?呃,你不知道每天的运营活动、后台服务故障都可能导致App出现Crash问题么?
怎么破?别担心,每天上班就到Crash监控平台上看看趋势分析视图,如果没有突变就安心写代码吧!
“有一次,在监控平台上发现Crash次数猛增,跟进后才知道,后台开发GG不小心把某个正在开发的功能发布到正式环境了,影响了线上服务。幸好当时项目组及时发现,并做了处理,才没有造成大的影响”,一位产品运营企鹅MM心有余悸地说道。
小结
小编还是将以上的访谈总结成一张图吧。希望看完文章的你,也能通过我们Bugly来提高研发效率和质量。这样,在后续的不管什么节日,都能早点下班陪家人过节。
本文系腾讯Bugly特邀文章,转载请注明作者和出处“腾讯Bugly(http://bugly.qq.com)”