开发测试自动化脚本以及自动化框架

在进行测试自动化项目顾问工作的早期阶段，经常有人请我对于自动化的实现进行评估。而当我给出一个初步的估算时，很快就会遇到下一个问题：“这个估算所针对的是一个测试套件还是框架呢？”

这种问题经常会让我感到难以回答，因为我不清楚他们问的到底是什么……哪些东西属于测试脚本？哪些东西属于框架？他们之间到底如何区分？

让我们首先来明确几个定义。

自动化工具

自动化工具/指令的作用是与UI进行交互，例如模仿单击按钮、输入文本及验证文本框中的值。至少这个定义是我所能够确认的，不存在任何含糊的地方

框架

我从前对于框架的认知是偏具体的，即可重用的、与SUT（待测试系统）无关的、并且与自动化工具无关的库，它能够加速自动化的实现。

但在IT业界中，框架这个词的使用非常频繁，甚至即使仅仅谈论自动化测试的时候，这个单词在不同的上下文中也会具有不同的含义

图1 – 不同的框架示例

特定于工具的框架

一般来说，商业级自动化工具的提供者，乃至开源社区往往会为他们的工具打造一个完整的基础设施，在其中实现报表生成、测试套件的运行、分布式测试的运行，并与测试的执行环境相集成。举例来说，Selenium工具的主要组件是WebDriver，它作为web浏览器的插件运行，对于在web浏览器中运行的web应用进行DOM模型（即web页面的一种基于xml文档对象模型）的操作。但Selenium还包括大量的额外编码库，以及一个实现了录制-重播功能的工具（Selenium IDE）。所有这一切工具共同组成了Selenium自动化测试框架

Serenity是另一个很好的例子，它也是一种特定于工具（围绕着Selenium Web Driver而创建）的框架。但它的目标不在于提供大量的可选组件或插件，因为特定的组件已经由社区专家合而为一了。你可以将它设想为一种加速器，通过它提供对更快的测试自动化实现的启动的支持，同时也支持BDD类型的测试。

而在商业产品中，更难以找出测试命令本身所在，原因是商业级的特定于工具的框架（例如HP QTP、Ranorex和TestComplete）通常是一种经过完整构建与部署的基础设施，包含了行为的模拟器、编写脚本的IDE及报表工具。

特定于项目的框架

这种框架是在特定的应用开发阶段为了实现自动化而开发的，用于支持特定的应用的自动化测试的需求。这种框架的组件可以由其他开源库实现，针对SUT建立一种特定的环境，以支持以下功能中的部分或全部：

将经过构建的应用（包括它的组件，例如数据库、服务库和后端）部署到某个环境中；

启动应用；

运行测试用例；

将测试的运行结果报告直接发送给某个测试管理系统

提供控件的封装，以支持通过某些特定的控件（例如grid或自定义控件等等）简化自动化的编码工作。

另一个需要考虑的重要组件是测试用具（test harness），它能够支持在不同的云环境中运行测试用例，允许在所支持的操作系统与浏览器的运行产生不同的结果。可以选择自行创建这些操作，也可以选择某种工具框架中的组件。

最佳实践框架

框架是个非常吸引人的词，一旦你提到这个词，就会令人产生深刻的印象。举例来说，Zachman框架与开发组件之间没有任何关联，它只是一种用于定义企业架构的方法。同样的道理也适用于自行开发的自动化构建框架，它们可以包含用于自动化测试的组件，也可以包含描述如何以最佳方式对某个测试进行自动化的方法。对于那些希望首次尝试自动化测试，或是试图理解现有的自动化项目的运行情况的客户来说，自动化测试专家（包括我）通常会为他们推荐这种框架。

关键字驱动的框架

还有一种类型的框架也不可不提，这是一种针对编码经验较少的员工、特定于工具或项目的框架。这种框架能够让他们编写或维护自动化脚本。经过代码化的关键字（例如Login、Click、NavigateToPage和TypeText等等）是在代码中的某处实现的，这里的代码被实现为了一种关键字的库。

原文转自：http://www.uml.org.cn/Test/201610172.asp