持续集成实践之自动化测试

2014-11-18

Table of Content:

软件测试

软件测试大概这么分类:

黑盒测试 VS 白盒测试，以及介于黑盒白盒之间的灰盒测试
按测试粒度可分为: unit test, functional test, integration test, system test, acceptance test 等
按测试目的可分为: sanity test(smoke test), build verification test(BVT), regression test, stress test, performance test, usability test, security test, ad hoc test 等
按是否自动化可分为: manual test VS automated test (简称TA)

BVT, regression test, performance test等都应该是automated test, 否则测试效率会很低.

在TA成本可接受的情况下，应该尽可能将测试都做成automated test, 除非某些测试需要人来校验(界面是否美观,音视频质量是否可接受等).

自动化测试

自动化测试就是用程序测试程序。项目需要快速迭代快速交付，或手工测试无法完成（譬如性能测试）时，就需要考虑自动化测试，自动化测试可以简单分为：

UI driven testing - 模拟鼠标键盘事件来验证程序行为，或者录制回放(UI通常变化较快，录制脚本不容易维护，因此不推荐)
Code driven testing
- Unit Test - 利用xUnit框架测试类方法，模块接口，库接口的输入输出来验证程序行为
- API driven testing - 程序常常分层设计，可以测试每一层的API interface来验证程序行为

记住，自动化测试是为了提高效率，测试脚本要易维护，不能让测试脚本变成另一种技术债务，不能为了自动化测试而自动化测试。

自动化测试框架

正如有各种各样的开发框架，自动化测试也有各种各样的框架，这些框架可以帮助我们更快速的实现自动化测试，更方便的写测试脚本，让我们更专注于项目逻辑和测试本身，自动化测试框架非常多，有的开源，有的收费，开源测试框架基本能满足我们的大多数需要，因此我们将主要推荐开源测试框架。

如何选择测试框架？不同框架适用不同测试目的，支持不同平台，支持不同语言等，想明白这几个问题就很容易找到适合自己的框架了。

Unit test, UI driven test, performance test这三种类型是比较常见的自动化测试类型，相应的自动化测试框架也多一些。

下面列出一些比较常见的框架，后面会详细介绍一些框架。

STAF/STAX - Software Test Automation Framework (STAF) 是由IBM开发的开源、跨平台、支持多语言的自动化测试框架
Robot Framework
- 由Nokia Networks提供的跨平台、支持Python,Java等语言的开源测试框架，主要代码由Python实现，是一种keyworld driven的测试框架。可以通过XML-RPC插件实现跨机器的testing。Robot Framework + Selenium是比较常见的web UI的测试方案。
- STAF和Robot Framework都属于管理执行框架，本身不提供基础的自动化测试支持，一般会集成一个其他自动化测试框架，譬如robot可以集成selenium，http://wiki.opensfs.org/Automation_framework_evaluation有STAF vs Robot Framework的比较.
TestNG - Java功能测试一般使用这个框架
JMeter - Java性能测试一般使用这个框架
UI testing framework:
- QTP(收费) - HP QuickTest Professional
- calabash-android, calabash-ios - 移动平台的测试框架
- Selenium/webdriver - web UI测试一般使用这个框架
- Robotium - android UI测试一般使用这个框架
- AutoIt - windows UI，基于windows控件消息
- UI Automation - 微软提供的测试框架，基于MSAA技术
LoadRunner(收费) - HP提供，用于性能测试

iOS/Android/OSX等平台都自带了测试自动化的支持，Visual Stadio和Xcode也包含自动化测试工具.

xDD

软件工程界流行各种xDD (x driven developmen)，下面介绍几个:

TDD - Test Driven Development

大概的流程是先针对每个功能点抽象出接口代码，然后编写单元测试代码，接下来实现接口，运行单元测试代码，循环此过程，直到整个单元测试都通过。

BDD - Behavior Driven Development

BDD基于TDD，使用Given/When/Then的句式描述一个个use case，描述更接近自然语言和容易理解，方便DEV/QA/PO/stakeholders等人员相互交流。Cucumber是目前流行的BDD框架，由Ruby实现。

其他的xDD还有IDD(Inteface Driven Development), DDD(Domain Driven Development), FDD(Feature Driven Development), MDD(Model Driven Development), ATDD(Acceptance Test-Driven Development)等。

个人认为，程序能做到Interface Driven Design就可以有效的实现模块间的解耦和方便测试代码的编写，IDD也是TDD的基础，因此开发代码时需要先做到IDD，再做到TDD，其他的xDD则未必需要。

单元测试框架 - xUnit/xMock

单元测试是最常见的测试类型，一般为xUnit框架，常用的Unit Test框架有:

Java - JUnit, TestNG, jMock
C++ - Google Test, Google Mock
JavaScript - QUnit, JSTestDriver
Python - py.test, nose
C# - NUnit

更多阅读:

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks －各种语言的单元测试框架列表
http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle - C++ unit test框架比较

STAF/STAX

Software Test Automation Framework (STAF) 是由IBM开发的开源、跨平台、支持多语言的自动化测试框架，主要代码由C++实现，支持Windows/Linux/Mac/Solaris等平台。

STAF封装了不同平台和不同语言间通信的复杂性，提供了消息、互斥、同步、日志等可复用的服务，使用户可以在此基础上方便快速地构建自动化测试解决方案。

STAFProc

STAF的核心是一个后台程序STAFProc，也叫STAF Daemon，举例，如果你想在你的本地linux机器上驱动实验室里的3台windows test machine和2台mac test machine，那么需要在这6台机器上都装上STAF，也就是说，这6台机器上都运行STAFProc程序，如下图:

STAFProc

从STAF的环境里，并没有客户端/服务器的区别，这6台机器都是平等的，从一个STAF端可以直接调用另一个STAF端提供的服务。

STAF Service

STAF是一个插件架构，这些插件就是Service，STAF的具体功能都是由各种service提供，STAFProc自带了一些service（称为内部service），也有很多外部service，用户还可以开发自己的service，外部Service可以用C++或Java开发，STAF可以加载DLL文件或JAR文件里的Service。

STAF Service

内部Service和STAFProc在一起，这表示内部Service是永远可用的，名字也是固定的，下面是几个常见的内部Service（非完整列表）：

DIAG - diagnostics, 用于调试
DELAY - 延迟等待一段时间
FS - file system, 用于文件操作
PING - 检查本地或远程服务是否可用
PROCESS - 可以启动、停止或者查询进程
SHUTDOWN - 用于shutdown STAFProc

外部service一般需要到STAF官网去下载服务组件包,一般服务组件包下完后还需要一些配置，下面是一些常用的外部服务：

STAX - 一个基于XML的执行引擎，在XML中定义测试工作流，可以实现并行执行、嵌套测试用例、控制运行时间等，STAX支持Java 和 Python 模块
CRON - 定义定时任务，使用Jenkins的话，也可以在Jenkins里定义定时任务
EMAIL - 发送邮件
HTTP - 发送HTTP请求
ZIP - 提供压缩与解压

STAF Requests

STAF实现了跨机器的通讯，用户程序通过发送请求来调用各个服务的功能，每个请求都以字符串的形式发送，这样可以保证 STAF 能够跨平台的运行。每个请求都有三个参数，以“系统-服务-参数”的形式出现，第一个参数表示此请求需要被发送到的哪个机器，第二个参数表示要调用哪个Service，第三个参数传给被调用的Service使用。举例，"STAF local ECHO hello"表示调用本机的ECHO Service，“STAF 1.2.3.4 PING PING”表示调用机器1.2.3.4上的PING服务。

STAF的通讯层基于CORBA，http://www.51testing.com/html/36/n-73836.html详细介绍了STAF的由来和设计细节。

Windows GUI测试 - MSAA与AutoIt

MSAA全称为Microsoft Active Accessibility，基于COM技术，核心接口是IAccessible，MSAA的下一代产品是UI Automation (UIA)，核心接口为IAccessibleEx和IRawElementProviderSimple，从 Windows7以来，微软在努力把它的accessibility technologies放进一个framework里面，称之为Windows Automation API。详情参考博客

Windows GUI的自动化测试一般都是基于MSAA技术，被测程序需要支持MSAA/UIA，实现对应的COM接口，然后测试程序就可以通过MSAA接口读取UI元素。

另一个测试windows UI的常用工具是AutoIt，AutoIt基于类似Spy++的窗口技术，可以识别标准的window控件，使用类似basic的自有语言来写test case，AutoIt不仅用于Windows GUI测试，也常用来开发windows平台工具软件来自动执行常见的任务，还常用来开发计算机游戏机器人，用来自动执行游戏中的任务等。

Web UI测试 - Selenium WebDriver

Selenium是由ThoughtWorks公司开发的开源的web自动化测试工具，用于自动化浏览器。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持所有主流浏览器，也支持多种语言来编写测试代码，是应用最广泛的web程序自动化测试工具.

Selenium 2.0（又名 Selenium WebDriver）的主要新功能是集成了 WebDriver。WebDriver 曾经是 Selenium 1（又名 Selenium Remote Control, 简写为Selenium RC）的竞争对手。Selenium RC 在浏览器中运行 JavaScript 应用，而 WebDriver 通过原生浏览器支持或者浏览器扩展直接控制浏览器。

Selenium 1.0 + WebDriver = Selenium 2.0

Selenium 1 是一款流行和完善的测试框架，支持众多浏览器（因其 JavaScript 实现），允许用户通过许多编程语言（从 Java/C# 到 PHP、Erlang...）编写测试脚本，而 WebDriver 则弥补了 Selenium 1 的缺点，跳出了 JavaScript 的沙箱，提供快速、轻量级的浏览器模拟器。之所以合并，原因如下：

