谈自动化测试

自动化测试的必要性

测试有很多种类型：单元测试，集成测试，接口测试，功能测试，安全测试，性能测试，可靠性测试，界面测试等很多种。

项目成立之后，随着需求不断增多，需求也可能存在变更，有一个问题：老的需求功能怎么守护?怎么回归?最省事的方法就是有工具来帮你自动跑用例并输出报告。

你可能会说人工执行下也是可以的，但随着时间推移，测试人员的变更，老的功能需求不一定很熟练甚至是需要学习的成本。再说了人会挑剔的，总是测试老功能，时间久了或者次数多了会烦的，总是要学习新东西。

人的上班时间是朝九晚五，测试工具就不一样了，7*24小时运行也是可以的。同一套测试环境，白天人工测试新功能，晚上自动测试回归老功能，可以充分利用资源和加速测试进度。

人工测试有些是比较繁琐的：1) 操作重复和统计数据繁琐：比如每个迭代都要手工点击每个界面每个按钮进行测试，如果采用录制方式进行界面测试，一次录制可以不断用来测试，是不是比较节省人力，这当然有个前提界面变化不大。界面响应时间也是测试必须采集的数据，人工一个个统计并计时是很繁琐，告诉工具统一的方法或原则，这些数据很容易拿动的；2) 有现成的自动测试工具和通用的自动化测试用例，何必人工测试：比如安全测试，代码的安全扫描，端口扫描是否有被攻击的漏洞，web扫描是否有被攻击的漏洞等等；3) 有些场景是人工操作不来的，只能通过自动化工具来模拟：比如性能压力测试，模拟几百个到几千个并发测试，建立整系统和某个模块的性能测试模型，整个系统的性能压力可以通过自动化来守护住产品发布的要求，部分模块的性能压力可以慢慢的探索。

自动化测试有它自己的好处也有其缺点：首先是可靠、准确、从不疲惫和可多次重复使用等优点，有助于软件开发提高效率和产品质量、缩短周期、节省人力资源等。但机器执行测试用例是按部就班进行的，没有变通的余地，缺乏创造力，其次自动化用例中出现用例错误尤其是用例校验错误说不定会一直错下去。而手工测试过程中，人具有创造性，容易受到前面操作或结果的启发，能举一反三，发现更多的问题。有资料显示，即使自动化测试实施良好，也只能发现软件系统中30%的问题，而70%的问题还要靠手工测试发现。所以自动化测试更适合于负载测试、性能测试和回归测试。——摘自朱少民老师的《轻轻松松自动化测试》。

当然了，测试自动化是需要投入大量人力的，比如将文本用例转化为相应的自动化用例，写自动化用例需要熟悉自动化工具甚至要学习编程语言，写的用例要满足制定的自动化规范，后期自动化用例的维护比如每日CI分析每个迭代自动化分析和根据需求变更进行自动化用例的调整等等。

以上的投入是必要的，可以根据项目的真实情况，合理安排人力来节约部分人力，比如固定的自动化分析人员和自动化用例维护人员，固定的自动化工具开发人员，手工测试某功能的人员直接编写自动化用例，成立自动化委员会制定自动化用例提交流程和自动化用例规范等等。

自动化是比较消耗人力的，但长期来看收益是大于投入的。自动化过的人，尤其是测试经理项目经理，都是懂这个道理的。自动化不分早晚，根据项目自身情况进行自动化用例编写，建议在每个需求交接时完成自动化用例编写和提交，当然也可以根据功能接口设计提前写好自动化用例，功能交付后再补自动化用例也是可以的，原则上越早越好收益也越多。

朱少民老师给的建议：1) 功能自动化测试的投入成本，需要在3～4个版本开发之后收回，所以对一次性项目的功能测试，自动化测试解决方案的投入产出率是很低的、不合算。如果是软件产品开发项目，产品的版本会不断升级，其开发过程是长期的任务，会延续几年甚至十几年，所以适合自动化功能测试。2) 自动化测试一般不适合新功能的测试，而适合回归测试，胜任对原有功能的验证工作，保证准确、客观地不断重复原有的测试。3) 任务越单调，自动化测试越适合；重复性越大，自动化测试越适合；越容易量化，自动化测试越适合。

自动化测试工具选型

1. 以功能测试工具为例，需要考虑下列因素。

1) 是否简单易用，考虑学习成本；

2) 是否有脚本录制和回放功能，考虑用例编写成本，一次录制即可；

3) 是否具有很强的GUI对象识别能力或提供单独的对象识别、查询功能，考虑web界面测试；

