Appium appium + xml + web 自动化测试框架设想及实践分享
加入新公司二个月了，对 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 指令配置即可，这样即解决了断言的问题，也同时解决了同一元素需要在不同场景执行不同指令的需求~
nice。半小时的操作能节约半天的测试工作量，这才是自动化的精髓。以往崇尚写代码说回归的只适合传统自动化了。现在迭代太快了，两个月就天翻地覆，没意义。当然如果你的对象是百度啊什么的，当我没说
#1 楼 @pighero001 当然我们在做自动化的时候，也是需要抽取适合做自动化的功能的，针对一些比较固化的流程类做一些辅助性的自动化不是的挺好的嘛~ 不需要再从头到尾的全部点一遍才能看到最后的测试结果（同时还要验证各环节数据的正确性），通过自动化一键完成不是会相对简单一些撒~~~
1.如果一个页面的同一个元素，在同一个 case 中， 不同时间做不同的操作，是写两个,还是定义两个，xml 解析成脚本时在做处理?
2.你们是用 UIautomator 把页面元素 dump 下来再去编辑修改维护 xml 吗?一个页面一个 xml。你们现在管理编辑起来感觉方便吗?
3.web 平台上显示的 html 点击运行开始解析脚本跑用例，这挺好的。以后你们的可以平台化了。
4.谢谢楼主的分享。
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 是由开发者维护吗？
#13 楼 @xushizhao 好的。等你的分享 ~
这个开发人员还是要维护用于元素管理的 XML 文件，如果 UI 有改动的话，或者大改版，是不是 XML 文件和后面封装的相关类都需要修改？还有，可不可以做全局的自动化，针对所有可以自动执行的测试用例都做成自动化执行，这样的方向对吗？
#16 楼 @longmazhanfeng 后台的封装只是用于解析动作，UI 改动不会影响后台代码，一般情况下只维护 XML 文件就可以了。全局的自动化，就需要自己在后台灵活配置了。
@xushizhao ，你写的非常好，我最近再想怎么封装代码，尤其是 UI 改动后不会影响后台代码的执行，如何用 XML 文件，你写的看了后，我执行不起来；期望能否给个可执行的范例库
不错的分享，建议楼主将 动作 与 数据分离 数据包含两种：第一是测试数据，第二是元素！以页面为对象 元素为子类 都可以落库存储，方便维护！
@xushizhao 可执行的 demo 能不能也顺便给我一份
#22 楼 @xushizhao 是啥群？我可以加入吗？
#23 楼 @huayinwang 汗 社区的官方群呀 315508626
#22 楼 @xushizhao 不再群里
刚开始学习 ，对于框架才有个模糊的概念，看你你的文章后觉得很实用，加个 QQ 吧，方便请教问题
类似的框架几年前开发过几个，业界其他公司包括去年在淘宝的测试嘉年华看到阿里系也有类似的框架。xml 也好，其他类似的关键字驱动框架也好，在灵活性和适应性上都有比较大的问题，例如如何来做数据库数据的验证，如何灵活的来做断言等等，解决好自定义标签才能使这种类型的框架脱胎换骨，淘宝的，包括我自己开发的都没有很好的解决这个问题。搞到最后发现还是直接写代码合适一点。
uiautomator 获取页面元素中文乱码，机型安卓 5.0.2，请问能解决吗
对在 web 页面提交 并出报告比较有兴趣
