谈到自动化测试，很多客户端的 QA 第一反应想到的应该是 UI 自动化了。今天就来说说 UI 自动化。

探索 iOS 的 UI 自动化，应该有一年左右了。最早比较信奉自己公司的框架，因而最早接触的是公司质量保障部撸的一个自动化框架。直接引入我们自己的项目后，大致可用但是也有一些问题，当然有过自动化经历的同学应该知道，常常会遇到一些比如 控件非标准抓不到，一些手势操作出现异常等。而我引入这个框架的时候，它们已经不怎么花时间维护了，而它们框架是以 jar 包的形式，that means 没有源代码，不方便解决这些问题。

其实，iOS 和 Android 的自动化框架中，Appium 还是有名的。于是，我就基于 Appium 做了一些自己的封装，然后供组内其他 QA 使用，然后一起去完善用例。那么，其实就是分两件事了：完善框架，补充用例。

在聊我的框架结构前，想先说一下 Appium 的一些原理，这里说的是 iOS，当然 Android 是支持的，只是我没试过。首先，你要在 Appium 设置一些配置：第一个，App Path 或者 Bundle id；第二个，如果是模拟器，要选好设备类型，系统版本，如果是真机，选好 udid；其他的选项，选默认的也问题不大。另外，不得不提一点，非常坑的一点，Appium 和 XCode 的版本是要配合使用的，有些 Appium 只支持对于的 XCode。我记得今年（2016）10 月那会，我们 QA 随开发一起更新了 XCode8。于是，悲剧就发生了，那会的 Appium 版本不支持 XCode8。所以，要么等，要么降 XCode。降 XCode 是很悲剧的，因为开发的工程编译你要用 XCode8，与 Appium 关联的又要是 XCode7。于是我们项目组后来先暂时搁置了，转而尝试走 XCode 下的 UI 或接口自动化，这个话题以后再聊，先继续聊 Appium。那么 Appium 设置都搞好后，在 Appium 里点 Launch，然后再启动你的自动化工程里的用例，就可以了。

然后，我们可以来说框架了。对于框架结构，我的思路是分这几层：控件层，操作层，用例层。姑且这么叫吧，名字我自己造的，词能达意就好。

控件层，存控件的 XPath 或者 Name，这些是抓控件时，通过 ByXPath 或者 ByName 去获取得到所要的控件。

操作层，用来写一些操作，比如 InputUserName(String userName) 是一个输入用户名的操作，供用例层调用，那实现就要包括，判断输入框本身内容，如果有内容要清空，然后在把要输的内容输入进去。当然操作层还要包括一些常用手势操作，比如滑屏。

用例层，用 testNG，这个只调用操作层的方法和 testNG 的 AssertTrue 等判定，以及输出结果报告，看去代码非常简洁，层次清楚，便于阅读，便于调试。

最后，结果报告也有单独封装，这里就不在扩展介绍了。

Appium 框架讲完了，其实有一路走过了很多坑，如果遇到问题也可以留言交流。框架完成后，我和我们组其他 QA 就按各自模块分工，开始补充用例了。应该补了 50 左右的用例了，不算多。主要平时业务也多，自动化的时间不太够，但是框架完善后，补充用例就只是时间问题了。当然，我也听说过其他部门大神做过一些更牛逼的封装，但是还是愿意用自己的，哈哈。但愿说的这些对你有帮助吧，有问题和踩到坑了欢迎交流。