自动化测试概论（四）

续接“自动化测试概论（一）”、“自动化测试概论（二）”、“自动化测试概论（三）”，今天捡一些比较典型的工具型自动化框架来介绍，主要围绕历史、特点和原理来讲解，至于使用教程，网络上已经有很多资料，这里就不加以展开。

09. Quick Test Professional

如果时光倒流二十年，QTP 在自动化领域绝对是王者一般的存在。它诞生于 03 年，由 Mercury Interactive 发布，前身是 Astra Quick Test，和同出一门的 LR（LoadRunner）并称当时测试工具界的倚天剑和屠龙刀。08 年卖给了惠普，17 年又卖给了 MicroFocus，现在的名字叫 UFT（Unified Functional Testing）。

Mercury 早在 95 年还做过另一款自动化工具叫 WinRunner，使用比较流行的录制回放模式，曾经也是风靡一时。但它的生命周期却不算很长，数年之后即被同门兄弟 QTP 超越，渐渐退出历史舞台。

之所以说 QTP 是一个标杆性的产品，是因为它在很多方面提供了较为先进的方法，对后来的其他自动化工具产生了很强的影响，特别是关键字驱动测试，至今仍然是自动化测试领域的一个重要设计方式。

QTP 使用 VB 做为脚本语言，学习成本比较低。通过加装各种插件，可以支持多平台的自动化测试，可以实现对 Excel、XML 等常用文件的操作。这种时代适应性和易用性，可能是 Mercury 为什么在有 WinRunner 之后，还要开发 QTP 的原因。

但是随着开源风潮的到来，各种免费的自动化工具越来越成熟，QTP 的没落似乎也成为了一种必然。B/S 几乎已经是 Selenium 的天下，C/S 虽说还有它的一席之地，不过缺乏创新的 QTP，前景恐怕也是不容乐观。

10. Selenium

如果说 QTP 是最具代表性的商业自动化工具，那么 Selenium 无疑是最具代表性的开源自动化工具。Selenium 这个名字其实也在暗暗“致敬” QTP，因为 Mercury 的意思是汞，Selenium 的意思是硒，而硒是汞的解毒品。不得不说老外玩起梗来，也是很有内涵的。

Selenium 的出生比 QTP 略晚。04 年的时候，ThoughtsWorks 的程序员 Jason Huggins 出于对回归测试的需要，使用JavaScript 写了一个自动化测试工具叫 JavascriptTestRunner。后来同事们用着感觉都不错，就正式改名为 Selenium Core 并开源。

由于浏览器的同源策略，当时 Selenium Core 还存在着诸多问题。所谓的同源策略，是浏览器本身的一个“规则”，粗略地说就是其他来源的 JS 脚本，不能对主站文档进行操作。因此早期的 Selenium Core，很难被大范围地应用，为了解决这个问题，又有一位程序员发展出了 Selenium RC。

RC（Remote Contol）的思路是：即然同源策略无法改变，那想办法变成“同源”就行了。网上的架构图画得比较复杂，我们可以这么简单理解：RC 做为一个中间代理，向目标发起请求，获得页面内容后，注入 Selenium Core，再一起返回给调用方。这样对于调用方而言，就拥有一个附带“同源”脚本的页面文档了。

再后来，随着 Selenium 群体的不断壮大，Selenium IDE 和 Selenium Grid 也先后加入进来，弥补了录制回放能力和分布式测试方面的空白。Selenium RC + Selenium IDE + Selenium Grid 这一整套东西，就是 Selenium 1.0。

代理的方式虽说可行，但整个过程实在复杂，稳定性和速度都不是很理想。好在 WebDriver 的加入，大大简化了这个过程。由 Selenium 主持的 WebDriver Wire Protocal，提供了一套客户端和浏览器的通信标准，各个浏览器基于协议分别实现自己的 API，比如 ChromeDriver，FirefoxDriver 等。由于它们是官方提供的接口，自然就没有同源策略的问题。

但是正如 JS 和 CSS 标准一样，WebDriver 无线协议也只是字面规范，实际上各个浏览器的 Driver 实现，多少会存在一些差异。所以 Selenium 在其中也承担了一定的“兼容”角色，尽可能（有些还做不到）地隐藏这样差异，并向用户提供统一的调用方式。Selenium 1.0 + WebDriver，就是 Selenium 2.0。

