解决方法:https://testerhome.com/topics/1996
问题:Robotium 在运行测试用例的时候,有时候会遇到导致被测试程序 crash 的情况,同时测试程序中会停止,然后测试结果也收集不到了。
Instrumentation tests live in the same process as your application, if you applications process crashes so do your tests 这个我知道,我目前只是想找到解决方法。
希望达到效果:把程序唤醒然后略过这条用例继续执行后续用例,保证能收集到所有测试结果,包括 crash 的部分
目前情况简介:我目前是通过 ant 在 build 文件中写 adb shell 命令配置到 jenkins 中执行用例,所有用例是在 xml 中配置好的,同时在 jenkins 写 groovy 脚本可以获取到所有要执行的测试用例类名
求助:大家有没有什么好的处理方法还请赐教
下图是执行过程中遇到的崩溃问题而终止执行的情况
看图上的共同特点是异常后都有 shortMsg=XXX
提问的方式不对吗?没有人遇到这样的问题吗?为什么没有人回答@lihuazhang
写个工具来重启崩溃的 TestSuite,
使用线程管理的办法,adb shell 命令启动 TestSuite。
把每个手机当作一个线程,每个手机里跑的 robotium 都是单线程的。你需要监控,管理每个线程,同时你还有监控每台手机的 log,当出现 crashe 的 log 时,启动新的线程来启动新的 TestSuite。
#3 楼 @ganyunxiao 你说的工具是运行在 PC 上的还是手机上的 apk,方便和 jenkins 搭配吗?我考虑一下你的方案,再找找看有没有合适的,非常感谢
#2 楼 @lihuazhang 好吧
把用例拆了,一个一个执行,crash 了就影响不到了
#9 楼 @shixue33
选择具体方法或者类后作为参数传入执行形如下列命令
adb shell am instrument -e class com.xxxx.sampletest.topics.TopicList#test_001_havenotanytopic,com.xxxx.sampletest.topics.TopicList#test_002_addtopic,com.xxxx.sampletest.topics.TopicList#test_003_cllectTopic" -w com.xxxx.sample.test/pl.polidea.instrumentation.PolideaInstrumentationTestRunner"
生成报告
如果一条命令一条命令执行的话,结果是每个用例都是一个 Html 形式的报告,不是最终的汇总报告。我可能需要重写 PolideaInstrumentationTestRunner 来重新组合报告。
我用 java swing 写了一个管理手机和启动 testsuite 工具,统一管理 testsuite。
运行在 pc 端,如果有需求也可以平台化。
jenkins 没用过。
首先,手机开 adb 连接电脑,工具上选择需要运行的手机设备。
现在用了一个 excel 来做配置文件,保存测试配置参数。
包括:设备 ID ; 被测 apk 路径 ;测试 apk 路径; RunClassName ;执行次数 ;保存路径 ;上传路径
RunClassName 是一个 testsuite 的 list。当运行到第 n 个 testsuite 崩溃时,就开启新的线程启动新的 testsuite 的 list。
收集测试报告: 我也写了一个小工具来解析 xml,把分散的 junit 的测试报告整合成几个或者一个报告。
#13 楼 @ganyunxiao 谢谢分享,如果没有更好的方法的话,我就按你这个思路自己写写,我先找找看还有其它更好的方法没有,如果有现成的东西或者简单些的方法,就不自己再搞一套东西出来了,因为自己搞出来以后还需要和 jenkis 啥的配合。
@emily 你解决了吗?我跟你遇到了同样的问题
#22 楼 @huadashao520
每个 case 作为一个 class 来处理就好了
新起一个监控线程,监控如果 Crash 了就重新执行启动命令就好了。
使用 Python 脚本循环启动 Robotium 脚本,另外,Robotium 脚本记录下当前 case 的运行情况,即哪些 case 运行过了,Robotium 脚本运行的时候只运行当前未运行的 case,这种实现方式比较简单~
我最近在做细化的 Robotium 脚本,发现其实大部分的因为脚本的问题导致的 crash 是可以避免的,像你举的几个例子,一个是空指针,在操作相应的 view 对象前,先判断下是否为空或者是否可点击就可以避免这种问题了,第二种,view 定位的问题,将异常 catch 住然后抛出就不会报错了;
我们如果可以从根本上解决为什么 crash 的问题,就不用考虑 crash 后的处理了