Appium 大家是如何设计 UI 自动化用例的

kasijia · August 19, 2019 · Last by 槽神 replied at August 20, 2019 · 1096 hits

测试框架用的是TestNG,用例方面我目前的设计方式如下,好处是一个页面崩了(会重试3次)不会导致其他页面的测试受到影响,坏处是进入到每一个测试页面都需要重启APP并且可能会经过重复的路径,影响执行效率。虽然深知UI自动化稳定性大于一切,但还是想尽可能提高执行效率,不知大家有没有更好的设计方式?

【Suite】
class1:页面1的测试类(集合所有页面1的测试点)
class2:页面2的测试类
class3:页面3的测试类

【测试类】
public class class1 extends BaseCase {
@BeforeSuite(写在base类BaseCase中)
作用:生成执行用例所需的资源,例如日志/截图目录等

@BeforeClass(写在base类BaseCase中)
作用:启动App

@BeforeClass(写在base类BaseCase中)
@Override
作用:操作元素进入claas1对应的测试页面

@Test
作用:测试点1

@Test
作用:测试点2
.
.
.
}

共收到 5 条回复 时间 点赞

BeforeClass 修改成 BeforeTest 我觉得就不会重启App了

J 回复

BeforeTest相当于每个用例(@Test下的方法)执行前都会执行一次,而我目前只会在切换页面(class)的时候才会重新启动。

不用没条case都重启app吧,可以封装一个通用的方法,执行完case返回到首页或特定页面,放在AfterMethod里面,而如果要处理执行case崩溃的问题,可以再封装一个方法,先判断当前app是否处于前台状态,不在的话,再重启app,也放在AfterMethod中调用

xiaoxiao 回复

多谢提供思路。决定把返回首页的步骤放在@AfterClass里,每个class中的case执行完后返回首页,然后继续执行下一个class中的case,假如返回失败就重启APP。😀

kasijia 回复

是吗,我怎么记得TestNG的@BeforeTest作用于suite里面的Test声明呢,一个test里面可以有多个class,一个class可以多个method,你所说的@Test注解,起作用的怕不是@BeforeMethod
我很久没用了(最后接触的是6.4),不知道现在TestNG改版了没有~

kasijia 关闭了讨论 20 Aug 09:53
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up