有了 WebDriver 之后，Selenium 也不再需要通过代理的方式进行调用，但出于对历史兼容的需要，2.0 并没有抛弃 RC，直到 3.0 才彻底移除。所以 Selenium 2.0 – RC + 一些优化，就是 Selenium 3.0。

现如今，Selenium 也迎来了 4.0 的时代，在标准化、IDE、Grid 等多个方面都有新的变化。Selenium 当下仍然保持着强大的生命力和社区群体，在可预见的未来内，它还会是较为主流的自动化工具框架之一。

11. Appium

Appium 是 Selenium 的好兄弟，一个是移动端自动化测试的利器，一个是网页端自动化测试的利器。肯定会有人好奇它们的关系到底是什么，为何都叫 xxium，又为何都支持 WebDriver。接下来就讲讲这个神奇的故事。

这次的主人公是 Dan Cuellar，11 年加入 Zoosk 做 Test Manager，在职期间研究了 iOS 的自动化测试，因不满足于 Apple 自带的 UIAutomation 方案，自行研发了一款自动化工具叫 iOSAuto。iOSAuto 使用 C# 编写测试代码，语法风格上大量借鉴 Selenium，它就是 Appium 的前身。

12 年的时候，Dan 参加了 Selenium 大会，对外展示了这款 iOSAuto 工具，引起了参会者的兴趣，并建议他晚些时候再进行一次演讲，以便具体解释这款工具的运作方式。意外的是，Dan 第二天的演讲遇到了技术故障，只讲了五分钟就结束了，因此 iOSAuto 在当时并没能引起较大的反响。

然而在 4 个月之后，Jason（就是最早做 Selenium 的那哥们，大会主持人）找到了 Dan，原来他在 Sauce Labs 为客户提供 iOS 测试支持，想起了 Dan 演讲过的 iOSAuto。两人在酒吧里见面，Dan 展示了 iOSAuto 的源码，Jason 鼓励 Dan 将代码开源，并修改语言以便吸引更多的潜在贡献者。

同年 9 月，Dan 上传了基于 Python 的新版本，而 Jason 通过 HTTP 实现了 WebDriver Wire Protocal，使得 iOSAuto 可以直接使用 Selenium WebDriver。Jason 认为它应该在 11 月的移动测试峰会上展示，但要先确定一个新名字。两人讨论之后决定命名为 Appium（Application + Selenium，即 APP 版的 Selenium）。

13 年 1 月，Sauce Labs 决定全力支持 Appium，团队认为 Appium 需要一次重构，最终选择了 Node.js 做为框架。新版本的 Appium 在 13 年的 Google 测试大会上首次亮相，后来又发布了 Android 和 Selendroid 支持，直到 14 年正式发布 Appium 1.0。

与 Selenium 一样，Appium 也要解决目标操作权限的问题。它采用的办法是向终端安装一个本地执行器，在 Android 上叫 bootstrap.jar，在 iOS 上叫 bootstrap.js，它们分别与 UIAutomator(2) 以及 UIAutomation 进行通信，以实现对终端设备的操作。

我们可以近似等价地理解为：UIAutomator/UIAutomation = WebDriver，但由于移动端的特殊性，Appium 天生就只能以 Server/Client 的模式来运行，这和 Selenium 的情况有所不同。Selenium 在只需要进行本地浏览器测试的时候，可以没有 Selenium Server，从这方面来看，Appium 似乎比 Selenium 更加“云原生”。

Appium 在 21 年发布了它的 2.0 版本，最核心的改变是将 Appium 视为一个生态系统而非单一的项目，允许更多开发者自行研发驱动和插件。同时 Appium 也是 OPENJS 基金会的重要项目，这种开放性的特点，也许是 Appium 为什么具有如此旺盛生命力的原因。

12. 未来的工具型框架

由于篇幅的关系，其他工具型自动化框架就不多介绍了。现有的测试方案大多依托于本地工具和团队内部的二次开发，但在不久的未来，我相信“上云”必然是工具型框架要走的道路。

原因有这么几点：首先，云服务在国内已经很成熟，基础条件上已经具备这样的可能性；其次，云能够提供成本更低的解决方案，比如设备成本、管理成本、人员成本；再者，云在专项领域，能够为中小企业设计更加专业的服务，比如专项性能测试、安全测试等。

还有一个重要的原因是，随着智能化时代的到来，测试智能化所需的专业能力和机器算力，已经不是一般企业能够负担得了的，所以 AI 的普及会进一步加速这个时间节点的到来。不得不说，时代的变迁，实在是令人感叹。