自动化测试框架总结-网络知识

1. 单元测试框架

2. Web自动化测试框架

3. iOS自动化测试框架

4. Android自动化测试框架

1. 单元测试框架

几乎所有的主流语言，都会有其对应的单元测试框架,下面简单介绍一下python,java,C#三种语言的常见单元测试框架

1.1 Python

python常见单元测试框架包括unittest, pytest

1.1.1 unittest

unittest单元测试框架不仅可以适用于单元测试，还可以适用WEB自动化测试用例的开发与执行，该测试框架可组织执行测试用例，并且提供了丰富的断言方法，判断测试用例是否通过，最终生成测试结果。
unittest为python内置库,不需要单独安装(好像也和版本有关系)

1.1.2 pytest

pytest是一个非常成熟的全功能的Python测试框架，主要有以下几个特点：

简单灵活，容易上手
支持参数化
能够支持简单的单元测试和复杂的功能测试，还可以用来做selenium/appnium等自动化测试、接口自动化测试（pytest+requests)
pytest不是python内置库,需要单独安装

1.1.3 unittest与pytest对比

unittest提供了test cases、test suites、test fixtures、test runner相关的类,让测试更加明确、方便、可控。使用unittest编写用例,必须遵守以下规则:

（1）测试文件必须先import unittest
（2）测试类必须继承unittest.TestCase
（3）测试方法必须以“test_”开头
（4）测试类必须要有unittest.main()方法

pytest是python的第三方测试框架,是基于unittest的扩展框架,比unittest更简洁,更高效。使用pytest编写用例,必须遵守以下规则:

（1）测试文件名必须以“test_”开头或者"test"结尾(如:test_ab.py)
（2）测试方法必须以“test”开头。
（3）测试类命名以"Test"开头。

unittest提供了setUp/tearDown，只能针对所有用例。
pytest提供了模块级、函数级、类级、方法级的setup/teardown，比unittest的setUp/tearDown更灵活。

模块级（setup_module/teardown_module）开始于模块始末，全局的
函数级（setup_function/teardown_function）只对函数用例生效（不在类中）
类级（setup_class/teardown_class）只在类中前后运行一次(在类中)
方法级（setup_method/teardown_method）开始于方法始末（在类中）
类里面的（setup/teardown）运行在调用方法的前后

pytest还可以在函数前加@pytest.fixture()装饰器，在测试用例中装在fixture函数。fixture的使用范围可以是function,module,class,session。
fixture相对于setup和teardown来说有以下几点优势：

(1)命名方式灵活，不局限于setup和teardown这几个命名
(2)conftest.py 配置里可以实现数据共享，不需要import就能自动找到一些配置，可供多个py文件调用。
(3)scope="module" 可以实现多个.py跨文件共享前置
(4)scope="session" 以实现多个.py跨文件使用一个session来完成多个用例
(5)用yield来唤醒teardown的执行

断言方面:
unittest提供了assertEqual、assertIn、assertTrue、assertFalse.
pytest直接使用assert 表达式,相对而言更简单且高效.
unittest不支持失败重跑,pytest支持
unittest依赖ddt库参数化，pytest直接使用@pytest.mark.parametrize装饰器

pytest总的来说优于unittest,提供了更多的功能和可拓展性

1.2 Java

Java常见单元测试框架包括Junit、testNG

1.3 C#

C#常见单元测试框架包括NUnit

2. Web自动化测试框架

2.1 Selenium

Selenium是一个用于Web应用程序测试的工具。支持的浏览器包括IE、Mozilla Firefox、Mozilla Suite等。这个工具的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。Selenium 是一套完整的web应用程序测试系统，包含了测试的录制（selenium IDE）,编写及运行（Selenium Remote Control）和测试的并行处理（Selenium Grid）。Selenium的核心Selenium Core基于JsUnit，完全由JavaScript编写，因此可以用于任何支持JavaScript的浏览器上。Selenium可以模拟真实浏览器，自动化测试工具，支持多种浏览器，爬虫中主要用来解决JavaScript渲染问题。

