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

harsayer · 发布于 2018年02月01日 · 最后由 zzljeky 回复于 2018年02月09日 · 3441 次阅读
本帖已被设为精华帖!

参考项目:
这个支持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在跑流程用例的过程中, 莫名出来的都能捕获 。

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

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

学习了

3f5e79

楼主好人呐,谢谢!

110

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

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

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

4f9cc2
harsayer · 6楼 · 2018年02月02日 作者
110Lihuazhang 回复

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

我现在重点看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测试小书童 的学习和整合能力明显更强,很有潜力。开源就是怕你开源了就不维护了。

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

110
4f9cc2harsayer 回复

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

4f9cc2
harsayer · 8楼 · 2018年02月02日 作者
110Lihuazhang 回复

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

110
4f9cc2harsayer 回复

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

Ee76af

通用的成本太高了

4481

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

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

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

12288

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

6853

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

69c0e6

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

4f9cc2
harsayer · 18楼 · 2018年02月08日 作者
69c0e6wonder1z 回复

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

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

69c0e6
4f9cc2harsayer 回复

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

1cfb31

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

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