作者：吴晓华
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Selenium WebDriver实战宝典试读：
前言
随着互联网的高速发展，中国的互联网繁荣程度达到了一个空前的发达水平，数亿量级用户的产品登上了中国的互联网发展舞台，阿里巴巴、腾讯、百度等多个互联网巨头也开始在世界的互联网舞台崭露头角，互联网行业的从业人员也达到了上百万人的规模，中国的互联网产品已经深入到网民生活的方方面面。
随着互联网行业在中国的迅猛发展，对于中国的软件开发和测试行业也提出了更高的技术要求与质量要求，软件测试从业者的技术水平也被提升到空前且不绝后的高要求阶段。以往我们看到测试人员的招聘重点都是对于测试用例设计和业务的理解，现今我们看到更多的测试职位对测试人员提出了更高的技术能力要求，例如，精通一门编程语言，熟悉MySQL或者Oracle数据库，精通自动化测试和性能测试等。为了更好地适应互联网社会的发展潮流，软件测试从业者必须在技术能力上不断地提升自己，才能真正站在职业发展的巅峰。
自动化测试技术对于测试人员来说是一个必要的高级技能要求，越来越多的测试从业者并不甘于仅仅使用手工方式进行测试，他们非常希望使用自动化的方式来减少枯燥无味且不断重复的手工测试劳动。目前，主流的Web自动化测试开源工具Selenium WebDriver成为众多软件测试从业者学习的热点，但是市面上针对Selenium自动化测试方面的书籍很少，基于实践方式来讲解Selenium应用技术的书籍更是凤毛麟角。因此，笔者个人非常希望能够写出一本基于实践操作的Selenium教学书籍，来解决软件测试人员的自动化测试学习问题。
本书采用图文并茂的方式分步骤讲解Selenium的各种实用技巧，并且提供被测试对象的实现代码或者被测试对象的访问网址，方便读者在本地搭建自己的测试环境或者访问互联网上的网站，从而进行自动化测试技术的实践。
这是我第一次写一本技术专著的书籍，当我真正开始提笔的时候，我深深感觉到用简洁的语言讲明白工具的使用方法和测试程序代码绝非易事，为此我投入了大量的精力来不断组织、优化书中的文字和图片，希望能够让读者通过本书深入掌握Selenium的使用技巧，助大家在自动化测试方向上的一臂之力。
由于我平时还要忙于其他工作，只能利用业余时间来编写此书，所以足足耗时8个月之久才完成此书，共写了三十多万字，希望能够获得读者的欢迎。非常感谢我的妻子和女儿，她们对我给予了巨大支持。我相信通过我的努力一定可以改变一些人的命运，所以和大家共勉，希望我们共同努力，改变中国测试行业技术含量低的现状。各章内容介绍：
第一篇“基础篇”：包括第1～8章。
第1章介绍了Selenium的发展历史及组成Selenium的工具套件，列举了Selenium 1和Selenium 2支持的浏览器和平台，讲解了Selenium RC和WebDriver的实现原理，比较了Selenium 1和Selenium 2的各自特点。
第2章介绍了在日常测试工作中常见的自动化测试目标，讲解了如何获得公司管理层对于开展自动化测试的支持，介绍了如何衡量自动化测试工作的投入产出比及在敏捷开发中的自动化测试应用，讲解了自动化测试工作的分工及测试工具的选择和推广使用，分享了在实际项目中最佳实践经验，说明了学习Selenium工具的能力要求。
第3章主要讲解了与Selenium工具使用相关的辅助工具FireBug和FirePath插件，主要介绍了这两种插件的安装方法和基本使用技巧。
第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～16章。
第12章讲解了数据驱动的概念，以及如何基于TestNG工具使用CSV文件、Excel文件和MySQL数据库分别进行数据驱动测试。
第13章介绍了页面对象（Page Object）设计模式，通过使用类函数封装方式实现自动化测试框架的设计模式。
第14章介绍了基于Cucumber工具的行为驱动测试实例，分别基于中文测试用例文件和英文测试用例文件进行了实例讲解。
第15章介绍了如何基于Selenium Gird组件实现并发执行测试用例，并通过实例进行了深入讲解。
第16章深入讲解了如何从零搭建一个数据驱动测试框架和关键字驱动测试框架，提供了完整的框架实例代码。此章节为本书的最重要章节，建议读者在阅读前面所有章节后再阅读此章节。
第四篇“常见问题和解决方法”：包含第17章。
第17章讲解了WebDriver使用过程中的常见疑难问题和解决方法，读者可以在使用WebDrvier遇到问题时进行查阅。特别致谢：
感谢我的好朋友李雄刚和部凯文帮我校对本书中的所有实例和代码，从中发现了不少书写错误和代码问题，在此对他们表示真挚的感谢。吴晓华2015年8月第一篇基础篇第1章 Selenium简介
Selenium工具诞生的时间已经超过了10年，目前已经在软件开发公司中得到大规模的应用，但是很少有人能够清晰地描述此工具的发展历史和特点，通过本章的介绍让读者和Selenium工具来一次亲密接触，了解它的前世今生及特点。1.1 Selenium的前世今生
2004年，在ThoughtWorks公司，一个名为Jason Huggins的测试同行为了减少手工测试的工作量，自己实现了一套基于JavaScript语言的代码库，使用这套库可以进行页面的交互操作，并且可以重复地在不同浏览器上进行各种测试操作。通过不断地改进和优化，这个代码库逐步发展成Selenium Core。Selenium Core为Selenium Remote Control（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的痛处。2008年，Selenium和WebDriver这两个项目进行了合并，Selenium 2出现了，也就是我们现在常常看到的Selenium WebDriver（简称WebDriver）。
Selenium 2 =Selenium 1 + WebDriver
Selenium的官网地址是www.seleniumhq.org，网站提供了Selenium WebDriver的安装文件和使用教程。Selenium 2是Selenium 1的升级版本，它本身向下兼容Selenium 1的所有功能，同时又提供了更多的新API来完成自动化测试的各种复杂需求。现阶段，Selenium 1已经退出了历史舞台，大部分Web自动化测试人员已经完全转向使用Selenium 2（WebDriver）来搭建自己的自动化测试框架。为了迎合历史的发展潮流，本书全部的案例均基于Selenium 2的WebDriver API进行讲解。1.2 Selenium工具套件介绍• Selenium 2（Selenium WebDriver）：提供了极佳的特性，例如，面向对象API，提供Selenium 1的接口用于向下兼容。• Selenium 1（Selenium RC或Remote Control（RC））：支持更多的浏览器，支持更多的编程语言（如Java、JavaScript、Ruby、PHP、Python、Perl和C#）。• Selenium IDE（集成开发环境）：Firefox插件，提供图形界面来录制和回放脚本。此插件只是用来做原型的工具，并不希望测试工程师使用此工具来运行大批量的测试脚本。此插件需要使用第三方的JavaScript代码库才能支持循环和条件判断。• Selenium -Grid可以在多个测试环境以并发的方式执行测试脚本，实现测试脚本的并发执行，缩短大量测试脚本的执行时间。1.3 Selenium 1和Selenium 2支持的浏览器和平台
Selenium 1的一大特点就是能够在多种操作系统上支持多种浏览器的自动化测试，通过下面的章节我们可以了解此工具能够支持的平台列表和浏览器类型列表。1.3.1 Selenium IDE、Selenium 1和Selenium RC支持的浏览器和平台
Selenium IDE、Selenium 1和Selenium RC支持的浏览器和平台如表1-1所示。表1-1Selenium 1（即浏览器Selenium IDE操作系统Selenium RC）WindowsFirefox 启动浏览器录制脚本和回放脚本、Linux、3.x运行测试脚本MacWindowsFirefox 启动浏览器录制脚本和回放脚本、Linux、3运行测试脚本MacWindowsFirefox 启动浏览器录制脚本和回放脚本、Linux、2运行测试脚本Mac仅能通过Selenium 启动浏览器IE 8Windows1（RC）来运行测试脚本运行测试脚本仅能通过Selenium 启动浏览器IE 7Windows1（RC）来运行测试脚本运行测试脚本仅能通过Selenium 启动浏览器IE 6Windows1（RC）来运行测试脚本运行测试脚本仅能通过Selenium 启动浏览器WindowsSafari 41（RC）来运行测试脚本运行测试脚本、Mac仅能通过Selenium 启动浏览器WindowsSafari 31（RC）来运行测试脚本运行测试脚本、Mac仅能通过Selenium 启动浏览器WindowsSafari 21（RC）来运行测试脚本运行测试脚本、MacWindowsOpera 仅能通过Selenium 启动浏览器、Linux、101（RC）来运行测试脚本运行测试脚本MacWindows仅能通过Selenium 启动浏览器Opera 9、Linux、1（RC）来运行测试脚本运行测试脚本MacWindows仅能通过Selenium 启动浏览器Opera 8、Linux、1（RC）来运行测试脚本运行测试脚本MacWindowsGoogle 仅能通过Selenium 启动浏览器、Linux、Chrome1（RC）来运行测试脚本运行测试脚本Mac1.3.2 Selenium 2（WebDriver）支持的浏览器
官网中并没有明确列出WebDriver支持浏览器的所有版本号，仅仅列出浏览器的名称。下面结合笔者个人的实际使用情况列出WebDriver支持的浏览器版本，请在测试实践中进行再次确认。• Google Chrome。• IE 6、7、8、9、10和11。• Mac操作系统的Safari默认版本均支持。• Firefox的大部分版本。• Opera。• HtmlUnit。• Android手机操作系统的默认浏览器。• iOS手机操作系统的默认浏览器。1.4 Selenium RC和WebDriver的实现原理
当执行Selenium自动化测试脚本时，测试人员可以看到浏览器中发生的神奇一幕：页面上会自动进行各种操作，例如，打开新窗口、在输入框中输入文字、选择下拉列表框等。测试人员为此不禁要多问一句：“它到底是怎么实现的？”为了了解Selenium工具的神奇之处，读者必须深入了解它的实现原理和机制。1.4.1 Selenium RC的实现原理
Selenium RC的实现原理如图1-1所示。图1-1
Selenium 1的自动化测试执行步骤如下。
第一步：测试人员基于Selenium支持的编程语言编写好测试脚本程序。
第二步：测试人员执行测试程序。
第三步：测试脚本程序发送访问网站的Http请求给Remote Control Sever（RC）。
第四步：Remote Control Sever（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代理模式的实现机制。图1-2
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.4.2 WebDriver的实现原理
WebDriver与Selenium 1的JavaScript注入实现不同，它直接利用浏览器的内部接口来操作浏览器。对于不同平台中的不同浏览器，必须依赖浏览器内部的Native Component（原生组件）来实现把WebDriver API调用转化为浏览器内部接口的调用。
Selenium 1采用JavaScript的合成事件来处理页面元素的操作，比如要单击某个页面元素，要先使用JavaScript定位到这个元素，然后触发单击事件。而WebDriver使用的是系统的内部接口或函数，首先要找到这个元素的坐标位置，并在这个坐标点触发一个鼠标左键的单击操作。由此可以看出，WebDriver能更好地模拟真实的环境，仅能测试那些可见的页面元素。也正因为这个区别，有些隐藏的页面元素是可以使用Selenium 1进行操作的，而WebDriver却无法实现，尝试单击的话则会产生一个cannot clickable的错误提示信息。1.4.3 Selenium 1和WebDriver的特点
1．Selenium 1的缺点
Selenium 1具有以下缺点：（1）本机的键盘和鼠标事件无法调用和触发。（2）因为浏览器的同源策略，只能使用JavaScript插入方式来进行网页操作的模拟测试。（3）基本身份认证、自签名的证书和文件上传/下载的框体无法处理。
2．Selenium 2（WebDriver）的优点
Selenium 2（WebDriver）具有以下优点：（1）Selenium必须操作真实的浏览器，但是WebDriver可以使用HtmlUnit进行测试，在不打开浏览器的情况下进行快速测试。（2）WebDriver基于浏览器的内部接口实现自动化测试，更接近用户使用的真实情况。（3）WebDriver提供了更简洁的面向对象API，提高了测试脚本的编写效率。（4）WebDriver在使用过程中无须单独启动Selenium Server。第2章 自动化测试的那点事儿
虽然每个测试工程师都了解一些“自动化测试”的知识，但是鲜有人能够准确地回答如下问题：• 在自动化实施的过程中应该如何设定自动化测试的目标？• 如何衡量自动化测试的投入产出比？• 需要什么样的人员分工？• 自动化测试的最佳实践是什么？
要想知道上面问题的答案，请仔细阅读本章内容，它其实比你搭建一个自动化测试框架的意义还要大。2.1 自动化测试目标
我们做任何事情都应该有个目的，有了目的就会产生一个对应的目标，然后再基于这个目标进行相关活动的实施，以此来达到目的。类似地，我们在进行自动化实施的时候，首先要明确自动化测试的目标，即实现了自动化测试到底能为我们带来什么好处、解决了什么问题？我们不能为了自动化而自动化，必须在实施自动化测试之前明确自动化测试的目标。
笔者基于多年的自动化测试实践，列出了一些相对通用的自动化测试目标。
1．提高测试人员的工作成就感和幸福感，减少手工测试中的重复性工作
目前，在中国的大部分中小企业中，手工测试占日常测试工作的大部分比例，测试人员必须跟随开发团队一起不断地进行迭代式开发和测试，一个功能模块可能在整个测试周期被重复测试的次数超过10次以上。测试人员在执行了如此多的重复工作之后，常常会对于“IT民工”这个词有着更加深刻的理解。
如何改变这个现状呢？使用自动化测试肯定是个很好的选择，脚本写好以后，可以不断地重复运行，测试人员只需要单击某个按钮就可以开始测试工作了，然后去喝喝茶看看报纸，一会儿回来看一下测试结果，就完成了以往手工测试需要花费很长时间的工作。测试工作的成就感和幸福感油然而生，测试人员也会有精力和意愿去主动地推进自动化测试在不同项目中的深入实施。
如何验证达到了此目的呢？可以通过测试人员的满意度调查来了解是否提高了测试人员的成就感和满意度。
2．提高测试用例的执行效率，实现快速的自动化回归测试，快速地给予开发团队质量反馈
使用手工方式来执行测试用例，执行速度必然是很慢的。人是一种生物，而不是机器，工作时间长了必然会觉得劳累，测试执行的速度自然就慢了下来，在测试用例非常多的情况下，完整测试一遍所有测试用例的时间成本就会相当高。
使用自动化测试取代手工测试，那么测试用例的执行者就变成了机器执行，机器可以24小时不停地执行，它可以毫无怨言地、不知疲倦地、快速地完成测试脚本指派给它的测试任务。此种方式势必可以大大提高测试执行的效率，减少测试用例的执行时间，提高测试执行的准确性。
目前，敏捷开发模式也在各类软件企业中开始普及和应用。敏捷开发对于被开发产品的质量反馈有着很高的要求，需要每星期甚至每天开发出一个build版本，并且部署在测试环境上，同时希望测试人员能够给予质量的快速反馈。目前，只有通过自动化测试的方式才能真正实现对于大型敏捷开发项目的质量反馈需求，缺少自动化测试的敏捷开发项目会大大增加项目失败的风险。
如何验证达到了此目的呢？可以和以前手工测试的执行时间进行对比，看看是否明显缩短了测试用例的执行时间，询问开发人员项目的质量反馈速度能否为快速地发布产品带来很大帮助。
3．减少测试人员的数量，提高开发和测试的比例，节省企业的人力成本
在大部分IT企业的运营成本中，50%～70%的成本是人工成本，如何能够更好地控制人工成本，对于企业的发展有着重要意义。使用自动化测试方式，势必会减少手工测试的工作量，从而达到减少测试人员的目的，进而降低企业的人工成本，增强企业的盈利能力。
如何验证达到了此目的呢？在相同级别测试工作量的情况下，企业可以测算在使用自动化测试后，项目中是否减少了测试人员投入数量和工作时长。
4．在线产品的运行状态监控
在完成产品开发和测试工作后，产品会被发布到生产环境，正式地为用户提供服务。但是产品在生产环境的运营过程中，总是会由于各类原因造成这样或者那样的运行问题或故障。如何快速发现这样的问题呢？有人说“出了问题一定会有用户给客服打电话进行投诉的，那么我们就可以发现生产环境中的问题了”。如果采用这样的处理方式，势必会降低用户对于产品使用的满意度。另外，如果没有热心的用户进行投诉，那么生产环境问题被发现的时间会被大大推迟，所以依靠客户投诉的方式是不可取的。
为了保证快速、及时地发现生产环境的不定期问题，建议采用拨测的方式来监控产品的运行状态，可以编写自动化测试脚本测试产品的主要功能逻辑，定时运行测试脚本检查产品系统是否依旧可以正常工作，如果运行测试脚本后没有发现任何问题，则休眠等待一段时间后再运行测试脚本检测产品系统的运行状态。如果测试脚本发现了产品系统的运行问题，在重试几次之后确认产品系统的问题依旧存在，则测试脚本会自动给系统运维的值班人员发出报警邮件和短信，相关人员收到报警后可以人工去处理系统出现的运行故障，这样就达到了实时监控产品系统的目的，可以在第一时间发现和处理系统的故障。
如何验证达到了此目的呢？在生产环境运行的产品系统出现问题，系统可以在几分钟内实现自动报警。
5．插入大量测试数据
在系统级别的测试过程中，经常要插入大量的测试数据来验证系统的处理能力。比如测试人员想要插入100个注册用户，并且每个用户都有特定的10条用户数据，那么需要插入的数据量足有1000条之多，使用手工的方式来插入这些数据势必会花费很长的时间和精力。测试人员可以通过3种自动化的方式来实现上述测试数据的插入要求。
第一种方式：测试人员编写数据库的存储过程脚本，在数据库的不同数据表中插入测试数据，使用这样的方式可以实现海量数据的快速插入。当然此方式也有缺点，如果搞不清楚数据库中各个表的逻辑关系和数据格式的插入要求，很可能插入错误数据，导致无法被前台的程序所正确展示和使用。
第二种方式：按照系统接口的调用规范要求，在测试系统的接口层编写测试脚本调用插入数据的系统接口，实现测试数据的快速插入，速度虽然不一定有第一种方式快，但是能够基本保证插入数据的正确性。如果被测试系统没有接口层，那么此方式就无法实施了。
第三种方式：使用前台的自动化测试工具，在系统的前台界面模拟用户的真实操作行为来输入各类测试数据，然后再提交到测试系统中。此方式的优点是可以真正模拟用户插入数据的行为，保证数据插入的准确性和完整性，包含前台界面的系统均可使用此方式。此方式的缺点是插入数据的速度要比前两种方式慢好几倍。
针对被测试系统的实际情况，测试人员可以使用3种方式之一实现测试数据的插入需求。
6．常见的错误目标：使用自动化完全替代手工测试，使用自动化测试发现更多的新bug
很多测试人员都有一个错误的想法，就是想用自动化测试完全替代手工测试，如果设定此目标则会让自动化测试的实施带来极大的困难。测试工作本身就是一门艺术，需要测试人员用智慧去探索系统中可能出现的问题，并且需要在测试过程中使用不同的测试方法、测试数据和测试策略来发现更多问题。而自动化测试的实施方式则是使用固定的方法和数据去实施测试，无法像人一样根据测试系统的响应情况作出及时的测试策略调整，势必会造成测试逻辑的低覆盖率。另外，测试用例中有很多异常操作很难使用程序来进行模拟，若要完全实现自动化测试来模拟则会带来极大的技术难度挑战。所以，只要设定自动化测试能够替代一定比例的手工测试工作为目标即可，千万不可对自动化测试的覆盖度设定过高的比例要求。
还有的测试人员期望使用自动化测试来发现更多的新bug，这个也是一个常见误区。虽然在编写自动化测试用例的过程中会发现大部分的bug，但是自动化测试本身的作用不是用来发现新bug，而是用来验证以前能够正常工作的功能是否依旧可以正常工作。举一个例子，一个被测试系统有100个功能点，由5万行代码来实现，这100个功能在上一个版本中均通过测试，在下一个迭代的版本开发中，程序员根据产品人员的5个新需求修改了5个复杂的功能点，并且新增和修改了500行代码，那么测试人员针对这样的场景如何来测试这个版本的产品呢？因为测试人员不知道被修改的500行代码到底会怎样影响整体的100个功能点，所以只能把100个功能点都测试一遍才能放心地让这个版本发布和上线。100个功能点的测试工作量就这样产生了。如果采用手工测试的方式，则测试用例的执行周期肯定会很长，并且测试人员发现了新bug后，程序员又修改了100行代码，那么是不是又要重新测试这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）使用持续集成和自动化测试方式快速反馈项目质量，及时地适应新的需求，保证产品的正确性。
其中，自动化测试是敏捷开发中很重要的一个环节，因为敏捷开发模式一般会在每天提交开发的代码到代码版本控制系统，为了保证所有提交的代码都是正确的，开发团队通常都会使用自动化测试手段来进行回归测试，验证所有代码修改没有影响到以前版本的功能。通过自动化测试手段，开发团队可以实现每日代码集成的开发任务，并保证每天的代码开发质量。自动化测试是敏捷开发模式的基础，如果缺少自动化测试，那么敏捷测试通常会失败，因为项目本身无法控制持续集成过程中出现的代码修改风险，也无法对项目的不断重构提供快速测试的支持，势必会引发项目延期、质量下降等一系列问题，无法真正实现小步快跑的目标。
敏捷开发中通常使用测试驱动开发的方法（TDD），这种方法不同于传统软件开发流程的开发方法，它要求在编写某个功能的代码之前先编写测试代码，开发人员只编写使测试通过的功能代码，通过测试来推动整个开发的进行。此种方式可以确保开发人员集中精力在明确的需求上，防止过度设计，尽可能保持代码的简洁性，提高开发效率。
还有一种敏捷开发中常用的技术就是行为驱动开发（Behavior Driven Development, BDD）。BDD是测试驱动开发的进化，可以有效地改善设计，并在系统的演化过程中为团队指明前进方向。BDD使用客户和开发者通用的语言来定义系统的行为，从而作出符合客户需求的设计，避免其他开发模式中常见的客户和开发双方对于需求理解的不一致性。图2-1
敏捷开发中的测试可以从图2-1所示的3个层级进行。
图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 在项目中实施自动化的最佳实践
自动化测试在大部分企业的推行过程中都会遇到各种困难，在不合适的项目和不适当的项目阶段实施自动化，导致自动化测试实施效果不佳，自动化测试团队会被质疑其存在的价值。自动化测试的实施是一个复杂的过程，须结合企业文化、研发流程、团队技术能力、项目情况及实施成本等多种因素来逐步实施。以下列出了企业在自动化实施过程中的十个最佳实践，供广大自动化测试的爱好者参考。（1）在自动化测试实施前，建立可衡量和易达到的自动化测试实施目标，不要在初期制订过高的目标和期望。
俗话说，“好的开始是成功的一半”，为了后续更好地推广和实施自动化测试，须在初期就让研发团队和相关参与者看到自动化测试带来的好处，增强大家成功实施自动化测试的信心。使用可衡量的目标，有助于参与各方有效地评估自动化测试的效果；易达到的目标会进一步鼓励自动化测试实施者按部就班地开展实施工作，避免采用急功近利和好高骛远的实施方法。（2）选择适合公司普遍使用的测试工具，可以是一个工具或者一组工具，作出选择后需要针对选定工具进行深入研究。
每种测试工具都有其优点和缺点，都有某些独特适用的场景，建议对工具充分了解后再进行团队内部的使用技巧培训，夯实自动化测试实施的技术基础。另外，建议中小型公司尽可能选择使用开源的测试工具，降低购买商业测试工具产生的相关成本。（3）分析测试项目的特点，编写适合项目特点的自动化测试框架，减少编写测试脚本的重复性和复杂性，降低其他测试人员编写自动化测试脚本的门槛。
每个测试项目都是独特的，总是会有一些很独特的测试需求，需要仔细分析其特点后，由测试开发团队实现适合当前项目使用的自动化测试框架。一个优秀的定制化测试框架可以有效地推动自动化测试在项目中的实施。由于大部分测试人员的编程能力存在一定局限性，须依靠优秀的测试框架来降低编写自动化脚本的难度，从而让尽可能多的测试人员从自动化测试中受益，更好地调动团队积极性去支持自动化测试的进一步实施。（4）聘用具备丰富开发经验的工程师承担测试框架的开发工作，并根据测试框架的推广程度进行不断优化。
测试框架的意义已无须赘述，为了更好地服务于测试人员，团队应该聘用最优秀的技术开发人员来承担测试框架的开发工作，良好设计的测试框架会极大地增加自动化测试实施的成功率。优秀的测试框架也不会短周期内被迅速开发出来，必须经过一个长期的优化过程，才能打磨出一套适应公司大多数项目的自动化测试框架，因此建议长期投入优化测试框架的人力。（5）在自动化测试工作开始大规模推广实施前，须在中小类型项目中进行充分试点实施，充分评估实施自动化测试的风险和产出，总结试点实施中的问题和收益，并在后期推广过程中尽可能扬长避短。
为了降低自动化测试实施过程中的风险，测试团队应该提前进行风险分析，做好针对性的风险应对计划，并在中小类型项目中进行试点实施，证明测试团队已经做好了实施自动化测试的充分准备。在试点过程中尽可能多地发现问题，并通过不断地解决问题来完善自动化测试实施的方法和流程，为后续的大规模推广做好充分准备。（6）获得开发团队的协作支持，提高开发代码的可测试性，降低自动化测试实施的难度。
由于测试工具本身的局限性、测试人员的编程能力及被测试对象的复杂度，很可能需要开发团队作出一定程度的配合才能实现较为复杂的自动化测试脚本。在自动化测试实施前，测试团队应该和开发团队对代码的可测试性要求达成共识，建议制订代码开发的可测试性标准或规范，并在自动化测试实施过程中不断完善。（7）在需求相对稳定的阶段，开始UI层级大规模自动化测试脚本的编写。
项目启动阶段，项目需求一般都是不太稳定的，UI层的需求变化很大，如果在项目启动阶段就开始编写大量UI级别的自动化测试脚本，一旦需求发生了大范围的变更，那么自动化测试脚本的维护工作量也会随之产生，这不但会降低自动化测试人员的实施积极性，也会增加自动化测试投入的人工成本。自动化测试工程师会质疑自己为什么每天都要维护以前可以正常运行的自动化测试脚本。为了降低自动化脚本维护的成本，须在项目需求稳定阶段，且大部分严重bug已经修改完毕的情况下，再进行大规模自动化测试脚本的编写，尽量降低维护测试脚本的工作量，使自动化测试脚本可以使用更长的周期。（8）在测试过程中，使用局部自动化测试的实施策略。
有的时候大规模实施自动化可能会带来各种实施的难度和困难，维护大量的自动化测试脚本可能也没有太多人力和时间去完成，这样可能会导致测试团队抵制使用自动化测试技术。测试人员可以尝试使用局部自动化测试的实施策略，找到相对重复的手工劳动过程，然后编写自动化测试脚本来替代重复性的手工劳动。少量的测试脚本编写和调试会比较容易，耗时更少，并且更易于传递给其他测试人员使用。如果能够减少一些测试人员的手工测试工作量，测试团队何尝不多做一些这样的尝试呢？小脚本积累多了也是一笔可观的财富，总会有爆发的那一天。（9）全面提高自动化测试实施人员的技术素质。
实施自动化测试的技术要求很高，为了能够保证自动化测试的创新和普遍使用，测试团队负责人须尽可能提高自动化测试实施人员的技术素质。每个人的技术基础打好了，后续才能发挥每个人的主观能动性，结合项目应用场景，因地制宜地编写出优秀的自动化测试框架和高质量的测试脚本。我们要认识到企业中的“人”才是最重要的资产，须让这些重要的资产不断增值，而不是让它们贬值。（10）定期做好自动化测试最佳实践的总结。
自动化测试的实施过程不可能一蹴而就，也不可能一帆风顺，总是会遇到各种困难和问题。作为自动化测试的实施团队应该定期总结一段时间内自动化测试的得失，不断形成团队最佳实践的自动化测试知识库，这样才能让自动化测试技术在企业中的实施更加深入和全面，确保企业在人员流失的时候不至于丢掉宝贵的最佳实践经验。建议最佳实践经验的资料都放到团队内部的培训文档中，让更多的后来者能够站在前人的肩膀上不断成长，为企业降低更多的自动化测试实施成本，提高人员的劳动产出率。2.8 学习Selenium工具的能力要求
自动化测试相对于手工测试人员来说需要更多的知识和编程技能，以下列出在使用Selenium WebDriver工具时常遇到的一些知识领域：HTML、XML、CSS、JavaScript、Ajax、Java/Python/C#/Ruby其中一种编程语言、MySQL数据库、JUnit/TestNG、Ant/Maven、Jenkins/Hudson、Cucumber测试框架。
建议Selenium WebDriver工具的使用者尽可能地深入学习以上知识领域，尤其要增加学习编程技能的时间，因为编程能力的高低直接决定你是否可以写出优秀的自动化测试框架。真正的自动化测试高手，从技术能力上来说比中等开发人员的水平还要高，所以想成为一个能够独当一面的自动化测试工程师，须不断地学习各类开发知识。不是每个测试工程师都可以成为自动化测试工程师，要想改变常年手工测试的命运，必须坚持不懈地学习和实践，才能让我们离自动化测试的巅峰越来越近，终有一天我们会站在顶峰摇旗呐喊。第3章 自动化测试辅助工具
Selenium工具本身虽然很强大，但是它也需要一些辅助工具来解决一些特定的问题。本章主要介绍和Selenium工具配合使用的辅助工具。3.1 Firefox浏览器的安装
Firefox浏览器的安装步骤如下。（1）在地址栏中输入浏览器访问网址http://www.Firefox.com.cn/。（2）单击浏览器页面中的“免费下载”，下载Firefox浏览器安装文件，下载链接如图3-1所示。图3-1（3）下载完成后，在下载文件保存目录会生成一个名为Firefox-latest.exe的文件。（4）双击Firefox-latest.exe文件，按照安装向导进行安装，如无特殊安装路径要求，则不断单击“下一步”按钮即可完成Firefox浏览器的安装。（5）安装完毕后，桌面会显示Firefox浏览器的快捷方式图标。
本书实例所使用的Firefox浏览器版本是33.0.1。3.2 安装Firebug插件
安装Firebug插件的操作步骤如下。（1）双击Firefox浏览器的快捷图标，启动Firefox浏览器。（2）单击浏览器地址栏区域最右侧的按钮，如图3-2所示。图3-2（3）浏览器会显示出弹层，单击弹层界面中的“附加组件”，如图3-3所示。图3-3（4）单击后，Firefox浏览器显示出“附加组件页面”，如图3-4所示。图3-4（5）在页面最右侧的组件搜索框中输入“firebug”，并单击放大镜图标按钮，如图3-5所示。图3-5（6）Firefox浏览器显示出Firebug插件的相关信息，单击右侧的“安装”按钮，Firefox会自动下载和安装Firebug插件，如图3-6所示。图3-6
下载需要一段时间来完成，如图3-7所示。图3-7（7）安装完成后，在插件管理页面中会显示出“禁用”和“移除”两个按钮，如图3-8所示。图3-8
至此，Firebug插件的安装工作全部完成。3.3 Firebug插件的使用
本节主要介绍Firebug插件的使用方法和常用功能。3.3.1 启动Firebug插件
启动Firebug插件的步骤如下。（1）启动Firefox浏览器。（2）方法1：在Firefox浏览器工具栏的最右侧区域单击Firebug插件图标进行启动，如图3-9所示。图3-9
方法2：在显示Firefox浏览器的界面时，直接按下F12键启动Firebug插件。
Firebug插件启动完成后，在Firefox浏览器下方区域会显示出Firebug插件的操作界面，如图3-10所示。图3-103.3.2 Firebug插件的常用功能
1．Firebug插件的配置菜单
启动Firebug插件后，单击图3-11所示的Firebug图标后，会弹出Firebug插件的配置菜单。通过改变配置菜单项设置可以对Firebug插件进行自定义设置，如停用Firebug、隐藏Firebug、改变Firebug的界面位置等。
试读结束[说明：试读内容隐藏了图片]