Appium 自己做的基于 webdriver/appium 的 UI 自动化框架,有源码和框架说明文档,欢迎大家使用并给出建议

金圣勋 · 2018年06月19日 · 最后由 乾行 回复于 2018年06月25日 · 3878 次阅读

框架名称:jsx 的 MyDriverUITest

框架简介:基于 selenium webdriver 和 appium driver 的自动化框架,支持 web 端和安卓端的 UI 自动化测试(IOS 端框架本身支持但没验证过),目前支持 java 方式脚本编写,所有测试数据用 excel 管理。目前只是 jar 包形式的框架,按最近趋势,也想把它平台化,请大家给个建议。

框架提供的功能:
1、数据配置
1.1 支持 web 端和手机端 (安卓/IOS) 的测试,提供丰富的启动参数配置附带详细说明

(web 端配置)

(手机端配置)
1.2 支持多个设备 (浏览器/手机) 同时参与测试

1.3 支持数据驱动方式,提供多样化的数据配置,包括工具参数、测试用例数据、模块用例定义、控件定义等,数据和脚本完全分离,方便日常维护

1.4 提供灵活的调度执行机制,每个测试集或用例都有开关控制可以任意选择执行,可配置测试集和用例之间的包含关系和所使用的业务单元


1.5 通过对象库管理所有 UI 控件,支持基于 xpath,id,uiautomator,坐标等多种控件描述方法,在对象库的对应控件上直接配置,无需修改脚本

1.6 支持不同页面分辨率下的坐标自动变换,根据调试环境和实际环境下分辨率的比例对应调整坐标点以适应实际运行环境,也可以手动配置不同分辨率下的坐标点,框架根据当前分辨率自动选择对应的坐标点使用


1.7 支持测试用例的数据驱动执行和出错时重复执行,提供不同的输入数据组循环执行,每个数据组都有开关控制,提高用例的复用性

2、脚本设计和开发
2.1 提供 web 端和手机端常规操作和数据获取接口,几乎所有的页面操作和测试判断都能实现
操作接口:点击、滑动、鼠标移动、长按、文本输入、键盘指令、弹窗处理、上传下载
数据获取接口:获取控件文本/数量/大小/坐标、判断控件存在/可见/有效/选中等
2.2 提供脚本调试模式,可以在任意脚本段设置断点,方便脚本调试

2.3 提供 5 种级别的异常处理和重复执行机制,遇到异常时可以忽略继续执行或转到上一层脚本继续执行,保证测试用例执行的稳定性

2.4 引入业务单元概念,所有测试模块和用例全部通过业务单元实现内部逻辑,避免脚本的重复编写,减少脚本开发和维护工作量
2.5 脚本全部通过控件名引用目标 UI 控件,支持在控件名里传递变量值及多个控件组合使用,提高脚本可读性的同时适应多种控件引用方式

2.6 手机端测试支持 session 连接失效时自动重连机制,重连后自动进行恢复到测试用例初始化状态,保证继续执行

2.7 提供丰富的测试断言用于测试结果判断,包括文本内容/控件属性值判断、数字日期型数据的比较、控件状态判断、控件数量判断、页面跳转判断等,也支持正则表达式的比较

2.8 提供字符串处理工具,包括目标字符串截取、删除、日期型数据处理等,内置大部分日期型数据的正则表达式和日期格式,让用户更专注到业务而无需考虑字符串处理的算法
2.9 框架基于目前自己的自动化工作流程和脚本设计规范开发,有详细的流程和脚本设计规范文档
(测试模块脚本设计)
(测试用例脚本设计)
(业务单元设计)
2.10 支持变量的使用,用于存储测试过程中的中间数据用于测试结果的期待值。变量分全局、业务单元级别两种,生命周期都是脚本执行全过程,但作用范围不同。

2.11 手机端测试支持列表项内控件的自动定位,当前列表页无目标控件时自动滑动到下一页继续寻找直到定位该控件为止,也支持从列表中间自动返回到列表顶部。




2,12 Web 端和手机端都支持全屏和局部截图,局部截图可根据控件位置或坐标范围确定截图区域,测试日志的截图提供开关控制以提高脚本执行效率



2.13 Web 端支持 iframe 切换和多窗口跳转,手机端支持 App 内 h5 页面的测试,需要用户手动切换到目标 iframe/浏览器窗口/h5 模式并返回默认状态,当切换后测试中出现异常时自动返回到默认状态保证脚本继续往下执行



3、测试结果输出
3.1 提供基于特征控件的操作层面验证机制,每个操作结束后可以马上验证结果,在配置文件直接描述验证逻辑,提供丰富的描述语法和’&&’,’||’ 组合描述,支持变量传递
(特征控件语法描述)
(特征控件结果显示)
3.2 提供 html 表格式的测试日志和测试报告,日志描述每个操作的所属模块/用例、操作名、操作对象和相关数据、错误原因、截图等,报告提供每个用例的测试点结果及统计信息,提高日志报告的可读性