selenium 1.0 包括以下两部分：selenium server、 Client Libraries组成

2.1.1 selenium server

selenium server负责控制浏览器的行为。主要有launcher，Http Proxy，selenium core。selenium core使用Selenium Server嵌入到浏览器页面中。实质上，selenium core是由JS函数组成，这样我们可以实现用程序对浏览器进行操作。

2.1.2 client Libraries

编写测试用例时控制selenium server的库

下图介绍了testcase的执行过程：

执行过程

(1).测试案例（Testcase）通过Client Lib的接口向Selenium Server发送Http请求，要求和Selenium Server建立连接。

为什么要通过发送Http请求控制Selenium Server而不采用其他方式呢？从上文可以看出，Selenium Server是一个独立的中间服务器（确切地说是代理服务器），它可以架设在其他机器上！所以测试案例通过发送HTTP请求去控制Selenium Server是很正常的。

(2).Selenium Server的Launcher启动浏览器，把Selenium Core加载入浏览器页面当中，并把浏览器的代理设置为Selenium Server的Http Proxy。

(3).测试案例通过Client Lib的接口向Selenium Server发送Http请求，Selenium Server对请求进行解析，然后通过Http Proxy发送JS命令通知Selenium Core执行操作浏览器的动作。

(4).Selenium Core接收到指令后，执行操作。

(5).浏览器收到新的页面请求信息（因为在(4)中，Selenium Core的操作可能引发新的页面请求），于是发送Http请求，请求新的Web页面。

由于Selenium Server在启动浏览器时做了手脚，所以Selenium Server会接收到所有由它启动的浏览器发送的请求。

(6).Selenium Server接收到浏览器的发送的Http请求后，自己重组Http请求，获取对应的Web页面。

(7).Selenium Server的Http Proxy把接收的Web页面返回给浏览器。

2.2 Selenium2(Webdriver)

Selenium 2将浏览器原生的API封装成WebDriver API，可以直接操作浏览器页面里的元素，甚至操作浏览器本身（截屏，窗口大小，启动，关闭，安装插件，配置证书之类的）,所以就像真正的用户在操作一样。

下图介绍了Selenium2的架构:

Selenium2架构

webdriver按照server–client的经典设计模式设计
server端就是remote server，可以是任意的浏览器：我们的脚本启动浏览器后，该浏览器就是remote server，它的职责就是等待client发送请求并做出相应；
client端简单说来就是我们的测试代码：们测试代码中的一些行为，比如打开浏览器，转跳到特定的url等操作是以http请求的方式发送给被server端（也就是被测浏览器）server接受请求，并执行相应操作，并在response中返回执行状态、返回值等信息；
the WebDriver Wire Protocol是Selenium自己设计定义的协议，这套协议非常之强大，几乎可以操作浏览器做任何事情，包括打开、关闭、最大化、最小化、元素定位、元素点击、上传文件等。
WebDriver Wire协议是通用的，也就是说不管FirefoxDriver还是ChromeDriver，启动之后都会在某一个端口启动基于这套协议的Web Service,例如FirefoxDriver初始化成功，默认从http://localhost:7055开始，IE则是http://localhost:52432

webdriver的工作原理：

(1)启动浏览器后，selenium-webdriver会将目标浏览器绑定到特定的端口，启动后的浏览器则作为webdriver的remote server。

(2)客户端(也就是测试脚本)，借助ComandExecutor发送HTTP请求给sever端（通信协议：The WebDriver Wire Protocol，在HTTP request的body中，会以WebDriver Wire协议规定的JSON格式的字符串来告诉Selenium我们希望浏览器接下来做什么事情）。

(3)Sever端需要依赖原生的浏览器组件，转化Web Service的命令为浏览器native的调用来完成操作。

3. iOS自动化测试框架

3.1 XCTest

About Testing with Xcode

XCTest是苹果在iOS 7和Xcode5引入的一个简单而强大的测试框架，它的测试编写起来非常简单，并且遵循xUnit风格。XCTest的优点是与Xcode深度集成，有专门的Test导航栏，但因为受限于官方测试API，因此功能不是很丰富。

3.2 UIAutomation

https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UIAutomation.html

UIAutomation是苹果提供的UI自动化测试框架，使用Javascript编写。基于UIAutomation有扩展型的工具框架和驱动型的框架。扩展型框架以JavaScript扩展库方法提供了很多好用js工具，注入式的框架通常会提供一些Lib或者是Framework，要求测试人员在待测应用的代码工程中导入这些内容，框架可以通过他们完成对app的驱动。驱动型UI Automation 在自动化测试底层使用了UI Automation库，通过TCP通信的方式驱动UI Automation来完成自动化测试，通过这种方式，编辑脚本的语言不再局限于JavaScript。

3.3 Frank

App Development Ireland - App Developers Dublin

Frank是iOS平台一款非常受欢迎的app测试框架，它使用Cucumber语言来编写测试用例， Frank包含一个强大的“app inspector”–Symbiote，可以用它来获得运行中app的详细信息，便于开发者将来进行测试回顾。它允许使用Cucumber编写结构化英语句子的测试场景。 Frank要求测试时在应用程序内部编译，这意味着对源代码的改变是强制性的。操作方式为使用Cucumber和JSON组合命令，将命令发送到在本地应用程序内部运行的服务器上，并利用UISpec运行命令。

**优点： **测试场景是在Cucumber的帮助下，用可理解的英语句子写的。强大的Symbiote实时检查工具。活跃的社区支持。不断扩大中的库。

缺点：对手势的支持有限。在设备上运行测试有点难。修改配置文件需要在实际设备上运行。记录功能不可用。

3.4 KIF

iOS 中使用 KIF 测试 UI - OSCHINA - 中文开源技术交流社区

KIF是Keep It Functional项目的缩写，是一款iOS app功能性测试框架，使用Objective-C语言编写，对苹果开发者来说非常容易上手，更是一款开发者广为推荐的测试工具。KIF tester使用私有API来了解App中的视图层级。但缺点是运行较慢。

3.5 Calabash-ios

详见Calabash-android 描述。

3.6 Subliminal

Subliminal

Subliminal是另一款与XCTest集成的框架。与KIF不同的是，它基于UIAutomation编写，旨在对开发者隐藏UIAutomation中一些复杂的细节。

3.7 Kiwi

https://github.com/kiwi-bdd/Kiwi/wiki/Getting-Started-with-Kiwi-2.0

Kiwi是对XCTest的一个完整替代，使用xSpec风格编写测试。 Kiwi带有自己的一套工具集，包括expectations、mocks、stubs，甚至还支持异步测试。它是一个适用于iOS 开发的Behavior Driven Development（BDD）库，优点在于其简洁的接口和可用性，易于设置和使用，非常适合新手开发者。Kiwi使用Objective-C语言编写，易于IOS开发人员上手。

3.8 Appium

Appium: Mobile App Automation Made Awesome.

Appium是一个开源的、跨平台的自动化测试工具，支持IOS、Android和FirefoxOS平台。通过Appium，开发者无需重新编译app或者做任何调整，就可以测试移动应用，可以使测试代码访问后端API和数据库。它是通过驱动苹果的UIAutomation和Android的UiAutomator框架来实现的双平台支持，同时绑定了Selenium WebDriver用于老的Android平台测试。开发者可以使用WebDriver兼容的任何语言编写测试脚本，如Java， OC， JS， PHP，Python， Ruby， C#，Clojure 和Perl语言。

总结:IOS自动化测试框架继承关系如下. XCTest与 Xcode 的 IDE 直接集成,使用简单, 但其不支持stub和mock, 所以单使用XCTest框架的较少. Kiwi是一个iOS平台十分好用的行为驱动开发BDD的测试框架，有着非常漂亮的语法，可以写出结构性强，非常容易读懂的测试。UI Automation是Apple官方提供的UI自动化测试的解决方法,但接口不够丰富。

iOS自动化测试框架

KIF、Frank、Calabash都是通过使用代码的形式来模拟事件触发，使得被测代码就像是由用户行为所触发的一样。但这样的代价是插入一个额外层的复杂度。
IOS测试框架中支持BDD的有calabash 和Kiwi。
可选用的单元测试框架有Kiwi，Specta，Quick等，而KIF，Subliminal和calabash更适用于UI级验收测试。

4. Android自动化测试框架

4.1 Instrumentation

https://developer.android.com/reference/android/app/Instrumentation.html

Instrumentaion 是Android自带的一个测试框架，是很多其它测试框架的基础，可以在同进程中加载被测组件。它有很多丰富的高层封装，使用者可以使用基于instrumentation的其他框架，避免过多二次开发量。但Instrumentation不支持跨应用，导致基于instrumentation的框架都继承了这个缺点。

4.2 Robotium

https://github.com/robotiumtech/robotium

Robotium是基于Instrumentation框架开发的一个更强的框架. 对常用的操作进行了易用性的封装. 用于开发功能性、系统和验收测试场景。它运行时绑定到GUI组件。它安装了一个测试用例套件作为在Android设备或仿真器上的应用程序，并提供用于执行测试的真实环境。

优点： 容易在最短的时间内编写测试脚本，易用性高。自动跟随当前activity。由于运行时绑定到GUI组件，所以相比Appium，它的测试执行更快，更强大。不访问代码或不了解app实现，也可以工作。支持Activities、Dialogs、Toasts、Menus、Context Menus和其他Android SDK控件。

缺点： 不能处理flash和web组件。在旧设备上会变得很慢。由于不支持iOS设备,当自动化测试同时覆盖 android与iOS的情况时，测试会被中断。没有内置的记录和回放功能.，使用记录功能需要 TestDroid 和 Robotium Recorder 这样的收费工具。

4.3 UIAutomator

https://google.github.io/android-testing-support-library/docs/uiautomator/

UIAutomator是由谷歌提供的测试框架，它提供了原生Android app和游戏的高级UI测试。这是一个包含API的Java库，用来创建功能性UI测试，还有运行测试的执行引擎。该库自带Android SDK。

优点：它在运行访问不同的进程时，会给JUnit测试案例特权。库由谷歌社区支持和维护。

缺点：仅支持android4.1（API level 16）及以上。不支持脚本记录。支持的重点是Java。你不能获得当前活动或仪表化。目前不支持web视图。库仅支持使用Java，因此很难和使用Ruby的cucumber混合。如想支持BDD框架，建议使用Java自己的BDD框架，例如Jbehave。

4.4 Espresso

https://google.github.io/android-testing-support-library/docs/espresso/index.html

Espresso是Google的开源自动化测试框架。相对于Robotium和UIAutomator，它的特点是规模更小、更简洁、API更加精确、编写测试代码简单、容易快速上手。因为是基于Instrumentation的，所以不能跨App。

4.5 Calabash

https://github.com/calabash

Calabash是一个适用于iOS和Android开发者的跨平台app测试框架，可用来测试屏幕截图、手势和实际功能代码。Calabash开源免费并支持Cucumber语言，Cucumber能让你用自然的英语语言表述app的行为，实现BDD（Behavior Driven Development，行为驱动开发）。 Cucumber中的所有语句使用Ruby定义。

**优点： **有大型社区支持。列表项简单，类似英语表述的测试语句支持在屏幕上的所有动作，如滑动，缩放，旋转，敲击等。跨平台开发支持（同样的代码在Android和iOS设备中都适用）。

缺点：测试步骤失败后，将跳过所有的后续步骤，这可能会导致错过更严重的产品问题。测试耗费时间，因为它总是默认先安装app。需要Calabash框架安装在ios的ipa文件中，因此测试人员必须要有iOS的app源码。除了Ruby，对其他语言不友好。

