Appium appium + xml + web 自动化测试框架设想及实践分享

49875183 · 2015年07月12日 · 最后由 jojotester 回复于 2016年11月10日 · 58 次阅读
本帖已被设为精华帖!

加入新公司二个月了,对 appium 也有了初步的了解。
针对我们自己编写的 appium 自动化脚本,如何更好的维护?及让其他测试组员更方便、更灵活使用我们编写的脚本进行自动化的测试?我做了一个简单的设想,并抽空做了实践,我会持续更新帖子,将最新的实践成果分享给大家,欢迎各位指正,也希望大家砸一些新的思路给我,一起学习,共同进步~~

想要做的事:

1, 测试人员在没有进行环境安装、不懂 appium 的情况下也可以使用我们开发的脚本
2, 测试人员通过 WEB 页面去定义要测试的元素对象、模块、流程以及测试数据的配置
3, 测试人员在 WEB 页面直接点击执行按钮,就可以执行测试脚本,脚本运行完成后,输出执行结果供测试人员查看
4, 使用 XML 文件做为元素对象库,方便后续维护(当然如果是数据库配置的话会更加灵活,测试人员也可以自行添加元素对应关系,为了方便快速的验证设想,使用了 XML)

通过近日和大家的交流,对思路及实现方式进行了调整和优化。目前使用 APP 的登录功能进行了实践和设计,代码已进行实际跑测。

1,为了方便快速实践还是使用 XML 进行元素管理,对元素属性进行精减,去掉不必要的属性
<?xml version="1.0" encoding="UTF-8"?>
<page>
    <element name="user"> <!-- 元素对象 -->
          <name>手机号</name><!-- 元素名称 -->
          <type>input</type><!-- 元素类型 input/button -->
          <pathtype>1</pathtype><!-- 获取元素的模式 1:findElementByAndroidUIAutomator/2:findElementByXPath/3:findElementById-->
          <pathvalue>new UiSelector().className("android.widget.EditText").index(0)</pathvalue><!-- 元素定位路径 -->
    </element>   

    <element name="password"> <!-- 元素对象 -->
          <name>密码</name><!-- 元素名称 -->
          <type>input</type><!-- 元素类型 input/button -->
          <pathtype>1</pathtype><!-- 获取元素的模式 1:findElementByAndroidUIAutomator/2:findElementByXPath/3:findElementById -->
          <pathvalue>new UiSelector().className("android.widget.EditText").index(1)</pathvalue><!-- 元素定位路径 -->        
    </element> 

    <element name="denglu"> <!-- 元素对象 -->
          <name>登录按钮</name><!-- 元素名称 -->
          <type>button</type><!-- 元素类型 input/button -->
          <pathtype>1</pathtype><!-- 获取元素的模式 1:findElementByAndroidUIAutomator/2:findElementByXPath/3:findElementById -->
          <pathvalue>new UiSelector().className("android.view.View").description("登录")</pathvalue><!-- 元素定位路径 -->        
    </element> 
</page>
2,对常用方法进行了封装

AppiumActionUtil 对组合活动操作进行了封装

AppiumFindElementUtil 对查找元素的方法进行了封装

AppiumHandleUtil 对元素活动进行了封装

AppiumXpathXmlUtil 使用 XPATH 对 XML 文件元素进行解析(使用 XPATH 替换掉了 Document 方式)

Util 封装了一些其他通用功能

3,每一个应用页面对应相应工厂类(此类用于定制各类通用操作)


登录页面工厂类

4,调用 CASE 时,只要获取 web 传入的句柄就可以轻松执行自动化脚本(这里就可以穿插各类断言,对同一元素对象,在同一脚本中多次出现、执行不同动作、出现在不同位置进行相关配置)

user=15910532052;password=123;denglu:click
“;” 号用于对操作组合进行拆分
“=” 号表示对元素进行赋值操作
":"号表示对元素进行点击或其它操作

