其他测试框架介绍一个我开发的跨平台 UI 自动化框架——AXUI

xcgspring · 2015年04月20日 · 最后由 hope1 回复于 2022年06月08日 · 5366 次阅读

本帖已被设为精华帖！

最近在 windows 上做 UI 自动化，用的是 Windows UIA，用 python comtypes 库来访问 windows 的 COM 组件。写了一段时间脚本，感觉想要做好 UI 自动化是一个相当有难度的任务，尤其是对没有经验的团队。于是就有想法做一个 UI 自动化框架，来处理 UI 自动化中的一些常见的坑，简化

主要的想法就是：

将 UI 逻辑从测试脚本中分离，增强脚本的可读性和可维护性
统一 UI 自动化的 API，降低 tester 的学习难度
处理 UI 自动化中的常见的需要处理的问题，比如 UI 响应时间，自动截图
提供脚本模板，使得各种水平的 tester 都能写出可维护的脚本
整理一些 best practice，怎样做 UI 自动化能提高投入产出比，少走弯路

根据这些想法我写了一个 python 的 UI 自动化框架 AXUI，实现了基本的想法，现在 windows 的支持比较完备，对 selenium 和 appium 的支持实现了基本功能，由于精力和工作环境，没有怎么测试。欢迎试用和拍砖，如果有人有兴趣一起完善就更好了。现在 AXUI 基本功能包括：

AppMap 机制，将 UI 逻辑分离出来
提供了三个 built-in driver，支持 windows，selenium，appium
为 UI 自动化中的一些问题提供了处理方法

AXUI 的一些资源：

GitHub： https://github.com/xcgspring/AXUI
PyPI：https://pypi.python.org/pypi/AXUI/
文档：http://axui.readthedocs.org/en/latest/index.html

下面的介绍是 github 的介绍，平时工作中习惯用英文写文档，所以 AXUI 现在的文档也是英文的：

AXUI

AXUI is short for "Auto eXecute UI", is an UI automation framework, target to minimize the gap between tools and testers.
AXUI provides testers a powerful, unified, easy to use interface for common met platforms, like windows desktop, web, Android, IOS...

AXUI features

AXUI provide a plug-in mechanism for automation guy to extend support for different UI
AXUI provide built-in drivers for:

windows native UIAutomation Client API for windows desktop UI
selenium project for web UI
appium project for Android and IOS UI

AXUI provide an unified, easy to use python interface for use in test scripts
AXUI separate UI logic from test scripts, make test scripts more readable and easier to maintain
AXUI provide mechanism to handle auto met UI automation issues, like UI response time

An overview of AXUI structure

AXUI structure

code demonstrations

This code is in example/selenium, it's a simple example to demonstrate how AXUI separate UI logic from test script.

Though this example give us a impression that AXUI add extra complexities but doesn't improve code readability.
Image that an app contains a lot of UI Elements, and the search identifiers split into multiple test scripts, then AXUI can gather all UI identifiers into one appmap, and make your scripts clean to read and maintain.

Original:

import selenium.webdriver as webdriver

browser = webdriver.Chrome(executable_path = r"chromedriver.exe")
browser.get(r"http://www.bing.com")

searchEdit = browser.find_element_by_id("sb_form_q")
goButton = browser.find_element_by_id("sb_form_go")

searchEdit.send_keys("AXUI")
goButton.click()

AXUI AppMap*:

<AXUI:app_map xmlns:AXUI="AXUI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="AXUI AXUI_app_map.xsd">
    <AXUI:funcs>
        <AXUI:func name="go_to_bing" description="">
            <AXUI:step type="GUI" cmd='browser.BrowserPattern.get "http://www.bing.com"'/>
        </AXUI:func>
    </AXUI:funcs>

    <AXUI:UI_elements>
        <AXUI:Root_element name="browser" >
            <AXUI:UI_element name="searchEdit" identifier="id='sb_form_q'" start_func="go_to_bing"/>
            <AXUI:UI_element name="goButton" identifier="id='sb_form_go'" start_func="go_to_bing"/>
        </AXUI:Root_element>
    </AXUI:UI_elements>
</AXUI:app_map>

AXUI Code:

import AXUI

config_file = "selenium.cfg"
app_map = "www.bing.com.xml"

AXUI.Config(config_file)
appmap = AXUI.AppMap(app_map)

