因为业务需求和准备毕设,最近开始研究自动化测试的内容。由于同时要做 iOS、安卓和 Web 测试,我们最终选择了 Appium 这个开源工具并基于它做一些封装,从而能够使用一套公共 API 完成移动端的双端测试。本文主要会基于一些开源代码和个人实践,对 iOS 端的自动化测试原理做一个简单介绍,Android 略有区别但也大致同理。
其实文章没有很长,也没有太多技术含量,驱使我写这篇文章的主要原因是 Google 上能搜到的绝大多数博客都是错的,大多是根据一篇老旧过时的文章抄抄改改。所以真的很想问问这些文章的作者,你真的搞懂 Appium 的原理么?对这一些错误的知识有可能搞懂么?自己不先搞懂,怎么能昧着良心写进博客里?
Appium
我假设读者完全没有了解过自动化测试以及相关的概念,那么首先就要搞明白 Appium 是什么,大概由几个步骤组成,接下来才是对每个部分的深入了解。
简单来说,Appium 是一个测试工具,可以进行 iOS、Android 和 Web 测试,同时还允许使用多种语言来编写测试用例。那么问题就变成了为什么 Appium 支持多种语言来写测试用例,以及这些测试用例是如何运行在具体的平台(比如 iOS )上的。为了回答这个问题,我们需要把 Appium 分成三个部分来看,分别是 Appium 客户端、Appium 服务端和设备端。既然是自动化测试,那么就先从设备端说起。
设备端
如果你按照官网的教程成功的运行了 iOS 真机测试,你会看到手机上多了一个名为 WebDriverAgentRunner 的应用,以后简称 WDA,这个应用的作用就是对你的目标 App 进行测试。
好吧,是不是觉得事情有点神奇了?安装了一个别人的 app,居然能唤起你自己的应用,还能执行测试,是不是存在什么黑魔法?
首先需要介绍一下苹果的 UI 自动化测试框架,在 Xcode 7 以前使用了UI Automation
框架,利用 JS 脚本去做应用测试。而在 Xcode 7 中苹果提供了新的框架 UI Testing
,在 Xcode 8 中干脆直接移除了对 UI Automation
的支持。所以毫无疑问,在 iOS 9 或者更高的系统版本中,Appium 也是利用了 UI Testing
框架来做测试而不是UI Automation
。
很多程序员应对 UI Testing
框架并不陌生,在新建项目的时候就有机会勾选上这个选项,或者后期通过 Add target
的方式补上。默认情况下,一个测试用例就是一个 .m
文件,模板代码如下:
#import <XCTest/XCTest.h>
@interface Test : XCTestCase
@end
@implementation Test
- (void)setUp {
[super setUp];
// Put setup code here. This method is called before the invocation of each test method in the class.
// In UI tests it is usually best to stop immediately when a failure occurs.
self.continueAfterFailure = NO;
// UI tests must launch the application that they test. Doing this in setup will make sure it happens for each test method.
[[[XCUIApplication alloc] init] launch];
// In UI tests it’s important to set the initial state - such as interface orientation - required for your tests before they run. The setUp method is a good place to do this.
}
- (void)tearDown {
// Put teardown code here. This method is called after the invocation of each test method in the class.
[super tearDown];
}
- (void)testExample {
// Use recording to get started writing UI tests.
// Use XCTAssert and related functions to verify your tests produce the correct results.
}
@end复制代码
可以看到一共只有三个方法, setUp
方法中主要做一些测试前的准备,比如这里的 [[[XCUIApplication alloc] init] launch];
就创建了一个被测试应用的实例并唤起它。tearDown
方法是测试结束后的清理工作。
所有的测试函数都必须以 test
开头,比如这里的 - (void)testExample
。好吧,不得不承认 OC 这们语言还是有缺陷的,缺少了 Annotation 以后就只能用变量名来做标记,这种业务对应的 Java 表示应该是:
@test
public void example() {
// do some test
}复制代码
言归正传,有了这样的测试代码后,只要 Command + U
就可以运行测试。不过这还是没有解决之前的疑惑,为什么 Appium 可以用一个第三方 app 唤起待测试的应用并进行调试?当然,这个问题等价于,上面代码中的 [[XCUIApplication alloc] init]
到底会创建一个什么样的 app 实例?它怎么知道这个对象的 launch
方法会打开手机上的哪个 app?
这个问题似乎没有搜到比较明确的答案,不过经过实践分析以后发现,XCUIApplication
类存在一个私有方法,可以传入目标应用的 BundleID:
[[XCUIApplication alloc] initPrivateWithPath:nil bundleID:@"com.bestswifte.targetapp"];复制代码
我们知道手机上一个 BundleID 唯一对应了一个应用,后装的应用会替换掉之前相同 ID 的应用,所以通过 BundleID 总是可以正确的唤起待测试应用。唯一要注意的是,为了顺利通过编译器的语法检测,我们在调用私有方法之前需要先构造一份 XCUIApplication
的头文件,声明一下将要调用的私有方法。
当我们用这个私有的初始化方法替换掉默认的 init
方法后,就可以正常唤起待测试应用了,不过你会发现被测试的应用刚一打开就会退出,这是因为我们的测试代码内容为空,所以很快就会进入到销毁流程。
解决问题也很简单,我们可以在 testExample
里面跑一个死循环,模拟 Runloop 的操作。只不过这次不是监听用户事件,而是监听某个 TCP 端口,等待网络传输过来的消息。
我们以 Facebook 开源的 WDA 为例,看看它的 FBScreenshotCommands.m
文件:
#import "FBScreenshotCommands.h"
#import "XCUIDevice+FBHelpers.h"
@implementation FBScreenshotCommands
#pragma mark - <FBCommandHandler>
+ (NSArray *)routes
{
return
@[
[[FBRoute GET:@"/screenshot"].withoutSession respondWithTarget:self action:@selector(handleGetScreenshot:)],
[[FBRoute GET:@"/screenshot"] respondWithTarget:self action:@selector(handleGetScreenshot:)],
];
}
#pragma mark - Commands
+ (id<FBResponsePayload>)handleGetScreenshot:(FBRouteRequest *)request
{
NSString *screenshot = [[XCUIDevice sharedDevice].fb_screenshot base64EncodedStringWithOptions:NSDataBase64Encoding64CharacterLineLength];
return FBResponseWithObject(screenshot);
}
@end复制代码
这里首先会注册一个 /screenshot
的路由,并且制定处理函数为 handleGetScreenshot
,然后函数内部调用 XCUIDevice
的截图方法。
所以分析到这里,WDA 的套路就很清晰了,它能根据被测试应用的 BundleID 将它唤起,然后自己进入死循环保证测试用例一直不退出。此时等待服务器传来 URL 数据,然后解析 URL,分发到对应模块,各个模块根据 URL 指令执行对应的测试操作,最终再把测试结果返回。
Appium 服务端
简单来说,Appium 服务端是一个 Node.js 应用,这个应用跑在电脑上,用于和 WDA 进行通信。刚刚我们看到了截图命令的 URL 是 /screenshot
,可以想见还有别的类似的测试操作,所以 WDA 有必要和 Appium 服务端约定一套通信协议。考虑到 Appium 还支持 Android 测试,所以在安卓手机上也有类似的东西需要和 Appium 服务端进行交互。这样一来,约定一套通用的协议就显得非常重要。
Appium 采用的是 WebDriver 协议。在 w3.org 上有一个对该协议的详细描述,而 Selenim 的官网 也介绍了 WebDriver 协议。目前我尚不知道这两处介绍的关系,是互为补充 or 两套规范,但可以肯定的是下面这段话的介绍:
WebDriver’s goal is to supply a well-designed object-oriented API that provides improved support for modern advanced web-app testing problems.
所以简单的把 WebDriver 理解成一套通用的测试协议即可。
Appium 客户端
Appium 客户端就是指我们写的那些测试代码了。Appium 支持多种测试语言的根本原因在于,WebDriver 协议为各种主流语言提供了一个第三方库,能够方便的把测试脚本转化成符合 WebDriver 规范的 URL。比如 www.w3.org/TR/webdrive… 就规定了包括截图、寻找元素、点击元素等操作对应的 URL 格式。
我们的项目目前使用 Java 语言来编写测试脚本,这样的好处是 Android 工程师就可以承担起维护和编写 Android、iOS 两个平台下测试代码的重任了。
总结
其实 Appium 的原理非常简单,一句话就能概括:
提供各个语言的第三方库,将测试脚本转化成 WebDriver 协议下的 URL,通过 Node 服务发送到各个平台上的代理工具,代理工具在运行过程中不断接收 URL,根据 WebDriver 协议解析出要执行的操作,然后调用各个平台上的原生测试框架完成测试,再将测试结果返回给 Node 服务器。
最后再友情提醒一句:
iOS 上的真机测试环境很难配置,如果一天搞不定,不要气馁,多试几次,也许明天就好了
参考资料:
- [iOS9 UIAutomation] What is Appium approach to UIAutomation deprecation by Apple
- 现在开始把UI Testing用起来!
- A Beginner’s Guide to Automated UI Testing in iOS
学习的过程中走了不少弯路,如果你看到下面这两篇文章,建议立刻按下 Command + w
,不要浪费时间去学习错误知识了: