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

发表于:2016-10-17来源:UML作者:Sasha Reminnyi点击数: 标签:
在进行测试自动化项目顾问工作的早期阶段,经常有人请我对于自动化的实现进行评估。而当我给出一个初步的估算时,很快就会遇到下一个问题:“这个估算所针对的是一个测试套件

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

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

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

自动化工具

自动化工具/指令的作用是与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

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)