重构一下脚本，使用 xunit，在 teardown 函数里面加返回主界面的逻辑。

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

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

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

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

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

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

1. 我的目标人群是测试人员，他们大部分的工作是测试设计和测试执行，但也有写自动化脚本的任务。他们精于对某个 domain 的测试设计，能看出平常人看不出的问题，但编程的经验比较少，不懂设计模式，不同重构代码来提高代码可维护性。我的目标是提供一个通用的工具，具有详细的文档和直观的 API，让他们照着模板就能写出不错的自动化脚本，最好还有各个平台的一键化配置。对 webdriver API，我觉得它作为一个 CS 的通信协议是不错的，但 selenium 和 appium 的上层 API 还可以更加完善。

2. 如果没有好的编程经验，一段时间的迭代之后，测试脚本库就会臃肿不堪，没法维护，于是我们又得重写脚本 这段在第一段已经描述。 对于 tester，换一个项目的成本很高，之前项目的经验有时候很难在现有的项目复用 这段我考虑的是测试工程师的核心竞争力问题。比如我在 windows 上做了几年自动化，对 windows 上的技术熟了，然后公司方向变了，开始移动互联化，开始做 Android……这个时候我之前的工具使用经验就基本没用了，当然厉害的人能从之前的经验中吸取营养，用在后来的项目上，但学习成本挺高了。

3. XML 的易用性和可读性还可以，比不上专门为人设计的 UI，但比 Json 这种 for 编程的交互格式好一些。我以后可以做一个专门的编辑器来增强可读性，当然没有 schedule。 PageObject 也是一种增强代码可读性/可维护性的方法，但和 AppMap 有一些区别（我草草看了一下 PageObject 资料，有错误的评论请指正）

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

1. 为 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 库抽象过多，功能受限。抽象太少，表单就没法写了。

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

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