低代码到底是不是行业毒瘤?一线大厂怎么做的?戳此了解>>> 了解详情
写点什么

自动化测试中的测试执行自动化

2015 年 12 月 06 日

“自动化测试”这个术语的使用是如何对团队深挖自动化益处产生束缚作用的,Richard Bradshaw 在 Agile Testing Days 2015 上对此进行了探讨分析。

InfoQ 有幸采访到了 Bradshaw,就测试和检查的不同之处以及为什么两者都很重要、自动化能怎样支持测试、自动化框架的使用以及为什么测试人员应当时刻紧盯测试中的问题等话题与其进行了交流。

InfoQ:请您详细说明一下测试和检查二者之间的区别。

Bradshaw关于这点,我建议每个人都去读一下 James Bach 及 Michael Bolton 写的精析测试与检查这篇文章,形成下自己的看法,我的观点目前和两位作者在文章中所阐述的一致。对我来说,测试和检查的主要区别在于是否以学习为中心。学习是知识的获取。我们通过测试软件来获得软件自身的知识,这些知识实质是业务需求,后面做出明智的决策均基于此基础上。在测试的时候,我们可以自由随意地研究系统,遵循启发式思路,在已有结果的基础上进行研究,去探寻新的信息。在这个过程中,我们在不断学习。而检查,确切地说,就是只有检查。我们依靠某些模型来检查系统,去检测有违模型的变化之处。我们所执行的只不过是一系列的算法步骤。这中间没有学习。我们还得评估所有这些检查的结果,为了找出其中是否存在问题。而这些只有人方能办到。

InfoQ:您为什么认可这两者都是重要的呢?

Bradshaw它们二者互相补充。在我看来,二者若缺其一,剩下的一个也将独木难支。我们需要对系统的关键行为进行检查,尤其是那些会消耗商业资源或破坏商业声誉的行为。当然了,你也可以说所有的 bug 都会造成这样的后果,所以我说的是诸如不能在亚马逊上下单,或者不能在 Slack 里发送信息之类的重要事件。与此同时,还要测试系统的新功能,尽管从业务层面能够理解系统行为,但我们的测试还是要做,得弄清楚这些新功能是怎样影响系统其它部分的。检查有助于引导此类测试活动,检查活动就像当检测到了某一部分的变化时,对外发出公开邀请,以对变化部分做进一步的探索和测试。

InfoQ:您在讲演中提到,自动化应是对测试形成支持,而不是去替代测试。请您解释下这个观点。

Bradshaw在以前的工作里,别人告诉我,自动化的目标是替代测试活动,主要是替代回归测试。好几次我甚至还碰到过这样的讨论,说自动化实际上能够替代测试工程师。这当然不过是空谈。讲演中提及这个观点的主要原因,是为了保持我在测试和检查上的观点的一致性。在我看来,大多数人口中的自动化测试,实际上只是自动化检查。他们为系统制定了一个模型,照着这个模型做检查。但正如前面所说的,我们还需要测试,所以需要理解的是,这些自动化检查支撑了我们的测试成果,而不是替代测试成果。另外,如果认可测试是必需的话,我们应当去研究怎样才能让测试变得更快、更深入,或者研究如何才能进一步延拓测试范围。什么样的工具我们能用来支撑测试,完成像数据管理、状态控制以及日志文件解析等事务。

InfoQ:您正在用哪些自动化框架?您在测试过程中是如何应用它们来达成自动化的?请举些例子谈谈。

Bradshaw我喜欢用类似于拼出来的架构,拼图性质的架构。用拼图来描述抽象和解耦比较朗朗上口。在架构设计时,我一般会把它们设计为一个个独立的部分。比如说,GUI 自动化检查方法通常是这样的,有一部分代码用做数据管理,从电子表格程序中读数据或者在数据库里创建数据,另一部分代码用于创建浏览器实例,供测试人员使用,还有一部分代码用于管理测试人员和页面的交互,最常见的就是 PageObjects,最后还有一部分代码用于处理报告结果。把所有这些部分拼在一起,就组成了一个能用于自动化检查 GUI 的工具了。既然设计出来的架构的粒度小,那么现在在整个测试过程中这些模块都可被我们利用了。我们可以为数据生成代码创建一个 GUI,或甚至是命令行接口,团队成员在测试的时候就可以用这部分代码来生成数据,而不用自己一头扎进 DB 里。另外一个例子是我目前正在做的,通过使用终端自动化架构中的部分内容,将 app 部署在 1-N 设备上,启动 app,执行登录和停止。这样我一下子就能完成手机批量更新,每个版本节省了大概 15~30 分钟的时间,多出的时间我可以去做测试。

