移动测试基础 求问各位大佬,对于偶现的崩溃有什么好的解决方案吗,平时测试测不出来,一上线崩溃率就不断增大?

bozeng · August 01, 2019 · Last by 胡章正 replied at August 14, 2019 · 2313 hits

移动端测试,平时测试测不出来一上线崩溃率就不断上升,对于偶现的崩溃有什么解决方案吗,如何管理这类问题?求各位大佬不吝赐教。

共收到 23 条回复 时间 点赞

我抛个砖,楼主有没有收集线上反馈的崩溃的原因,都是哪些原因呢,是因为机型还是某些怪异的操作?

bozeng #2 · August 01, 2019 作者
黑山老妖 回复

线上是有监控的,日志是能够收集的,原因自然也能知道。但是测试的时候这些偶现的crash并不能暴露出来,所以造成测试的时候测不出来,一上线crash概率就有可能增大。所以我想问的是,能够通过一些手段或者方案,在测试阶段就把这些偶现的崩溃暴露出来?

  1. 自动收集和上报闪退信息,便于后期分析处理。
  2. 测试阶段,跑跑monkey和云测,可以帮助重现问题

就没有人考虑过为什么移动端,尤其是native,那么容易crash吗
我觉得要么操作系统垃圾要么就是编程语言/编译器垃圾啊,没有有志气的大厂想着从根本上解决问题的么……
出点NPE就crash,出点小意外就crash,试问PC上或者Web上哪来这么脆弱的~~~
移动端这操性,放在系统架构的概念里面来说就是可用性极差,No Availability~想想就恶心~

APP的monkey不要断,坚持每个版本多个机型试试,线上的机型多且杂乱,不可能每个机型都涉及到,但是主流机型要看看

有没有分析过具体原因?后端返回缺少字段?索引越界?NPE?弱网?框架问题?
分析出原因后就增加用例,针对性的测试;崩溃率很高只能说明测试覆盖率还不够。

arrow 回复

如果方便的话,可以把崩溃的原因发出来,这样方便分析问题,也可以帮助其他人少踩坑。😀

bozeng #8 · August 01, 2019 作者
槽神 回复

老哥思考问题很深入,格局很大,学习了

测试机型不够嘛。还是特定机型特定版本?
上线前找云测测一轮。覆盖会全点。
日志啥的都监控上。
不可能完全覆盖的,有发现异常或者用户反馈就重点处理呗。

bozeng #10 · August 01, 2019 作者
arrow 回复

老哥说的很好,想问一下,针对NPE、框架这种问题如何针对性的设计case呢?

槽神 回复

NPE导致崩溃,这个一般是后端缺少返回字段或者传了空导致的吧

是某个操作有一定概率崩溃,测试有覆盖到只是崩溃的概率低,还是没有覆盖到,属于场景没有考虑到没测到的崩溃

bozeng 回复

我胡喷的,格局这个词太抬举了
平时听到看到的真是大把的开发、测试人力浪费在这种事情上面,我觉得不久的将来可能会得到根本的解决吧~

其实对于NPE来说,只从编码角度来说,改改习惯,配合代码扫描就能解决,关键有没有这个意识,最近刚学的杜绝NPE的一种方法,后端的Java为例,方法有很多,比如善用Lambda表达式和Guava工具包等等:

List<CodeMissionStatus> sts = baseQueryDAO.codeMissionStatus();
String oldStatusName = sts.stream().filter(f -> Objects.equals(f.getStatusId(), mission.getStatus())).findFirst().orElse(new CodeMissionStatus()).getStatusName();
String newStatusName = sts.stream().filter(f -> Objects.equals(f.getStatusId(), statusId)).findFirst().orElse(new CodeMissionStatus()).getStatusName();
bozeng #16 · August 02, 2019 作者
陈恒捷 回复

赞,思路清晰,具体深入,学习了。多谢大佬

bozeng #17 · August 02, 2019 作者
槽神 回复

赞,学习了。

app 崩溃;
这 第一印象就是空指针之类的问题; 其实也可以逆向思考; 这个版本的app 质量如何,检查版本代码质量 看看 编写方式引起的 异常;
也可以通过 虚拟模拟手机 抓取app 运行的 dump 进行对比和分析;

其实就是将单元测试纳入测试范畴;是最好的防范措施; 也可以通过市场上 一些 监控数据流的 平台,监控;

监控+单元测试+应用app dump +埋点 多方式的去思考;

题外话哦 ,其实最直接的 就是找一个 android架构师 看看当前应用app 架构,应用是否合理,架构会帮你看 开发代码质量的问题;

感觉和我这边服务端某个版本会出现1-2台机器core一样,测不出来😂

提供一个蠢办法.
拉研发一起分析线上崩溃的主要场景.把这些场景结合你们的主功能编写对应的自动化用例.【该部分作为每次必过自动化用例】
对于新增功能可以结合自己和研发的建议,选择性的执行对应场景的自动化稳定性.
在每个版本测试期间执行个几万次机型选你们APP支持的手机系统版本[例如5.X~9.X].大体上是可以跑出一些线上较高崩溃率的BUG来.
最简单的方式就是airtest,uiautomator2啥的选个顺手的自己工作机搭个环境就可以跑起来了.

还是要先找到奔溃的原因先

22Floor has been deleted

我觉得,
难道不应该写代码的好好想一下为啥会crash么?为啥PC或者Web的没有crash么?
系统都是一样的系统,只不过代码不是一样的代码,写代码的人更参差不齐。
web上的,浏览器他家写的么?异常他家捕捉的么?内存他代码去管理的么?crash表现不一样而已,你web crash相当于脚本crash没了交互,页面还是正常显示,感知没这么明显而已,浏览器子进程处理,没卡死主进程而已。
写web就写一下业务代码,内存泄漏不知道就说别人家电脑卡,浏览器卡的时候考虑过电脑的感受么。
写PC的不catch致命异常,他正常运行给我看看。

bug问题可能隐藏的很深,不同的网络环境,不同的应用场景,因素太多;也可能咱们的兼容适配也有问题,我是云测sales,感兴趣可以深入探讨下,嘿嘿,17600620488

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up