appmap.browser.start(browser_name="CHROME", executable_path = r"chromedriver.exe")

appmap.browser.searchEdit.Keyboard.input("AXUI")
appmap.browser.goButton.Mouse.left_click()

More details, please check AXUI documents

To have quick experience about AXUI, please check AXUI samples

9 个赞

共收到 20 条回复时间点赞

恒温 #1 · 2015年04月21日

把 web desktop mobile 通吃了？

陈恒捷 #2 · 2015年04月21日

#1 楼 @lihuazhang 在它的文档找到这段：

AXUI provide built-in drivers for:

windows native UIAutomation Client API for windows desktop UI
selenium project for web UI
appium project for Android and IOS UI

和

AXUI is first developed for easy use of windows UIAutomation API, then restructure to add support for WebDriver API used by selenium and appium. So if your UI automation is similar to windows UIAutomation API or WebDriver API, it will be easy to add support for it in AXUI.

应该是可以通吃的。只是最主要支持的是 windows desktop ，然后扩展支持 webdriver 。

剪烛 #3 · 2015年04月21日

围观大神。

xcgspring #4 · 2015年04月21日 Author

#2 楼 @chenhengjie123
是的，AXUI 对 windows，web，mobile 都支持，还可以通过扩展支持更多的 API，这个是最初设计的一个 feature。

本人做手动测试有一段时间了，也写过一些 UI 自动化的测试脚本，感觉现在的 UI 自动化工具对我们写脚本的 tester 并不友好，如果没有好的编程经验，一段时间的迭代之后，测试脚本库就会臃肿不堪，没法维护，于是我们又得重写脚本。而且与 programmer 不同，对于 tester，换一个项目的成本很高，之前项目的经验有时候很难在现有的项目复用。因为不同项目根据 team 的风格不同，选择的库，语言，测试的思想都千差万别，碎片化蛮严重。所以我选择在我熟悉的 UI 自动化测试方面，想贡献自己的一份力量，总结一下 UI 自动化测试的经验，让写脚本的 tester 的少走一点弯路，日子好过一点。AXUI 库只是其中一个部分，更重要的是 practice 文档，API 文档，脚本模板。需要大家的支持。

Anonymous #5 · 2015年04月21日

无论如何,熟悉一门通用的编程语言都是一样重要的, 很多时候. 很多由 manual 测试,转过来的同行, 大部分都受困于编程经验和技巧的缺乏. 即使有想法也无法实现. 我们更多做的是基于一个 tool 或者说是一个通用的框架做些应用层的东西. 很多时候,你能体现出多少的实力,最直接变现的形式就是编程经验,单纯的全自动 (全部自己手动) 的日子不多了...

个人感觉, 如果能看到额明白你的项目的代码, 弄的明白结构,那基本上操作其他的别的自动化的框架也问题不大,现在设计方式很多都类似. 说白了,没有足够的编程经验,学那个框架都是费劲的.更不要说扩展了.

陈恒捷 #6 · 2015年04月22日

#4 楼 @xcgspring 关于你这个框架，我大致看了一下介绍，有些问题想问一下。如果问得不好或理解不对的地方，请见谅：

1、你的目标群体是什么？手工测试人员/写过自动化脚本的人/对自动化测试和开发都有较深入了解的人/开发？看了你的示例代码后感觉前两个类型的人不一定搞的定，后两个类型的可能会偏向于使用符合一些规范的工具，如 selenium，selendroid，appium，他们都符合 webdriver API 规范。

2、从你的描述来看，你希望解决的痛点是 如果没有好的编程经验，一段时间的迭代之后，测试脚本库就会臃肿不堪，没法维护，于是我们又得重写脚本 ， 对于 tester，换一个项目的成本很高，之前项目的经验有时候很难在现有的项目复用，但通过你的示例代码我没看出 AXUI 对于这两个痛点有很好的解决办法（目前只发现它相比 webdriver 多了对 windows desktop 程序的支持）

3、把 UI 逻辑和测试脚本分离是一个很好的想法，但通过 xml 来实现会不会导致易用性/可读性不是太友好？而且 selenium 的 PageObject 设计模式也能做到类似效果。