InfoQ:在测试和自动化方面,您有什么心得体会想和其他测试人员分享的?

Bradshaw我们对自动化的看法及其讨论都需要改变。应牢记我们所要解决的是测试问题,而不是“我们需要自动化”的问题。严肃认真地思考下你面临的测试问题,在最适合的环节使用工具,同时别忘了工具自有其局限性。

我想要表达的观点是,我目睹了很多公司盲目追求自动化,自动化好像是它非要不可的玩具一样。我也遇到过团队将自动化单纯地视为端到端的脚本,其中包含了一些启动项、一些动作项和一些断言语句。应破除这些模子。以批判性的眼光来审视测试过程中需要改进的部分,如果自动化对此能有所帮助,就加入相应部分的自动化。分析测试方法中的瓶颈之处,深入的挖掘分析,不要止步于比如回归测试耗时太长这种层次的分析。究竟是哪一部分的回归测试耗时过长?别只盯着瓶颈自动化,很多时候这远不是事情的全部。

最后一点,别忘了自动化本质上是笨呆的,实现自动化需要持续不断的培训。这会花费很多时间,你确定有这么多的时间吗?而测试人员作为一个鲜活的人,时刻都在不停学习,想象下,如果你手头上有一些趁手好使的工具,那该能对你的测试起到多么大的改善作用啊?

查看英文原文: Automation in Testing over Test Automation

2015 年 12 月 06 日 18:002136
用户头像

发布了 30 篇内容, 共 67420 次阅读, 收获喜欢 1 次。

关注

评论

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

开源这件事儿,越来越“声势浩大”了

赵钰莹

Apache GitHub 阿里巴巴 开源 腾讯

redis数据结构介绍-第一部分 SDS,链表,字典

Nick

redis 源码 数据结构 源码分析 算法

NVidia Docker介绍

薛磊

Docker

特定系统的Linux的构建

韩超

苏宁云商向江旭:是时候让技术成为新司机了!

TGO鲲鹏会

聊聊分心这件事

Jackey

我使用了哪些生产力工具?

ikook

效率工具 软件 Alfred Notion 推荐

面试官,不要再问我三次握手和四次挥手

猿人谷

面试 TCP 三次握手 四次挥手

百度主任架构师谭待:打造非职权技术管理机制

TGO鲲鹏会

字节跳动的增长密码

池建强

字节跳动 张一鸣

ELF文件格式

韩超

纯技术改造,技术如何驱动需求,我有话说

一叶而不知秋

项目管理 架构 技术

基于RocketMQ实现分布式事务 - 完整示例

清幽之地

Java 分布式事务 RocketMQ 微服务

高手和普通人的差距,不看不知道,一看吓一跳

熊斌

学习

中台之路,从平台到中台的思考与实践(二)

孤岛旭日

架构 中台 企业中台 企业架构

人间至味——苦瓜

三只猫

人生 美食 生活

Gitlab CI/CD 中的 Cache 机制

Chong

DevOps gitlab cicd

Doris 一种实时多维分析的解决方案

迹_Jason

大数据

Linux的proc文件系统编程

韩超

微服务架构深度解析与最佳实践-第一部分

kimmking

微服务 微服务架构 最佳实践 深度解析 高可用

3000w人民币的学费——我的决策反思

孤岛旭日

数据中台 架构 中台 企业中台 企业架构

程序员通过哪些方式来赚钱?

一尘观世界

程序员 外包 自由职业 副业 赚钱

Kylin 实时流处理技术探秘.笔记

迹_Jason

大数据

从西游到武侠——确定性与不确定性

伯薇

个人成长 管理 确定性 不确定性

服务降级的常见套路

松花皮蛋me

Java

NVidia-Docker2 性能优化

薛磊

Docker gpu nvidia container

【JAVA】感受下JDK14的空指针提示

遇见

Java jdk jep

Docker Swarm 踩坑

ikook

Docker Docker Swarm 技术 容器 踩坑

自动驾驶复苏在2020

陈思

人工智能 自动驾驶

[KubeFlow] MPI-Operator深度解读

薛磊

Docker gpu kubeflow Kubernetes

中台之路,从平台到中台的思考与实践(一)

孤岛旭日

架构 中台 企业中台 企业架构

2021 ThoughtWorks 技术雷达峰会

2021 ThoughtWorks 技术雷达峰会

自动化测试中的测试执行自动化-InfoQ