Appium python appium UI 自动化测试框架讨论

harsayer · 2018年02月01日 · 最后由 hero 回复于 2018年05月09日 · 9886 次阅读
本帖已被设为精华帖!

参考项目:
这个支持ios android
https://github.com/Louis-me/appium
https://github.com/Louis-me/appiumn_auto
https://testerhome.com/topics/11720

这个仅支持android
https://github.com/ztwo/Auto_Analysis
https://testerhome.com/topics/6482

这个没开源列举了些实现
https://testerhome.com/topics/10552

这个开源又被下掉了 github上 没找到
https://testerhome.com/topics/3460
https://testerhome.com/topics/3526

当然还有我比较看好的atx
https://github.com/NetEaseGame/ATX

框架共性总结
1 自动找设备 连接设备
2 自动启appium server
3 用例框架unittest pytest
4 用例组织 yml 读ini 读excell 或做html前端编写
5 用例断言 unittest的 assert 或是pytest 或是第三方asertpy

(阻碍式 还是非阻碍式 https://www.cnblogs.com/xiaobucainiao/p/6186826.html
6 用例报告形式格式 htmltestrunner Allure ExtentReports等
这个是Auto_Analysis

7 用例多线程跑 失败重跑机制
8 android方向自动监控权限弹窗 (macaca有服务参数permissionPatterns实现,appium也可以,Auto_Analysis在public.installApp也实现了一种监控屏幕是否有需要点击的安装按钮 )
9 执行过程异常捕获与Log 这个Auto_Analysis的log做的日志非常好,用的是logging.

10 执行过程性能捕获 是adb形式的 还是其他形式的 比如atx 引入的gt 还是专业的appetizer工具。

以上简单逛论坛发现的一些不错的框架思路和开源实现汇总,每个人的实现和支持都或多或少不一样。开源的我都调通了,大致看了下,各有优劣。
有的我想要的在这个框架,有的我想看到的在另一个框架。总之每个项目都各有优点,又各有劣处。

所以想发起个讨论贴,坛子里的各位python大牛,可以来大家一起讨论下。到底共性总结节里提到的,到底用什么实现最好。

Auto_Analysis权限弹窗识别

Auto_Analysis在public.installApp也实现了一种监控屏幕是否有需要点击的安装按钮 调试了下 发现了这里
在我的小米mix2里 安装demo的apk 没法点继续安装, 所以想扩展的话 可以把不同系统的写到这里。
比如安卓原生的就是com.android*** 而小米 的我发现都是com.miui***。

先捕获miui9.2 的安装弹窗 看看到底是啥

原来package=com.miui.securitycenter resource-id=android:id/button2

看到继续安装与代码里定义的 button4 = 'android:id/button1' 冲突了 ,所以每次都是先点的拒绝 (miui9.2里 拒绝是android:id/button1)。。。。。

"""
同属性单个元素,返回单个坐标元组
button_list:常见的确认,同意,按钮控件id
"""
button0 = 'com.android.packageinstaller:id/ok_button'
button1 = 'com.android.packageinstaller:id/btn_allow_once'
button2 = 'com.android.packageinstaller:id/bottom_button_two'
button3 = 'com.android.packageinstaller:id/btn_continue_install'
#追加的miui9.2系统 继续安装的package=com.miui.securitycenter  resource-id=android:id/button2  
#这么写没过先放这儿 button4 = 'com.miui.securitycenter:id/android:id/button2'
#button4 = 'android:id/button1'与miui9.2 securitycenter权限安装 继续安装冲突 改为android:id/button2
button4 = 'android:id/button2'
button5 = 'vivo:id/vivo_adb_install_ok_button'
button_list = [button0, button1, button2, button3, button4, button5]

改后完美识别了 miui9.2的权限安装弹窗

这种方式的 原理 我看了下 是抓取整个界面的xml 类似appium里或appcrawler里getpageresource 然后解析该元素xml 找到对应的元素操作之。
比其他appium 找权限弹窗的方案好许多。

附上相关代码:

def main(self):
    """
    开启多线程:
            线程1:安装应用
            线程2:获取当前页面是否有可点击的按钮
    :return:
    """
    ini = U.ConfigIni()
    install_file = ini.get_ini('test_install_path', 'path')
    package_name = ini.get_ini('test_package_name', 'package_name')

    threads = []

    click_button = threading.Thread(target=self.tap_all, args=())
    threads.append(click_button)
    install_app = threading.Thread(
        target=self.__install_app, args=(
            package_name, install_file))
    threads.append(install_app)
    process_list = range(len(threads))

    for i in process_list:
        threads[i].start()
    for i in process_list:
        threads[i].join()

    self.adb.shell('"rm -r /data/local/tmp/*.xml"')


@U.l()
def __element(self):
    """
    同属性单个元素,返回单个坐标元组
    button_list:常见的确认,同意,按钮控件id
    """
    button0 = 'com.android.packageinstaller:id/ok_button'
    button1 = 'com.android.packageinstaller:id/btn_allow_once'
    button2 = 'com.android.packageinstaller:id/bottom_button_two'
    button3 = 'com.android.packageinstaller:id/btn_continue_install'
    #追加的miui9.2系统 继续安装的package=com.miui.securitycenter  resource-id=android:id/button2  button4 = 'com.miui.securitycenter:id/android:id/button2'
    #button4 = 'android:id/button1'与miui9.2 securitycenter权限安装 继续安装冲突 改为android:id/button2
    button4 = 'android:id/button2'
    button5 = 'vivo:id/vivo_adb_install_ok_button'
    button_list = [button0, button1, button2, button3, button4, button5]
    self.__uidump()
    self.pattern = re.compile(r"\d+")
    if not os.path.exists(self.all_result_path + "/dump.xml"):
        U.Logging.warn('Failed to get xml')
        return None

    tree = ET.ElementTree(file=self.all_result_path + "/dump.xml")
    tree_iter = tree.iter(tag="node")
    for elem in tree_iter:
        if elem.attrib["resource-id"] in button_list:
            bounds = elem.attrib["bounds"]
            coord = self.pattern.findall(bounds)
            x_point = (int(coord[2]) - int(coord[0])) / 2.0 + int(coord[0])
            y_point = (int(coord[3]) - int(coord[1])) / 2.0 + int(coord[1])
            return x_point, y_point
    else:
        return None

def tap(self):
    """
    点击动作
    :return:
    """
    coordinate_points = self.__element()
    if coordinate_points is not None:
        self.adb.touch_by_element(coordinate_points)

def tap_all(self):
    """
    不间断获取xml,并且点击。配合多线程使用
    :return:
    """
    while True:
        self.tap()
        if not self.queue.empty():
            break

安装APP的时候 那个main 启动了两个线程一个安装负责安装apk, 同时另一个监控,先捕获当前安装界面的元素对象树xml 然后循环去判断是否有元素在__element 定义中, 有的话 就点击。

这个方案 也是捆绑在安装过程中的, 我还是想要那种 ,不管是安装过程中 ,还是apk在跑流程用例的过程中, 莫名出来的都能捕获 。

不过可以用这个思路 去改改 。

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

学习了

楼主好人呐,谢谢!

基本上是为了10%的不同,重复90%的工作。我觉得倒是可以把90%的工作统一掉,比如你说的框架共性总结

  1. 自动找设备 连接设备
  2. 自动启appium server

另外对于 UI 自动化,如何高效率的组织po对象非常重要,目前没找到太好的方法。

Lihuazhang 回复

嗯 是的,好多共性问题,都有不同的解决代码方案。但各个方案也许都有坑,或不适合自家项目的场景。所以希望 大神进来评估和讨论。

我现在重点看joko 的Auto_Analysis 和 lose 的appium 两个项目。

Auto_Analysis 代码非常工整简洁,用的都是py高级写法,logging管理用的也是看的执行过程非常的爽,感觉目录结构lib po pulic这些更像是一个搞过java项目的。

lose测试小书童 近期更像频繁啊,star数明显增加,目录结构命名更符合py目前流行的pageobject那种,但代码没Auto_Analysis工整,基本demo里有许多自家app测试的东西,没有完全剥离开,好多用例也都保留在了项目里,不像Auto_Analysis 做了一个测试apk 和Demo。但它的用例维护比较麻烦 要改三处py 好像,

不过这些都不是大问题,lose测试小书童 的学习和整合能力明显更强,很有潜力。开源就是怕你开源了就不维护了。

群里还是有很多大神的,但感觉有的好东西,都是藏着掖着给自家用的。。。。

harsayer 回复

不废话么,很多东西是公司作品啊

Lihuazhang 回复

我意思是 抽离解决方案。。。 搞那种共性问题 的通用解决方案,或者集思广益 提供方案的时候 说明是基于什么前提上下文场景的一个方案。 否则,其他人只能自己玩了一遍后 才知道适合不适合,大大增加了时间和精力成本。

harsayer 回复

并不是不想抽离,是因为要真正高效率的就又得深度定制,和业务耦合,做大了就又剥不开了。所有的通用解决方案,一开始看架构都是很清晰的,代码量级上去后,就又一塌糊涂了。

通用的成本太高了

在开发平台的时候 底层借用了lose写的不少东西(主要是因为从java转python写太多不同),目前已弃appium转向atx,可以一起研究研究。

seveniruby 将本帖设为了精华贴 02月02日 22:04
wuhenyan 线下班第二期 Bash 教程 中提及了此贴 02月03日 21:06
hxbjava 回复

atx 是款很不错的工具,正在用

小白问下,你这个测试报告是用HTMLTestRunner实现的吗,里面展示截图是怎样做到的呀,求教求教

你这个标题应该改成 App安装弹窗解决方案

大神 能 大概说说 ATX与 APPIUM 的优劣吗

wonder1z 回复

基于python 学习简单 底层用的uiautomator2 python版( 既是晓聪根据google uiautomator2 改的python版)

制作了个atx-agent 安装到手机端(既是一个u2 server 类似appium server的角色)
处理速度快。 同功能脚本 手机 你可以测试用appium 和u2 分别做同样的用例 来比较

harsayer 回复

emmm, 执行速度 正是我想要的👍

确实,感觉现在测试框架越来越多,还是要根据公司的业务进行权衡

Auto_Analysis的检查弹窗的功能不会因为等待install_app的结果,整个线程阻塞,导致每次取的dump.xml都不是弹窗正在发生时的状态么?

仔细看源码,这个是和安装app过程同时启动的一个线程,同时去捕获的。所以这个方案只能解决,appium sercer在初始化首次安装过程,向手机安装相关组件的情景,自动点掉继续安装的弹窗,不是很通用。

https://testerhome.com/topics/11482 你可以参考下macaca的这个参数的弹窗实现机制,这个是通用的,什么意思呢,既可以各类自动化工具初始化时向手机安装组件过程的弹窗,也可以是比如请求读取联系人许可的权限弹窗的自动点允许。

wd.java

porps.put("permissionPatterns","[\\\"继续安装\\\",\\\"下一步\\\",\\\"好\\\",\\\"允许\\\",\\\"确定\\\",\\\"我知道\\\"]");

wd.py

desired_caps = {
    'platformName': 'android',
    'app': 'D:\\Install\\apk\\***.apk',
    'reuse': 3,
    'package': 'com.***.ggaicai',
    'activity': 'com.***.***.activity.MainActivity',
    'permissionPatterns': '[\\\"继续安装\\\",\\\"下一步\\\",\\\"\\\",\\\"允许\\\",\\\"确定\\\",\\\"我知道\\\"]',
}

macaca 目前向手机安装的依次有
1 UiAutoMator sample
2 com.macaca.android.testing.test
3 android-unlock

harsayer 回复

appium java 试了下加到启动参数中也没有起作用啊

KingDow 回复

是macaca的初始化参数,不是appium的。

这个监控弹窗的,我很早以前已经通过uiautomator实现(能够监控安装弹框、手机权限申请弹框等),只要事先push一个jar包进去就可以,地址:https://mp.weixin.qq.com/s?__biz=MzIwNDYxMzI1Nw==&mid=2247483772&idx=1&sn=6cdaa01fd383dc22c529e179642b5e6d&chksm=973c329aa04bbb8cacb8cba023e6cb06f3d733330f6bbeef8781453de8c355d2b1a91fa1a35e&scene=0#rd

chunyong 回复

你这个是开线程定时循环主动检查的,还有一种是回调触发的。方法都是不错的,唯一缺陷是会长时占用accessibilityservice。仍适用手工辅助的

关于appium的框架很少,必须收藏一波

学习到了,收藏一波


mac系统今天安装appium启动的时候,遇到这个错,看社区里面也没人遇到过,自己也没解决,目前所有的包都不是sudo安装的,但是启动报这个错

Lihuazhang 回复

嗯,这位兄台说的是重点. 这个帖子嘛,没啥营养

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