前言

最近我们的项目赶在圣诞前上线，测试这关一直过不去。我们的项目是一个类似电商项目，因此支付这块一直都是重中之重。由于产品经理脑洞大开，支付方式多种多样，钱包金额、优惠券、支付宝、银联支付、多次支付等等，排列组合一下竟然有80多种，再加上退款流程，维护起来简直就是灾难。于是就出现了这么奇葩的一幕：测试团队加技术团队加运营排排坐周末加班加点，人手一张A4样例纸测支付。更可怕的是，如果发现一个金额问题，后台一改代码，还得回归测试！！！！

宝宝好怕怕

折磨了整整2周之后，我们老大痛定思痛，给每人下达了一个任务，去寻找UI自动化测试的方法，于是就有了这篇文章。

UI Tests

IOS的UI自动化测试由于系统封闭的原因，一直不太成熟。UI Tests是Xcode7推出的一项UI自动化测试功能，毕竟是apple官方推出，相对来说比较稳定，它可以通过编写代码、或者是记录开发者的操作过程并代码化，来实现自动点击某个按钮、视图，或者自动输入文字等功能。

使用方法

• 添加UI Tests
  如果是新项目，在创建项目的时候只要把Include UI Tests勾上就行。

勾选上UI Tests

不过大部分项目都是老项目，那么就要通过添加target的方式添加UI Tests。

添加target

添加target

之后在你的项目中就会出现xxxxUITests.m文件，那么UI Tests就添加完毕了。

完成

• 测试用例
  如果有过单元测试经验的同学应该很熟悉这个文件，UI Test测试其实就详单与单元测试，一上来。这个文件就会生成2个函数：- (void)setUp 、- (void)tearDown ，分别会在测试开始和测试完成的时候调用。下面就是一些测试用例，可以自己写方法生成。如图：

测试用例

测试用例

这里值得一提的是，UI测试中也可以下断点，这极大帮助开发者分析用例不通过的原因。

• 断言

既然是单元测试，判断测试通过不通过当然需要断言。这里列举一些常用的断言：

XCTFail(format…) 生成一个失败的测试；

XCTAssertNil(a1, format...)为空判断，a1为空时通过，反之不通过；

XCTAssertNotNil(a1, format…)不为空判断，a1不为空时通过，反之不通过；

XCTAssert(expression, format...)当expression求值为TRUE时通过；

XCTAssertTrue(expression, format...)当expression求值为TRUE时通过；

XCTAssertFalse(expression, format...)当expression求值为False时通过；

XCTAssertEqualObjects(a1, a2, format...)判断相等，[a1 isEqual:a2]值为TRUE时通过，其中一个不为空时，不通过；

XCTAssertNotEqualObjects(a1, a2, format...)判断不等，[a1 isEqual:a2]值为False时通过，

XCTAssertEqual(a1, a2, format...)判断相等（当a1和a2是 C语言标量、结构体或联合体时使用,实际测试发现NSString也可以）；

XCTAssertNotEqual(a1, a2, format...)判断不等（当a1和a2是 C语言标量、结构体或联合体时使用）；

XCTAssertEqualWithAccuracy(a1, a2, accuracy, format...)判断相等，（double或float类型）提供一个误差范围，当在误差范围（+/-accuracy）以内相等时通过测试；

XCTAssertNotEqualWithAccuracy(a1, a2, accuracy, format...) 判断不等，（double或float类型）提供一个误差范围，当在误差范围以内不等时通过测试；

XCTAssertThrows(expression, format...)异常测试，当expression发生异常时通过；反之不通过；（很变态）

XCTAssertThrowsSpecific(expression, specificException, format...) 异常测试，当expression发生specificException异常时通过；反之发生其他异常或不发生异常均不通过；

XCTAssertThrowsSpecificNamed(expression, specificException, exception_name, format...)异常测试，当expression发生具体异常、具体异常名称的异常时通过测试，反之不通过；

XCTAssertNoThrow(expression, format…)异常测试，当expression没有发生异常时通过测试；

XCTAssertNoThrowSpecific(expression, specificException, format...)异常测试，当expression没有发生具体异常、具体异常名称的异常时通过测试，反之不通过；

XCTAssertNoThrowSpecificNamed(expression, specificException, exception_name, format...)异常测试，当expression没有发生具体异常、具体异常名称的异常时通过测试，反之不通过

• XCTest UI Testing API

