【QCon】精华内容上线92%,全面覆盖“人工智能+”的典型案例!>>> 了解详情
写点什么

Robot Framework 作者建议如何选择自动化测试框架

  • 2012-06-04
  • 本文字数:1971 字

    阅读完需:约 6 分钟

软件自动化测试,作为手工测试的替代,越来越受到关注。 Pekka Klärck ,作为 Robot Framework 的创建者和核心开发者,按照系统级别,介绍了几种不同的自动化测试方法的区别

一、记录回放的方式流行于商业工具之中,无需编程技能即可快速上手。然而这种方法相对脆弱,一旦UI 变化测试就会受到影响,分散的脚本不可重用且难以维护,而且系统在测试前必须可用(也就意味着无法使用A-TDD 方法)。因此这种方法并不适合大型自动化测试。

二、线性脚本允许使用各种语言来编写非结构化脚本,脚本直接与被测系统交互。能够快速上手,灵活性强。但是编写脚本需要编程技能,系统中一个改动会影响所有脚本,没有经过模块化或重用的大量脚本难以维护。因此这种方法适合简单任务,不适合大型自动化。

三、模块化脚本由两部分组成:驱动脚本执行测试,测试库函数完成与被测系统交互。驱动脚本编写起来非常简单,这样可以更快地建立新测试,容易维护。然而需要花时间和编程技能建立测试库,并将测试数据嵌入脚本,建立新测试就需要新的测试脚本。因此,只要拥有编程技能,这种方法还是适合大型项目,但不适合非编程人员。

四、数据驱动方法,将数据与测试脚本分离,基于模块化的测试库,一个驱动脚本可以执行多个相似测试,这样非常容易建立新测试。维护工作可以分离,测试人员负责数据,程序员负责写测试库。然而,不同类型测试仍需要新的驱动脚本,初始建立数据解析器和重用组件需要花人力。这种方法适合大型项目,只需要较少的编程技能。

五、关键字驱动,将数据与关键字结合来描述如何使用数据执行测试。这种方法具备数据驱动的优势,同时非编程人员也能建立新类型测试。所有测试由同一个框架来执行,无需不同的驱动脚本。然而初始成本很大,但是可以使用开源方案!因此非常适合大型项目。

Pekka 对以上五种方法的介绍其实也是对自动化测试发展史的介绍,同时也体现了 RobotFramework 背后的设计思想。

除了测试框架的选择,要想做好自动化测试,还要关注其他方面。

自动化测试需要关注可测性。自动化最难的部分是与被测系统交互,特别是 GUI 层。确保系统容易被测试,比如给 GUI 元素增加标识、输出易于解析的文本、提供自动化接口等。

系统一般可以分为 GUI 层以及 GUI 之下的业务层。GUI 层测试需要调用与普通用户同样的接口,但是某些 GUI 技术缺乏好的工具支持,会使测试变得脆弱,而且执行相对较慢。从业务层开始测试相对容易,执行快。但 GUI 层仍然需要被测试,以保证 GUI 正确连接到了业务层,甚至有时 GUI 层也具有业务功能。Pekka 建议考虑对业务层进行完全测试,而部分地对 GUI 层实行端到端测试。 不是所有系统都具有 GUI 层,却可能具有 API、数据库、服务器、命令行等。自动化测试框架可以调用不同驱动来进行测试。这些非 GUI 层相对容易测试,只要把测试用例看作另一个客户端而已。

那么自动化测试应该在什么阶段进行?如果开发完成后单独做自动化,这是典型的瀑布式过程,不同团队之间存在沟通障碍,反馈周期慢,产品在后期难以获得可测性,从而导致复杂和脆弱的测试方案。相反,典型敏捷式过程中,程序员和测试人员协同完成自动化。把自动化看作团队开发的一部分,可测性不再是问题,团队做技术决定时就可以考虑可测性和工具选择,程序员可以提前加入提供可测性的钩子特性。

自动化测试需要版本控制和持续集成来支持。将测试和代码放在一起,像管理代码一样管理测试脚本,那么多可用工具,SVN、GIT、Mercurial,没道理不用。持续集成是全方位自动化的关键,当测试或代码有所改动立即执行测试。如果测试运行时间比较长,也可以定期运行。使用 Jenkins Hudson Cruise Control BuildBot 吧,自己写定时脚本或 Cron Job 可以休矣。

