写点什么

自动化验收测试的实用技巧

  • 2017-02-16
  • 本文字数:2553 字

    阅读完需:约 8 分钟

等价划分、边界值分析以及基于风险的测试等测试技术,可以帮助我们决定测试的对象以及转换自动化测试的时机。Adrian Bolboacă表示,当你在开发一个新的项目时,一开始放低自动化测试的占比是一个明智的选择。当你在测试一个现存的项目时,他建议在 bug 出现过的地方覆盖更多的自动化测试案例。

Adrian Bolboacă是 Mozaic Works 的组织及技术教练兼培训师,他在 2017 欧洲测试大会上阐述了自动化测试的各种类型。InfoQ 将追踪报道大会的提问环节、总结以及相关文章。

在 Bolboacă《自动化测试目的》的博客中,他定义了验收测试的目的:

验收测试常常是由测试人员编写的,它们验证一些系统特定的功能。但很奇怪,大多数人在谈及自动化测试时单指验收测试。

我们可以在模块、跨模块、系统、跨系统等级别进行验收测试。如果一个验收测试涉及跨模块或跨系统,即更多地关注于两个模块之间的交互,那么这就成为了综合测试(integrated test)。例如,任何涉及使用图形界面,来与另一个模块进行交互操作的测试都是综合测试。由于它们依赖于图形界面,使得这些测试很难被维护,因此不建议使用。

业务人员和业务赞助商是这些测试案例的首要受众群体。其次是测试人员,最后才是技术团队。

InfoQ 采访 Adrian Bolboacă,讨论了不同类型的测试、如何编写足够且优质的验收测试、何时使用自动化的测试、以及如何利用自动化测试来制定一个可行的测试标准。

InfoQ:您认为好的测试案例应该是怎么样的?

Adrian Bolboacă:测试案例应该非常清晰。以测试的名字和内容开头,任何人都可以理解需要这个案例的原因、它能怎么用来验证代码以及它存在的意义。基于这个原因,它应该足够短,并且不应该包含技术词汇。例如,使用“error”(错误)而不是“exception”(异常)就更便于非技术人员理解。

写很多小而独立的测试案例可以帮助我们定位问题出在哪里。但是这样我们就需要为单个行为写原子性的小测试。如果在测试中校验了多个行为,那么就不能称其为单元测试了,这时它们就成为了集成测试 (integration test)、验收测试、综合测试(integrated test)或端到端测试(end-to-end test)。当然,一个好的单元测试应该进行且仅进行一次验证。

InfoQ:那综合测试、验收测试和端到端测试有什么区别呢?

Bolboacă:先说最后一个。端到端测试用于检查系统多个模块的协调工作是否正常。它们不应该关心各模块中琐碎的行为。它们是技术层面的测试,可以帮助我们了解我们是否正确安装启动、安全设置是否完整、数据库连接是否正常、webservice 连接是否正常等。端到端测试主要由技术团队关注。

验收测试专注于系统功能,主要被产品业务人员所关心。他们需要查看各个功能是否工作正常。业务人员可以使用这些测试来决定是否可以将某个功能部署到生产环境。验收测试可以是模块级别的,也可以校验多个模块,甚至是贯穿整个系统。这取决于我们需要验收的对象,以及我们的系统架构。这些测试越大就越难维护。维护验收测试的成本会随着其大小而递增。我建议让验收测试专注于模块级别,而只在端到端测试中验证各模块交互是否正常。

综合测试的测试案例会涉及多个模块,常常会验证多个模块的细小行为。它们十分混乱,因为它们时常被修改,而且常常依赖于各个模块的琐碎细节。

假设我们有多个模块,每个模块都有一些行为需要检测。如:

模块 1:需检测 16 个行为
模块 2:需检测 21 个行为
模块 3:需检测 36 个行为

如果我们想要在综合测试中覆盖所有行为,我们在写每个测试案例时只能改变一个行为,且保持其他行为不变。让我们简单算一下,这样一共会有 16 * 21 * 36 = 12096 个综合测试案例。由于这些测试案例使用了图形用户界面、真实数据库及真实系统,导致它们运行速度还会很慢。

我推荐的替代方法是隔离每个模块的验收测试,再写一些端到端测试来确保设置正确,之后只要确保测试结果正确就行了。再让我们计算一下,16 + 21 + 36 = 73 个隔离的验收测试 + 2-10 个端到端测试。因此我建议避免使用综合测试。

InfoQ:您对编写足够且优质的测试案例有什么建议么?

Bolboacă:明智的决策应该是在一开始就对每个功能进行分析,确定是否应该编写 100% 覆盖的测试案例。可以使用等价划分、边界值分析、正反测试案例等技术。一开始一定要关注于正案例,即用户想要做什么操作?之后再关注反案例,即什么操作会导致问题?

