自动化测试（转自百度百科）

定义 编辑

自动化测试 ^[1] 是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了 测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了 自动化测试的概念。

工具介绍编辑

QTP

全名HP QuickTest Professional software ，2012年12月6日发布11.5版本，并更名为 Unified Functional Testing
　　QTP是quicktest Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等
　　QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。

WinRunner

Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。
　　企业级应用可能包括Web应用系统， ERP系统， CRM系统等等。这些系统在发布之前，升级之后都要经过测试，确保所有功能都能正常运行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。

Rational Robot

是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面IBM Rational Test Manager上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。

AdventNet QEngine

AdventNet QEngine是一个应用广泛且独立于平台的自动化软件测试工具，可用于Web功能测试、web性能测试、Java应用功能测试、Java API测试、SOAP测试、回归测试和Java应用性能测试。支持对于使用HTML、JSP、ASP、.NET、PHP、JavaScript/VBScript、XML、SOAP、WSDL、e-commerce、传统客户端/服务器等开发的应用程序进行测试。此工具以Java开发，因此便于移植和提供多平台支持。

SilkTest

是业界领先的、用于对企业级应用进行功能测试的产品，可用于测试Web、Java或是传统的C/S结构。SilkTest提供了许多功能，使用户能够高效率地进行软件自动化测试。这些功能包括：测试的计划和管理；直接的数据库访问及校验；灵活、强大的4Test脚本语言，内置的恢复系统(Recovery System)；以及具有使用同一套脚本进行跨平台、跨浏览器和技术进行测试的能力。

QA Run

QARun的测试实现方式是通过鼠标移动、键盘点击操作被测应用，即而得到相应的测试脚本，对该脚本可以进行编辑和调试。在记录的过程中可针对被测应用中所包含的功能点进行基线值的建立，换句话说就是在插入检查点的同时建立期望值。在这里检查点是目标系统的一个特殊方面在一特定点的期望状态。通常，检查点在QARun提示目标系统执行一系列事件之后被执行。检查点用于确定实际结果与期望结果是否相同

Test Partner

是一个自动化的功能测试工具，它专为测试基于微软、Java和Web技术的复杂应用而设计。它使测试人员和开发人员都可以使用可视的脚本编制和自动向导来生成可重复的测试，用户可以调用VBA的所有功能，并进行任何水平层次和细节的测试。TestPartner的脚本开发采用通用的、分层的方式来进行。没有编程知识的测试人员也可以通过TestPartner的可视化导航器来快速创建测试并执行。通过可视的导航器录制并回放测试，每一个测试都将被展示为树状结构，以清楚地显现测试通过应用的路径。

Holodeck

-强大的故障植入软件测试工具
　　Holodeck is an advanced fault-injection tool that gives you the power to attack an application while it monitors and logs everything your application does - every function call, registry entry, piece of data read or written.

Telelogic TAU

TAU第二代包含三个最新的、最强大的技术用来加速大规模软件开发和测试：统一建模语言(UML)及它的许多最新修订版本中的特性，UML2.0；功能强大的测试语言TTCN-3和新的构造系统的方法：Model Driven Architecture(模型驱动构架)。这三个新的业界标准结合成TAU的已经过认可的软件开发平台，形成了一个系统，一个一流的稳定可靠的工具解决方案。TAU第二代是系统与软件开发解决方案的一个突破，它把业界从使用了太长时间的手工、易出错、以代码为中心的方法中释放出来，自然而然地迈向下一步，一个更加可视化、自动化及可靠的开发方法。Telelogic TAU/Tester是基于通用测试语言TTCN-3,用于自动化的系统和集成测试的强大工具。TAU/Tester以现代化的开发工具为基础，提供高层测试功能，支持整个测试生命周期，加速自动化测试。TAU/Tester可使用户特别关注于测试的开发，因为TTCN-3语言是独立于开发语言或测试设备的，且是抽象和可移植的。