4.6 Appium

Appium: Mobile App Automation Made Awesome.

4.7 Selendroid

GitBook - Where software teams break knowledge silos.

Selendroid 是一个基于Instrumentation的一个框架. 完全兼容Webdriver协议。 Selendroid 可以在模拟器和实际设备上使用，也可以集成网格节点作为缩放和并行测试。

4.8 Robolectric

Robolectric

Robolectric 是一款Android单元测试框架，但它并不依赖于Android提供的测试功能，它通过实现一套JVM能运行的Android代码，然后在unit test运行的时候去截取android相关的代码调用，然后转到Robolectric实现的代码（shadow objects）去执行这个调用的过程。因此它不像模拟器或设备需要dexing（Android dex编译器将类文件编译成Android设备上的Dalvik VM使用的格式）、打包、部署和运行的过程，大大减少了测试执行的时间。Pivotal实验室声称使用Robolectric可以在28秒内运行1047个测试。

除了实现Android里面的类的现有接口，Robolectric还给每个Shadow类额外增加了很多接口，可以读取对应的Android类的一些状态。比如它为ImageView提供了getImageResourceId()方法，测试者可以通过getImageResourceId()接口来确定是不是正确显示了期望的Image。

4.9 RoboSpock

http://robospock.org/

RoboSpock是一个开源的Android测试框架，它提供了简单的编写BDD行为驱动开发规范的方法，使用Groovy语言，支持Google Guice库。RoboSpock合并了Robolectic和Spock的功能。

4.10 Cafe

项目管理iCafe_项目进度管理-百度智能云

Cafe是百度出品的一个基于Robotium的测试框架，它提供了跨进程的测试解决方案。

4.11 Athrun

http://code.taobao.org/p/athrun/wiki/index/

Athrun 是taobao出的一个移动测试框架，它支持Android和IOS。Android部分是基于Instrumentation，在Android原有的ActivityInstrumentationTestCase2类基础上进行了扩展，提供了一整套面向对象的API。 IOS上的自动化测试包括注入式自动化框架AppFramework，和基于录制的自动化框架Athrun_IOS, InstrumentDriver。

4.12 其他

其他自动化框架还有应用于稳定性测试的Monkey系列（Monkey, Monkeyrunner, MonkeyTalk）, 其中MonkeyTalk 支持iOS 和 Android，它可以为应用进行真实的，功能性交互测试。MonkeyTalk 提供简单的 “smoke tests”，复杂数据驱动的测试套件。MonkeyTalk 支持原生，移动和混合应用，真实设备或者模拟器。MonkeyTalk 使得场景捕获非常容易，可以记录高级别，可读的测试脚本。还有适用于浏览器自动测试的Selenium WebDriver，可以真实测试用户行为，用户交互如触摸、手指滚动、长按等，还支持HTML5的一些特性，比如本地存储、session存储、应用缓存等。而CTS则是应用于兼容性测试的自动化工具， CTS大部分是基于Junit和仪表盘技术编写的。还扩展了自动化测试过程，可以自动执行用例，自动收集和汇总测试结果。CTS采用XML配置文件的方式将这些测试用例分组成多个测试计划（plan）,第三方也可以创建自己的plan。

总结:

各个测试框架的继承关系如下,继承关系决定了有些框架的先天优势或先天不足. 在实际应用中可以集成多个框架。

Android 自动化测试框架

基于Instrumentation的测试框架，比如Espresso，Robotium，Selendroid等，都不能支持跨APP使用。如自动化测试中有跨APP操作，可以结合UiAutomator实现。
支持BDD的自动化框架比较少，可以在calabash 和 RoboSpock及Jbehave之间选择。
若想同时支持Android和IOS，可选框架有Appium和Calabash，或AthRun。
若为单元测试选择框架，可选Instrumentation或Robolectric。Robolectric实现了shadow object 类，耗时短。