配合我们封装好的方法,只需要短短几句就可以执行 web 传入的操作指令

句柄到底怎么定义,可以根据需求进行相关 web 指令配置即可,这样即解决了断言的问题,也同时解决了同一元素需要在不同场景执行不同指令的需求~

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

nice。半小时的操作能节约半天的测试工作量,这才是自动化的精髓。以往崇尚写代码说回归的只适合传统自动化了。现在迭代太快了,两个月就天翻地覆,没意义。当然如果你的对象是百度啊什么的,当我没说

#1 楼 @pighero001 当然我们在做自动化的时候,也是需要抽取适合做自动化的功能的,针对一些比较固化的流程类做一些辅助性的自动化不是的挺好的嘛~ 不需要再从头到尾的全部点一遍才能看到最后的测试结果(同时还要验证各环节数据的正确性),通过自动化一键完成不是会相对简单一些撒~~~

1.如果一个页面的同一个元素,在同一个 case 中, 不同时间做不同的操作,是写两个,还是定义两个,xml 解析成脚本时在做处理?
2.你们是用 UIautomator 把页面元素 dump 下来再去编辑修改维护 xml 吗?一个页面一个 xml。你们现在管理编辑起来感觉方便吗?
3.web 平台上显示的 html 点击运行开始解析脚本跑用例,这挺好的。以后你们的可以平台化了。
4.谢谢楼主的分享。

#3 楼 @jennyhui
1、不同时间做不同操作,这是个小范围事件,大约整体用例 5%。
有没有必要做?如果做,可以采用动态代码加载的方式,将你在 BDD 中写入的代码块加载进入系统中(我已实现),部分满足需求,还是有些满足不了。所以针对这种情况,单独写代码用例最好,在系统中进行整合,绝大多数资源共用。
2、xml 不好用。我就用的数据库,再加上前台页面管理,效率还不错。

#3 楼 @jennyhui 因为根据设想目前也只搭建了一半,功能并不是太完善,针对一个元素要进行多次操作,在哪一步骤进行操作也是可以进行关联配置的,这需要根据测试需求去梳理了。
针对元素对像库的维护,使用数据库方式管理会更加灵活(模块 + 元素),可以把维护元素功能制作成 WEB 页面,这样当执行过程中发现元素找不到,测试人员就可以自行维护元素,添加新元素、元素路径重置,再次执行即可,除非有需要改变程序逻辑,再去修改业务代码~

appium 本事就比较重,不算比较稳定的测试框架,再加上一层 web 先后端交互,稳定性有待商榷,其次 UI 自动化测试在今后的测试发展中必然会逐渐减少,无论出于测试金字塔考虑还是 ROI,最好不要把这块的比例放大,基本的 smoke 就可以了。

web page element 采集,使用 yaml:

element:
    type: name
    value: submit
    index: 0

index 可有可无,逻辑判断就可。

#6 楼 @vigossjjj 这个俺非常认同!只要把思路整理清楚,有个基本实现概念就可以了。只要在真正需要去做一个这样的框架的时候,能有个大体实现方向就可以啦 (只要能想到的,基本还是可实现地~~~)

#6 楼 @vigossjjj
#8 楼 @xushizhao
如果是 WEB 的话,我非常赞同你们。
如果是 APP 的话,那就不一样了。自动化的初衷和设想不一样。

APP 较 WEB 多两点:
1、历史版本回归,强制升级毕竟少数;服务端发版本,光接口自动化不一定能全效;
2、android、ios 碎片版本回归。同一个功能,可能在某些机器不通过。

所以,APP 的自动化金字塔,应该是倒三角,UI+ 接口 + 单元测试。UI 我放置位置很重要。

PS.单元测试的确很重要,不过要根据实际,一般公司都没有,所以优先保证核心的没问题就好。

APPIUM 稳定性是不咋滴。不过你在外层包裹一下,做个异常监控,加强捕获和重跑机制建立,就可以明显的降低这方面问题。