4) 是否支持不同的脚本语言（如VB、Javascript、Perl、Python等）， 考虑二次开发；

5) 脚本语言是否支持数据驱动和关键字驱动的结构，考虑测试数据构造和关键字封装提取；

6) 脚本语言是否支持外部函数调用、函数可重用和自身脚本引用等特性；

7) 是否支持跨平台，如是否支持Windows/Mac/Solaris/Linux等不同的操作系统；

8) 是否支持国际统一编码Unicode（如UTF-8）；

9) 脚本开发是否具有良好的集成环境（如IDE），包括脚本调试功能；

10) 是否支持分布式、远程调用等运行方式；

11) 测试结果显示是否直观，如是否具有常用的统计图表、曲线分析手段。

12) 是否支持消息并发操作

13) 是否支持多种类型的消息发生，比如rest、snmp、http、https和soap等消息。

朱老师建议将开源测试工具作为首选目标，是非常有道理的。如果开源测试工具应用一段时间之后，确实不能满足自己的需求，可以考虑选择商业化的测试工具。实际上，如果发现工具不能满足自己的需求，因为是开源工具，完全可以对它进行修改（二次开发），增加相应的功能特性，从而满足自己的特定需求，这也是开源测试工具的魅力所在。

一般情况下，也会选择自研的测试自动化工具，如果有人力，自研的测试工具更适合二次开发，甚至支持更多的功能。

2. 性能测试工具

当我们谈到开源软件阵营中的负载测试或性能测试工具时，首先会想到的是Apache JMeter，它最初是为了Web应用而开发的性能测试工具，但现在已扩展到其他应用领域，如数据库、邮件服务器、SOAP或LDAP服务器等。JMeter可以针对许多不同的静态资源和动态资源（Servlets、Perl脚本、Java对象、数据查询和FTP服务等）进行负载测试或性能测试，也可以进行非用户界面（non-UI）的功能测试。

选择性能测试工具时，主要考虑是否支持多种通信协议或服务器类型、是否支持不同的负载模式、是否有良好的系统资源监控机制和报表生成机制。

一些开源性能测试工具：

1) Grinder是一个很好的负载测试框架，被誉为J2EE上的LoadRunner。通过Jython来编写测试脚本，支持多种协议（如HTTP、SOAP和REST等 ）的Web服务和应用服务器（如CORBA、RMI、JMS和EJBs等），基于HTTP的测试可以由浏览器来记录整个要测试的过程。与此相关的工具，还包括Eclipse的Grinder插件GrinderStone （http://code.google.com/p/grinderstone/）、分析器Grinder Analyzer、源于Grinder的持续性能测试工具webFlange等。

2)  TestMaker通过基于Jython的测试代理（test agents）来完成测试，并借助PTTMonitor以监控应用服务器的资源和统计信息（如线程、对象和调用等）。其开放版本是商用软件的“简装版本”，不支持分布式的负载部署（即模拟的并发用户数量受到限制），其他功能比较全面。

3) OpenSTA （www.opensta.org）是针对B/S结构的性能测试开源工具，基于公共对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），并通过虚拟代理（proxy）来记录通过proxy的HTTP请求，而其性能指标收集器收集各项性能指标，然后进行分析，能提供较为丰富的图形化测试结果，提高了测试报告的可读性。

4) Siege（ http://www.joedog.org/JoeDog/Siege）是一个开源的Web压力测试和评测工具。

5) ApacheBench（apache服务器ab命令，httpd.apache.org）能同时模拟多个并发请求，专门用于Web服务器的基准测试。

6) DBMonster是一个生成随机数据、用来测试SQL数据库的压力测试工具。

7) JDBHammer是针对MySQL数据库服务器进行压力测试的开源工具，而MySQL官方提供的压力测试工具则是mysqlslap。

3. 安全性测试工具

安全性测试工具主要有Nikto、Paros proxy、SPI Dynamics WebInspect、Tripwire、TamperIE、Wapiti。专门检查数据库SQL注入攻击漏洞的工具，如sqlninja。

Paros proxy是基于Java的web代理程序，可以评估Web应用程序的漏洞。它支持动态地编辑、查看HTTP/HTTPS，从而改变cookies和表单字段等项目。它包括一个Web通信记录程序、Web圈套程序（spider）、散列（hash ）计算器，还有一个可以测试常见的Web应用程序攻击（如SQL注入式攻击和跨站脚本攻击）的扫描器。

朱少民老师的《轻轻松松自动化测试》