AutoRunner

AutoRunner ^[2] 是黑盒测试工具，可以用来完成功能测试、回归测试，可以提高测试效率，降低测试人工成本。

产品可以对以下类型对象进行GUI功能性测试：

1 Windows类型对象，一般为用C++/Delphi/VB/VFP/PB/.NetForm等技术开发的桌面程序。

2 IE网页对象，一般性的网站，比如大的门户类网站。

3 Java对象，一般为用AWT/Swing/SWT等技术开发的桌面程序。

4 Flex对象，网页的内容是用Flex开发的。

5 Silverlight对象，网页的内容是用Silverlight开发的。

6 WPF对象，一般为用WPF技术开发的桌面程序。

7 QT对象，一般为用QT技术开发的桌面程序。

Phoenix Framework

Phoenix Framework是一款基于 Selenium，Webdriver，autoIt研发的一款集资源管理和测试于一体的Web自动化测试工具。最新版本是1.1.8，该工具支持无脚本执行模式，无人值守执行模式，自由定制模式。不仅执行模式可以定制，功能模块也支持定制。使用该工具的界面创建用例，组装脚本，启动执行。使用该工具其他开放的接口，可手动创建脚本，组装并执行。它支持两种部署模式，第一种是Server-Client方式，Server与Client均为EXE程序，通信协议是Socket；另一种是WEB版部署，方便与现有系统集成，支持Linux，将Server与Client放到Tomcat或Weblogic服务器下部署，通信协议为Http，通过WEB页面控制并监控Client端的执行。

前提条件编辑

实施自动化测试之前需要对 软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：

1) 需求变动不频繁

测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新 测试用例以及相关的测试 脚本，而脚本的维护本身就是一个 代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。

项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用 手工测试。

2) 项目周期足够长

自动化测试需求的确定、 自动化测试框架的设计、 测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。

3) 自动化测试脚本可重复使用

如果费尽心思开发了一套近乎完美的自动化 测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。

另外，在 手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如 性能测试、 配置测试、大数据量输入测试等。

适用场合编辑

通常适合于 软件测试自动化的场合：

(1) 回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费；

(2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具；

(3)采用自动化测试工具有利于 测试报告文档的生成和版本的连贯性；

(4)自动化工具 ^[3] 能够确定 测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖。

随着测试流程的不断规范以及 软件测试技术的进一步细化，软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率，正是本期所要讨论的话题。

软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及 动态测试的自动化（如 单元测试、 功能测试以及 性能方面）。在这两个领域，与 手工测试相比，测试自动化的优势是明显的。首先自动化测试可以提高测试效率，使测试人员更加专注于新的测试模块的建立和开发，从而提高测试覆盖率;其次，自动化测试更便于测试资产的数字化管理，使得测试资产在整个测试 生命周期内可以得到复用，这个特点在 功能测试和 回归测试中尤其具有意义;此外，测试流程自动化管理可以使机构的测试活动开展更加过程化，这很符合 CMMI过程改进的思想。根据OppenheimerFunds的调查，在2001年前后的3年中，全球范围内由于采用了测试自动化手段所实现的 投资回报率高达1500%。

选型原则编辑

然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢？也不尽然，任何一种产品化的测试自动化工具，都可能存在与某具体项目不甚贴切的地方。再加上，在企业内部通常存在许多不同种类的应用平台，应用开发技术也不尽相同，甚至在一个应用中可能就跨越了多种平台;或同一应用的不同版本之间存在技术差异。所以选择 软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。

以下笔者给出企业用户进行 软件测试自动化方案选型的参考性原则，这些原则是从笔者实际工作中凝练而成的，它包括以下六个方面的建议：

●选择尽可能少的自动化产品覆盖尽可能多的平台，以降低产品投资和团队的学习成本；

●测试流程管理自动化通常应该优先考虑，以满足为企业测试团队提供流程管理支持的需求；

●在投资有限的情况下， 性能测试自动化产品将优先于 功能测试自动化被考虑；

●在考虑产品性价比的同时，应充分关注产品的支持服务和售后服务的完善性；

●尽量选择趋于主流的产品，以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持；

●应对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求。

过程编辑

自动化测试 ^[4] 与 软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于 软件开发工具），经过对测试需求的分析（ 软件过程中的 需求分析），设计出自动化 测试用例（软件过程中的需求规格），从而搭建自动化测试的 框架（软件过程中的 概要设计），设计与编写自动化 脚本（ 详细设计与 编码）， 测试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的 应用软件）。

1) 自动化测试 需求分析。