WebDriver 解决了 Selenium 存在的缺点（比如，绕过 JS 沙箱）
Selenium 解决了 WebDriver 存在的问题（例如支持广泛的浏览器）

WebDriver 针对各个浏览器而开发，使用各个浏览器提供的native support操纵浏览器，取代了 Selenium RC 中嵌入到被测 Web 应用中的 JavaScript，与浏览器的紧密集成可以支持创建更高级的测试，且避免了 JavaScript 安全模型导致的限制。除了来自浏览器厂商的支持，WebDriver 还利用操作系统级的调用模拟用户输入。

WebDriver 支持 Firefox (FirefoxDriver)、IE (InternetExplorerDriver)、Opera (OperaDriver) 和 Chrome (ChromeDriver)。它还支持 Android (AndroidDriver) 和 iPhone (IPhoneDriver) 的移动应用测试。此外，还包括一个基于 HtmlUnit 的无界面实现，即 HtmlUnitDriver。WebDriver API 可以通过 Python、Ruby、Java 和 C# 访问，支持开发人员使用他们偏爱的编程语言来创建测试。

Selenium 2.0包含如下几个工具:

Selenium IDE - 一个Firefox插件，录制回放用户的基本操作，生成测试用例
Selenium WebDriver - 前身为Selenium RC, 包括一组browser driver和不同语言对应的language bindings, 支持多种平台(Windows，Linux，Mac等)和多种浏览器(IE，Firefox，Opera，Safari，Chrome等)，可以用多种语言(Java，Ruby，Python，Perl，PHP，C#等)编写测试用例
Selenium Server - 单机运行测试脚本时无需这个工具，使用Selenium Grid分发到远程机器上运行Webdriver测试脚本时需要

假设在Mac机器上用Java写测试脚本在Chrome里测试，配置Selenium开发环境可能需要如下几个工具:

Selenium Chrome Driver, 用于驱动Chrome浏览器
Selenium Client Drivers - Java, 用于支持Java测试脚本
Selenium Server, 用于远程机器测试，单机时不需要

另一个简单的方法是使用Maven来配置Java环境的Selenium开发环境，参考官网可以了解更多配置文档.

更多阅读:

http://www.ibm.com/developerworks/cn/web/1306_chenlei_webdriver
http://www.cnblogs.com/nbkhic/tag/webdriver/ - 乙醇的blog
https://github.com/easonhan007/webdriver_guide/blob/master/README.md - WebDriver使用指南
http://watirwebdriver.com - Watir WebDriver, in Ruby
http://www.17test.info - Watir WebDriver中文站, by 乙醇

Android测试 - Robotium

Robotium用于Android平台上进行黑盒自动化测试，作用类似于web平台的selenium，提供了模拟各种手势操作（点击、长按、滑动等）、查找和断言机制的API，能够对各种控件进行操作，适用于测试android native app and hybrid app。

Robotium是 android 自带类 Instrumentation 的一个封装，方便测试人员直接调用封装好的接口，也就是说，实际上我们直接使用Instrumentation 也能够进行自动化测试，但robotium可以简化我们的测试步骤，我们只需要调用某个robotium的API，传几个参数，就等于我们在调用一部分的Instrumentation帮我们实现测试。

Java代码测试 - TestNG

TestNG是类似JUnit/NUnit的测试工具，能够实现unit test, functional test, end-to-end test, integration test等各种测试.

TestNG和JUnit是针对Java语言的两个比较常用的测试框架，两者的相同点：

使用annotation，且大部分annotation相同。
都可以进行单元测试（Unit test）。
都是针对Java测试的工具。

TestNG与JUnit的不同点：

JUnit只能进行单元测试，TestNG可以进行单元测试，功能测试，端到端测试，集成测试等
TestNG需要一个额外的xml配置文件，配置测试的class、method甚至package
TestNG的运行方式更加灵活：命令行、ant和IDE，JUnit只能使用IDE
TestNG的annotation更加丰富，比如@ExpectedExceptions、@DataProvider等

其他工具

自动化测试一般是持续集成的一部分，为了做好持续集成，通常会需要：

Jenkins － CI工具

test case fail时，可能会需要自动创建bug跟踪，因此可能需要集成下面的bug管理工具:

Jira/Bugzilla - Bug管理工具

为了提高代码质量，可能会用到下面一些工具:

代码静态扫描 -
内存泄漏分析 - valgrind on linux, appverifier on windows
性能分析

为了验证测试coverage，可能需要用到code coverage tool:

gcov, c++, gcc only
BullseyeCoverage, c++
Rational PureCoverage, c++
EMMA, java
ScriptCover, javascript
JSCoverage, javascript

更多阅读:

http://mysuperbaby.iteye.com/blog/1393781 - jenkins入门
http://blog.csdn.net/windone0109/article/details/15814653 - c++ code coverage tools
http://www.csdn.net/article/2010-09-09/279253 - 代码覆盖率：80%，不能少