要想写好测试用例代码，当然得知道UI Test的API。主要分为XCUIApplication、XCUIElement和XCUIElementQuery。

XCUIApplication

这是你正在测试的应用的代理。它能让你启动应用，这样你就能执行测试了。它每次都会新起一个进程，这会多花一些时间，但是能保证测试应用时的状态是干净的，这样你需要处理的变量就少了些。这里面主要有2个方法：

- (void)launch;//启动程序
- (void)terminate;//终止程序

XCUIElement

继承NSObject，实现协议XCUIElementAttributes, XCUIElementTypeQueryProvider

可以表示系统的各种UI元素，比如UIView、UIButton、UITestField等。
主要方法：

- (BOOL)exists;//判断该元素是否存在
- (XCUIElementQuery *)descendantsMatchingType:(XCUIElementType)type;//取某种类型的元素以及它的子类集合
- (XCUIElementQuery *)childrenMatchingType:(XCUIElementType)type;//取某种类型的元素集合，不包含它的子类

//交互类方法
- (void)tap;//单击,还能使testField获得焦点
- (void)doubleTap;//双击
- (void)swipeUp;//pan手势
- (void)typeText:(NSString *)text;//输入文字
- (void)pressForDuration:(NSTimeInterval)duration;//长按

• 自动录制代码
  Xcode很贴心的给开发者一个偷懒的机会，可以录制,并自动生成代码，开发者只要在界面上点点点就能生成对应代码。

录制代码

但是这个功能很鸡肋，因为生成代码大概像这样：

  XCUIApplication *app = [[XCUIApplication alloc] init];
    XCUIElement *element = [[[[app childrenMatchingType:XCUIElementTypeWindow] elementBoundByIndex:0] childrenMatchingType:XCUIElementTypeOther].element childrenMatchingType:XCUIElementTypeOther].element;
    [element tap];

简单的点击就生成了一大堆代码，而且如果界面一变，代码就不可用了。。。不过如果一时不知道怎么敲的话，可以拿来参考下，然后修改成自己的代码。

• demo
  这里主要测试一个登陆功能是否正常作为例子，界面很简单，先看一下演示过程。

流程1

流程2

流程3

测试样例代码

- (void)testExample {

    XCUIApplication *app = [[XCUIApplication alloc] init];
    [app.buttons[@"点击"] tap];

   XCUIElement * textFiled = [app.textFields elementMatchingType:XCUIElementTypeTextField identifier:@"test"];
    [textFiled tap];
    [textFiled typeText:@"user"];

    XCUIElement * textFiled2 = [app.textFields elementMatchingType:XCUIElementTypeTextField identifier:@"hello"];
    if ([textFiled2 exists]){
        [textFiled2 tap];
        [textFiled2 typeText:@"123456"];
    }  
     [app.buttons[@"点击"] tap];    
}

从上面代码不难看出，我们主要的任务就是找到某一个元素（UIButton或者UITextFiled），然后执行单击、长按、输入等操作。这里可以简单得通过app.buttons[@"点击"]获得界面上一个title为点击的按钮，或者通过elementMatchingType:identifier:来获取。经过我尝试，这个identifier的设置位置如下图

identifier

也就是说Accessibility中设置的内容都能在XCUIElement拿来利用和定位。比方设置了Accessibility中的label，就可以写一个函数遍历获取这个元素。

- (XCUIElement *)getElemWithLabel:(NSString *)str type:(XCUIElementType)type{
    XCUIApplication *app = [[XCUIApplication alloc] init];
   XCUIElementQuery * list = [app descendantsMatchingType:type];
    for (int i = 0 ; i < list.count ; i++) {
        XCUIElement * tmpElem =[list elementBoundByIndex:i];
        if ([tmpElem.label isEqualToString:str]) {
            return tmpElem;
        }
    }
    return  nil;
}

ps：我发现elementMatchingType:identifier:中identifier如果是纯英文能拿到，但是英文加数字组合就拿不到了。。不知道算不算bug。

总结

UI Tests虽然能完成UI自动化测试，但是还仅仅是单元测试的层面，想要做到系统测试还远远不够。用来测试能不能登录可以，但是要想解决上面的支付问题还有明显的不足，比如截图，日志等（也许可以，没有深究）。

UI Tests还是在一定程度上增加了开发人员的工作，而且对开发人员有一定的技术要求。至于值不值在生产环境中使用，只能因人而异了。

我是翻滚的牛宝宝，欢迎大家评论交流~