后续更新内容:
1、支持不同 iframe,不同 window 之间,native 和 webview 之间等跨模式下的特征控件判断
2、手机端优化自动搜索列表项控件算法,根据页面结构 (getPageResource) 判断滑动有效性和是否到达列表底端
3、控件定位方式支持与 index 的组合定位,根据 xpath,id,classname 等获取控件列表后再获取指定 index 的控件
4、支持 IOS 端 app 测试
5、实现在脚本内启动 AppiumServer,测试结束后关闭服务
6、实现多任务并发测试,线程之间完全独立,配置文件独立
7、手机端进行设备检查,配置设备和实际连接设备不一致时删除不合格的设备
8、手机端日志输出增加 AppiumServer 日志和 adb/ios 设备日志
9、日志除了 html 外还提供基于 log4j 的文本日志,用户可选择
10、Html 日志和断言报告都按测试模块生成,不包含父类模块;增加错误日志和错误断言报告;测试日志和断言报告增加测试环境描述;测试日志增加操作统计,按用例、按模块、按线程;增加所有线程最终统计;
11、支持邮件通知,开关控制,详细日志和报告按模块实时发送给指定人,统计报告测试结束后一次性发送给指定人
12、脚本开发环境支持 xml 方式,所有操作命令封装为 xml 节点,效果跟 Java 编写脚本完全一致
13、文本化脚本环境,所有操作命令封装为文本化的操作指令
14、支持手机端浏览器测试,web 端浏览器增加 safari 的支持
15、支持 PC 端 client 测试

相关资源下载:
百度盘(https://pan.baidu.com/s/1EGaUIxy0S3xD-q9SMLC3zA),有详细的框架说明文档和源代码,欢迎大家使用。

个人信息
作者:金圣勋
手机:13581520201
QQ:395433458

最佳回复

感谢楼主分享,几年前做过同样类似的事情,当然楼主显然做的比我要好,我说下我碰到的问题:
1,像这种数据驱动或者关键字驱动体系化的框架会限制测试开发同学的一些开发或架构设计能力
2,同时上层框架化的话局限性挺大,让别人看到上层的东西会感觉技术 sense 有点 low
3,其次有一些复杂场景支持不是很好

共收到 15 条回复 时间 点赞

感谢楼主分享,几年前做过同样类似的事情,当然楼主显然做的比我要好,我说下我碰到的问题:
1,像这种数据驱动或者关键字驱动体系化的框架会限制测试开发同学的一些开发或架构设计能力
2,同时上层框架化的话局限性挺大,让别人看到上层的东西会感觉技术 sense 有点 low
3,其次有一些复杂场景支持不是很好

想起了以前做的一个关键字驱动程序,完全不用写代码,就再页面上填写一些关键字,后台实现自动化,返回测试结果。简单的 ui 检查还行,复杂业务就很难实现了。

testly 回复

这么详细分享说明还是很不错的,而且好多路要走过才知道,分享精神还是值得学习肯定的嘛。

如果继续做的话,楼主应该继续完善,自动或者选择拾取关键字,生成关键字对应的 xml,完全解放双手,不然业务变化时这样维护数据也是很麻烦的。而且应该考虑复杂业务复杂场景实现的可行性。

hello 回复

嗯 没错

感謝樓主,請問還有開放下載嗎?
網盤點進去似乎已經錯誤連結了

謝謝

脚本不用代码写,感觉很多场景不好实现,并且维护起来也不简单.
我自己也写了个类似基于 appium 的 GUI 框架,实现功能很多,但是还是有很多缺点.

我觉得很多自动化玩着玩着就玩坏了,我认为,开发出一个类似 katalon studio 这样的自动化工具,最好了。这种 excel 和 xml 的配置多了,反而更复杂了,

@testly
2,同时上层框架化的话局限性挺大,让别人看到上层的东西会感觉技术 sense 有点 low
答:确实 low 点😂 ,我本来就业务测试出身,对技术不是很敏感,之前想的是在自己的技术范围内只要满足自动化需求就 OK 了,不过考虑为了框架扩展必须使用标准技术,如项目改成 maven,数据存储用 xml/yml 之类,使用关键字驱动方式脱离 java 环境下脚本编写等。
3,其次有一些复杂场景支持不是很好
答:如果指的是复杂业务场景,我是用业务单元形式写脚本,测试用例全部通过这些业务单元实现脚本,这些业务单元通过参数驱动调用,实现脚本重复利用,任何复杂业务都可以实现且保证脚本和数据唯一性,可以参考下面的用例案例。

整个用例先后经历 15 个业务单元完成脚本,在 4 个结果页面进行断言判断,算是业务比较复杂的用例。业务单元和测试用例框架提供了对应的实现机制,只要业务分析到位,觉得任何复杂用例都能快速编写脚本。

hello 回复

类似 qtp 的快速模式吧,以后打算把框架平台化,让用户直接在平台上写脚本,类似如下格式:
输入 | 登录页.用户名输入框 |userid;
输入 | 登录页.密码输入框 |password;
点击 | 登录页.登录按钮;
var1=获取 | 首页.右上角登录信息.用户名;
var2=获取 | 首页.右上角登录信息.用户名 | 是否激活;
支持页面操作和数据获取,同时引入循环和条件判断机制,这样任何复杂业务场景应该都能实现,效果跟我现在用 java 写脚本完全一样。

hello 回复

业务发生比那话无非要修改业务脚本、控件定位、测试输入数据 3 种,现在已经做到脚本/控件/数据的唯一性,哪个部分发生变化只修改一次即可。不知道业主说的 “自动或者选择拾取关键字,生成关键字对应的 xml” 啥意思?

hello 回复

我理解的是把 java 写的业务脚本转换为 xml 形式,方便用户以后修改是吗

amy 回复

链接是永久有效的,进入后如下:

业主网络是不是有问题?以后代码共享在 git 上,更专业点

Then 回复

对,不懂 java 的业务测试人员用起来确实有难度,以后将转成 xml 形式或自定义语法的文本化脚本,同时引入脚本录制功能,尽量方便维护修改。

楼主的精神可嘉,但是 UI 自动化的趋势没有抓住。
在学习 UI 自动化的测试同行们建议多了解一下 UI 录制、UI 遍历!

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