第二步是要制作一个测试案例的列表。

第三步我建议进行风险分析。为每个案例在风险 - 影响的二维图表上标一个点。那些有高风险和巨大影响的测试案例需要进行自动化。大家可以更多地学习关于基于风险的测试的知识,我认为这些知识在这个过程中十分有用。

接下来第四步是要开始自动化所选中的测试案例。确保它们足够小、足够清晰,并且尽量使用业务领域的语言。把自己当做用户来查看这些案例,看是否能理解它们。

第五步是要和测试、分析、编码及业务的同事进行审查。

我们很难得知测试案例是否足够。我们常常会忘记一些关键测试案例,有时还会引入一些重复无用的测试案例。这也就是为什么需要审查环节。始终要记住三个臭皮匠顶个诸葛亮,团队的力量总比个人强。

InfoQ:那可以使用什么条件来决定是否应该将一个测试案例自动化呢?

Bolboacă:正如我之前所说,我建议使用基于风险的测试,来决定哪些测试案例需要自动化。

同时,这里还包含许多其他因素。

对于新的项目,也许在充分了解需要哪些自动化测试以及它们怎么能帮助到项目之前,并不需要自动化很多案例。但是了解了这些背景后,就要为过去的这些功能写更多测试案例,并且测试案例的开发需要同时与新功能的开发保持同步。在 2-5 个月后,就应该能充分了解团队会在哪些地方犯错以及会有哪些风险等。

对于现存的项目,我们就要使用过去的经验,看哪里出现过 bug,为何会发生这些 bug,并使用更多自动化测试案例将它们覆盖。

对于增加使用新工具或框架的情况,就需要更多的测试案例,因为很明显我们会在一开始就犯错。大家将这些错误归类为 bug。

InfoQ:您是如何利用自动化测试来制定一个可行的测试标准的?

Bolboacă:首先,测试案例需要使用领域驱动语言,而非技术语言。测试的名字应该能够被业务人员及用户理解。

其次,我们要将测试按照不同受众对象分组。这样我们就可以将单元测试、集成测试、验收测试等分别放入各自对应的包中。

查看英文原文: Practical Tips for Automated Acceptance Tests

2017-02-16 18:002778
用户头像

发布了 41 篇内容, 共 13.6 次阅读, 收获喜欢 3 次。

关注

评论

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

数据通信网络之IPv6以太网二层交换

timerring

数据通信网络

自动化办公更简单了!新版python-office,有哪些更新?

程序员晚枫

Python

蓝易云:Linux 修改系统时间的两种方式?

百度搜索:蓝易云

云计算 Linux 运维 Date 云服务器

Zebec 生态 AMA 回顾:Nautilus 以及 $ZBC 的未来

BlockChain先知

一文读懂云公有、私有云、混合云的区别

青椒云云电脑

云桌面 云桌面厂家 云桌面方案

5G时代超级玩家云游戏 技术是否为最大阻碍

青椒云云电脑

云厂商 云游戏

Zebec 生态 AMA 回顾:Nautilus 以及 $ZBC 的未来

股市老人

dapp技术开发团队 dapp开发

V\TG【ch3nguang】

蓝易云:【Linux】磁盘分区和挂载详细教程!

百度搜索:蓝易云

云计算 Linux 运维 服务器 云服务器

iOS技术博主指南:填写苹果应用上架中的隐私政策信息

雪奈椰子

DAPP系统开发需要多久?DAPP系统开发功能介绍

V\TG【ch3nguang】

springboot+jxls复杂excel模板导出

源字节1号

开源 软件开发 前端开发 后端开发 小程序开发

AITO问界新M7系列发布,全款问界车型已支持空间音频体验

最新动态

5G时代还在用传统PC?云电脑了解一下

青椒云云电脑

桌面云 云桌面 云桌面厂家

一文说清云桌面:设计师的秘密武器

青椒云云电脑

桌面云 云桌面

Mobpush与A/B测试:覆盖多应用场景下的精细化运营神器

MobTech袤博科技

六大商用场景:云游戏赚钱方法论

青椒云云电脑

云游戏

与 Dave 和 Ruba 一起探讨亚马逊云科技 2023 芯片创新日

亚马逊云科技 (Amazon Web Services)

人工智能 机器学习 量子计算 亚马逊云科技

Zebec 生态 AMA 回顾:Nautilus 以及 $ZBC 的未来

石头财经

ArrayList源码解析

前行

#java #源码分析

ARTS 打卡第 4周: BaseCamp团队是如何做产品的

前行

#ARTS #ArrayList

基于点云标注的自动驾驶系统的安全性与可靠性

来自四九城儿

自动化验收测试的实用技巧_语言 & 开发_Ben Linders_InfoQ精选文章