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/seleniumSelenium 是用于测试 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 IDESelenium IDE (集成开发环境) 是一个建立测试脚本的原型工具。它是一个 Firefox 插件,实现简单的浏览器操做的录制与回放功能,提供建立自动化测试的建议接口。Selenium IDE 有一个记录功能,能记录用户的操做,而且能选择多种语言把它们导出到一个可重用的脚本中用于后续执行。Selenium RCSelenium 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 GridSelenium Grid 使得 Selenium RC 解决方案能提高针对大型的测试套件或者哪些须要运行在多环境的测试套件的处理能力。Selenium Grid 能让你并行的运行你的测试,也就是说,不一样的测试能够同时跑在不一样的远程机器上。这样作有两个有事,首先,若是你有一个大型的测试套件,或者一个跑的很慢的测试套件,你可使用 Selenium Grid 将你的测试套件划分红几份同时在几个不一样的机器上运行,这样能显著的提高它的性能。同时,若是你必须在多环境中运行你的测试套件,你能够得到多个远程机器的支持,它们将同时运行你的测试套件。在每种状况下,Selenium Grid 都能经过并行处理显著地缩短你的测试套件的处理时间。Selenium WebDriverWebDriver 是 Selenium 2 主推的工具,事实上WebDriver是Selenium RC的替代品,由于Selenium须要保留向下兼容性的缘由,在 Selenium 2 中, Selenium RC才没有被完全的抛弃,若是使用Selenium开发一个新的自动化测试项目,那么咱们强烈推荐使用Selenium2 的 WebDriver进行编码。另外, 在Selenium 3 中,Selenium RC 被移除了。 |