ios软件测试兼职,iOS自动化测试的那些干货

Quick

Quick是建立在XCTestSuite上的框架，使用XCTestSuite允许你动态创建测试用例。所以，使用Quick,你仍让可以使用XCode的测试相关GUI和命令行工具。

使用Quick编写的测试用例看起来是这样子的：

import Quick

import Nimble

class TableOfContentsSpec: QuickSpec {

override func spec() {

describe("the 'Documentation' directory") {

it("has everything you need to get started") {

let sections = Directory("Documentation").sections

expect(sections).to(contain("Organized Tests with Quick Examples and Example Groups"))

expect(sections).to(contain("Installing Quick"))

}

context("if it doesn't have what you're looking for") {

it("needs to be updated") {

let you = You(awesome: true)

expect{you.submittedAnIssue}.toEventually(beTruthy())

}

}

}

}

}

BDD的框架让测试用例的目的更加明确，测试是否通过更加清晰。使用Quick,测试用例分为两种：

单独的用例 - 使用it来描述

it有两个参数，

行为描述

行为的测试代码

比如，以下测试Dolphin行为，它具有行为is friendly和is smart

//Swift代码

class DolphinSpec: QuickSpec {

override func spec() {

it("is friendly") {

expect(Dolphin().isFriendly).to(beTruthy())

}

it("is smart") {

expect(Dolphin().isSmart).to(beTruthy())

}

}

}

可以看到，BDD的核心是行为。也就是说，需要关注的是一个类提供哪些行为。

用例集合，用describe和context描述

比如，验证dolphin的click行为的时候，我们需要两个用例。一个是is loud,一个是has a high frequency，就可以用describe将用例组织起来。

class DolphinSpec: QuickSpec {

override func spec() {

describe("a dolphin") {

describe("its click") {

it("is loud") {

let click = Dolphin().click()

expect(click.isLoud).to(beTruthy())

}

it("has a high frequency") {

let click = Dolphin().click()

expect(click.hasHighFrequency).to(beTruthy())

}

}

}

}

}

context可以指定用例的条件：

比如

describe("its click") {

context("when the dolphin is not near anything interesting") {

it("is only emitted once") {

expect(dolphin!.click().count).to(equal(1))

}

}

}

除了这些之外，Quick也支持一些切入点，进行测试前的配置：

●beforeEach

●afterEach

●beforeAll

●afterAll

●beforeSuite

●afterSuite

●Nimble

由于Quick是基于XCTest，开发者当然可以收使用断言来定义测试用例成功或者失败。Quick提供了一个更有好的Framework来进行这种断言：Nimble

比如，一个常见的XCTest断言如下：

XCTAssertTrue(ConditionCode, "FailReason")11

在出错的时候，会提示

XCAssertTrue failed, balabala

这时候，开发者要打个断点，查看下上下文，看看具体失败的原因在哪。

使用Nimble后，断言变成类似

expect(1 + 1).to(equal(2))

expect(3) > 2

expect("seahorse").to(contain("sea"))

expect(["Atlantic", "Pacific"]).toNot(contain("Mississippi"))

并且，出错的时候，提示信息会带着上下文的值信息，让开发者更容易的找到错误。

让你的代码更容易单元测试

测试的准确性和工作量很大程度上依赖于开发人员的代码质量。

通常，为了单元测试的准确性，我们在写函数(方法)的时候会借鉴一些函数式编程的思想。其中最重要的一个思想就是

pure function(纯函数)

何为Pure function？就是如果一个函数的输入一样，那么输出一定一样。

比如，这样的一个函数就不是pure function。因为它依赖于外部变量value的值。

static NSInteger value = 0;

- (NSInteger)function_1{

value = value + 1;

return value;

}

而这个函数就是pure function，因为给定输入，输出一定一致。

- (NSInteger)function_2:(NSInteger)base{

NSInteger value = base + 1;

return value;

}

所以，如果你写了一个没有参数，或者没有返回值的方法，那么你要小心了，很可能这个方法很难测试。

关于MVC

在良好的MVC架构的App中，

View只做纯粹的展示型工作，把用户交互通过各种方式传递到外部

Model只做数据存储类工作

Controller作为View和Model的枢纽，往往要和很多View和Model进行交互，也是自动化包括代码维护的痛点。

所以，对Controller瘦身是iOS架构中比较重要的一环，一些通用的技巧包括：

逻辑抽离：

网络请求独立。可以每个网络请求以Command模式封装成一个对象，不要直接在Controller调用AFNetworking。

数据存储独立。建立独立的Store类，用来做数据持久化和缓存。

共有数据服务化(协议)。比如登录状态等等，通过服务去访问，这样服务提供者之需要处理服务的质量，服务使用者则信任服务提供者的结果。

Controller与View解耦合

建立ViewModel层，这样Controller只需要和ViewModel进行交互。

建立UIView子类作为容器，将一些View放到容器后再把容器作为SubView添加到Controller里

建立可复用的Layout层，不管是AutoLayout还是手动布局。

Controller与Controller解耦合

