移动测试基础 UI 自动化的一些实践

king.yu · 2017年09月27日 · 最后由 king.yu 回复于 2017年09月28日 · 1775 次阅读

背景

自动化 case 维护成本随着界面 UI 的变化越来越大,最后直接到放弃,怎样快速的维护 case 成为了突破口;
目前提供实现思路,后期会补上基于现有的 UI 自动化框架的实现;

重要的事情说三遍:

UI 自动化只做页面逻辑,不校验接口数据的正确性;(有意见来喷,互喷才能成长)
UI 自动化只做页面逻辑,不校验接口数据的正确性;(有意见来喷,互喷才能成长)
UI 自动化只做页面逻辑,不校验接口数据的正确性;(有意见来喷,互喷才能成长)

目前的 case 流程

起初为了自动化而自动化,后来 leader 认为业务质量高于一切而放弃,等有时间了再来补一发,然后就不了了之了;

1 自动化小组封装现有的开源框架;
2 按照业务流程书写 case 或者 增加 PO 模型书写 case;
3 跟着迭代的步伐修改页面对象和业务流程;
4 版本发布频繁,case 无法不足,直接放弃;

突破口

1 书写 PO 模型的时候其实我们已经知道该控件的所有属性,暂且定义如下:

protected ElementGetWay elementGetWay;          // 控件的获取方式
protected String value;                         // 获取方式使用的value值
protected int index = HAS_NO_LIST;              // 控件index值 default 999999 无list
protected String desc;                          // 控件信息描述
protected String text;                          // 控件text内容,操作为getText()时用来存储数据
protected OperateType operateType;              // 操作方式
protected ElementType elementType;              // 控件获取平台 :Native 或者 H5 或者 WEB
protected String childPageName;                 // 控件操作后到达的页面
protected String depend;                        // 同级页面依赖:该类中控件的属性名
protected OperateType need;                     // 滑动方向 查找元素或者其他必要的操作
protected int priority;                         // 同级页面操作优先级 ,例如:下单页面的地址栏添加等

2 定义注解,通过反射实例化各个控件:

@Retention(RUNTIME)
@Target({FIELD, TYPE})
public @interface WebFindBy {

    /**
     * 控件获取方式
     */
    ElementGetWay getElementWay() default ElementGetWay.APPIUM_ID;

    /**
     * 对应控件获取方式的值
     */
    String value() default "";

    /**
     * 控件text值
     */
    String text() default "";

    /**
     * 控件index值 default 999999.
     */
    int index() default ElementUIBean.HAS_NO_LIST;

    /**
     * 控件信息描述
     */
    String desc() default "";

    /**
     * 控件操作方式
     */
    OperateType operateType() default OperateType.SCROLL_PULL_UP;

    /**
     * 控件类型
     */
    ElementUIBean.ElementType elementType() default ElementUIBean.ElementType.NATIVE;

    /**
     * 同页面依赖
     */
    String depend() default "";

    /**
     * 该控件操作后到达的页面
     */
    String child() default "";

    /**
     * 设置滑动方向来查找元素
     */
    OperateType need() default OperateType.SCROLL_PULL_UP;

    /**
     * @return priority 优先级 数字与用例基本对等 n = p(n)
     */
    int priority() default 3;

3 根据控件中 child 与 页面对象中的 PARENTS 属性(父页面)自动生成执行路径

4 根据控件中的控件获取平台 与 控件操作方式 来执行对应的操作;

总结

通过以上方式解决了由原来维护 PO 对象和业务流程的方式变为只要维护页面对象的方式,减少了一部分工作量;

后期扩展

1 与 Xmind 的路径 case 做集成;
2 控件可以通过自动遍历得到,用户修改添加权限值;(突出关键业务的遍历)

DEMO 的下载地址:(找到 Test 类运行可以看到效果)

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 3 条回复 时间 点赞

相当不错的思路,多谢楼主分享,可以继续增加新的内容

—— 来自 TesterHome 官方 安卓客户端

不验证接口数据的正确性
比如一个查询库存的 case,页面点击后,出现的库存数量,不需要与数据库的数据进行校验,是这个意思吗

adonisjph 回复

跟页面的交互数据全部 mock,页面稳定,接口稳定后再做集成回归;否则 case 的维护成本与实际效益相差甚远;
你这种场景需要验证的是库存不足时,购买或者下单失败;(但这又是特殊场景,所以做 UI 得有个度)

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册