封装属于自己的 Appium 测试框架与实践

封装属于自己的 Appium 测试框架与实践

谈到自动化测试，很多客户端的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左右的用例了，不算多。主要平时业务也多，自动化的时间不太够，但是框架完善后，补充用例就只是时间问题了。当然，我也听说过其他部门大神做过一些更牛逼的封装，但是还是愿意用自己的，哈哈。但愿说的这些对你有帮助吧，有问题和踩到坑了欢迎交流。