建立页面路由。每一个界面都抽象为一个URL，跳转仅仅通过Intent或者URL跳转，这样两个Controller完全独立。

如果你的App用Swift开发，那么面向协议编程和不可变的值类型会让你的代码更容易测试。

当然，iOS组建化对自动化测试的帮助也很大，因为不管是基础组件还是业务组件，都可以独立测试。组建化又是一个很大的课题，这里不深入讲解了。

KIF

KIF的全称是Keep it functional。它是一个建立在XCTest的UI测试框架，通过accessibility来定位具体的控件，再利用私有的API来操作UI。由于是建立在XCTest上的，所以你可以完美的借助XCode的测试相关工具(包括命令行脚本)。

> KIF是个人非常推荐的一个框架，简单易用。

使用KIF框架强制要求你的代码支持accessibility。如果你之前没接触过，可以看看Apple的文档

Accessibility Programming Guide for iOS

简单来说，accessibility能够让视觉障碍人士使用你的App。每一个控件都有一个描述AccessibilityLabel。在开启VoiceOver的时候，点击控件就可以选中并且听到对应的描述。

通常UIKit的控件是支持accessibility的，自定定义控件可以通过代码或者Storyboard上设置。

在Storyboard上设置：

上面的通过Runtime Attributes设置(KVC)

下面的通过GUI来设置

通过代码设置：

[alert setAccessibilityLabel:@"Label"];

[alert setAccessibilityValue:@"Value"];

[alert setAccessibilityTraits:UIAccessibilityTraitButton];

如果你有些Accessibility的经验，那么你肯定知道，像TableView的这种不应该支持VoiceOver的。我们可以用条件编译来只对测试Target进行设置：

#ifdef DEBUG

[tableView setAccessibilityValue:@"Main List Table"];

#endif

#ifdef KIF_TARGET (这个值需要在build settings里设置)

[tableView setAccessibilityValue:@"Main List Table"];

#endif

使用KIF主要有两个核心类：

KIFTestCase XCTestCase的子类

KIFUITestActor 控制UI，常见的三种是：点击一个View，向一个View输入内容，等待一个View的出现

我们用KIF来测试添加一个新的ToDo

- (void)testAddANewItem{

[tester tapViewWithAccessibilityLabel:@"Add"];

[tester enterText:@"Create a test to do item" intoViewWithAccessibilityLabel:@"Input what you want todo"];

[tester tapViewWithAccessibilityLabel:@"Save"];

[tester waitForTimeInterval:0.2];

[tester waitForViewWithAccessibilityLabel:@"Create a test to do item"];

}

命令行

自动化测试中，命令行工具可以facebook的开源项目：

xctool

这是一个基于xcodebuild命令的扩展，在iOS自动化测试和持续集成领域很有用,而且它支持-parallelize并行测试多个bundle，大大提高测试效率。

安装XCTool,

brew install xctool11

使用

path/to/xctool.sh \

-workspace YourWorkspace.xcworkspace \

-scheme YourScheme \

-reporter plain:/path/to/plain-output.txt \

run-test

并且，xctool对于持续集成很有用，iOS常用的持续集成的server有两个：

Travis CI 对于公开仓库(比如github)免费，私有仓库收费

Jenkins 免费

优化你的测试代码

准确的测试用例

通常，你的你的测试用例分为三部分：

配置测试的初始状态

对要测试的目标执行代码

对测试结果进行断言(成功 or 失败)

测试代码结构

当测试用例多了，你会发现测试代码编写和维护也是一个技术活。通常，我们会从几个角度考虑：

不要测试私有方法(封装是OOP的核心思想之一，不要为了测试破坏封装)

对用例分组(功能，业务相似)

对单个用例保证测试独立(不受之前测试的影响，不影响之后的测试)，这也是测试是否准确的核心。

提取公共的代码和操作，减少copy/paste这类工作，测试用例是上层调用，只关心业务逻辑，不关心内部代码实现。

一个常见的测试代码组织如下：

appium

appium采用了Client Server的模式。对于App来说就是一个Server，基于WebDriver JSON wire protocol对实际的UI操作库进行了封装，并且暴露出RESTFUL的接口。然后测试代码通过HTTP请求的方式，来进行实际的测试。其中，实际驱动UI的框架根据系统版本有所不同：

< 9.3 采用UIAutomation

>= 9.3 XCUITest

原因也比较简单：Apple在10.0之后，移除了UIAutomation的支持，只支持XCUITest。

对比KIF，appium有它的优点：

跨平台，支持iOS，Android

测试代码可以由多种语言编写，这对测试来说门槛更低

测试脚本独立与源代码和测试框架

当然，任何框架都有缺点：

自定义控件支持不好

WebView的支持不好

总结

由于我不是专业的iOS测试，关于测试的一点见解如下：

单元测试还是选择BDD框架，毕竟可读性高一些，推荐Quick(Swift)，Kiwi(Objective C)

UI测试优先推荐KIF，如果需要兼顾安卓测试，或者测试人员对OC/Swift很陌生，可以采用appium

22/2<12