《Testing with Xcode》第二章——Testing Basics

原文地址：https://developer.apple.com/library/prerelease/content/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/03-testing_basics.html#//apple_ref/doc/uid/TP40014132-CH3-SW1

文章导读

本文是纯理论篇，介绍了测试的基础概念。

声明

文章翻译自Apple官方文档《Testing with Xcode》，不保证每个字都能翻译的精准，如有翻译错误，请留言指出，不胜感激。

本文由于是纯理论，翻译起来非常生硬，大概意思应该是能看懂的，语言上可能组织不当，我已经约了一个精通英语的朋友，等他有时间会帮我校对，现在就请大家将就着看吧。

Testing Basics(测试基础)

测试是你写的代码或者代码库的代码运行在App中，获取结果来比对预期的结果，成功或者失败。测试需要检查经过一系列操作后，变量变化的情况。当涉及到边界等情况，能跑出一个特别的结果。对于性能测试，衡量标准就是你完成一系列运行的最大次数。

Defining Test Scope（定义测试范围）

一个软件是由很多部分构成的，意味着小的元素放在一起组成一个大的。当项目的目标和需求都被满足了，高等级的元素有着非常实用性的意义。好的测试需要覆盖程序所有等级。XCTest允许为程序所有等级的元素编写测试用例。

测试用例的构成由你定义。可以是一个类中的方法，或者是一系列你认为必要的方法。例如，它可以是一个计算的操作，就像在第一章QuickStart中例子介绍的计算类型的app那样。你需要用不同的方法来区别TableView和你代码中数据结构定义的名字。它们中的每一个方法都意味着测试app实用功能。元素测试的行为可以有一个确定的结果，成功或者失败。

app元素的行为你细分的越多。在你的项目增长和变化过程中，就能越有效的测试代码的行为是否符合标准。在大型的项目中，有非常多的元素，你需要运行非常大量的测试代码去完全的测试程序。如果可能，测试用例需要被设计的执行非常快速。但是某些测试用例必须要非常大而且执行的很慢。小而快速的执行测试可以经常的执行，很简单的定位，帮忙诊断和修复问题失败的地方。

为一个项目设计单元测试时基于测试驱动开发——一种写代码的方式，在写功能代码之前先写测试逻辑的代码。这种开发方式能够让你代码在实施之前更符合需求和边缘情况的规范。当你下次执行测试的时候，你可以很自信的修改你的代码，因为任何变化都在于其的行为中。

当然如果你不使用测试驱动开发的方式，测试也能帮你减少开发新功能时引入新的bug。当你修复bug时，你可以增加测试用例来证实缺陷被修复了。测试需要执行你的代码。寻找成功或者失败的情况，来覆盖所有的边界情况。

---

注意： 如果原来没有测试的项目增加测试用例，可能需要重新设计部分代码来让测试更容易实施。 Appendix A: Writing Testable Code为你编写测试代码提供了简单的指南，你可能会找到一些有用的东西

---

你的app的任意两个不同的单元可能会互相影响，由于一些类型的测试需要执行很长的时间，你最好周期性的运行他们或者只在一个服务商运行。稍后你会看到下一章，你可以安排你的测试用例，使用不同方式执行来适应不同的需求。

Performance Testing（性能测试）

单元测试可以在测试自然环境下的功能，或者性能。XCTest提供了API来衡量性能指标。让你能够和功能测试一样的跟踪性能改善的情况。

当执行性能测试的时候，需要提供一个成功或者失败的结果，一个测试用例需要有一个基线来评估。基线市值程序运行十次结果的平均值。测试结果高于基线时间很多的用例要被报告为失败。

---

注意：你第一次运行性能测试的时候，XCTest总会给一个失败的结果，是由于基线还不知道。如果你有接受了某一次性能的指标可以当成基线，XCTest会在报告中评估结果是成功或者失败，然后提供给你测试结果的细节。

---

User Interface Testing（界面测试）

到目前为止，讨论的功能和性能测试，通常被称为单元测试。其中的“单元”取决于你对功能细分的颗粒度。单元测试主要关心的是符合预期的组件，或者与其他组件交互的预期行为。从设计的角度来看，单元测试可以在开发项目的时候，就从内部检查，实现你的意图。

用户通过界面来与你的代码进行交互。用户界面的交互一般来说是比较高级的行为。使用外部的界面来操作几个组件来实现app的功能。如果没有特殊的设计来操作app外部会话，要想通过单元测试来测试用户通过界面执行的方法是非常困难的。这些特殊的设计被称为“UI测试”。

UI测试就像用户操作一样，测试app的表面层。他们让你写测试用例，发送模拟的时间给系统和界面的对象，捕捉这些对象的响应，然后就像你做单元测试一样测试响应的正确性是否符合预期。

App and Library Tests（App和库测试？）

Xcode提供了两种单元测试的会话，App测试和库测试。

• app测试

App测试检查app中代码行为的正确性，就像例子中的计算器app计算的操作一样。

• 库测试

库测试检查代码在动态库和框架中行为的正确性，而不依赖于他们在程序运行时使用的框架。进行库测试，你可以构建单元测试来测试库的组件。

XCTest——the Xcode Testing Framework（Xcode测试框架）

从Xcode5开始包含该了XCTest，是提供给你的测试框架。

考虑到版本的一致性：

• In Xcode 5, XCTest is compatible with running on OS X v10.8 and OS X v10.9, and with iOS 7 and later.

• In Xcode 6, XCTest is compatible with running on OS X v10.9 and OS X v10.10, and with iOS 6 and later.

• In Xcode 7, XCTest is compatible with running on OS X v10.10 and OS X v10.11, and with iOS 6 and later.

UI测试在OS X v10.11和IOS9之后支持运行，可以运行在模拟器和设备上。

更多详细的版本信息，请看 Xcode Release Notes.

Xcode把XCTest.framework收入在你的项目中。这个框架提供了让你设计测试并且在你的代码中运行他们的接口。获取更多有关于XCTest测试框架的信息，请看XCTest Framework Reference。

---

注意：Xcode包含了已经存在OCUnit test项目的更新迁移方法，获取更多信息请看Appendix B: Transitioning from OCUnit to XCTest。

---

Where to Start When Testing（当测试的时候从哪里开始）

当你开始创建测试的时候，记住下列几个建议：

• 当创建单元测试的时候，重点测试你代码中最基础的功能，模型中与控制器交互的类和方法。

一个高级的程序框架，通常会有模型，视图和控制器类。这是大多数与Cocoa和Cocoa Touch工作中最熟悉的设计模式。如果你需要写的测试要覆盖所有的模型类，在你测以你的方式测试控制器类等app复杂部分之前，你需要确定你的app是容易被测试。

作为一个起点，如果你正在编写一个测试框架或者库，你最好从你API的表面开始，从那里，你的工作方式就是内部类。

• 当创建UI测试的时候，要考虑大部分常见的工作流。考虑当用户开始使用app的时候会从哪里开始，UI层会马上执行哪些进程。使用UI录制是一个很好的方式来捕获用户一些列行为到测试方法中，这些测试方法经过扩展，可以很容易的正确的实现测试和性能测试。

这种UI测试倾向于一个粗颗粒度的测试，每个测试可能会跨越多个子系统。他们会返回很多信息让你难以分析。所以你和你的UI测试套件工作的时候，你最要细分每个测试，以便更清晰的反映某个子系统的行为。