当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试 需求分析。此过程需要确定自动化测试的范围以及相应的 测试用例、测试数据，并形成详细的文档，以便于 自动化测试框架的建立。

2) 自动化测试框架的搭建。

所谓自动化测试框架便是像 软件架构一般，定义了在使用该套 脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。

而根据自动化 测试用例，我们很容易能够定位出 自动化测试框架的典型要素：

a. 公用的 对象。

不同的 测试用例会有一些相同的 对象被重复使用，比如窗口、按钮、页面等。这些公用的 对象可被抽取出来，在编写 脚本时随时调用。当这些 对象的属性因为需求的变更而改变时，只需要修改该 对象属性即可，而无需修改所有相关的 测试脚本。

b. 公用的环境。

各 测试用例也会用到相同的 测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强 脚本的可维护性。

c. 公用的方法。

当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便 脚本的调用。

d. 测试数据。

也许一个 测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由 测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。

在该框架中需要将这些典型要素考虑进去，在 测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。

脚本编写编辑

该编写过程便是具体的 测试用例的 脚本转化。初学的自动化测试人员均会使用录制 脚本到修改脚本的过程。但专业化的建议是以录制为参考,以编写 脚本为主要行为，以避免录制脚本带来的 冗余、公用元素的不可调用、脚本的调试复杂等问题。

测试运行编辑

事实上，当每一个 测试用例所形成的 脚本通过测试后，并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及 测试环境的改变，都会导致测试结果受到影响甚至失败。而如果只是一个个执行 测试用例，也仅能被称作是半自动化测试，这会极大的影响自动化测试的效率，甚至不能满足夜间自动执行的特殊要求。

因此， 脚本的测试与试运行极为重要，它需要详查多个脚本不能依计划执行的原因，并保证其得到修复。同时他也需要经过多轮的 脚本试运行，以保证测试结果得一致性与精确性。

自动化测试引入的原因是就把 软件测试人员从枯燥乏味的机械性 手工测试劳动中解放出来，以自动化测试工具取而代之，使测试人员的精力真正花在提高软件产品质量本身。

注意事项编辑

首先，一个企业实施测试自动化，绝对不是拍脑袋说干就能干好的，它不仅涉及测试工作本身流程上、组织结构上的调整与改进，甚至也包括需求、设计、开发、维护及 配置管理等其他方面的配合。如果对这些必要的因素没有考虑周全的话，必然在实施过程中处处碰壁，既定的实施方案也无法开展。其次，尽管自动化测试可以降低人工测试的工作量，但并不能完全取代 手工测试。100%的自动化测试只是一个理想目标，根据笔者的经验，即便一些如SAP、OracleERP等测试库规划十分完善的套件，其测试自动化率也不会超过70%。所以一味追求测试自动化只会给企业带来运作成本的急剧上升。再次，实施测试自动化需要企业有相对规模的投入，对企业运作来说，投入回报率将是决定是否实施 软件测试自动化的最终指挥棒，笔者建议企业在决定实施软件测试自动化之前，必须要做量化的投资回报分析。此外，实施 软件测试自动化并不意味着必须采购强大的自动化 软件测试工具或自动化管理平台，毕竟 软件质量的保证不是依靠产品或技术，更多的因素在于高素质的人员和合理有效的流程。