1 初识自动化测试
如果以前没有做过自动化测试，那么就不了解自动化测试，可能会觉得自动化测试比较神秘，但是，我们在日常的计算机操作中，可能会碰到一些自动化处理的过程，这些过程和自动化测试比较接近。
例如，
- Windows操作系统的控制面板中，有一项功能：任务计划向导。
- DOS批处理文件，直到今天的Windows Vista还在使用它。它更接近自动化测试。
上述的自动化处理过程还不是测试，因为测试的重要一点是须要验证，将实际执行的结果和用户期望的结果进行比较。没有这个比较，就不是自动化测试。
2 自动化测试和手工测试有什么不同
亲手做过自动化测试之后，我们对自动化测试就有了一个感性的认识，至少有下列几点感觉：
l 机器人从来就不会感觉累
l 自动化测试的速度，是手工测试无法比的
l 测试结果准确。例如搜索用时即使是0.33秒或0.24秒，系统都会发现问题，不会忽视任何差异。
l 一旦脚本完成，可以一劳永逸地运行很多遍，重复使用。
从这里就可以初步体会到自动化测试的优越性――高效率、准确可靠和复用性。同时，自动化测试也有不利的一面，即在创造性、发现新缺陷等方面能力不足。
有资料显示，即使自动化测试实施良好，也只能发现软件系统中30%的问题，而70%的问题还要靠手工测试发现。所以自动化测试更适合于负载测试、性能测试和回归测试。
概括起来，通过自动化测试，软件企业可以获得许多好处。
l 测试周期缩短，因为自动化测试效率高、能够长时间不间断地运行。
l 完成更多的测试，实现更高的测试覆盖率，保证测试的一致性，提高测试的可靠性，最终获得更高质量的软件。
l 更高的测试团队士气，因为有更多机会学习编程、获取新技术；同时，自动化测试使测试工作变得更有趣。
3 什么是自动化测试
谈到自动化测试，一般会提到测试工具。许多人觉得使用了一两个测试工具就是实现了测试自动化，这种理解是不对的，至少是片面的。的确，测试工具的使用是自动化测试的一部分工作，但是“用测试工具进行测试”不等于“自动化测试”。那么，什么是“自动化测试”呢？
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程，即模拟手工测试步骤，通过执行程序语言编制的测试脚本自动地测试软件，自动地完成软件的单元测试、功能测试、负载测试或性能测试等全部工作。
实际上，对于自动化测试有两种说法――“自动化测试”和“测试自动化”。它们之间存在某些微妙的差别，如果严格地加以区分，可以看作是两个概念：
自动化测试（Automated Test），侧重说明由测试工具自动地执行某项软件测试任务，自动化处理范围比较小。例如通过某个软件工具完成应用系统的功能测试和性能测试等测试执行工作，而测试的计划、设计和管理等其他工作还是由手工完成的。
测试自动化（Test Automated），侧重说明整个测试过程都由计算机系统自动完成，体现了更理想的自动化测试思想，有更广的范畴和更大的挑战。它不仅要求由工具完成测试的执行，而且要求测试的设计和管理也能由系统自动完成，例如基于模型实现测试设计的自动化、基于软件设计规格说明书实现测试用例的自动生成、基于数据库系统实现测试管理的自动化等。
根据上面的描述，测试自动化的要求相对来说高得多，即要求所有的测试工作都由计算机系统自动完成。包括：
l 测试环境的搭建和设置，如自动上传软件包到服务器并完成安装。
l 脚本自动生成，如根据UML状态图、时序图等生成可运行的测试脚本。
l 测试数据的自动产生，例如通过SQL语句在数据库中产生大量的数据记录，用于测试；
l 测试操作步骤的自动执行，包括软件系统的模拟操作、测试执行过程的监控；
l 测试结果分析，实际输出和预期输出的自动对比分析；
l 测试流程（工作流）的自动处理，包括测试计划复审和批准、测试任务安排和执行、缺陷生命周期等自动化处理。
l 测试报告自动生成功能等。
这样，测试自动化意味着测试全过程的自动化和测试管理工作的完全自动化，是测试工程师所追求的一种理想境界。如果使整个软件测试过程完全自动化，而不需要丝毫的人工参与或干涉，这是不现实的。
4 自动化测试和手工测试应用范围的对比
在充分利用自动化工具、全力进行自动化测试的同时，牢记不要追求100%的自动化，手工测试仍然至关重要。对高风险的模块或领域要进行更多的人工测试。根据手工测试和自动化测试的各自优势，对人工测试和自动测试区别对待，进行有效分工。
|
适用于自动化测试 |
适用于手工测试 |
|
l 明确的、特定的测试任务 l 软件包括验证测试（Build Verification Test、BVT） l 回归测试、压力测试、性能测试等 l 相对稳定且界面改动比较少的功能测试 l 人工容易出错的测试工作 l 在多个平台环境上运行相同的用例、大量组合性测试或其他重复性测试任务 l 周期长的软件产品开发项目 l 项目的时间压力不太大 l 被测试软件具有很好的可测试性 l 能确保多个测试运行的构建策略 l 拥有运行测试所需的软硬件资源 l 拥有较强编程能力的测试人员 |
l 一次性项目或周期很短的项目的功能测试 l 需求不确定或需求变化比较快 l 适用性测试或验收测试 l 产品的功能设计或界面设计还不成熟 l 没有适当的测试过程 l 测试内容和测试方法不清晰 l 项目的时间压力较大 l 团队缺乏编程能力的测试人才 l 缺乏软硬件资源 |
如表，概括起来，任务越单调，自动化测试越适合；重复性越大，自动化测试越适合；越容易量化，自动化测试越适合。
5 区别对待不同的测试阶段
单元测试、集成测试、系统测试和验收测试等不同的测试阶段，虽然都可以采用自动化测试来完成，但自动化测试的程度不一样。
在单元测试中，自动化测试工具和开发工具集成在一起，自动化测试程度比较高，而且比较全面。如前面所说的，代码的静态扫描，可以充分利用测试工具来完成。而单元的功能测试，一般可以借助单元测试框架实现，但须要写大量的测试脚本或测试代码，手工的工作量不小，这也是许多软件公司的单元测试覆盖率总是不够高的主要原因。
在集成测试阶段，自动化测试工具的作用是间接的，不是直接的、主动的。多数测试组织不是通过测试工具验证模块之间的接口，而是通过基本功能的验证来验证系统的集成，即通过BVT来完成每日测试，以满足每日构建、每日集成（持续集成）的需要。
在系统测试阶段，人们首先会将自动化测试运用在性能测试、压力测试、可靠性测试中，而在功能测试中，自动化测试的投入会比较谨慎。功能测试中逻辑、数据和API等验证，比较适合自动化测试，而GUI界面、易用性等测试，更宜由手工完成。
在用户参与的验收测试中，一般不宜于采用自动化测试。同样，针对软件界面操作友好性、易用性的测试，自动化无能为力，必须由手工测试来完成。
6 如何评估测试工具
满足测试任务及其特点的测试工具可能会比较多，我们须要考虑对它们进行评估，选择出正确的测试工具。如何评估测试工具呢？人们可能会想到下列这些指标：
l 工具的功能是否强大，或者是满足需要？
l 价格是否合适、在预算之内？
l 性能价格比如何、是否数一数二？
l 工具的质量，工具运行是否稳定？
l 目前的用户量或是否流行？
l 和其他测试工具的兼容性、集成是否容易？
l 技术支持和服务是否及时、方便？
有时候，工具的选择也没有那么复杂，而是根据市场决定，市场哪个流行就选择哪个。市场流行，自然也有优势，这样做也不无道理。但这样做，具有盲目性，毕竟功能最强的工具不一定适合自己，最合适的工具，才是最好的。
我们建议将开源测试工具作为首选目标。如果开源测试工具应用一段时间之后，确实不能满足自己的需求，可以考虑选择商业化的测试工具。实际上，如果发现工具不能满足自己的需求，因为它是开源工具，完全可以对它进行修改（二次开发），增加相应的功能特性，从而满足自己的特定需求，这也是开源测试工具的魅力所在。
千万不要一开始就用巨资引入商业化的测试工具，那样测试人员压力很大，急于求成，反而效果不好，要么测试工具成了摆设，要么从此以后再也不敢提“自动化测试”。
7 如何选择合适的测试工具
测试工具的选择，还须要从某类具体的工具着手，对症下药，才能达到期望的目标。一般来说，测试工具可以分为：
单元测试工具，包括静态测试工具和动态测试工具；
功能测试工具，包括WEB功能测试工具、Windows客户端功能测试工具等；
性能测试工具，包括负载测试工具、压力测试工具等；
测试管理工具，包括缺陷、测试用例和计划等管理工具；
其他测试工具，如安全测试、多媒体测试等。
7.1 单元测试工具的选择
建议：用什么编程语言就选用对应这种编程语言的单元测试工具，如：
如果用JAVA语言编程，就要选用JAVA的单元测试工具，如Junit，TestNG
如果用NET语言，就要选用适用C#的单元测试工具，如：NUnit，NUnitForms等；
如果用PHP语言，就要选用PHPUnit作为单元测试工具；
如果针对C/C++语言的程序，就要选择相应的单元测试工具，如CppTest*等；
如果只是进行纯页面的开发，针对HTML文件的table\form\link等元素进行测试，则单元测试工具选择HtmlUnit。
7.2 功能测试工具的选择
如：Selenium\TestMaker
7.3 性能测试工具的选择
Grinder是一个很好的负载测试框架，被誉为J2EE上的LoadRunner。通过Jython来编写测试脚本，支持多种协议的WEB服务和应用服务器，基于HTTP的测试可以由浏览器来记录整个要测试的过程。
TestMaker通过基于Jython的测试代理来完成测试，并借助PTTMonitor以监控应用服务器的资源和统计信息。
OpenSTA是针对B/S结构的性能测试开源工具，基于公共对象请求代理体系结构，并通过虚拟代理来记录通过proxy的HTTP请求，而其性能测试指标收集各项性能指标，然后进行分析，能提供较为丰富的图形化测试结果，提高了测试报告的可读性。
Siege是一个开源的WEB压力测试和评测工具。
ApacheBench能同时模拟多个并发请求，专门用于Web服务器的基准测试。
DBMonster是一个生成随机数据、用来测试SQL数据库的压力测试工具。
JDB Hammer是针对MySQL数据库服务器进行压力测试的开源工具，而MySQL官方提供的压力测试工具则mysqlslap.
另外要说明的是，TestMarker是一个更灵活的框架，可以和Seleinium、soapUI集成，充分利用Selenium和soapUI的测试能力，而TestMarker只是更好地调度、监控和管理测试的过程，监控系统的性能指标，获得测试结果。
7.4 测试管理工具
软件测试离不开管理，包括测试计划、用例、测试结果和缺陷等管理，这些管理也通过工具和系统来帮助处理，以提高管理的效率和准确性。测试管理工具的选择，依赖于测试组织的规模和流程。规模小的组织，可以选择轻量型的测试管理工具；而规模大的组织，应选择功能强、支持多项目和分布式的测试管理工具。
对于轻型的开源测试管理框架，如JtestCase\FitNesse\Salome TMF\JTR等
对于更为规范的、具有一定规模的软件组织，可以选用TestLink\Bromine\Eclipse TPTP等测试管理框架或系统。
软件测试管理的重要工作之一是缺陷管理，缺陷管理工具有Mantis、Bugzilla、Bugfree、Scarab、TrackIT、Itracker等。
7.5 其它测试工具
7.5.1 安全测试工具
主要有Nikto、Paros Proxy、SPI Dynamics WebInspect、Tripwire、TamperIE、Wapiti，其中前３项工具的功能强大，而其他工具则检查某个方面的测试。例如，TamperIE是一个小巧的XSS漏洞检测辅助工具，而WebScarab分析HTTP和HTTPS协议的通信。除此之外，还有专门检查数据库SQL注入攻击漏洞的工具，如sqlninja.
Paros Proxy是基于JAVA的WEB代理程序，可以评估WEB的应用程序的漏洞。它支持动态地编辑、查看HTTP/HTTPS，从而改变cookies和表单字段等项目。它包括一个WEB通信记录程序。
7.5.2 可达性测试工具
可达性（Accessibility）在国际性软件测试中也是不可忽视的。这类工具包括色彩对比度分析，键盘和鼠标的特殊操作等。微软公司在２００９年３月发布了两种可达性测试工具（http://www.codeplex.com）。
AccChecker：用户界面可达性测试工具（UI Accessibility Checker）；
UIA Verify：用户界面自动验证（UI Automation Verify）.
除此之外，还有很多这类测试工具，详见：http://www.w3.org/WAI/ER/tools/complete.
7.5.3 多媒体测试工具
多媒体应用越来越多，对测试工具的要求也越来越高，须要覆盖语言（VoIP）、视频（Vedio）和IP电话等各项多媒体应用的特殊测试，如多媒体数据交换、服务质量（Qos）等。多媒体方面的开源测试工具有Ethereal、Auto Tool、SIPp、Seagull、Asterisk和X-Lite等。
7.5.4 网络监控工具
网络监控工具也常常在测试中使用，这类开源工具比较多，选择的余地很大，常用的工具有Nessus、Ethereal/Wireshark、Snort、Switzerland和Netcat，其中Wireshark就很不错。
转自：http://www.cnblogs.com/yangxia-test/p/4554385.html
原文地址：https://www.cnblogs.com/Adazyn/p/8984280.html