支持mobile app UI自动化测试的工具比较多，其中使用时间很长，应用很广泛的有appium，前面博客也详细介绍过appium webdriverio工具的特点，此篇博客将介绍之前项目实际使用或者调研过的mobile app ui工具，最后再对多个工具进行横向对比，便于你在进行工具选型时做出更好的选择。
Detox
Detox是Wix开发的，针对react native开发的移动应用进行测试的UI层自动化工具。下图是Detox的原理图，从下图可以看出，Detox 并不依赖 Webdriver，它的底层使用了 Google 开源的 EarlGrey(iOS)和 Espresso(Android)，也正是得益于这两个底层框架，保证了在 iOS 和 Android 的 Native 进程里测试框架和 app 的同步。
Detox 会利用 app 的内部资源或通过监听一些 callback 来得知 app 是否空闲，并且只有在 app 空闲时，比如没有正在进行的请求、主线程和其他线程都空闲、渲染动画结束、React Native的bridge也空闲时，它才会在主线程上执行下一步测试，从而避免了在代码中加入各种 magic sleep 时间，也增加了测试的稳定性。
从官网的描述来看，detox在稳定性上进行了优化改进，那么实际项目使用的结果是什么呢？Detox实际项目使用过程中你会发现下面的一些limitation
1.iOS 不支持WebView (你可以尝试用android 去测试)。（比如： 你的app登陆模块是用webview做的，这个时候用Detox去定位html元素就比较困难。）
2.编写代码的实际过程总，你会发现Detox不支持自动将element拖动到viewport中，需要手写代码按像素值进行拖动，如果页面有变化，这类测试会非常脆弱。
3.使用Detox的并行执行feature的时候，会发生偶发性hang住的情况，即框架判断app 一直忙于某些task，不处于ideal状态，最终导致并发运行多个case的时候，某些case会失败。这个错误在官网也有提及，属于框架级别的错误，无根本性的解决办法。
总结而言，Detox不推荐在实际项目中使用。接下来再看看一个以少写编码为亮点的工具Maestro
Maestro
Maestro是一款低代码的mobile app UI自动化测试工具，他的代码是yaml文件格式，另外，Maestro提供Meastro studio，通过studio可以连接启动的app device，与app交互的过程，studio可自动生成代码，或者选择某个element，生成对应的locator。Meastro的代码在yaml文件中，yaml文件内容如下所示。定位元素的时候可以通过id，id+index，text居多。
appId: com.matrixport.mark
---
- launchApp
- tapOn:id: com.matrixport.mark:id/et_mark_editindex: 1
- inputText: Qtl@com123456
- tapOn: Log In
- tapOn: id: com.matrixport.mark:id/et_mark_edit
- inputText: 111111
- tapOn: "No thanks"
- tapOn:id: "com.matrixport.mark:id/ll_bottom_nav_trade"
- tapOn:id: "com.matrixport.mark:id/iv_order_type_arrow"
- tapOn: "Limit Order"
- tapOn:id: "com.matrixport.mark:id/editText"index: 0
- inputText: 64000
- tapOn:id: "com.matrixport.mark:id/editText"index: 1
- inputText: 0.01
- tapOn:id: "com.matrixport.mark:id/tvOpenOrder"
- tapOn:id: "com.matrixport.mark:id/tvConfirm"
- scrollUntilVisible:element: id: "com.matrixport.mark:id/tvAssetEmptyDeposit" direction: DOWN
- tapOn:id: "com.matrixport.mark:id/tvPairName"
- tapOn:id: "com.matrixport.mark:id/layoutPair"index: 2 Meastro的一个主要亮点就是低代码，即不用写代码即可完成自动化测试，那这个工具除了亮点外，有哪些局限性呢？
第一：上面的yaml格式，对于简单的应用可行，对于复杂场景case就很难管理了。这种yaml格式的代码天然不支持UI自动化测试中的page object设计模式，page object设计模式增强了代码可维护性、可复用性、可读性。不适配即代表上面的这种形式的代码在可读性、可维护性、可服用性方面有很大挑战。
第二：在spike这个工具过程中，发现存在稳定性的问题，即相同的case在模拟器上运行时，有时候能成功，有时候就卡住了，直到超时报错。
总结而言，在实际项目中不推荐使用Meastro。接下来再看看国内使用较广泛的一款Mobile UI自动化工具AirTest。
AirTest
AirTest最大的亮点是支持游戏类应用测试，支持通过图片进行元素定位，后来又提供了poco。另外，AirTest IDE工具支持加载连接启动的mobile device，在device上操作的同时，可以录制生成代码或者生成单个element的locator。总体来说AirTest提供的功能已经非常强大，实际项目考虑采用这个工具的吸引点是可以通过图片定位元素，这样，即便页面结构发生改变，也无需修改代码。实际项目中应用效果如何呢？在之前的工具spike过程中，以手机上的计算器为被测应用，采用图片定位的方式发现定位成功率较低，因为计算器的图片非常简单，不像游戏app上的图片，图片间差异较少。如果是常规应用，很多按钮，菜单等只是上面的文字有差异，针对非游戏类的应用，如果完全采用图片定位，你会发现相同的case存在某些时候成功，某些使用找不到目标elementd的情况。也许这也是后来会退出poco的原因吧。总结而言，这个工具的图片定位并不能给常规app应用带来很多的优势。另外，因为AirTest底层并不是依赖Android和IOS官网提供的框架，而是自研的底层框架，如果是最新的IOS或者Android版本，开源版本的AirTest不一定能及时支持，这也是是否要采用这个工具的一个考虑点。
总结而言，AirTest独有的优势是支持游戏引擎，如果是常规mobile app应用，和Appium对比，无明显优势。
Appium
最后再看看使用非常广泛的mobile app自动化工具Appium，appium有多个客户端library，下面是不同client library的对比，鉴于其他client library和webdriverio相比，都明显所示，这里以介绍webdriverio来介绍使用Appium的一些优势以及limitation。
如果选用appium+webdriverio，那么该client支持自动等待、支持自动将目标元素scroll到viewport中，支持上下左右滑动，支持page object设计模式。更多webdriverio的特点可以参见上一篇博客。那么如果采用appium+webdriverio有哪些局限性呢？
第一：定位页面元素需要appium inspector辅助，appium inspector刷新页面也很慢
第二：appium启动较慢，如果运行多个case，需要配置并发运行来提高运行速度
第三：和上面两个工具比较，appium+webdriverio不支持自动录制
因为上面的三个limitation，在编写代码时，成本会更大一点。总结而言，如果实际项目中进行工具选型，还是首推appium，主要原因是使用广泛，潜在的重大issue较少，稳定性方面能得到保障。
上面是对三个不通亮点工具的分别介绍，下面是对他们的横向汇总对比
以上就是曾经使用或者spike过的移动应用UI自动化测试工具总结。
