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


↙↙↙阅读原文可查看相关链接,并与作者交流