G_Tester
(盖盖)
2
有些页面出现空白,卡死情况(例如企业微信的通讯录菜单切换不进去),就会导致后续用例无法执行,这种情况出现如何直接跳过影响的case
这个问题:
你可以在后续用例加上页面字段判断,比如从企业微信跳转到通讯录菜单页面,怎么判断跳转成功,pagesource有特定的字段,这样才执行下面的方法,如果没有直接break结束
G_Tester
(盖盖)
3
例执行过程中卡在某一步,如何退出到指定页面,继续执行后面的用例,老师上课都是正常场景且都是单场景(goback部分都是demo,未具体实现),其实如何组织用例执行也是一个大的难点在里面(特别是用例执行过程遇见异常时)
这个问题,你封装个back方法,默认返回次数为5或者10,看你app的深度,每次返回的时候,back对应页面就好,判断back是否结束,就判断返回的页面是否是打开app的那个页面
G_Tester
(盖盖)
4
- 异常崩溃类(包括adb、driver异常退出、APP/浏览器 crash等)
这个添加报告,到时候看报告日志,appium的报告,还有web的报告,在每个关键字上添加对应抛出的异常放在日志里面,只能这样分析,对应的app自动化长时间可能uiautomator2不稳定,所以,最好加上重试机制
king152
(迪)
5
这种崩溃类的 重试机制应该没用,我的想法是如果崩溃了,能不能重启杀掉原来的进程重启应用,继续执行与崩溃无关的case,不然一个崩溃到后面都没得到执行,影响效率
king152
(迪)
6
目前对于UI自动化各种异常的情况,都是非常脆弱,基本上最后都做的不稳定,所以想要做的更加稳定
G_Tester
(盖盖)
7
可以通过adb命令重启app,在每个大case执行前进行重启一次也行
UI的时候你要判定是否是当前包名,来定义是否崩溃
G_Tester
(盖盖)
8
更加稳定就是加各种判断,断言是在最后做,判断在中间按钮或者页面进入的时候做
因为场景可能需要这次进入app点击登录然后点击查看,下一个场景是需要进入app登录后点击输入搜索,再查看,还是用到po,你把每一个方法颗粒度最小化,便于组合
这些问题本质都是对Session Suite与TestCase级别的BeforeXXX AfterAll的利用。无论哪个层次的异常,都是捕获异常+异常处理,处理失败+异常上报机制。上课的时候给大家讲的是捕获异常+异常处理。
你提的问题主要是第二个方向,就是处理失败+异常上报的机制,这方面可以看下 Junit5的扩展机制