4、通过扩展支持更多 API 这个想法也很赞，而且拓展方法看起来也不是太复杂。不过你的框架本来是为了 windows desktop 的 UI 自动化设计的，让它完整支持其他 API 会不会有难度？通过扩展支持大量平台的测试框架目前我比较了解的是 robotframework ，它的办法是 API 什么的都不限定，只限定用例的编写格式，降低跨平台用例的学习难度。

xcgspring #11 · 2015年04月22日 Author

#6 楼 @chenhengjie123 谢谢你的提问，下面是对你的问题的解释，都是我自己的想法，不一定对。

我的目标人群是测试人员，他们大部分的工作是测试设计和测试执行，但也有写自动化脚本的任务。他们精于对某个 domain 的测试设计，能看出平常人看不出的问题，但编程的经验比较少，不懂设计模式，不同重构代码来提高代码可维护性。我的目标是提供一个通用的工具，具有详细的文档和直观的 API，让他们照着模板就能写出不错的自动化脚本，最好还有各个平台的一键化配置。对 webdriver API，我觉得它作为一个 CS 的通信协议是不错的，但 selenium 和 appium 的上层 API 还可以更加完善。
如果没有好的编程经验，一段时间的迭代之后，测试脚本库就会臃肿不堪，没法维护，于是我们又得重写脚本 这段在第一段已经描述。 对于 tester，换一个项目的成本很高，之前项目的经验有时候很难在现有的项目复用 这段我考虑的是测试工程师的核心竞争力问题。比如我在 windows 上做了几年自动化，对 windows 上的技术熟了，然后公司方向变了，开始移动互联化，开始做 Android……这个时候我之前的工具使用经验就基本没用了，当然厉害的人能从之前的经验中吸取营养，用在后来的项目上，但学习成本挺高了。
XML 的易用性和可读性还可以，比不上专门为人设计的 UI，但比 Json 这种 for 编程的交互格式好一些。我以后可以做一个专门的编辑器来增强可读性，当然没有 schedule。 PageObject 也是一种增强代码可读性/可维护性的方法，但和 AppMap 有一些区别（我草草看了一下 PageObject 资料，有错误的评论请指正）

PageObject 是一种设计模式，只是推荐使用的，需要 programmer 的自觉， AppMap 是 AXUI 的功能，使用 AXUI 必须用AppMap。可以类比 python 代码中的强制缩进带来的 python 代码可读性，而其他语言只是推荐对不同的代码段做缩进。
PageObject 实现的好坏和 programmer 的水平相关，这个其实又回到了第一个问题，关于 tester 的编码水平
PageObject 没有统一的规范

为 AXUI 编写 windows 和 webdriver 的 driver 的时候，我挺惊讶的，因为 windows UIA 的接口和 webdriver 的接口本质上很类似，这也是为什么我能写出来 AXUI 的一个原因，要是不同的地方很多或者有本质区别，我估计做不出来。虽然我还没有接触其他的 API，但感觉殊途同归吧。Robotframework 我看过，也参照着它的理念写过一个 key-word driven 的 framework，效果差强人意。有几个的问题：

Robotframework 让测试脚本和执行的 framework 耦合了，也就是说你必须通过 robotframework 来 run 你的 case。这点我很不喜欢，因为写 case 也需要 debug，在加入测试集之前，我会先 run 一下。用 robotframework 会让这个 task 变得很困难。
表单形式的测试脚本真的好吗？可读性不错，功能/开发速度大受限制。
key-word 的库谁来写呢？key-word 库抽象过多，功能受限。抽象太少，表单就没法写了。

Bluesky Yao #8 · 2015年04月25日

#7 楼 @xcgspring 看了一下写的很赞！

关于学习经验问题，开发也遇到类似的情况，但开发的思维是继续学习，然后事情变的更加简单。
PageObject 既然是模式，只要有一个人懂了，就可以复制传递下去，因为是模式，就是可以照模画的
关于 xml 语言，显然这些年的沉淀，开始回归代码，有些复杂绕不过去，直面它反而简单。直接使用 Python 或某一种平台语言抽象出移动自动化的 dsl 脚本，其实需要知道的知识极其的少。

这也正是 selenium 中的最佳实践推荐
https://seleniumhq.github.io/docs/best.html#best_practices

Lucifer #9 · 2015年04月26日

楼主，这个能在 mac 上跑么

xcgspring #10 · 2015年04月27日 Author

