| 1. 使用测试工具 《论语》有云：工欲善其事，必先利其器。在开始具体的自动化测试之前，我们需要做好更多的准备，包括以下几个方面： 认识自动化测试 准备自动化测试工具 使用有效的方式 针对具体的测试对象 接下来的第一部分内容，我们将会从上述的几个方面进行探讨。 1.1 自动化测试理论介绍 自动化测试的5W 正如开篇所提到的，自动化测试不再是一个陌生的话题，而是一个具体的存在。作为测试实践活动的一部分，我们首先分析一下自动化测试的方方面面。 WHAT, 什么是自动化测试 G.J.Myers在其经典的著作《软件测试艺术》（The Art of Software Testing）一书中，给出了测试的定义： “程序测试是为了发现错误而执行的过程。” 这个概念产生于30年前，对软件测试的认识还非常有局限性，当然也是因为受瀑布开发模型的影响，认为软件测试是编程之后的一个阶段。只有等待代码开发出来以后，通过执行程序，像用户那样操作软件去发现问题。 自动化测试：以人为驱动的测试行为转化为机器执行的一种过程 自动化测试，就是把手工进行的测试过程，转变成机器自动执行的测试过程。该过程，依旧是为了发现错误而执行。因此自动化测试的关键在于“自动化”三个字。自动化测试的内容，也就相应的转变成如何“自动化”去实现原本手工进行的测试的过程。 所有的“自动化”，依靠的无疑都是程序。 通过程序，可以把手工测试，转变成自动化测试。 WHEN, 在什么时候开展自动化测试 自动化测试的开展，依赖于“程序”。那么程序，其实就是由“源代码”构建而来的。那么原则上，只要能做出自动化测试所需要的“程序”的时候，变可以进行自动化测试。但往往，并不是所有的“时候”都是好的“时机”。从这个W开始，我们将会加入对于成本的顾虑，也正是因为“成本”的存在，才使得下面的讨论，变得有意义。 所有的开销，都是有成本的。构建成“程序”的源代码，也是由工程师写出来的。那么需要考虑这个过程中的成本。基于这个考虑，在能够比较稳定的构建“程序”的时候，不需要花费太多开销在“源代码”的时候，就是开展自动化测试的好时机。这个开销包括编写和修改源代码，而源代码指的是构建出用来做自动化测试的程序的源代码。 WHERE, 在什么地方进行自动化测试 自动化测试的执行，依靠的是机器。那么自动化测试必将在“机器”上进行。一般来说，这个机器包括桌面电脑和服务器。通过将写好的源代码部署在机器上，构建出用来做自动化测试的"程序"，并且运行该程序，实现自动化测试。 WHICH, 对什么目标进行自动化测试 自动化测试的目标，是被测试的软件。抛开人工智能的成分，手工测试必将在“人工智能”足够普及和足够“智能”之前，替代一大部分不需要“人类智能”的手工测试；以及自动化测试会做一些手工测试无法实施的，或者手工测试无法覆盖的测试。 不需要“人类智能”的普通手工测试 界面的普通操作 通过固定输入和固定操作而进行的流程化测试 重复的普通测试 手工测试无法实施或者覆盖的 大量的数据的输入 大量的步骤的操作 源代码基本的测试 系统模块间接口的调用测试 HOW, 如何开展自动化测试 准备测试用例 找到合适的自动化测试工具 用准确的编程形成测试脚本 在测试脚本中对目标进行“检查”，即做断言 记录测试日志，生成测试结果 和所有的其他测试一样，自动化测试的流程也是由“用例”执行和“缺陷”验证组成。差别是需要找到合适的“工具”来替代“人手”。不同目标的自动化测试有不同的测试工具，但是任何工具都无不例外的需要“编程”的过程，实现“源代码”，也可以称之为测试脚本。于是开展自动化测试的方式基本上如下： 自动化测试的典型金字塔原理 谈到自动化测试，就不得不提的一个人和概念就是：Martin Fowler和他的金字塔原理 自动化测试包括三个方面：UI前端界面，Service服务契约和Unit底层单元 越是底层的测试，运行速度越快，时间开销越少，金钱开销越少 越是顶层的测试，运行速度越慢，时间开销越多，金钱开销越多 这是理想中的金字塔原理。 在实际的项目中，尤其是结合国内的项目实践，其实还隐藏了另一个问题：越是顶层的测试，效果越明显。有句话说“贵的东西，除了贵，其他都是好的！”能够很清晰的阐述这个观点。 金字塔原理在国内的适应性也有一定的问题 自动化测试的起步不是特别早 甚至软件测试很长一段时间都在进行基于业务的手工测试，测试人员的代码能力相对较弱 开发人员在代码中不太习惯写单元测试 近些年基于服务契约的API测试也在兴起 相对来说，在基于UI前端界面的自动化测试反倒是开展和实施的不是特别多。尽管基于界面的测试带来的效果还是能够立竿见影的。对于产品的质量提升，还是比较容易有保证。 自动化测试的适用范围 自动化测试可以涉及和试用的范围主要在以下方面： 基于Web UI的浏览器应用的界面测试 基于WebService或者WebAPI的服务契约测试 基于WCF、.net remoting、Spring等框架的服务的集成测试 基于APP UI的移动应用界面测试 基于Java、C#等编程文件进行的单元测试 本文集中讨论第一条：基于Web UI的浏览器应用的界面测试。界面的改动对于测试来说，具有较大的成本风险。主要考虑以下方面： 任务测试明确，不会频繁变动 每日构建后的测试验证 比较频繁的回归测试 软件系统界面稳定，变动少 需要在多平台上运行的相同测试案例、组合遍历型的测试、大量的重复任务 软件维护周期长 项目进度压力不太大 被测软件系统开发比较规范，能够保证系统的可测试性 具备大量的自动化测试平台 测试人员具备较强的编程能力 自动化测试的流程 自动化测试和普通的手工测试遵循的测试流程，与项目的具体实践相关。一般来说，也是需要从测试计划开始涉及自动化测试的。 测试计划：划定自动化测试的范围包含哪些需求，涉及到哪些测试过程 测试策略：确定自动化测试的工具、编程方案、代码管理、测试重点 测试设计：使用测试设计方法对被测试的需求进行设计，得出测试的测试点、用例思维导图等 测试实施：根据测试设计进行用例编写，并且将测试用例用编程的方式实现测试脚本 测试执行：执行测试用例，运行测试脚本，生成测试结果 1.2 自动化测试工具 基于Web UI的自动化测试工具主要有两大类：付费的商业版工具和免费使用的开源版工具。典型的有两种： UFT，QTP被惠普收购以后的新名称。 通过程序的录制，可以实现测试的编辑 录制的测试脚本是 VBScript 语法 成熟版的商业付费工具 工具比较庞大，对具体的项目定制测试有难度 SELENIUM，本次选择的开源工具 本身不是测试工具，只是模拟浏览器操作的工具 背后有 Google 维护源代码 支持全部主流的浏览器 支持主流的编程语言，包括：Java、Python、C#、PHP、Ruby、JavaScript等 工具很小，可以实现对测试项目的定制测试方案 基于标准的 WebDriver 语法规范 1.2.1 Selenium 基本介绍 Selenium`是开源的自动化测试工具，它主要是用于Web 应用程序的自动化测试，不只局限于此，同时支持所有基于web 的管理任务自动化。 Selenium官网的介绍 Selenium is a suite of tools to automate web browsers across many platforms. runs in many browsers and operating systems can be controlled by many programming languages and testing frameworks. Selenium 官网：http://seleniumhq.org/ Selenium Github 主页：https://github.com/SeleniumHQ/selenium Selenium 是用于测试 Web 应用程序用户界面 (UI) 的常用框架。它是一款用于运行端到端功能测试的超强工具。您可以使用多个编程语言编写测试，并且 Selenium 能够在一个或多个浏览器中执行这些测试。 Selenium 经历了三个版本：Selenium 1，Selenium 2 和 Selenium 3。Selenium 也不是简单一个工具，而是由几个工具组成，每个工具都有其特点和应用场景。 Selenium 诞生于 2004 年，当在 ThoughtWorks 工作的 Jason Huggins 在测试一个内部应用时。作为一个聪明的家伙，他意识到相对于每次改动都需要手工进行测试，他的时间应该用得更有价值。他开发了一个可以驱动页面进行交互的 Javascript 库，能让多浏览器自动返回测试结果。那个库最终变成了 Selenium 的核心，它是 Selenium RC（远程控制）和 Selenium IDE 所有功能的基础。Selenium RC 是开拓性的，因为没有其他产品能让你使用自己喜欢的语言来控制浏览器。这就是 Selenium 1。 然而，由于它使用了基于 Javascript 的自动化引擎，而浏览器对 Javascript 又有很多安全限制，有些事情就难以实现。更糟糕的是，网站应用正变得越来越强大，它们使用了新浏览器提供的各种特性，都使得这些限制让人痛苦不堪。 在 2006 年，一名 Google 的工程师， Simon Stewart 开始基于这个项目进行开发，这个项目被命名为 WebDriver。此时，Google 早已是 Selenium 的重度用户，但是测试工程师们不得不绕过它的限制进行工具。Simon 需要一款能通过浏览器和操作系统的本地方法直接和浏览器进行通话的测试工具，来解决Javascript 环境沙箱的问题。WebDriver 项目的目标就是要解决 Selenium 的痛点。 到了 2008 年，Selenium 和 WebDriver 两个项目合并。Selenium 有着丰富的社区和商业支持，但 WebDriver 显然代表着未来的趋势。两者的合并为所有用户提供了一组通用功能，并且借鉴了一些测试自动化领域最闪光的思想。这就是 Selenium 2。 2016 年，Selenium 3 诞生。移除了不再使用的 Selenium 1 中的 Selenium RC，并且官方重写了所有的浏览器驱动。 Selenium 工具集 Selenium IDE Selenium IDE (集成开发环境) 是一个创建测试脚本的原型工具。它是一个 Firefox 插件，实现简单的浏览器操作的录制与回放功能，提供创建自动化测试的建议接口。Selenium IDE 有一个记录功能，能记录用户的操作，并且能选择多种语言把它们导出到一个可重用的脚本中用于后续执行。 Selenium RC Selenium RC 是selenium 家族的核心工具，Selenium RC 支持多种不同的语言编写自动化测试脚本，通过selenium RC 的服务器作为代理服务器去访问应用从而达到测试的目的。 selenium RC 使用分Client Libraries 和Selenium Server。 Client Libraries 库主要主要用于编写测试脚本，用来控制selenium Server 的库。 Selenium Server 负责控制浏览器行为，总的来说，Selenium Server 主要包括3 个部分：Launcher、Http Proxy、Core。 Selenium Grid Selenium Grid 使得 Selenium RC 解决方案能提升针对大型的测试套件或者哪些需要运行在多环境的测试套件的处理能力。Selenium Grid 能让你并行的运行你的测试，也就是说，不同的测试可以同时跑在不同的远程机器上。这样做有两个有事，首先，如果你有一个大型的测试套件，或者一个跑的很慢的测试套件，你可以使用 Selenium Grid 将你的测试套件划分成几份同时在几个不同的机器上运行，这样能显著的提升它的性能。同时，如果你必须在多环境中运行你的测试套件，你可以获得多个远程机器的支持，它们将同时运行你的测试套件。在每种情况下，Selenium Grid 都能通过并行处理显著地缩短你的测试套件的处理时间。 Selenium WebDriver WebDriver 是 Selenium 2 主推的工具，事实上WebDriver是Selenium RC的替代品，因为Selenium需要保留向下兼容性的原因，在 Selenium 2 中， Selenium RC才没有被彻底的抛弃，如果使用Selenium开发一个新的自动化测试项目，那么我们强烈推荐使用Selenium2 的 WebDriver进行编码。另外， 在Selenium 3 中，Selenium RC 被移除了。 |