kerry (kerrylike@163.com)
自动化测试的好处
在过去的数年中，通过使用自动化的测试工具对软件的质量进行保障的例子已经数不胜数。到现在为止自动化测试工具已经足够完善了，我们完全可以通过在软件的测试中应用自动化的测试工具来大幅度的提供软件测试的效率和质量。在使用自动化的测试工具的时候我们建议尽早的开始测试的工作，这样可以使修改错误更加的容易和廉价，并且可以减少更正错误对软件开发周期的影响。下图显示了手工测试与自动化测试的比较。这个测试案例中包括1750个测试用例和700多个错误。
手工测试与自动化测试的比较
| 测试步骤 |
手工测试 |
自动化测试 |
通过使用工具的改善测试的百分比 |
| 测试计划的开发 |
32 |
40 |
-25% |
| 测试用例的开发 |
262 |
117 |
55% |
| 测试执行 |
466 |
23 |
95% |
| 测试结果分析 |
117 |
58 |
50% |
| 错误状态/更正检测 |
117 |
23 |
80% |
| 产生报告 |
96 |
16 |
83% |
| 时间总和 |
1090 |
277 |
75% |
通过这个表我们可以看出自动化测试与传统的手工测试在所有的方面都有很大的不同，尤其是在执行测试和产生测试报告的方面。
短测试周期中手工测试面临的挑战
迭代式的开发过程已经显示了比瀑布式开发的巨大好处，并已逐渐的取代传统的瀑布式开发成为了目前最流行的软件开发过程。在迭代开发中强调在较短的时间间隔中产生多个可执行、可测试的软件版本，这就意味着测试人员也必须为每次个迭代产成的软件系统进行测试。测试工作的周期被缩短了，测试的频率被增加了。在这种情况下，传统的手工测试已经严重的满足不了软件开发的需求。如下图所示，当第一个可测试的版本产生后，测试人员开始对这个版本的系统进行测试，很快第二个版本在第一个版本的技术上产生了，测试人员需要在第二次测试时重复上次的测试工作，还要对新增加的功能进行测试，每经过一个迭代测试的工作量会逐步的累加。随着软件开发过程的进展，测试工作变得越来越繁重，如果使用手工测试的方法，将很难保证测试工作的进度和质量。在这种情况下应用良好的自动测试工具将势在必行。通过使用自动化测试工具测试人员只要根据测试需求完成测试过程中的所需的行为，自动化测试工具将自动生成测试脚本，通过对测试脚本的简单修改便可以用于以后相同功能的测试了，而不必手工的重复已经测试过的功能部分。
手工测试的问题
同时，现代的 GUI 开发技术已经非常的先进了，它提供给开发人员快速开发的能力。这就意味着开发人员能够非常快速的改变应用程序，并将新的版本交个测试人员进行测试。实际上，很多公司每天都会有多个应用版本产生。如果还是使用传统的手工测试的方法是根本不可能符合软件快速开发的要求的。
自动化测试的步骤
自动化测试的步骤：
- 录制测试过程成为自动化测试脚本
- 增强和改进录制的自动化测试脚本
- 执行自动化测试脚本完成自动化测试
自动化测试过程
录制测试过程成为自动化测试脚本
开始自动化测试过程的第一个步骤是根据测试用例（测试需求）录制测试活动的过程。当测试人员在被测试的应用程序中进行测试的活动时，自动化测试工具将捕获测试人员与应用程序之间的所有交互，并根据这些交互生成可重用的测试脚本。测试人员在这个阶段需要考虑的一个关键问题就是，使用的测试工具是否有能力在应用程序的环境中捕获所有与应用程序的交互。
这里我们要强调的是你需要考虑与测试应用有关的所有环境。让我们通过一个例子进行说明。假如你的应用是一个基于 Web 的应用，你可能会认为我们测试工具只要能够支持你使用的浏览器就足够了。但这并不是足够的，在测试基于 Web 的应用的过程中，一定会去要和一些其他的补助应用打交道，比如也许你需要和某种数据库查许工具进行交互以确认数据被正确的输入到了数据库，或者也许你需要和注册表编辑器进行交互以验证注册表的键值。或者也许你将需要和一个电子邮件的客户端程序交互来验证从你的 Web 应用发出的邮件。 你对主要测试环境将是你对浏览器，但是你同时要确认你能够通过测试工具来测试其他所有的辅助环境，这样才能实现测试的所有环节的自动化。如果某一个测试环节不能被自动化测试工具支持，它将成为阻碍测试效率的瓶颈。
增强和改进录制的自动化测试脚本
自动化测试过程的第二个步骤是增强和改进已录制的测试脚本。你需要阅读录制好的脚本代码，并对其进行适当的需改。我们举例说明，当你录制一个脚本时，自动化测试工具将记录你输入的所有数据。用一个简单的脚本来说，你的脚本可以读出一个文本文件的内容，你可以通过设置参数为这个脚本输入不同的数据集。这样这个脚本变得更加有用了。
为了实现这一点，你需要确保你能够得到一种简单的语言以支持你所有的需要。
你还要确认你的测试工具能够支持所有你应用程序中的控件。通常情况下，开发人员将创建自己的GUI 或者甚至是一些非 GUI 的对象在应用程序中。你需要确认你能够通过修改测试脚本来使用这些控件。
执行自动化测试脚本完成自动化测试
执行单个或者少量的测试脚本是十分简单的，但是当回归测试不断的增加时，情况就变得复杂多了。你必须确认你能够协调测试脚本之间的关系，并能够从多台机器上按照多种配置来执行测试脚本。
Ratioanl Robot 帮助你实现有效的自动化测试
Robot 对录制测试脚本的支持
Robot 可以监测到测试人员与应用程序之间的所有交互行为，并可以产生相应的测试脚本。
现在你必须理解自动化测试中关于验证点和检查的主要区别。当你进行手工测试时，通常你可以通过看屏幕中显示的结果来判断应用程序执行是否是正确的，或者你可以将屏幕上的结果与文档或者其他的一些结果基线进行比较。在 Robot 中这种比较是通过在测试脚本中设置验证点实现的。在执行脚本时Robot 会在验证点获取测试感兴趣的数据，然后与已设定好的结果集进行比较判断测试是否通过。这个比较的过程叫作检查。
Robot支持的环境
目前 Robot 对几乎所有流行的应用环境多有良好的支持和工作表现。尤其是对象 HTML、Java 和 .NET 应用、 Visual Basic,、PowerBuilder,、Delphi、 Oracle 表单 和 MFC 控件（控件最常用在 C和 C++ 的应用中）有着非常强大的支持。
在 Robot 覆盖了几乎所有的应用环境的同时，仍然存在一些用很少被使用的语言和环境创建的程序部分，对于这些环境， Robot 具有一种通用的记录引擎可以捕获几乎所有的基本界面交互。因此可以说，使用 Robot 能过满足几乎所有的测试环境要求。
测试的验证点
验证点是一个 Robot 测试脚本中的一个术语，在验证点上你可以检查某些系统表单的行为。
在 Robot中最常用的验证点是对象属性和对象的数据验证。这些验证点被用于捕获对象的状态和对象测试期间的数据。在 Robot 中创建验证点与选择想得到的验证点和识别想要被测试的对象一样的简单。
但是很多情况下我们想要的验证点可能并不是眼睛可以看到的控件。就像下面图中显示的，测试者看到的是浏览器中各个元素的结果值，这些结果值 Robot 也可以看到，但测试者却看不到网页上对象的属性，比如网页的 Cookie 属性，但是这些对象属性都可以被 Robot 看见。
Robot 的测试验证点
一旦验证点被捕获了，信息就会被存储在测试数据区域。在执行回放时，测试捕获的数据将与测试数据区域中的数据基线进行比较。如果比较结果有任何的不同，他们将获被标记为"失败"并被记录在测试日志中。
Robot 还具有对整个网站的断裂链接进行检查的能力，这也是通过设置验证点实现的。
Robot 对增强、改进测试脚本的支持
一旦脚步录制完成，在某些情况下，你可以直接执行它。对于一个简单的脚本，可能不需要进行任何的改进工作。然而，多数的测试脚本将从通过改进与增强中受益。改进和增强测试脚本的工作非常简单，就像在程序代码中添加几行代码以处理一些条件逻辑一样简单，这对于有一点开发语言基础的人来说也是很容易的工作。举一个简单的例子，你需要测试在给定的环境中计算机屏幕上是否弹出了一个窗口。在这个例子中，你只需要在测试脚本的代码中添加简单的类型声明以处理窗口是否出现。
灵活的编程语言
Robot 使用 SQA Basic 语言对测试脚本进行编辑。SQA Basic 遵循Visual Basic 的语法规则并且为我们提供了非常适合与测试环境的方便的阅读语言代码的方式。通过使用这种语言，即便是很少编程经验的测试人员也能够很容易的理解代码的含义。对于哪些有丰富编程经验的人来说，他们将会发现，SQA 可以非常灵活的进行一些高级的编程，比如利用 COM 对象或者访问Windows 的编程接口。
SQA Basic 语言是从 Visual Basic 语言中演化而来的，同时它对语法进行了扩展，添加了一些测试专用的命令。这些新的命令扩展了 Robot 对所有 GUI 对象的编程访问能力，同时也使通常的编程任务―象创建一个数据驱动的测试―更加的简单。
Robot 灵活的满足了客户需要的扩展性
对于测试人员来说，无法实现自动化测试的一个共同原因是，他们无法测试自定义的控件。自定义的控件通常是被开发人员编写的，或者是从特定的控件供应商买来的以填补开发的缺口，而这些控件的并不一定会保证是在标准的控件环境下被创建的。这些控件使开发人员的工作更加简单的同时，却给测试人员的工作带来了极大的麻烦。
通常的情况下， Robot的通用录制机制将可以支持多数的自定义的控件。但是也存在着 Robot 本身无法访问到被给的属性或者控件的数据的情况。在这种情况下，也不要感到无助， Robot 具有非常好的扩展接口，这个扩展接口使 IBM Rational 的合作伙伴可以扩展 Robot 的功能，以支持几乎任何的控件。这就可以使测试人员从问题控件中解脱出来，将精力放到测试任务之中。
Robot 对执行测试脚本的支持
一旦完成了了录制和改进测试脚本，就应该开始执行脚本完成测试了。
在执行或者回放时， Robot承担了这个任务。Robot 重复所有的用户交互，计算当前的应用程序结果与验证基线的任何差异，并将结果记录在测试日志中。在所有的测试脚本被执行完后，QA 小组检查测试日志评估他们应用程序的健康性。
成功的脚本执行的关键在于拥有多执行点的能力。有时你可能希望只是执行单个的或者少量的脚本，其他的时候你希望执行所有的测试用例。这两种情况是需要不同的考虑的。
Robot 对执行测试脚本的灵活性
Robot 给你提供了你所需要的执行脚本的灵活性。你可以以以下的方式执行测试脚本：
- 从Robot 图形界面中执行脚本
- 从Robot 命令行中执行脚本
- 从TestManager 中执行脚本（具有远程执行脚本的能力）
Robot 执行测试的方式
单一的脚本或者少量的脚本能过从 Robot 图形界面中或者从命令行被执行。更加复杂的大量的测试脚本能够在 IBM Rational TestManager 工具中被创建和执行。
当从 TestManager 中执行测试时，你可以获得在远程的机器上执行测试的增强能力。通过在远程的机器上安装"测试代理"，TestManager 可以与远程的机器进行通讯并计划在远程机器上进行测试脚本的执行 － 这个远程机器可能是在隔壁房间或者根本是在其他的地方！
Robot 与 Rational TestManger 紧密的集成实现自动化测试的有效管理
Robot 通过与 Rational TestMananger 的集成可以实现：
- TestManager可以协调测试执行的时间安排和测试脚本的依赖关系
- 以中心控制的方式计划在多台远程的机器上执行测试
- TestManager 可以对测试进行配置 （如被制定到 Windows XP 平台上的测试只能在 Windows XP 平台上执行）
从 Rational TestManager 执行测试
从 TestManager 执行测试提供了创建复杂的测试执行组合。TestManager 可以协调测试执行的时间安排和测试脚本的依赖关系。当你的回归测试不断增长时，这种能力时绝对必要的。
当从 TestManager 执行测试脚本时，你将获得管理测试配置的增强能力。TestManager 是"可配置的" ，这就意味着当它计划在远程机器上执行一个测试脚本时 －它对远程机器是可配置的（操作系统、处理器和其他任何条件） － 并针对配置来执行测试脚本。因为一个测试脚本需要对不同的操作系统有一些稍微不同的版本，比如 Windows 98 和 Windows XP。TestManager 将仅仅对被给定的测试代理配置发送正确的测试脚本。
Robot 功能特点的总结
最后我们来对 Robot 成功实现自动化测试的功能特性作一个总结。
Robot 具有广泛的环境支持。Robot 给你很好的灵活性来测试在几乎所有环境中被创建的应用程序。
Robot 提供了灵活的和可扩展的脚本语言 － SQA Basic 。 SQA Basic 是足够简单易懂的，没有编程经验的测试人员也可以很容易的理解，SQA Basic 同时也是足够强大的，可以满足专业的测试工程师进行复杂的编程需求。Robot 的通用录制引擎具有良好的扩展性，使你可以建立对任何控件的支持。当你排除了对控件的困扰时，你便可以将精力放到测试工作上。
Robot 提供了非常灵活的执行测试脚本的方式，你可以通过 Robot 图形界面和命令行执行测试脚本，也可以从 Rational TestManager 按照不同的配置计划在远程机器上的复杂的测试脚本的执行。
