|
kerry UML 工程组织咨询顾问 IBM 通过这个表我们可以看出自动化测试与传统的手工测试在所有的方面都有很大的不同，尤其是在执行测试和产生测试报告的方面。 短测试周期中手工测试面临的挑战 手工测试的问题
同时，现代的 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 图形界面中或者从命令行被执行。更加复杂的大量的测试脚本能够在 IBM Rational TestManager 工具中被创建和执行。 当从 TestManager 中执行测试时，你可以获得在远程的机器上执行测试的增强能力。通过在远程的机器上安装"测试代理"，TestManager 可以与远程的机器进行通讯并计划在远程机器上进行测试脚本的执行 － 这个远程机器可能是在隔壁房间或者根本是在其他的地方！ Robot 与 Rational TestManger 紧密的集成实现自动化测试的有效管理 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 按照不同的配置计划在远程机器上的复杂的测试脚本的执行。 关于作者 |