#9 楼 @pighero001 其实这块清理对代码要求还是比较高的,一般公司配一个自动化的就已经算 OK 了,定制这一块的时间周期、成本还是相对较大的,个人认为主要看公司对这块的需求了,是希望产出自己的测试框架还是只针对个别项目产出部分自动化的方法就可以了 。我觉着不管是 APP 还是 WEB 它们的理念都是互通的~~

@pighero001 不过你在外层包裹一下,做个异常监控,加强捕获和重跑机制建立,就可以明显的降低这方面问题。
这个我已经实现了 稳定性不错哈
这句话讲到的是心坎上 这块搞定可能需要 hard code 到 Appium 的源代码

我想问一下,关于断言部分是怎么做的,XML 是由开发者维护吗?

#12 楼 @emily @jennyhui 结合两位的问题,对于断言和同一元素做不同操作有了一个新的思路,周未我先实践一下,下周一我把实践后的代码贴上来~~

#13 楼 @xushizhao 好的。等你的分享 ~

#14 楼 @jennyhui 代码我已经更新到帖子上了,可以共同探讨~~~

这个开发人员还是要维护用于元素管理的 XML 文件,如果 UI 有改动的话,或者大改版,是不是 XML 文件和后面封装的相关类都需要修改?还有,可不可以做全局的自动化,针对所有可以自动执行的测试用例都做成自动化执行,这样的方向对吗?

#16 楼 @longmazhanfeng 后台的封装只是用于解析动作,UI 改动不会影响后台代码,一般情况下只维护 XML 文件就可以了。全局的自动化,就需要自己在后台灵活配置了。

@xushizhao ,你写的非常好,我最近再想怎么封装代码,尤其是 UI 改动后不会影响后台代码的执行,如何用 XML 文件,你写的看了后,我执行不起来;期望能否给个可执行的范例库

#18 楼 @xiaoli 。。你在群里嘛,我把代码发你。。最近在整接口方面的,还没来得急继续整这个。

不错的分享,建议楼主将 动作 与 数据分离 数据包含两种:第一是测试数据,第二是元素!以页面为对象 元素为子类 都可以落库存储,方便维护!

@xushizhao 可执行的 demo 能不能也顺便给我一份

#21 楼 @alwans 你在群里嘛 我直接发你?

#22 楼 @xushizhao 是啥群?我可以加入吗?

#23 楼 @huayinwang 汗 社区的官方群呀 315508626

#20 楼 @testly 恩 有这个找算。等我在新公司 安顿妥当 就准备开整到时候请多提 建议呀~

刚开始学习 ,对于框架才有个模糊的概念,看你你的文章后觉得很实用,加个 QQ 吧,方便请教问题

类似的框架几年前开发过几个,业界其他公司包括去年在淘宝的测试嘉年华看到阿里系也有类似的框架。xml 也好,其他类似的关键字驱动框架也好,在灵活性和适应性上都有比较大的问题,例如如何来做数据库数据的验证,如何灵活的来做断言等等,解决好自定义标签才能使这种类型的框架脱胎换骨,淘宝的,包括我自己开发的都没有很好的解决这个问题。搞到最后发现还是直接写代码合适一点。

#28 楼 @tbya 框架都是一步一步搭起来的,数据库验证也完全可以定义验证点,集合 UI 数据到后台进行查询验证,怎么配置拼接,就看诉求了。
我相信只要有规则,数据验证是可以解决的,不过就看坑值不值得填补了~

uiautomator 获取页面元素中文乱码,机型安卓 5.0.2,请问能解决吗

woyebuzhidaowoshishei [该话题已被删除] 中提及了此贴 06月30日 08:56

对在 web 页面提交 并出报告比较有兴趣

jojotester [该话题已被删除] 中提及了此贴 11月10日 07:53
woyebuzhidaowoshishei Appium+python 框架 (二) 中提及了此贴 12月01日 06:04
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册