选择商业自动化工具还是开源工具?好东西肯定贵,但是贵的不见得好,再便宜的许可证也会阻止整个团队的协作。而且商业化工具难以和其他自动化工具(特别是其他厂商的)或版本控制、持续集成进行整合和定制化。另外,产品终止或公司关门是潜在的风险。开源工具可供选择余地很大,当然也是良莠不齐。开源工具通常容易与其他工具整合,关键是免费,谁都可以随意使用和定制化,还永远不会消失。至于免费软件,越来越少了,很多自由软件都已经开源。免费软件同样不能定制化,且存在中止的风险。

做自动化需要哪些技能?一般来说,包括 Python、Ruby、Perl、JavaScript、正则表达式、XPath 和 CSS 定位、SQL 语句、版本控制等。

有了自动化,手工测试还需要吗?当然需要!! 不过,要避免手工执行脚本来测试,还是将其完全自动化吧,测试人员可以更多关注于探索性测试。 记住,机器擅长回归测试,人类善于寻找 Bug。


感谢郑柯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2012-06-04 05:5214794

评论

发布
暂无评论
发现更多内容

新书上市 | Vue 3.0 核心源码解析,这本书给 Vue 学习提供新方法

图灵社区

前端 代码 VUE 3.0 源码

计算机网络——奈式准则

StackOverflow

编程 计算机网络 9月月更

白天建筑师,晚上CG艺术家,他将建筑的华丽发挥极致

Renderbus瑞云渲染农场

云渲染 云渲染农场 渲染农场

DPDK源码分析之rte_eal_init(二)

于顾而言

DPDK

《新神榜:杨戬》亮点抢先看!追光新神话宇宙再添超燃国风巨作

Renderbus瑞云渲染农场

云渲染 云渲染农场 渲染农场 3D电影制作 CG动画电影

资本“呼唤”:走产品化路线,找得到PMF的云安全创业项目

B Impact

To B业务

jquery入门到实战

楠羽

笔记 JQuery框架 9月月更

企业容器云建设及推广的一点Tips

穿过生命散发芬芳

容器云 9月月更

二叉树的概念及三种遍历方法(C语言)

孤衫

后端 C语言 9月月更

【指针内功修炼】深度剖析指针笔试题(三)

Albert Edison

C语言 9月月更 指针数组 数组指针

mysql实数类型和字符串类型

急需上岸的小谢

9月月更

5 个 Promise 要避免的常见用法~

掘金安东尼

前端 9月月更

手把手教你如何使用 Timestream 实现物联网时序数据存储和分析

亚马逊云科技 (Amazon Web Services)

数据分析 物联网 数据存储

DPDK源码分析之网络基础知识

于顾而言

网络协议 DPDK

DPDK源码分析之l2fwd

于顾而言

DPDK

MFC与Qt多个控件响应统一响应消息处理

中国好公民st

c++ qt 9月月更

DPDK源码分析之rte_eal_init(一)

于顾而言

DPDK

NFTScan 正式发布 PlatON 网络 NFT 浏览器

NFT Research

NFT platon

Sentinel哨兵机制

急需上岸的小谢

9月月更

DPDK源码分析之DPDK基础概览

于顾而言

DPDK DPDK开发

图解Kafka Producer中的消息缓存模型

石臻臻的杂货铺

Kakfa 9月月更

每日算法刷题Day12-跳台阶、排列、替换空格、求n累加

timerring

算法题 9月月更

新书上市 | Vue 3.0 核心源码解析,这本书给Vue学习提供新方法

图灵教育

前端 代码 VUE 3.0 源码

图库

武师叔

双活数据建设方案

阿泽🧸

双活 9月月更

DAYU200升级最新的OpenHarmony系统,一起来玩开源鸿蒙呀!

坚果

鸿蒙 OpenHarmony 9月月更

DPDK源码分析之DPDK技术简介

于顾而言

DPDK DPDK开发

流计算中的Windows计算

孤衫

大数据 流计算 9月月更

网络入侵检测系统之Snort(一)--snort概览

于顾而言

网络安全 ips

架构师的十八般武艺:一致性

agnostic

CAP 一致性

TO B的本质是“定制化”不变,“定制化”实现方式求变

B Impact

TO B

Robot Framework作者建议如何选择自动化测试框架_软件工程_申健_InfoQ精选文章