#9 楼 @xxfcxx
我没有 Mac 的环境，所以没在 Mac 上试过，但应该可以在 Mac 跑。Appium 的支持还不完善，我会慢慢改进的。

ChrisWong #14 · 2015年04月27日

提几个个人的想法

其实个人认为集成 UIA 的框架是没必要的,win32 的自动化测试主要问题在于自定义 (通过 DShow,DDraw 渲染和 GDI 绘制) 控件的可识别性太差, win32 标准空间的解决方案其实有很多了,比如基于 MSAA,UIA(White, UIVerify, base on RPF 的 CodedUI 之类的) 的框架已经不少,如果做得没有人家好和专业,还是考虑别集成了,因为集成了没人用,只会增加设计的复杂度
APPMap 用 XML 过于复杂,其实可以考虑一下使用 DSL,降低使用和维护成本.
建议增加一个 test host,形成一套完整的体系,否则 test host 使用别人的,很难可以对 test suite 的粒度进行控制和对功能进行扩展.

xcgspring #12 · 2015年04月27日 Author

#11 楼 @wjm1985
本来想睡个午觉的……

UIA 的使用对于 tester 门槛有点高，尤其 UIA 里面并没有集成 keyboard/mouse 的操作，所以才有了各种框架出现。而你说的这些框架，其中 White，UIVerify 我用过，他们是基于.Net 的 manage UIA API，功能和性能相较于 Native 的 UIA 弱很多，有些 MS 的控件支持的不好，而且对于 Win store app，这些框架用的时候需要加入额外的权限，这个权限应该叫 UIAccess，写测试脚本的时候需要绕过这些坑。而对于自定义的 UI 的支持的确是个大问题，所以 AXUI 才提供了扩展支持，提供一套扩展接口让设计自定义 UI 的 team 能提供一个 backdoor 来统一支持他们的 UI 自动化。
所谓 DSL，是和 domain 相关的，是不适合用在一个通用框架里面的。AXUI 的 AppMap 并不和 DSL 冲突，它是来抽象 UI 逻辑的，对业务逻辑并不涉及，你可以在 AXUI 的基础上在包装一层 DSL。
Test host 我已经在做了，叫 XSTAF，见https://github.com/xcgspring/XSTAF ，是一个分布式的测试管理和执行框架。不过这个和 AXUI 没有什么关系，他们之间是互不依赖的，我一直觉得测试管理和执行框架和测试脚本应该是解耦的，即测试脚本不能依赖测试管理和执行框架。

ChrisWong #16 · 2015年04月27日

#12 楼 @xcgspring
关于 1,其实不管是 MSAA 和 UIAutomation 都有提供了相应的接口,比如 MSAA 提供了 IAccessible 接口, UIAutomation 提供了 ISawProviderSimple 接口用于支撑自定义控件的实现, 现在除了外企,很少会有团队愿意去修改代码提供 backdoor 来做交互的 (因为成本太高),一般都是基于 Process 做 Injection, 比如可以 SetWindowHook 去做.
关于 2,其实只是个建议拉,xml 的语法还是很麻烦,而且在编写的时候也挺操蛋的,当然,如果可以提供一个 IDE 给到用户,那可以极大提高用户的使用体验和语法检查 (因为以前我做过一个类似的东西,结果没有语法检查,出现错误的时候,使用者本身是很难定位的),但是如果不行,就比较麻烦,比如用户可能会写错语法,可能嵌套层次会乱. 所以是不是考虑提供一个更为简单,直观的方式给到用户.
关于 3, 大赞,是否基于 STAF 进行的封装?其实我个人这边之前也利用 STAF 做过一些测试分布式的分发的东西,相信可以进行更多的探讨和交流.

xcgspring #14 · 2015年04月27日 Author

#13 楼 @wjm1985
XML 的语法验证我是用 pyxb 做的，通过预定义的 schema 来验证，能定位到某行某列，当然用普通的编辑器来写 XML 的确容易出错，是要考虑做一个专门的编辑器。
XSTAF 的确是基于 STAF 的，用 STAF 做通信层，在上层做了测试集管理，测试机管理，测试执行等功能，用 pyqt 做的界面。等有空写好文档，我再来发一个帖子介绍，到时候还请批评指正。

我一直闭门造车的，这次发帖让我眼界开阔了不少，十分感谢这个平台的维护者，能给我们提供一个这么好的交流平台。