作者：吴晓华,俞美玲
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Selenium WebDriver 3 实战宝典(Java版)试读：
前言
随着互联网的高速发展，中国的互联网繁荣程度达到了一个空前的发达水平，数亿量级用户的产品登上了中国的互联网发展舞台，阿里巴巴、腾讯、百度等多个互联网巨头也开始在世界的互联网舞台上崭露头角，互联网行业的从业人员也达到了上百万人的规模，中国的互联网产品已经深入网民生活的方方面面。
互联网行业在中国的迅猛发展，对中国的软件开发和测试行业也提出了更高的技术要求与质量要求，软件测试从业者的技术水平也被提升到空前且不绝后的高要求阶段。以往我们看到，测试人员的招聘重点都是对于测试用例设计和业务的理解，现今我们看到，更多的测试职位对测试人员提出了更高的技术能力要求，例如，精通一门编程语言，熟悉MySQL或者Oracle数据库，精通自动化测试和性能测试等。为了更好地适应互联网社会的发展潮流，软件测试从业者只有在技术能力上不断地提升自己，才能真正站在职业发展的巅峰。
自动化测试技术对测试人员来说是一个必要的高级技能要求，越来越多的测试从业者并不甘于仅仅使用手工方式进行测试，他们非常希望使用自动化的方式来减少枯燥无味且不断重复的手工测试劳动。目前，主流的Web自动化测试开源工具Selenium WebDriver成为众多软件测试从业者学习的热点，但是市面上针对Selenium自动化测试的书籍很少，基于实践来讲解Selenium应用技术的书籍更是凤毛麟角。因此，笔者个人非常希望能够写出一本基于实践操作的Selenium教学书籍，来解决软件测试人员的自动化测试学习问题。
本书采用图文并茂的方式分步骤讲解Selenium的各种实用技巧，并且提供被测试对象的实现代码或者被测试对象的访问网址，方便读者在本地搭建自己的测试环境或者访问互联网上的网站，从而进行自动化测试的实践。
这是我第一次写一本技术方面的书籍，当我真正开始提笔的时候，深深感觉到用简洁的语言讲明白工具的使用方法和测试程序代码绝非易事，为此我投入了大量的精力来不断组织、优化书中的文字和图片，希望能够让读者通过本书深入掌握Selenium的使用技巧，在自动化测试上助大家一臂之力。
由于我平时还要忙于其他工作，只能利用业余时间来编写此书，所以足足耗时8个月之久才完成此书，共写了30多万字，希望能够获得读者的欢迎。非常感谢我的妻子和女儿，她们对我给予了巨大支持。我相信通过我的努力一定可以改变一些人的命运，所以和大家共勉，希望我们共同努力，改变中国测试行业技术含量低的现状。
各章内容介绍：
第一篇 基础篇：包括第1～8章。
第1章介绍了Selenium的发展历史及组成Selenium 的工具套件，列举了Selenium 1和Selenium 2支持的浏览器和平台，讲解了Selenium RC和 WebDriver的实现原理，同时介绍了Selenium 1、Selenium 2和Selenium 3的各自特点及区别。
第2章介绍了在日常测试工作中常见的自动化测试目标，讲解了如何获得公司管理层对开展自动化测试的支持，介绍了如何衡量自动化测试工作的投入产出比及在敏捷开发中的自动化测试应用，讲解了自动化测试工作的分工及测试工具的选择和推广使用，分享了实际项目的最佳实践经验，说明了学习Selenium工具的能力要求。
第3章主要讲解了与Selenium工具使用相关的辅助工具。
第4章主要讲解了Selenium IDE插件的安装、界面和基本的使用方法，并且讲解了使用实例和导出脚本的方法。
第5章主要讲解了如何搭建Java环境和Eclipse集成开发环境，并且介绍了Eclipse开发环境的最佳配置方法。
第6章主要讲解了WebDriver的安装和配置方法。
第7章主要讲解了单元测试的基本知识，并且结合JUnit和TestNG单元测试框架讲解了单元测试的实例。
第8章主要讲解了在自动化测试过程中使用的页面元素定位方法，包括ID定位方法、Name定位方法、链接定位方法、Class名称定位方法、XPath定位方法、CSS定位方法和jQuery定位方法，推荐将XPath定位方法作为页面元素定位的主要方法。
第二篇 实战应用篇：包括第9～11章。
第9章讲解了如何使用WebDriver工具分别操作IE浏览器、Firefox浏览器和Chrome浏览器进行自动化测试，介绍了TestNG工具的并发兼容性测试实例。
第10章通过实例全面讲解了WebDriver的常用API，共介绍了41个实例。
第11章讲解了WebDriver的20个高级应用实例。
第三篇 自动化测试框架搭建篇：包括第12～17章。
第12章讲解了数据驱动的概念，以及如何基于TestNG工具，使用CSV文件、Excel文件和MySQL数据库分别进行数据驱动测试。
第13章介绍了页面对象（Page Object）设计模式，通过使用类函数封装方式实现自动化测试框架的设计模式。
第14章介绍了基于Cucumber工具的行为驱动测试实例，分别基于中文测试用例文件和英文测试用例文件进行了实例讲解。
第15章介绍了如何基于Selenium Gird组件实现并发执行测试用例，并基于实例进行了深入讲解。
第16章深入讲解了如何从零开始，搭建数据驱动测试框架、关键字驱动测试框架和混合驱动测试框架，并提供了完整的框架实例代码。此章为本书最重要的章节，建议读者在阅读前面所有章节后再阅读此章节。
第17章以数据驱动框架为例，讲解了基于Maven的数据驱动测试框架的构建，提供了完整的框架实例代码。此章为实战的进阶内容，建议读者在阅读时，在本地计算机中进行实践搭建。
第四篇 常见问题和解决方法：包含第18章。
第18章讲解了在WebDriver使用过程中的常见问题和解决方法，读者可以在使用WebDrvier遇到问题时进行查阅。
特别致谢：
感谢我的好朋友王浩、李雄刚和部凯文帮忙校对本书中的所有实例和代码，从中发现了不少书写错误和代码问题，在此对他们表示真挚的感谢。吴晓华2019年4月第一篇 基础篇第1章 Selenium简介
Selenium工具诞生的时间已经超过了10年，目前在软件开发公司中得到了大规模的应用，但很少有人能够清晰地描述此工具的发展历史和特点，本章的内容能够让读者了解Selenium工具的“前世今生”及特点。1.1 Selenium的“前世今生”
2004年，在ThoughtWorks公司，一个名为Jason Huggins的测试同行为了减少手工测试的工作量，自己实现了一套基于JavaScript语言的代码库，使用这套代码库可以进行页面的交互操作，并且可以重复地在不同浏览器中进行各种测试操作。通过不断地改进和优化，这个代码库逐步发展成Selenium Core。Selenium Core为Selenium Remote Control（简称Selenium RC）和Selenium IDE提供了坚实的核心基础能力。
当时的自动化测试工具较少，已有的工具也无法灵活地支持各种复杂的测试操作，大部分测试人员只能使用手工的方式完成Web产品的测试工作。开发人员不断地开发代码，测试人员不断地发现bug，开发人员不断地修改bug，测试人员不断地进行回归测试来确认bug已经被修正，并且确认在程序中没有引入新的bug。这样的产品开发模式，导致测试人员必须经常性地手工回归测试系统的大部分功能，由此产生了大量的重复性手工操作。Jason Huggins想改变这样的现状，所以他开发了基于JavaScript语言的代码库，希望帮助测试人员从日常的重复性工作中解脱出来。经过其不懈努力，Selenium 1诞生了。
Web自动化测试工具Selenium是划时代的，因为其允许测试工程师使用多种开发语言来控制不同类型的浏览器，从而实现不同的测试目标。Selenium是开源工具软件，用户不需要付费就可以使用，甚至可以根据自己的使用需求来进行深入的定制化，改写其中的一些代码。基于以上优点，越来越多的测试人员开始使用此工具来进行Web自动化测试工作。在短短几年时间内，在世界范围内都有了Selenium工具的忠实拥护者，国内的几大互联网公司均使用Selenium作为Web自动化测试的主要工具。
但随着互联网技术的不断发展及浏览器对JavaScript语言的安全限制，Selenium的发展也遇到了瓶颈。由于其自身实现的机制，Selenium无法突破浏览器沙盒的限制，导致很多测试场景的测试需求难以满足。
2006年，Google的工程师Simon Stewart启动了WebDriver项目，此项目可以直接让测试工具调用浏览器和操作系统本身提供的内置方法，以此绕过JavaScript 环境的沙盒限制，WebDriver项目的目标就是解决Selenium的痛处。随着各厂商新版本浏览器的发布，原有的Selenium 1被越来越多的浏览器内部安全机制所限制，需要新版本的Selenium来解决这个问题。2008年，Selenium项目和WebDriver项目进行了合并，于是Selenium WebDriver 2（简称Selenium 2）出现了。
Selenium 2=Selenium 1+WebDriver
Selenium的官网地址是www.seleniumhq.org，网站提供了Selenium WebDriver的安装文件和使用教程。Selenium 2是Selenium 1的升级版本，它本身向下兼容Selenium 1的所有功能，同时又提供了更多的新API来满足自动化测试的各种复杂需求。
2016年10月，Selenium WebDriver 3（简称Selenium 3）诞生。开发者在Selenium 2的基础上做了很多了不起的工作，这个版本有很多新特性，主要实现了核心 API 与客户端Driver的分离，同时去掉了用得越来越少的Selenium RC的功能。3.0时代所有支持的浏览器均由浏览器官方提供支持，这意味着浏览器UI测试的速度和稳定性会有较大的提升。现阶段，Selenium 1 已经退出了历史舞台，大部分Web自动化测试人员已经完全转向使用Selenium 2或Selenium（WebDriver）来搭建自己的自动化测试框架。本书全部的案例均基于Windows 7操作系统上的Selenium 3进行讲解。1.2 Selenium工具套件介绍
● Selenium 3（Selenium WebDriver 3）：Selenium 3所有支持的浏览器均由浏览器官方提供支持，使得浏览器 Ui 测试的速度和稳定性得到了较大的提升。Selenium 3取消了对Selenium RC的支持，这意味着WebDriver协议已经成为业内公认的浏览器UI测试的标准。
● Selenium 2（Selenium WebDriver 2）：提供了极佳的特性，例如，面向对象API，提供Selenium 1的接口用于向下兼容等。
● Selenium 1（Selenium RC）：支持更多的浏览器，支持更多的编程语言（如Java、JavaScript、Ruby、PHP、Python、Perl和C＃）。
● Selenium IDE（集成开发环境）：Firefox插件，提供图形界面来录制和回放脚本，我们并不希望测试工程师使用此工具来运行大批量的测试脚本。此插件需要使用第三方的JavaScript代码库才能支持循环和条件判断。
● Selenium-Grid：可以在多个测试环境中以并发的方式执行测试脚本，进而实现测试脚本的并发执行，能够缩短大量测试脚本的执行时间。1.3 Selenium支持的浏览器和操作系统1.3.1 Selenium lDE和Selenium 1支持的浏览器和操作系统
Selenium IDE和Selenium 1支持的浏览器和操作系统如表1-1所示。表1-1续表注：Internet Explorer简称IE。1.3.2 Selenium 2和Selenium 3支持的浏览器
Selenium官网中并没有明确列出Selenium WebDriver支持的浏览器的所有版本号，仅列出了浏览器的名称。下面结合作者个人的实际使用情况，列出Selenium WebDriver支持的浏览器版本，请读者在测试实践中进行再次确认。
● Google Chrome
● IE 6、IE 7、IE 8、IE 9、IE 10、IE 11和IE Edge浏览器；
● Mac操作系统的Safari默认版本；
● Firefox的大部分版本；
● Opera;
● Android手机操作系统的默认浏览器；
● iOS手机操作系统的默认浏览器；
● 在不启动浏览器的情况下，使用PhantomJS运行自动化测试用例，并可以执行网页中的JS。
因为Firefox浏览器、Google Chrome浏览器和其他浏览器会持续更新，所以要想保证Selenium WebDriver的正常使用，就必须使用Selenium 3和最新版本的浏览器驱动程序。1.4 Selenium 1和WebDriver的实现原理
当执行Selenium自动化测试脚本时，测试人员可以看到浏览器中发生的神奇一幕：页面上会自动执行各种操作，如打开新窗口、在输入框中输入文字、选择下拉列表框等。为此，测试人员不禁要问一句：“这到底是怎么实现的?”为了了解Selenium工具的神奇之处，读者必须深入了解其实现原理和机制。1.4.1 Selenium 1的实现原理
Selenium 1的实现原理如图1-1所示。图1-1
Selenium 1的自动化测试执行步骤如下。
第一步：测试人员基于Selenium支持的编程语言编写测试脚本程序。
第二步：测试人员执行测试程序。
第三步：测试脚本程序发送访问网站的Http请求给Remote RC。
第四步：Remote RC收到请求后，访问被测试网站并获取网页数据内容，并在网页中插入Selenium Core的JavaScript代码库，然后返回给测试人员执行测试的浏览器。
第五步：测试脚本在浏览器内部再调用Selenium Core来执行测试代码，最后记录测试结果，完成测试。
参阅以上几个步骤，有人会疑惑，为什么要执行第四步?我们需要先学习一下浏览器的 JavaScript安全机制——同源策略。在浏览器访问某个网站后，会打开此网站的网页来获取内容。网页内容包含了要在网页中执行的JavaScript语句或外部引用的JavaScript文件，浏览器会执行属于此网站域名的JavaScript语句和文件。如果外部引用的JavaScript文件的URL和当前网页的域名不一致，那么浏览器会拒绝执行此JavaScript文件中的代码。通过此方式，浏览器就可以防止一些恶意的JavaScript文件被加载到用户的浏览器中，起到一定的安全防护作用。
Selenium 1工具的核心部分是基于JavaScript代码库实现的，这个库默认和被测试网站是分离的，也就是说，这个JavaScript库的URL和被测试网站的域名肯定是不一致的。参阅上面提到的浏览器同源策略，Selenium 1的JavaScript库是被禁止执行的，这样就无法实现对网站的自动化测试。为了应对浏览器的安全机制，Selenium 1使用了代理方法来解决此问题。如图1-2所示为Selenium 1代理模式的实现机制。
Selenium 1代理模式的实现机制具体如下。
第一步：执行测试脚本，向Selenium Server发起请求，要求和Selenium Server建立连接。
第二步：Selenium Server的Launcher启动浏览器，向浏览器中插入Selenium Core的JavaScript代码库，并把浏览器的代理设置为Selenium Server的Http Proxy。
第三步：测试脚本向Selenium Server发送Http请求，Selenium Server对请求进行解析，然后通过Http Proxy发送JS命令通知Selenium Core执行操作浏览器的动作。
第四步：Selenium Core在接收到指令后，执行测试脚本指定的网页操作命令。
第五步：浏览器收到新的页面请求信息（在第四步中，Selenium Core的操作可能引发新的页面请求），发送Http请求给Selenium Server的Http Proxy，请求新的Web页面。
第六步：由于 Selenium Server 在启动浏览器时设定了浏览器的代理访问地址为Selenium Server的Http Proxy，所以Selenium Server会接收到所有由它启动的浏览器发送的请求。Selenium Server在接收到浏览器发送的Http请求后，自己重组Http请求，获取对应的Web页面。
第七步：Selenium Server的Http Proxy把接收的Web页面返回浏览器。
通过以上步骤，我们实现了将Selenium Core的JavaScript代码库插入被测试网页的目的，然后就可以基于此代码库，在被测试网页中进行各种自动化测试操作了。此种方式是一种非常巧妙的“欺骗”，必须由衷地赞扬一下Selenium 1作者的智慧。图1-21.4.2 WebDriver的实现原理
WebDriver与Selenium 1的JavaScript插入方式不同，它直接利用浏览器的内部接口来操作浏览器。对于不同平台中的不同浏览器，必须依赖浏览器内部的Native Component（原生组件），将WebDriver API的调用转化为浏览器内部接口的调用。
Selenium 1采用JavaScript的合成事件来处理页面元素的操作，例如，要单击某个页面元素，要先使用JavaScript定位这个元素，然后触发单击事件。而WebDriver使用的是系统的内部接口或函数，找到这个元素的坐标位置，并在这个坐标点触发一个鼠标左键的单击操作。由此可以看出，WebDriver能更好地模拟真实的环境，但仅能测试那些可见的页面元素。也正因为如此，有些隐藏的页面元素可以使用Selenium 1进行操作，而WebDriver却无法实现。当WebDriver尝试单击时，就会产生“can not clickable”的错误提示信息。WebDriver的工作流程如图1-3所示，步骤说明以Firefox为例。图1-3
第一步：当客户端测试脚本启动Firefox时，Selenium WebDriver会首先在新线程中启动Firefox浏览器。如果在测试脚本中指定了Firefox的profile，那么就以此profile启动，否则，以新的profile启动Firefox；
第二步：Firefox一般以“-no-remote”的方法启动，启动后，Selenium WebDriver会将Firefox绑定到特定的端口，绑定完成后，此Firefox实例便作为WebDriver的Remote Server存在；
第三步：客户端（测试脚本）创建1个session，在该session中通过Http请求向Remote Server发送restful请求，Remoter Server通过驱动程序来解析请求，完成相应的操作并返回response；
第四步：客户端接收response，并分析其返回值以决定是转到第三步还是结束脚本。
以上就是WebDriver的工作流程，下面我们用一组实例来具体分析WebDriver和浏览器之间的信息交互。
步骤一：下载WebDriver的JAR文件。（1）访问Selenium官网下载地址（http://www.seleniumhq.org/download/），单击“3.10.0”进行下载，如图1-4所示。图1-4（2）在弹出的保存文件窗口中，单击“保存文件”按钮，如图1-5所示，下载selenium-server-standalone-3.10.0.jar文件，并保存在D盘中，如：“D:\”。图1-5
步骤二：进入文件所在目录，输入：java-jar selenium-server-standalone-3.10.0.jar，执行结果如图1-6所示。图1-6
步骤三：Selenium 3对Firefox浏览器的支持，要求必须下载驱动文件，下载路径为https://github.com/mozilla/geckodriver/releases，界面如图1-7所示。在弹出的保存文件窗口中，单击“保存”按钮，如图1-8所示，将geckodriver-v0.19.1-win64.zip文件保存在D盘中。图1-7图1-8
步骤四：编写测试代码，新建TestFirefox.java类，代码如下。
步骤五：在运行上述代码后，控制台会出现详细的打印信息，如图1-9所示。图1-9
通过日志我们可以看到，WebDriver启动目标浏览器，绑定到指定端口，该启动的浏览器实例作为WebDriver的Remote Server；客户端创建session向Remote Server发送restful请求；Remote Server依靠浏览器驱动来转换浏览器的native调用，即操作浏览器。
以上是使用客户端脚本的WebDriver工作流程，我们也可以通过WebDriver协议提供的接口来操作，实现相同的效果。
步骤一：进入selenium-server-standalone-3.10.0.jar文件所在目录，输入：java-jar selenium-server-standalone-3.10.0.jar（同前一方法的步骤二）。
步骤二：在浏览器中输入：http://localhost:4444/wd/hub，单击Create Session按钮创建一个session，Browser选择Firefox，单击“OK”，然后单击“Load Script”按钮，如图1-10所示。图1-10
步骤三：在Script URL输入框中输入：http://www.sogou.com，单击“OK”，获取session值，如图1-11所示。图1-11
步骤四：获取页面中sessionId的值：5a0bbad7-1c23-410f-b5bd-5a49be313d29，如图1-12所示。图1-12
步骤五：打开HttpRequester工具（Firefox插件），利用获取到的sessionId的值进行接口请求，在URL中输入：http://localhost:4444/wd/hub/session/5a0bbad7-1c23-410f-b5bd-5a49be 313d29/url，在POST请求体中输入：{"url":"http://www.sogou.com/"}，单击“POST”请求访问搜狗首页，如图1-13所示，该步骤与代码中dr.get（"http://www.sogou.com"）的执行效果一致。图1-13
步骤六：请求访问搜狗首页成功后，查看搜狗搜索的输入框，调用接口“/session/{session id}/element”，在URL中输入：http://localhost:4444/wd/hub/session/5a0bbad7-1c23-410f-b5bd-5a49be313d29/element，在POST请求体中输入：{"using":"id","value":"query"}，单击“POST”请求，请求结果如图1-14所示，该步骤与代码中“dr.findElement(By.id("query"))”的执行效果一致。图1-14
步骤七：在查找到搜索输入框后，要在搜索输入框中输入内容，调用接口/session/{session id}/element/{elementid}/value，在URL中输入：http://localhost:4444/wd/hub/session/5a0bbad7-1c23-410f-b5bd-5a49be313d29/element/b1238215-82b1-480f-9d7d-48684b108223/value，注意此处的element id为步骤六的响应结果，即“element-6066-11e4-a52e-4f735466cecf”的值“b1238215-82b1-480f-9d7d-48684b108223”，在POST请求体中输入：{"value":["gloryroad"]}，单击“POST”，如图1-15所示，该步骤与代码中“dr.findElement (By.id("query")).sendKeys ("gloryroad")”的执行效果一致。图1-15
在以上实践过程中，如果选择Firefox选项后不能成功创建session，则可以尝试选择“Internet Explorer”或“Chrome”选项来创建session，从而完成以上实践。1.5 Selenium的特性1.5.1 Selenium 1和Selenium 2的特点
1.Selenium 1的缺点
Selenium 1有以下缺点：（1）本机的键盘和鼠标事件无法调用和触发；（2）因为浏览器的同源策略，只能使用JavaScript插入方式来进行网页操作的模拟测试；（3）基本身份认证、自签名的证书和文件上传/下载的框体无法处理。
2.Selenium 2的优点
Selenium 2具有以下优点：（1）Selenium 1必须操作真实的浏览器，但Selenium 2可以使用HtmlUnit进行测试，在不打开浏览器的情况下进行快速测试；（2）Selenium 2基于浏览器的内部接口实现自动化测试，更接近用户使用的真实情况；（3）Selenium 2提供了更简洁的面向对象API，提高了测试脚本的编写效率；（4）在使用过程中，Selenium 2无须单独启动Selenium Server。1.5.2 Selenium 3的新特性
Selenium 3以开发一款聚焦Web端和移动端的自动化测试工具为目标，WebDriver API是Selenium 2的主要插件，Selenium 3依然沿用，并且基于W3C标准。Selenium会不断扩充WebDriver API，提供移动端的测试套件，以提高不同项目间的相互操作性。同时，Selenium 3更关注系统的稳定性，移除了Selenium RC API。与Selenium 2相比，Selenium 3的新特性如下。（1）Selenium 3去掉了Selenium RC，这是Selenium 3最大的变化。（2）Selenium 3只支持Java 8及以上版本。（3）Selenium 3不再提供默认浏览器支持，所有支持的浏览器均由浏览器官方提供支持，即由官方提供相应的驱动程序，由此提升了自动化测试的稳定性。Selenium 3以前的版本能直接启动Firefox浏览器，而Selenium 3需要下载Firefox官方提供的GeckDriver驱动才能启动Firefox浏览器，并且Firefox浏览器必须是48版本以上。（4）Selenium 3通过Apple自己的SafariDriver支持MacOS上的Safari浏览器。Safari浏览器的驱动直接集成到Selenium Server上。也就是说，想在Safari浏览器上执行自动化测试脚本，必须使用Selenium Server。（5）Selenium 3通过Microsoft官方提供的Microsoft WebDriver支持Edge浏览器，在Windows 10系统中就可以实现Edge浏览器的自动化测试，只需要访问“https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver/”并下载相应版本的驱动程序即可实现。（6）Selenium 3只支持IE 9.0及以上版本，早期版本也许还能工作，但不再提供支持。
Selenium 3让Web自动化测试运行更稳定，性能更高，支持的浏览器更多、更新。Selenium 1、Selenium 2和Selenium 3之间的关系如图1-16所示。图1-16第2章 自动化测试的那点事儿
Selenium工具诞生已经超过了10年，目前在软件开发公司中得到了大规模的应用，但很少有人能够清晰地描述此工具的发展历史和特点，本章的内容能够让读者了解Selenium工具的“前世今生”及特点。
虽然每个测试工程师都了解一些“自动化测试”的知识，但是很少有人能够准确地回答以下问题：
● 在自动化测试过程中应该如何设定自动化测试的目标？
● 如何衡量自动化测试的投入产出比？
● 需要什么样的人员分工？
● 自动化测试的最佳实践是什么？
要想知道以上问题的答案，请仔细阅读本章内容，实际上，这比自己搭建一个自动化测试框架的意义还要大。2.1 自动化测试的目标
我们做任何事情都应该有个目的，有了目的就会产生相应的目标，然后再基于这个目标进行相关活动，以此来达到目的。类似地，我们在进行自动化测试的时候，首先要明确自动化测试的目标，即实现了自动化测试到底能为我们带来什么好处、解决什么问题?我们不能为了自动化而自动化，必须在实施自动化测试之前明确自动化测试的目标。
作者基于自身多年的自动化测试实践，列出了一些相对通用的自动化测试目标。
1.提高测试人员的工作成就感和幸福感，减少手工测试中的重复性工作
目前，在中国的大部分中小企业中，手工测试在日常测试工作中占了很大比例，测试人员必须跟随开发团队，不断地进行迭代式开发和测试，一个功能模块在整个测试周期中被重复测试的次数可能超过10次。测试人员在执行了如此多的重复工作之后，常常会对“IT民工”这个词有了更深的感触。
如何改变这个现状呢?自动化测试肯定是个很好的选择。在脚本写好以后，可以不断地重复运行，测试人员只需要单击某个按钮就可以开始测试了，然后去喝喝茶、看看报纸，一会儿回来看一下测试结果，就完成了以往手工测试需要花费很长时间的工作。测试工作的成就感和幸福感油然而生，测试人员也会有精力和意愿去主动地推进自动化测试在不同项目中的深入实施。
如何验证达到了此目的呢?可以通过满意度调查来了解是否提高了测试人员的成就感和满意度。
2.提高测试用例的执行效率，实现快速的自动化回归测试，快速地给予开发团队质量反馈
使用手工方式来执行测试用例，执行速度必然是很慢的。人是一种生物，而不是机器，工作时间长了必然会觉得劳累，测试执行的速度自然就慢了下来。在测试用例非常多的情况下，测试一遍所有测试用例的时间成本就会相当高。
使用自动化测试取代手工测试，那么测试用例的执行者就变成了机器，机器可以24 小时不停地执行，它可以毫无怨言地、不知疲倦地、快速地完成测试脚本指派给它的测试任务。此种方式势必可以大大提高测试执行的效率，减少测试用例的执行时间，提高测试执行的准确性。
目前，敏捷开发模式也在各类软件企业中开始普及和应用。敏捷开发对被开发产品的质量反馈有很高的要求，需要每星期甚至每天开发出一个build 版本，并且部署在测试环境中，同时希望测试人员能够给予快速反馈。目前，只有通过自动化测试的方式，才能真正满足大型敏捷开发项目的质量反馈需求，缺少自动化测试的敏捷开发项目有较高失败风险。
如何验证达到了此目的呢?可以和以前手工测试的执行时间进行对比，了解是否明显缩短了测试用例的执行时间；也可以询问开发人员，了解质量反馈速度的提升能否为快速发布产品带来帮助。
3.减少测试人员的数量，提高开发和测试的比例，节省企业的人力成本
在大部分IT企业的运营成本中，50%～70%的成本是人工成本，更好地控制人工成本，对于企业的发展有着重要意义。采用自动化测试的方式，势必会减少手工测试的工作量，从而达到减少测试人员数量的目的，进而降低企业的人工成本，增强企业的盈利能力。
如何验证达到了此目的呢?在测试工作量相同的情况下，企业可以测算在使用自动化测试后，是否减少了测试人员投入数量和工作时长。
4.在线产品的运行状态监控
在完成产品开发和测试工作后，产品会被发布到生产环境，正式为用户提供服务。但在生产环境中，产品总是会由于各类原因产生各种运行问题或故障。如何快速发现这样的问题呢?有人认为，“出了问题一定会有用户给客服打电话进行投诉，那我们就可以发现生产环境中的问题了。”如果采用这样的处理方式，势必会降低用户对产品使用的满意度。另外，如果没有热心的用户进行投诉，那么发现生产环境问题的时间会被推迟，所以依靠客户投诉的方式是不可取的。
为了保证快速、及时地发现生产环境的不定期问题，建议采用拨测的方式来监控产品的运行状态，可以编写自动化测试脚本来测试产品的主要功能逻辑，定时运行测试脚本来检查产品系统是否依旧可以正常工作。如果在运行测试脚本后没有发现任何问题，则休眠等待一段时间后再运行测试脚本。如果在运行测试脚本后，发现了产品系统的运行问题，在重复几次之后确认产品系统的问题依旧存在，则测试脚本会自动给系统运维的值班人员发送报警邮件和短信。相关人员在收到报警后，可以人工处理系统出现的运行故障，这样就达到了实时监控产品系统的目的，可以在第一时间发现和处理系统的故障。
如何验证达到了此目的呢?在生产环境中运行的产品，如果系统出现了问题，可以在几分钟内实现自动报警。
5.插入大量测试数据
在系统级别的测试过程中，经常要插入大量的测试数据来验证系统的处理能力。例如，如果测试人员想要插入100个注册用户，并且每个用户都有特定的10条用户数据，那么需要插入的数据量足有1000条之多，使用手工的方式来插入这些数据势必会花费很长的时间和很多的精力。测试人员可以通过3种自动化的方式来完成上述测试数据的插入。
第一种方式：测试人员编写数据库的存储过程脚本，在数据库的不同数据表中插入测试数据，使用这样的方式可以实现海量数据的快速插入。当然此种方式也有缺点，如果搞不清楚数据库中各表的逻辑关系和数据格式的插入要求，很可能插入错误数据，导致无法得到正确结果。
第二种方式：按照系统接口的调用规范，在测试系统的接口层编写测试脚本，调用插入数据的系统接口，实现测试数据的快速插入，速度虽然不一定有第一种方式快，但是能够基本保证插入数据的准确性。但是，如果被测系统没有接口层，那么此种方式就无法实施了。
第三种方式：使用前台的自动化测试工具，在系统的前台界面模拟用户的真实操作行为来输入各类测试数据，然后再提交给测试系统。此种方式的优点是可以真正模拟用户插入数据的行为，保证数据插入的准确性和完整性，包含前台界面的系统均可使用此种方式。但此种方式的缺点是插入数据的速度要比前两种方式慢很多。
针对被测系统的实际情况，测试人员可以灵活选择某种方式来满足测试数据的插入需求。
6.常见的错误目标：自动化测试完全替代手工测试，使用自动化测试发现更多的新bug
很多测试人员都有一个错误的想法，就是用自动化测试完全替代手工测试。如果设定此目标，就会给自动化测试的实施带来极大的困难。测试工作本身就是一门艺术，需要测试人员用智慧去探索系统中可能出现的问题，并且需要在测试过程中使用不同的测试方法、测试数据和测试策略来发现更多问题。自动化测试则使用固定的方法和数据实施测试，无法像人一样根据测试系统的响应情况做出及时的测试策略调整，势必会造成测试逻辑的低覆盖率。另外，在测试用例中有很多异常操作很难用程序来进行模拟，完全采用自动化测试来模拟会带来极大的技术挑战。所以，以自动化测试能够替代一定比例的手工测试为目标即可，千万不可对自动化测试的覆盖度设定过高的值。
还有的测试人员期望使用自动化测试来发现更多的新bug，这也是一个常见误区。虽然在编写自动化测试用例的过程中会发现大部分的bug，但自动化测试的作用不是发现新bug，而是验证以前能够正常工作的功能是否依旧可以正常工作。举例来说，一个被测系统有100个功能点，由5万行代码实现，这100个功能点在上一个版本中均通过测试，在下一个迭代版本开发中，程序员根据产品人员的5个新需求修改了5个复杂的功能点，并且新增和修改了500行代码，那么测试人员针对这样的场景应如何进行测试呢?因为测试人员不知道这500行代码会对整体的100个功能点产生怎样的影响，所以只能把100个功能点都测试一遍，测试通过后才能放心地进行版本发布和上线。100个功能点的测试工作量就这样产生了。如果采用手工测试的方式，则测试用例的执行周期肯定会很长。如果测试人员发现了新bug后，程序员又修改了100行代码，那么是不是又要重新测试这100个功能点呢?如果再次测试，那么测试人员就陷入了周而复始的重复劳动中；如果不全部测试，那么被修改代码产生的不确定性又难以评估。如果测试人员拥有了这100个功能点的自动化测试脚本，就不会陷入进退两难的境地了，测试人员可以使用自动化测试脚本快速验证原有的95个功能点是否正常工作，只要手工测试5个被修改的功能点即可，这可以大大降低手工测试的重复性。测试人员充分测试这5个功能点并确认没有bug产生后，可以再编写这5个功能点的自动化测试用例，用于下一个版本的自动化测试。从该例可以看出，自动化测试更适合回归测试，而不适合用来发现新bug。
基于以上6个常见的自动化测试目标，测试人员应根据测试项目的具体要求正确设定目标。2.2 管理层的支持
在一个企业中推广自动化测试是一项非常困难的任务，因为改变原有的手工测试习惯、工作模式和工作流程，必然会让整个开发和测试团队有不适应的地方，难免会遇到抵制、不理解和不配合的情况。若能借助管理层的力量，那么自动化测试的推广工作势必会事半功倍。如果想在企业中推广自动化测试，首先要寻求管理层的支持，让高层管理人员在开发和测试团队中宣传自动化测试的意义和实施目标，并要求公司和团队给予必要的资源与时间支持。如果缺乏管理层的支持，自动化测试的推广工作基本上都会无疾而终。
在自动化测试实施过程中，要先选择合适的项目进行试点实施，建议选择开发进度不太紧张且产品需求相对稳定的项目。在实施过程中，要合理地设定自动化测试的实施目标，并争取在实施结束后实现目标。将试点项目的自动化测试成果汇报给相关管理层，让他们进一步理解自动化测试的意义、成果和作用。基于试点项目的杰出成果，让管理层再进行其他项目的宣传和推广，逐步地在全公司开展自动化测试工作。2.3 投入产出比
大部分软件企业或互联网企业的经营都是为了谋取尽可能多的利润，其都希望投入尽可能少的成本来获取尽可能多的利润，所以本节从这个角度来谈一下自动化测试的投入产出比问题。
在进行自动化测试实践时，测试团队需要分析要投入哪些资源，如技术人员的时间投入、购买相关软件版权的费用，以及机柜、带宽和服务器的投入等，需要列出具体的资源需求。结合项目的实际情况，测试团队制定自动化测试的短期目标和长期目标，并列出可能获取的收益，再提交给研发团队的管理层进行投入产出比评估。若管理层认为投入产出比较高，那么就可以开始实施工作了；否则，很可能无法实施。
建议测试团队从以下几个方面考虑自动化测试的成本投入：（1）项目本身是否适合实施自动化测试?测试脚本的编写和维护成本是否较高?（2）现有的测试团队成员是否具备自动化测试的实施能力?如果不具备，是采用培训的方式来培养，还是从外部招聘有能力的自动化测试实施人员?（3）使用何种自动化测试软件?是否需要购买版权?（4）现有的硬件设施是否符合自动化测试的实施要求?（5）研发团队管理层对于自动化测试的潜在期望和要求是什么?
建议测试团队从以下几个方面重点考虑自动化测试的产出：（1）从短期和长期来分析，能够节省多少测试人力资源?（2）是否能够搭建比较成熟的自动化测试框架，解决测试脚本编写和维护成本高的问题?（3）自动化测试脚本是否可以快速执行?应确认哪些具体量化指标?（4）自动化测试的引入是否会提高开发人员的开发效率和质量?应确认哪些具体量化指标?2.4 敏捷开发中的自动化测试应用
目前，敏捷开发模式已经在国内众多的开发团队中盛行，开发团队已经逐步享受到敏捷开发带来的效率和价值，其中，敏捷团队的全员质量负责方式和大规模的自动化测试引入成为热门话题。敏捷开发的本质到底是什么呢?为什么大家开始高度认可其价值呢?本节我们进行简单的解释说明。
首先，我们讲一下传统开发模式遇到的问题。传统的开发模式大部分采用长周期和里程碑的方式进行管理，分为需求、设计、开发、测试和上线等几个阶段，产品的发布周期也比较长，一般为2～3个月，长的甚至达1～2年。虽然每个阶段都有明确的目标和工作范围，但是令人困扰的是，需求总在不断地产生变化，影响项目的设计、开发、测试等多个阶段，导致项目设计人员在初期就要想办法进行各种冗余的系统设计来防止未来变更的需求带来的负面影响。然而，计划总是赶不上变化，需求的变化和不确定性依然会带来各种问题，导致项目被不断推延，团队成员也越来越抵制需求的变更，项目质量也会不断下降。
敏捷开发模式和传统开发模式完全不同，其只会实现明确的需求，采用自动化测试和重构的方式来应对不断变化的需求，实现每月、每周甚至每天发布新版本的目标，解决了传统开发模式的很多问题。
敏捷开发的核心理念是小步快跑，具有如下6个特点。（1）鼓励团队成员的面对面沟通，敏捷开发模式认为，人和人的相互交流胜于任何流程和工具。（2）客户协作胜过合同谈判。（3）把工作重点放在可执行的程序上，而不是编写大量的文档。（4）团队协作和团队激励，团队对产品的发布承担责任，明确团队的统一目标。（5）响应变化胜过遵循计划。（6）采用持续集成和自动化测试的方式快速反馈项目质量，及时地适应新的需求，保证产品的高质量。
其中，自动化测试是敏捷开发中很重要的一个环节，因为敏捷开发模式一般会每天提交开发的代码到代码版本控制系统中。为了保证提交的所有代码都是正确的，开发团队通常都会使用自动化测试手段来进行回归测试，验证所有代码修改没有影响以前版本的功能。通过自动化测试手段，开发团队可以实现每天代码集成的开发任务，并保证每天的代码开发质量。自动化测试是敏捷开发模式的基础，如果缺少自动化测试，那敏捷开发通常都会失败，因为项目本身无法控制在持续集成的过程中出现的代码修改风险，也无法对项目的不断重构提供快速测试的支持，势必会引发项目延期、质量下降等一系列问题，无法真正实现小步快跑的目标。
在敏捷开发中，通常使用测试驱动开发（Test Driven Development，TDD）的方法。
这种方法不同于传统的软件开发方法，它要求在编写某个功能的代码之前先编写测试代码，开发人员只编写能够通过测试的功能代码，以此来推动整个开发的进行。此种方式可以确保开发人员集中精力在明确的需求上，防止过度设计，尽可能保持代码的简洁性，提高开发效率。
还有一种敏捷开发中常用的方法就是行为驱动开发（Behavior Driven Development，BDD）。BDD是TDD的进化方法，可以有效地改善设计，并在系统的演化过程中为团队指明前进方向。BDD使用客户和开发者通用的语言来定义系统的行为，从而实现符合客户需求的设计，避免在其他开发模式中常见的客户和开发双方对于需求理解的不一致性。
敏捷开发中的测试可以按照如图2-1所示的3个层级进行。图2-1
图2-1是一个三角形的示意，在三层中，每层区域大小代表每个层级测试的收益大小。由图2-1可以看出，单元测试的收益是最大的，接口测试其次，UI测试的收益最小。单元测试的颗粒度是最小的，测试范围集中在类和方法，测试用例的编写相对简单，并且在出现bug后，定位问题相对快速，可以在开发初期发现大部分问题，并且单元测试执行的速度最快，通常在毫秒级别的运行时间内就可以得到测试结果。接口测试的颗粒度稍大一些，测试范围集中在模块与子模块之间的数据交互，定位问题相对复杂，需要分析的代码量很大，测试执行速度也比单元测试慢很多。UI测试的收益最小，通常在系统测试和验收测试阶段进行，基于全部的系统代码进行测试，在测试出现问题后定位和分析困难。UI测试通常在用户使用的界面进行，测试执行相对于单元测试和接口测试慢很多，并且因为UI界面经常发生变化和调整，自动化执行和维护的成本也很高。
敏捷开发中的自动化测试可以基于这3种方式进行。基于上述的收益说明，敏捷测试更鼓励在单元测试和接口测试上投入更多资源，以此来实现快速编写、快速执行、快速定位问题的测试目的，能够快速地给予项目质量反馈。UI测试虽然相对来说收益最低，但UI层对用户来说是最直观的感知，所以也要在这个层级实现一定程度的自动化测试，尽可能模拟用户的各种真实操作，确保用户的最佳产品体验。2.5 自动化测试人员分工
自动化测试通常涉及3种分工角色：（1）测试框架搭建人员；（2）基于测试框架编写测试脚本的人员；（3）编写自动化测试用例及测试框架需求的人员。
这3种角色可以根据测试团队人员的实际水平进行角色合并。在通常情况下，测试开发人员承担第一种角色和第二种角色，非测试开发人员承担第三种角色。测试框架搭建人员的技术能力要求最高，通常在人才市场中处于抢手的地位，优秀的测试开发人员的年薪一般为20万～30万元，并且他们的职业发展空间比传统的手工测试人员更大，更容易晋升到测试团队的管理层。2.6 自动化测试工具的选择和推广使用
目前，可供测试团队使用的自动化测试工具有数十种之多，到底应该选择哪些测试工具才能让测试团队顺利地开展自动化测试是一个亟须解决的问题。测试团队必须科学地分析自身的使用需求和技术能力，才能选择出适合团队使用的自动化测试工具。本节我们将介绍如何选择合适的自动化测试工具。2.6.1 自动化测试工具的选择
高效实施自动化测试的前提是选择一个适合测试团队使用的自动化测试工具。优秀的测试工具会让自动化测试工作的实施事半功倍，反之则可能给自动化测试的实施工作带来很大困难。在选择自动化测试工具时，要持谨慎态度，需要结合工具特点和测试团队的实际情况进行综合分析，最终决定选择哪个工具。
表2-1列出了选择自动化测试工具时需要考虑的关键点。表2-12.6.2 Selenium WebDriver和QTP的工具特点比较
目前，主流的Web自动化测试工具是Selenium WebDriver和QTP，下面详细比较一下这两种工具的特点，如表2-2所示。表2-2
综合以上几点，具备一定编程能力的测试团队更适合选择Selenium WebDriver作为团队的主要Web自动化测试工具，预算充裕且团队成员编程能力一般的测试团队更适合选择QTP作为团队的主要Web自动化测试工具。2.7 在项目中实施自动化测试的最佳实践
自动化测试在大部分企业的推行过程中都会遇到各种困难，在不合适的项目和不适当的项目阶段实施自动化测试，会导致自动化测试实施效果不佳，自动化测试团队会被质疑其存在的价值。自动化测试的实施是一个复杂的过程，须结合企业文化、研发流程、团队技术能力、项目情况及实施成本等多种因素来逐步实施。以下为企业在自动化实施过程中的10个最佳实践，供各位读者参考。（1）在自动化测试实施前，建立可衡量和易达到的自动化测试实施目标，不要在初期确立过高的目标和期望。
俗话说，“好的开始是成功的一半。”为了之后能够更好地推广和实施自动化测试，须在初期就让研发团队和相关参与者了解自动化测试能够带来的好处，增强大家成功实施自动化测试的信心。可衡量的目标有助于参与各方有效地评估自动化测试的效果；易达到的目标会进一步鼓励自动化测试实施者按部就班地开展实施工作，避免采用急功近利和好高骛远的实施方法。（2）选择适合公司普遍使用的测试工具，可以是一个工具或者一组工具，之后需要针对选定的工具进行深入研究。
每种测试工具都有其优点和缺点，也都有各自适用的场景，建议充分了解工具后再进行团队内部的使用培训，夯实自动化测试实施的技术基础。另外，建议中小型企业尽可能选择开源的测试工具，降低购买商业测试工具的成本。
试读结束[说明：试读内容隐藏了图片]