作者：朱少民
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
轻轻松松自动化测试试读：
前言
去年春天，我应本地一家软件公司邀请，参加该公司软件测试工作改进的座谈会。这次座谈会其实是一次诊断会或咨询会，本地不少知名的专家都去了，包括几所大学有名望的教授。会议的宗旨是帮助该公司改进测试工作，进而提高软件产品的质量，而其中一个议题就是讨论如何开发自动化测试，特别是针对它们的产品，选择合适的软件测试工具。在座谈会之前，该公司已经有了初步计划，欲投资200万元购买惠普公司Mercury系列测试工具，也就是市场上比较流行的LoadRunner、Quick Test Professional（QTP）等。该公司效益比较好，年产值在亿元以上，几百万的投资不是很困难的事。不过，在座谈会上，鉴于该公司从来还没有开展过自动化测试工作，而且公司主要以面向终端用户的软件项目开发为主，虽然将慢慢形成软件产品，但用户的需求不够稳定。我建议，刚开始时，在自动化测试工具上不宜进行过大投资，如果自动化测试实施效果不好，反而比较被动，所以，可以先采用开源自动化测试工具（如 Selenium、JMeter），进行为期半年的实验。如果这些工具能满足企业的需求，就不须要购买商业化工具；即使不能满足需求，在团队对自动化测试有了更深的理解而且能力得到了提升之后，再购买商业工具也不迟。我知道，我的建议被采纳的可能性比较小，但从那时起，我就有写一本自动化测试的书的计划，介绍开源（open source）测试工具，让大家全面了解这些成熟的开源工具，将它们应用于实际测试项目之中，为企业节省大量开支。本书以循序渐进的方式讲解如何开展自动化测试。由于没有自动化工具的大投入所带来的压力，测试人员借助本书和开源工具，能够轻轻松松地开展自动化测试工作。相对于商业工具，开源测试工具能使我们得到更好的锻炼，使企业的特定需求得到更好的满足，为什么呢？因为开源测试工具几乎不提供培训，文档也不全，须要自己进行更多的摸索。经过不断摸索和实践，自己的能力自然提升较快；更重要的是，开源测试工具提供了源代码，如果某些地方不能满足企业的要求，我们可以找到相应的地方对代码进行修改，扩充其功能，使之满足新的需求。自动化测试也是从无到有、由浅入深，逐步走向成熟的。但从国内看，自动化测试还不够普及，没有得到足够的重视，正如Dion Johnson 2007年10月在《Better Software》上发表文章《自动化测试成长（Test Automation Grows Up）》指出的，人们往往把自动化测试当成手工测试的附属品，就像当年把测试当成开发的附属品一样。今天，软件开源运动（open source）蓬勃发展，测试工具可以信手拈来，其投入小，必然使自动化测试快速普及。借助互联网，人们也可以非常方便地分享经验和保持良好的沟通。这一切，都会给自动化测试带来新的发展机遇，将极大地促进自动化测试的快速发展。从 1998 年开始提倡开源软件开始，开源软件在过去十年得到了蓬勃发展，从操作系统Linux、数据库MySQL、编程语言PHP、集成开发环境Eclipse到浏览器Firefox，已渗透到各个领域，并结出了丰硕的果实，得到了业界广泛认可。在软件测试领域，开源软件也不例外，从单元测试、功能测试到性能测试，从Web页面测试到数据库、多媒体、通信等应用领域的测试，以及软件测试管理平台、缺陷跟踪系统等，都可以找到合适的开源测试工具。可以说，目前成熟的开源测试工具可以覆盖整个测试的生命周期，针对各种测试任务，我们都能找到合适的开源测试工具。21世纪软件测试发展的一个重要趋势之一，就是开源测试工具会迅速发展，得到广泛使用，成为商业工具的有力竞争者。开源测试工具最终能和商业工具平分秋色，甚至成为其替代者。开源软件可谓“十年磨一剑”。忽然，我想到了“七剑下天山”，清朝初年，武林高手不断被追捕，天下大乱、天山名宿晦明禅师四位高徒连同三位剑侠——七剑下天山，拯救中原，欲救天下黎民百姓免受清军铁蹄蹂躏。正可谓“无限深情、舍己为人甘替死，绝招雪恨、闯关破敌勇除奸”。所以，我就将本书中重点介绍的7个测试工具比喻为天山七剑——游龙、青干、莫问、日月、竞星、天瀑和舍神，这也是本书的重头戏——从第3章到第9章，共7章。莫问剑 Selenium的Web功能测试，变化无穷、气势磅礴。第3章介绍了Selenium旗下的4大金刚——Selenium IDE、Core、Remore Control和Grid，以及其应用，从而使我们能够有效地完成大规模的、分布式的web应用系统的自动化测试。游龙剑 AutoIT 实施功能测试，灵活快速、削铁如泥。第 4 章在介绍了 AutoIT语法特征之后，通过两个不同类型的完整实例，让我们知道如何借助AutoIT完成Windows客户端软件的自动化测试。舍神剑 JMeter的性能测试，开山辟石、无坚不摧。第5章涉及JMeter的脚本录制和开发，以及如何通过JMeter完成复杂的、分布式大规模压力测试和数据库的性能测试。日月剑 JUnit的单元测试，变化奇快、丰富多彩。第6章介绍了JUnit的单元测试。从持久层和 Action 层的测试到完整的自动化单元测试，JUnit 展示了其魅力，并可很容易地和CVS、Ant等集成起来。竞星剑 EMMA覆盖率分析，出剑神速，迅雷不可目睹。第7章在介绍了覆盖率分析的意义及其常用工具之后，着重讨论了如何通过命令行和Ant集成等应用方式，完成覆盖率的收集和分析。在众多的覆盖率分析工具中， EMMA工具脱颖而出。青干剑 MantisBT管理缺陷，奇钝无比，却可抵挡天下最锋利的武器。第8章全面展示了 MantisBT 的安装及其使用方法，其中也融合了缺陷管理的思想和流程。天瀑剑 TestLink管理测试，无为而为，形无虚实，专一严谨。第9章帮助读者完整地领略软件测试需求、测试用例的管理思路，以及如何通过TestLink具体实施测试计划，进行测试执行和测试结果评估等。在介绍这些工具之前，第 1 章先让大家亲手完成一个简单的自动化测试，然后讲解自动化测试的作用和特点、如何引入自动化测试和如何选择合适的自动化测试工具。然后，用一章的篇幅由浅入深地剖析自动化测试的原理，包括不同对象的识别和各种脚本技术等。在介绍完这些工具之后，一方面介绍不同层次或不同方面的自动化测试框架，帮助读者构建一个完整的、理想的自动化测试框架；另一方面对自动化测试实施进行总结，并和读者进一步分享作者多年来所积累的自动化测试最佳实践经验。本书最后附有所需的测试工具及其相关软件的下载地址、参考资源等。读者还可在 http://files.cnblogs.com/bvbook/轻轻松松自动化测试附录.rar 处下载STAX XML示例文件、Selenium core实例所用的JavaScript代码，以及JMeterJDBCRequest脚本（.jmx）。本书由朱少民策划、主编和审稿，其中第 1、2、8、9、10、11 章由朱少民编写，第3章由刘涛、王鹏和朱少民编写，第4章由史玮编写，第5章由张军编写，第6章由王顺编写，第7章由姜文武编写。在此特别感谢同济大学软件学院常务副院长、ISTQB中国首席代表刘琴博士为本书写序，感谢电子工业出版社博文视点周筠老师的支持和关心，以及几位编辑所倾注的精力和热情，他们的支持使这本书可以早日和大家见面。由于水平和时间的限制，本书难免会存在一些错误，还望见谅并恳请读者提出宝贵意见。朱少民2009年春于合肥引子 案例介绍本书后面主要章节将围绕Liferay这个案例（应用系统）展开，包括Web功能测试、性能测试和单元测试等。Liferay的安装包和文档可以从其官方网站http://www.liferay.com下载。1. LifeRay功能简介Liferay Portal是一套相当成熟的、功能强大的企业级集成应用系统。Liferay Portal作为一个开源的Portal产品，提供了对多个独立系统的内容集成，可以帮助一个企业各个组织（社区）实现更有效的合作。图0-1就是用Liferay自建网站的首页。图0-1 Liferay自建网站的首页Liferay Portal代表了完整的J2EE应用，使用了Web、Struts、Spring、Hibernate、jBPM、jQuery JavaScript框架及JMS等技术，遵循Portlet API JSR168/127/170、AJAX、iCalendar &Microformat、OpenSearch 等各项标准，也遵守开放的 Web 服务标准，如 RMI、WSRP、JSON、REST等，而且LifeRay是JSR-286（Portlet 2.0）和JSF-314（JSF 2.0）标准委员会的成员。基于XML的portlet配置文件可以自由地动态扩展，使用Web Services来支持。LifeRay Portal由Portal服务器、Portlet容器和Portlet构成。● Portal服务器是承载Portlet容器、支持Portlet呈现的Web服务器，可以无缝集成多种数据源（如数据库、各类文档、Web页面等），支持单一登录（Single sign-on）、权限控制、内容管理、信息发布和文件管理等功能，包括采用多种缓存机制、ACL/SSL/LDAP安全技术等。● Portlet容器是普通Web Servlet容器的扩展，提供Portlet执行的环境，一个Portal容器接收到来自Portal的请求后，将请求传递给存在Portal容器的Portlet执行。Portlet容器包含很多Portlet并管理它们的生命周期（即装载、实例化和初始化），保存Portlet的定制信息。● Portlet是Portal中最重要的组件，负责信息内容的呈现。通过自定义Portlet，用户很容易定义个性化的Portal页面。LifeRay的功能也很强大，不仅可以支持标准Portal所支持的功能，而且支持国际化（I18N）和包括中文在内的多种语言、支持各种远程信息的获取，可使用Apahce Lucene实现全文检索功能，并已有大量的应用组件，如wiki、RSS、博客、工作流、投票和许多工具等，如图0-2所示。图0-2 LifeRay各种应用组件列表2. 环境设置LifeRay 能够在主流的 J2EE 应用服务器上运行，如 Tomcat、Jetty、Glassfish、JBoss+Jetty/Tomcat、JOnAS+Jetty/Tomcat 等，支持主流的数据库，如 PostgreSQL、MySQL 和Oracle等。1）安装Liferay的安装十分容易，建议下载Bundled with Tomcat 6.0：下载并解压后，就可直接运行。它会使用自带的HSQL数据库，其中包括一些初始数据和演示数据。因为是用于测试，我们无须更改数据库和用Liferay站点提供的SQL来初始化数据库。数据源由conf\Catalina\localhost中的ROOT.xml设置。此前应安装和配置Java环境。可以去http://java.sun.com/javase/downloads/index.jsp下载相应的JRE或JDK软件包进行安装。Java环境的配置，见本书2.1.1节中的内容。Liferay 安装成功后，运行 bin 目录下的 startup.bat，启动 liferay 系统。打开浏览器输入http://localhost:8080，页面会自动跳到 http://localhost:8080/web/guest/home，出现如图 0-3 所示的界面，说明安装成功。右上角的“Welcome”按钮是显示常用菜单的地方，包括“登入、登出、增加应用、处理页、布局模板、我的地方”等功能的使用。图0-3 LifeRay安装后首次启动的界面2）设置Liferay的可配置性极强，有两种办法：● 通过webapps\ROOT\WEB-INF\lib\portal-impl.jar中的portal.properties来配置，可以建立一个新文件portal-ext.properties，它会覆盖portal.properties中的配置。● 用test@liferay.com （口令是test）登录系统，通过点击“language”中的我国国旗图标设置中文界面，进入企业admin Portlet来配置，包括增加组织、用户群和角色等，如图0-4所示。图0-4企业admin Portlet在设置之前，最好了解 LifeRay 中组织、社区、用户组、用户和角色等之间的关系。组织和社区是并列的，一个社区中会由不同组织的用户来参加，一个组织中某些成员会参加不同的社区，这和现实社会是一致的。每个用户可能会属于一个或多个用户组，被赋予一个或多个角色。角色很多，包括总管理员、社区管理员、社区所有者、社区成员、组织所有者、组织成员和一般用户等。它们之间的关系如图0-5所示。图0-5 LifeRay组织、社区、用户组、用户和角色等之间的关系在一般设置中，可以设定语言和时区，如图0-6所示。而在“认证”项，可以设置是否限制登录、开始账号等，以及设置LDAP、CAS、NTLM、OpenIDden等安全加密选项。图0-6 企业admin中的设置功能除了企业admin，还有另外两个Portlet——“管理者”和“公共”。管理者Portlet用来管理Liferay Portal系统，监测系统运行情况，清理系统缓冲区及关闭系统等。而“公共”应该翻译为“社区”，是用来创建和管理不同社区的。3. 使用注册一个用户给自己用，使用起来简单，可以去“我的地方”，即“公共页面”和私有页面。所以，最常用的功能是：● 增加页面。● “处理页面”——对页面进行配置。● 在页面中增加应用。用户登录后，在网页标签栏右端出现一个“增加页面”的标签，点击并输入一个网页名字，按“存储”按钮即建立了新网页。刚建成的新网页是空白的，须要配置网页类型和外观属性，这就是“处理页面”，如图0-7所示，然后在页面中增加应用。图0-7 处理页面的界面对网页进行配置处理，配置网页的类型、外观与风格（Look and Feel）、访问权限、子网页和网页排列顺序等。在外观与风格中的“规则浏览器”是指普通电脑的浏览器，因为Liferay Portal可以向手机和PDA等移动上网设备提供服务。Liferay Portal的网页定义了6种类型。● Portlet：网页内容由Portlet组成。● Panel：将网页划分成左右两版，左侧显示选定的Portlet应用列表（树形菜单），右侧显示左侧列表中指定的一个Portlet应用。● Embedded：本网页内嵌入指定网址（由URL栏指定）的网页。● URL：脱离当前网站，将本网页直接跳转到指定的网址上。● LinktoPage：将本网页链接到本网站的某个网页上。在“LinktoPage”栏选择要链接的网页。● Article：本网页显示指定的期刊文章内容，由ArticleID栏输入的期刊文章的ID号决定。第1章 自动化测试入门软件测试在软件生命周期中占有很重要的位置，而且软件测试的工作量很大，根据有关研究，软件测试占整个软件项目工作量的40％～60％。所以，测试人员总怀有一个愿望，即由计算机自动完成测试的全部工作。产生这样的愿望是很自然的，因为当初发明计算机就是为了帮助我们完成各种各样的复杂计算，代替手工劳动。后来，计算机应用越来越广泛，例如帮助我们构建自动化生产线、数控机床和交通运输自动控制系统，计算机系统成为名符其实的自动化工具。软件是计算机系统的灵魂，当进行软件开发和测试时，我们很自然会产生自动化测试的想法。自动化测试，简单地说，就是用软件测试工具来自动完成测试。我们也就是想用一个软件去操作和监控正在开发或将来要开发的软件，或者说先开发一个简单的软件工具，然后再用这个工具去检测一个又一个复杂的应用软件系统。这就是自动化测试最朴素的理想，想法简单、自然，但是，当我们深入下去，就会有很多问题要问自己，促使我们去思考，例如：● 究竟什么是自动化测试？● 自动化测试有什么优势？● 自动化测试是不是投入很大？● 如何选择测试工具？如果把这些问题都想清楚了，就能够全面地、真正地理解自动化测试，将来能轻轻松松地实施自动化测试，实现自己的理想。1.1 初识自动化测试如果以前没有做过自动化测试，那么就不了解自动化测试，可能会觉得自动化测试比较神秘。但是，我们在日常的计算机操作中，可能会碰到一些自动化处理的过程，这些过程和自动化测试比较接近。下面两个简单的例子，可能对理解自动化测试会有所帮助。1.1.1 自动化处理并不陌生自动化处理过程，还是比较常见的，例如，在Windows操作系统的控制面板中，有一项功能——任务计划向导，可以预先安排一个定期自动执行的任务，如图1-1、图1-2所示，可以按照“每天、每周、每月、一次性或系统启动时、用户登录时”等方式来事先安排某些待执行的任务。等到事先设定的条件满足时，任务会被系统自动地执行。图1-1 Windows自动执行任务的安排图1-2 事先已安排好的任务除了预定任务的安排和执行，DOS 批处理文件也是一个很好的自动化处理的例子，直到今天的Windows Vista还在使用它。它更接近自动化测试，类似于后面介绍的自动化测试脚本。批处理文件中的命令行包括参数、判断条件、注释行、输入和输出等内容，如 Apache 启动的批处理文件，其代码如下。概念测试用例（test case）是为了特定测试目的（如检查程序是否出错或验证某个产品特性）而设计一个特定的使用实例或场景，包括测试条件、测试数据及与之相关的测试规程或操作过程。测试用例也可以被称为有效地发现软件缺陷的最小测试执行单元。测试脚本（Test script）是进行自动化测试时所编写的、可执行的一种程序，以实现测试用例的执行过程。测试脚本一般由解释性的程序语言（脚本语言）来编写，如Perl、Tcl/Tk、Shell、Python、Ruby和Javascript等，也有一些测试工具特有的脚本语言，如类似于VB的SQABasic等。采用何种脚本语言是与测试工具相对应的。1.1.2 一个简单的自动化测试过程上述的自动化处理过程还不是测试，因为测试的重要一点是须要验证，将实际执行的结果和用户期望的结果进行比较。没有这个比较，就不是自动化测试。下面，让我们亲自动手完成一个简单的自动化测试过程，以便获得测试自动化的感性认识，进而揭开自动化测试的神秘面纱。1. 下载和安装测试工具首先去http://seleniumhq.org/projects/ide/下载Selenium IDE，点击右页上部的链接“download now”，下载其最近的一个版本（本书使用的是1.0 beta 2，2008年6月发布）。在安装Selenium IDE之前，要准备好Firefox（火狐）浏览器，Firefox可以从http://www.firefoxplus.org/下载。安装Selenium IDE很容易。如果是用Firefox下载的，浏览器会自动提示安装，点击“立即安装”按钮就能完成安装。如果事先已下载类似“selenium-ide-1.0-beta-2.xpi”的文件，就用Firefox的“打开文件”菜单功能，打开已下载的xpi文件，安装Selenium IDE。安装成功后，重启Firefox，菜单“工具”下会出现“Selenium IDE”，如图1-3所示。图1-3 FireFox工具菜单点击“Selenium IDE”，启动Selenium IDE，出现主界面，可以展开左边测试用例（test case）列表窗口，默认是不展开的，展开后的界面如图1-4所示。左边测试用例的脚本直接显示在右边脚本窗口。这里只完成一个例子，可以合上左边窗口。图1-4Selenium IDE的界面2. 录制测试脚本打开SeleniumIDE，默认处在录制状态。如果不是，就点击录制操作按钮。去Firefox打开Google首页www.google.cn，输入“用Selenium进行自动化测试”，点击“Google搜索”按钮，进入搜索结果页面，然后选择搜索结果页面中的“www.ibm.com”，点击右键，如图 1-5 所示，选择倒数第3项“verifyTextPresnt www.ibm.com”，验证“www.ibm.com”会在搜索结果中出现。图1-5 对搜索结果进行验证操作界面同样，选择“有9 310项符合”和“搜索用时 0.38 秒”，进行同样的操作，即共进行3项验证。测试本身就是验证的过程，通过期望结果和实际结果比较，我们才能判断是否会出现缺陷。这里只是一个演示，所以简单地选择这3项内容作为将来验证的期望值。然后点击第1个搜索结果，结束录制，即点击按钮。录制的脚本可以在“脚本窗口”浏览，如图1-6所示。图1-6 脚本录制完毕后的界面3. 执行测试脚本完成了脚本录制，就可以执行脚本（也称脚本回放）。先将回放速度调整慢些，从而使执行过程看得更清楚些，即将中绿色游标向“slow”移动。然后，点击按钮，就开始执行脚本。我们会看到浏览器自动打开www.google.cn的首页，自动输入“用Selenium进行自动化测试”，搜索结果页面很快显示出来，脚本执行结束。4. 测试结果运行结果如图1-7所示，从中可以看出，前面两个验证结果通过，显示为绿色，而第3个验证“verifyTextPresent 搜索用时0.34秒”失败，显示为红色。为什么失败呢？因为Google每次搜索用时是不一样的，再次执行脚本的时候，用时只要0.04秒，会显示“搜索用时 0.04 秒”，导致第3个验证失败。查询日志（Log），可以看到红色的信息“[error] false”，说明验证失败。而且发现另一个操作，点击link也没成功，主要是链接页面已跳出基准URL（站点），不在Selenium IDE的控制范围。如果点击“高级搜索”链接，就没问题，你可以自己试试。这其中的原因，在第3章会做详细解释。图1-7 运行结果界面（参见彩图1）1.2 自动化测试和手工测试有什么不同亲手做过上述的自动化测试之后，我们对自动化测试就有了一个感性的认识，至少有下列几点感觉：● 自动运行的速度快，是手工无法比的。● 测试结果准确。例如搜索用时即使是0.33秒或0.24秒，系统都会发现问题，不会忽视任何差异。● 一旦脚本完成，可以一劳永逸地运行很多遍，重复使用。从这里就可以初步体会到自动化测试的优越性——高效率、准确可靠和复用性。如果再展开讨论，我们就会发现自动化测试的更多益处。例如，手工进行测试会感觉累，而且一个人一天正常工作时间是8小时，最多工作十几个小时，而机器不会感觉累，可以不间断工作，每周可以工作7天、每天可以工作24小时。其次，计算机可靠，对同一个被测系统、用相同的脚本进行测试，结果是一样的；而手工测试容易出错，甚至有些用例没被执行，人可能有意无意出错。最后一点，有些手工测试做不到的地方，自动化测试却可以做到。例如，对一个网站进行负载测试，要模拟1000个用户同时（并发）访问这个网站。如果用手工测试，需要1000个测试人员参与，对绝大多数软件公司是不可能的。这时，如果让机器执行这个任务，假如每台机器能同时执行20个线程，只需要50台机器就可以了，而且启动之后，测试工具会自动运行和监控整个过程。根据自动化测试的运行速度快、可靠、准确、从不疲惫和可多次重复使用等特点，可以知道——自动化测试有助于软件开发提高效率和产品质量、缩短周期、节省人力资源等。但同时也应看到，机器执行测试用例是按部就班进行的，没有变通的余地，缺乏创造力，而手工测试过程中，人具有创造性，容易受到前面操作或结果的启发，能举一反三，发现更多的问题。有资料显示，即使自动化测试实施良好，也只能发现软件系统中 30％的问题，而 70％的问题还要靠手工测试发现。所以自动化测试更适合于负载测试、性能测试和回归测试。概括起来，通过自动化测试，软件企业可以获得许多好处。● 测试周期缩短，因为自动化测试效率高、能够长时间不间断地运行。● 完成更多的测试，实现更高的测试覆盖率，保证测试的一致性，提高测试的可靠性，最终获得更高质量的软件。● 更高的测试团队士气，因为有更多机会学习编程、获取新技术；同时，自动化测试使测试工作变得更有趣。概念● 负载测试（Load Test），也称压力测试（Stress test）、强度测试。负载测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，逐渐加载或一次性加载、长时间或超大负荷地运行软件，以测试系统的稳定性，并试图找出系统性能瓶颈、异常的地方等。通过负载测试，也可以确定系统的正常工作条件、极限条件等，了解系统可靠性，从而提高软件系统的可靠性、稳定性，减少系统的宕机时间。● 性能测试（Performance test），通过测试确定系统运行特性的性能指标数据，如数据吞吐量、响应时间、CPU 使用率等。性能测试主要是为了获取或验证事先（如产品规格说明书）已定义的各项性能指标，测试的操作方式和负载测试相近，但结果和目的不一样。● 回归测试（regression test），由于软件修改或变更，对修改后的工作版本所有可能影响的范围进行的测试，回归测试的目的是发现原来正常的功能特性出现新的问题——回归缺陷，从而确保原来正常的或符合要求的特性，不受其他区域修改的影响。回归测试，伴随着测试过程，功能测试和系统测试、单元测试和集成测试中，一旦有变更或修正，都要进行相应的回归测试。1.3 什么是自动化测试谈到自动化测试，一般就会提到测试工具。许多人觉得使用了一两个测试工具就是实现了测试自动化，这种理解是不对的，至少是片面的。的确，测试工具的使用是自动化测试的一部分工作，但“用测试工具进行测试”不等于“自动化测试”。那什么是“自动化测试”呢？自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程，即模拟手工测试步骤，通过执行程序语言编制的测试脚本自动地测试软件，自动地完成软件的单元测试、功能测试、负载测试或性能测试等全部工作。自动化测试集中体现在实际测试被自动执行的过程上，也就是由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。自动化测试，虽然须要借助测试工具，但是仅仅使用测试工具不够，还要包括与之相适应的测试运行机制、流程和其他基础设施的支持。如果仅仅使用工具进行测试，可能只是起辅助测试作用，或者只是完成测试工作的一小部分任务，且这个测试执行过程可能是半自动的，而不是全自动的。实际上，对于自动化测试有两种说法——“自动化测试”和“测试自动化”。它们之间存在某些微妙的差别，如果严格加以区分，可以看作是两个概念：概念● 自动化测试（Automated Test），侧重说明由测试工具自动地执行某项软件测试任务，自动化处理范围比较小。例如通过某个软件工具完成应用系统的功能测试和性能测试等测试执行工作，而测试的计划、设计和管理等其他工作还是由手工完成的。● 测试自动化（Test Automation），侧重说明整个测试过程都由计算机系统自动完成，体现了更理想的自动化思想，有更广的范畴和更大的挑战。它不仅要求由工具完成测试的执行，而且要求测试的设计和管理也能由系统自动完成，例如基于模型实现测试设计的自动化、基于软件设计规格说明书实现测试用例的自动生成、基于数据库系统实现测试管理的自动化等。根据这样的描述，测试自动化的要求相对来说高得多，即要求所有的测试工作都由计算机系统自动完成，包括：● 测试环境的搭建和设置，如自动上传软件包到服务器并完成安装；● 脚本自动生成，如根据UML状态图、时序图等生成可运行的测试脚本；● 测试数据的自动产生，例如通过SQL语句在数据库中产生大量的数据记录，用于测试；● 测试操作步骤的自动执行，包括软件系统的模拟操作、测试执行过程的监控；● 测试结果分析，实际输出和预期输出的自动对比分析；● 测试流程（工作流）的自动处理，包括测试计划复审和批准、测试任务安排和执行、缺陷生命周期等自动化处理。● 测试报告自动生成功能等。这样，测试自动化意味着测试全过程的自动化和测试管理工作的完全自动化，是测试工程师所追求的一种理想境界。如果使整个软件测试过程完全实现自动化，而不需要丝毫的人工参与或干涉，这是不现实的。虽然不能完美地实现测试自动化的这种理想境界，但是，我们可以每时每刻向这个方向努力，不断地问自己——这些测试工作能否由软件系统或工具来自动完成？在测试计划、设计、实施和管理的任何时刻，始终寻求更有效、更可靠的方法和手段，以有助于提高测试的效率。所以，有人更希望将测试自动化解释成“能够使测试过程简单并有效率、使测试过程更快捷而没有延误的方法或努力”。从这里可以认识到，“全过程的自动化测试”思想是非常重要的，会改变我们测试工作的思维，改变我们测试的生活，将测试带到一个新的境界。在日常工作中，人们并不严格区分“自动化测试”和“测试自动化”这两个概念，而是将它们视为同一个概念。自动化测试是通过工具或程序来对软件进行自动测试，避免大量的手工操作，而只要很少的人工干预或调整。自动化测试是相对手工测试而存在的，所以自动化测试的真正含义可以理解为“一切可以由计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行”。它包含了下列3层含义。● “一切”，不仅仅指测试执行的工作——对被测试的对象进行验证，还包括测试的其他工作，如缺陷管理、测试管理、环境安装、设置和维护等。● “可以”，意味着某些工作无法由系统自动完成，如脚本的开发、测试用例的设计，需要创造性，其工作需要手工处理。● 即使由系统进行自动化测试，还少不了人工干预，包括事先安排自动化测试任务、测试结果分析、调试测试脚本等。自动化测试，理应从提高工作效率和产品质量的根本目标出发，而不是为了自动化而自动化。在某些时候，如果过分追求测试自动化的完美性，也可能得不偿失，即投入过大，而产出远远小于投入。脱离了自动化测试的根本目标，测试人员可能会变成自动化测试的奴隶。实际上，自动化测试和手工测试往往交织在一起，相互补充，工具执行过程须要人工分析，手工测试时也可以借助工具处理某些数据、日志或显示某些信息。也就是说，不是试图用自动化测试来代替所有的手工测试，而应尊重手工测试，尽量采用自动化测试。1.4 自动化测试的引入在进行自动化测试之前，人们往往会有许多疑问，例如，常常会问下列问题。● 从什么地方开始、从哪里入手？● 在进行自动化测试前要做哪些准备？● 测试管理如何适应自动化测试的需求？● 如何确定自动化测试范围？● 如何选择测试工具？● ……在自动化测试前，确实要做一些准备。如果从个人看，要在技术上做些准备，同时选择合适的测试工具、准备相应的自动化测试支撑环境。而对软件企业来说，需要进行更多的准备，包括思想、流程和人才等多个方面。最重要的是得到软件组织内部管理层的全力支持，对研发流程进行适当的调整，以适应自动化测试所带来的变化。其次，还要对测试人员进行相应的培训，包括编程能力、开发工具使用等方面的培训，以适应测试脚本或工具开发的能力要求。理想情况下，自动化测试需要相对独立的测试环境。当手工进行测试时，测试环境容易发生变动，这样可能对测试工具的执行带来较大的影响，使自动化测试的执行不够稳定。测试环境的建立，须要考虑硬件和软件，但不同的项目和不同的应用环境差异很大，须要具体问题具体对待。1.4.1 思想准备思想决定行为，树立正确的软件测试自动化的观念是非常重要的。例如，思想上高度重视自动化测试的方法，辩证地看待自动化测试和手工测试各自的优势和劣势，而不会认为可以百分之百地实现自动化测试或测试自动化可以完全代替手工测试。如果对自动化测试期望过高，容易急于求成、操之过急，反而不能获得成功。期望越高，失望就越大。在克服自动化测试所面临的困难上，也要有足够的心理准备。在实施自动化测试过程中，会遇到各种困难，包括技术上的障碍、项目进度的压力和流程上的挑战。例如，Windows应用程序的界面，某些对象不是标准的Windows控件，而是自绘的，就很难被测试工具识别，这种软件的不可测试性，不是由测试人员决定的，而是由开发人员决定的，要解决这类问题，相对困难一些。测试工具没有智能特性，所以不要寄希望于自动化测试可以发现大量新缺陷。如果想让自动化测试完成所有新功能的测试，是要冒很大风险的。实践证明，自动化测试适合对已有功能的验证，即适合回归测试。如果在思想上期望自动化测试方案解决目前所有遇到的问题，可能会带来更大的问题。例如，测试自动化可以将某些测试流程和管理方法固定下来，融入自动化管理系统中。但是，如果原来就缺乏有效的方法和流程，很难通过自动化测试来从根本上解决这方面的问题。如果寄予不切实际的希望，反而会导致软件产品质量的降低。总之，正确的思想是辩证地看待自动化测试和手工测试之间关系，将自动化测试和手工测试有机地结合起来，充分发挥各自的优势，从而使测试工作达到最佳平衡。1.4.2 引入自动化测试的流程引入自动化测试，除了在思想上有所准备，还要确定哪些项目、项目的哪些测试任务适合实施自动化测试。虽然自动化测试可以无处不在，在不同的测试阶段或不同的测试类型上都能开展自动化测试工作，但是有些测试项目不宜进行大规模的自动化测试，有些测试工作不适合自动化测试，要具体问题具体分析。不同的测试任务，要选用不同的自动化解决方案。单元测试和开发结合非常密切，其自动化测试一般要建立在集成开发环境之上。功能测试和系统测试有较大的差别，例如功能测试须要关注图形用户界面（Graphical user interface，GUI），GUI又是软件中变化比较大的部分，而性能测试，可以设法避免GUI变化所带来的影响，采用底层通信或应用程序接口（Application Programming Interface，API）等方式来实现和系统的交互作用。所以，针对不同的测试任务，其自动化测试的实施，自然会有不同的考虑。实施自动化测试，很重要的一点就是选择合适的自动化测试工具。不同的应用环境，要选择不同的测试工具。例如，单元测试工具和编程语言、开发环境有着密切关系，针对.Net 或 J2EE开发环境，会选择相对应的C#或Java的单元测试工具。不同的测试阶段或不同的测试任务，也会选择不同的工具，如功能测试工具、性能测试工具等。即使对某一特定的测试任务，也有较多的测试工具供选择，这时就要充分地评估测试工具，包括确定工具评估的指标、采取哪些关键业务来检验工具及试用等，从而做出正确的决策。概括起来，在测试自动化引入的过程中，要遵守一个有效的流程，如图1-8所示，才能达到所期望的目标。图1-8 选择测试工具的流程1.4.3 自动化测试范围的考量自动化测试虽然可以用在任何地方，不论是功能测试、性能测试，还是缺陷管理、测试用例管理和测试环境部署等，都可以采用测试工具或系统来处理。但是，自动化测试有其局限性，有某些特定的适应范围，而不适合其他一些应用场合。这就要求我们好好考量自动化测试的范围。自动化测试无法处理一些模糊结论的判断和验证，而适合非常明确的任务，以解决某个特定的问题。例如，自动部署某个服务器软件包、软件包中所有文件版本的校验、进行文件中链接检查等，这些任务都很清楚，相应的脚本就比较容易开发，而且将来脚本也容易维护，自动化测试应用起来会一劳永逸。1. 周期短或一次性的项目在实施自动化功能测试过程中，往往须要开发大量的测试脚本，而脚本开发的工作量大。如果项目周期很短，可能到项目快结束时脚本还没有完成调试或脚本还不能稳定运行，所以针对周期短的项目，功能测试不宜采用自动化测试方法，而采用手工方法会更好些、成本也会更低。性能测试的自动化测试脚本简单、量也少得多，其脚本开发能很快完成，而且性能测试又很难通过手工完成，所以，对周期短的项目，一般还是借助测试工具来完成性能测试。代码的静态测试和安全性测试，一般也通过工具对代码自动扫描来完成，所以其自动化工作也适合任何类型的项目。也正是因为自动化测试脚本开发的工作量很大，在一个项目中很难收回脚本开发的投入成本。曾经做过一次测算，功能自动化测试的投入成本，需要在 3～4 个版本开发之后收回，所以对一次性项目的功能测试，自动化测试解决方案的投入产出率是很低的、不合算。如果是软件产品开发项目，产品的版本会不断升级，其开发过程是长期的任务，会延续几年甚至十几年，所以适合自动化功能测试。2. 新功能测试和回归测试工具本身没有想象力和灵活性。根据经验报道，自动测试只能发现30%以下的缺陷，而手工测试可以发现70%以上的缺陷。从这一点延伸出去，我们可以理解，自动化测试工具对新开发的功能进行测试的能力比较弱，不容易发现程序中各种各样的缺陷，改善测试用例的能力也很弱。所以，自动化测试一般不适合新功能的测试，而适合回归测试，胜任对原有功能的验证工作，保证准确、客观地不断重复原有的测试。3. 自动化测试和手工测试应用范围的对比在充分利用自动化工具、全力进行自动化测试的同时，牢记不要追求 100%的自动化，手工测试仍然至关重要。对高风险的模块或领域要进行更多的人工测试。根据手工测试和自动化测试的各自优势，对人工测试和自动测试区别对待，进行有效分工。根据自动化测试特点及上述分析，相对手工测试，可以确定自动化测试的不同的应用场合，如表1-1所示。概括起来，任务越单调，自动化测试越适合；重复性越大，自动化测试越适合；越容易量化，自动化测试越适合。表1-1 自动化测试和手工测试的应用场合对比1.4.4 区别对待不同的测试阶段单元测试、集成测试、系统测试和验收测试等不同的测试阶段，虽然都可以采用自动化测试来完成，但自动化测试的程度不一样。● 在单元测试中，自动化测试工具和开发工具集成在一起，自动化测试程度比较高，而且比较全面。如前面所说的，代码的静态扫描，可以充分利用测试工具来完成。而单元的功能测试，一般可以借助单元测试框架实现，但须要写大量的测试脚本或测试代码，手工的工作量不小，这也是许多软件公司的单元测试覆盖率总是不够高的主要原因。● 在集成测试阶段，自动化测试工具的作用是间接的，不是直接的、主动的。多数测试组织不是通过测试工具验证模块之间的接口，而是通过基本功能的验证来验证系统的集成，即通过BVT来完成每日测试，以满足每日构建、每日集成（持续集成）的需要。● 在系统测试阶段，人们首先会将自动化测试运用在性能测试、压力测试、可靠性测试中，而在功能测试中，自动化测试的投入会比较谨慎。功能测试中逻辑、数据和API等验证，比较适合自动化测试，而GUI界面、易用性等测试，更宜由手工完成。● 在用户参与的验收测试中，一般不宜采用自动化测试。同样，针对软件界面操作友好性、易用性的测试，自动化无能为力，必须由手工完成测试。不同的测试阶段，自动化测试的方法和程度都是不一样的，可以通过表1-2给予总结性的描述。表1-2 自动化测试在不同测试阶段的应用1.4.5 如何评估测试工具满足测试任务及其特点的测试工具可能会比较多，我们须要考虑对它们进行评估，选择出正确的测试工具。如何评估测试工具呢？人们可能会想到下列这些指标：● 工具的功能是否强大，或者是否满足需求？● 价格是否合适、在预算之内？● 性能价格比如何、是否数一数二？● 工具的质量，工具运行是否稳定?● 目前的用户量或是否流行?● 和其他测试工具的兼容性、集成是否容易?● 技术支持和服务是否及时、方便?的确，工具的选择要考虑很多的因素，从功能、质量、服务等各个方面找出影响其评估的因素，然后为每个因素设定权重值、打分，最后根据每个工具获得的总分来做出决定。有时候，工具的选择也没有那么复杂，而是根据市场决定，市场哪个流行就选择哪个。市场流行，自然也有其优势，这样做也不无道理。但这样做，具有盲目性，毕竟功能最强的工具不一定适合自己，最合适的工具，才是最好的。即使排除价格、服务等因素，单就软件功能，考虑具体功能特性也不是一件简单的事情。如以功能测试工具为例，须要考虑下列众多因素。● 是否简单易用；● 是否有脚本录制和回放功能；● 是否具有很强的GUI对象识别能力或提供单独的对象识别、查询功能；● 是否支持不同的脚本语言（如VB、Javascript、Perl、Python等）；● 脚本语言是否支持数据驱动和关键字驱动的结构；● 脚本语言是否支持外部函数调用、函数可重用和自身脚本引用等特性；● 是否支持跨平台，如是否支持Windows/Mac/Solaris/Linux等不同的操作系统；● 是否支持国际统一编码Unicode（如UTF-8）；● 脚本开发是否具有良好的集成环境（如IDE），包括脚本调试功能；● 是否支持分布式、远程调用等运行方式；● 测试结果显示是否直观，如是否具有常用的统计图表、曲线分析手段。一般来说，测试工具的功能越强，对测试自动化工作越有利，我们会优先考虑。但是，有时须要一分为二地看待问题，功能简单，容易上手；而功能太强，应用起来复杂，培训成本也很高，而且其中一些功能又很少用。例如，脚本语言的功能强大（如类似于C语言的脚本语言），一方面能够为测试人员提供更大的发挥空间、使脚本具有更强的处理能力，另一方面掌握这样的脚本语言要困难得多。在充分考虑了测试工具的功能特性之外，还要考虑测试工具的成熟性（如版本至少是1.0以上，而不是0.4、0.8等Beta版本）、版本升级是否持续、团队能力、受资助的背景、社区活跃度等因素。我们建议将开源测试工具作为首选目标。如果开源测试工具应用一段时间之后，确实不能满足自己的需求，可以考虑选择商业化的测试工具。实际上，如果发现工具不能满足自己的需求，因为是开源工具，完全可以对它进行修改（二次开发），增加相应的功能特性，从而满足自己的特定需求，这也是开源测试工具的魅力所在。千万不要一开始就用巨资引入商业化的测试工具，那样测试人员压力太大，急于求成，反而效果不好，要么测试工具成了摆设，要么从此以后再也不敢提“自动化测试”。在选择测试工具的过程中，不要过早地下结论。最好对同类工具的几个产品同时进行试用和评估，比较它们的优缺点，最终做出比较明智的、正确的选择。选择开源工具，其中一个关键因素——价格，不须要考虑，无须做性能价格比的分析，更不须要和厂商进行艰难的谈判，省去了不少工作量。当然，我们还须要考虑测试工具的生命力，测试工具的研发由哪家公司或基金会支持、现在是否能得到及时更新和升级等因素。例如，前面介绍的Selenium是由Autoriginate、Contegix、ThoughtWorks等资助的，其中ThoughtWorks是开源世界、软件工程领域（敏捷方法）中大名鼎鼎的公司，而且Selenium的创始人之一——Jason Huggins加入了Google，可能在将来的一天Selenium会得到Google的大力支持，其研发经费就更有保证。开发团队由70多人组成，版本能不断得到升级，工具也逐渐走向成熟，并形成一个较完整的体系，其社区也非常活跃，如图 1-9所示。图1-9 OpenQA社区我们再看一个例子，Jmeter是由Apache软件基金会（Apache Software Foundation）资助的，而且有很强的开发团队、严格的缺陷管理，版本能得到持续不断的升级，所以我们对 JMeter 非常有信心。这也就是为什么本书选择Selenium和JMeter作为主要被介绍的测试工具的原因之一。1.5 如何选择合适的测试工具在上一节，我们就如何启动自动化测试工作及选择测试工具的总体思路进行了讨论。但测试工具的选择，还须要从某类具体的工具着手，对症下药，才能达到期望的目标。一般来说，测试工具可以分为：● 单元测试工具，包括静态测试工具和动态测试工具；● 功能测试工具，包括web功能测试工具、Windows客户端功能测试工具等；● 性能测试工具，包括负载测试工具、压力测试工具等；● 测试管理工具，包括缺陷、测试用例和计划等管理工具；● 其他测试工具，如安全性测试、多媒体测试等。下面以开源工具为例，分门别类进行讨论。1.5.1 单元测试工具的选择出于效率和可行性考虑，单元测试一般由编程人员来完成，测试人员可以辅助开发人员进行单元测试。单元测试和编程保持同步，一边编程、一边测试。例如每完成一个函数的代码，就对这个函数进行测试，用不同的参数来调用这个函数，检查返回值是否正确。只有确认这个函数可以正常工作、没有问题之后，才写下一个函数。所以单元测试的工具应能和开发平台很好地集成起来，用什么编程语言就要选用对应这种编程语言的单元测试工具，例如：● 如果用Java进行编程，就要选用Java的单元测试工具JUnit（www.junit.org）和TestNG(testng.org)，而且JUnit和TestNG可以作为Java集成开发环境（IDE）Eclipse的一个插件，和Eclipse无缝集成，如图1-10所示；● 如果基于.Net 进行软件项目开发，就要选用适合编程语言 C#的单元测试工具，如 NUnit（www.nunit.org）、NUnitForms*等；● 如果基于PHP的web应用程序开发，就可以选择PHPUnit作为单元测试工具。● 如果针对C/C++语言编写的程序，就要选择相应的C/C++单元测试工具CppTest* 、Cgreen*和Check等；● 如果只是进行纯页面的开发，针对HTML文件的table、form、link 等元素进行测试，则单元测试工具选择HtmlUnit*。这类单元测试工具，须要运行代码、检查运行的状态和结果，一般被称为动[1]态测试工具 。试读结束[说明：试读内容隐藏了图片]