自动化 case 维护成本随着界面 UI 的变化越来越大,最后直接到放弃,怎样快速的维护 case 成为了突破口;
目前提供实现思路,后期会补上基于现有的 UI 自动化框架的实现;
UI 自动化只做页面逻辑,不校验接口数据的正确性;(有意见来喷,互喷才能成长)
UI 自动化只做页面逻辑,不校验接口数据的正确性;(有意见来喷,互喷才能成长)
UI 自动化只做页面逻辑,不校验接口数据的正确性;(有意见来喷,互喷才能成长)
起初为了自动化而自动化,后来 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 类运行可以看到效果)