敏捷自动化测试(3)-让断言不再成为自动化测试的负担

第第页敏捷自动化测试(3)——让断言不再成为自动化测试的负担敏捷自动化测试(3)——让断言不再成为自动化测试的负担

发表于：2023-04-26来源：infoq：殷坤点击数：标签：

在本系列的第一篇文章“我们的测试为什么不够敏捷”中，根据实例总结出敏捷自动化测试的两大阻碍：“脚本维护困难”、“断言条件繁琐”。本文针对在不失自动化测试有效性的前

在本系列的第一篇文章"我们的（测试）为什么不够敏捷'中，根据实例总结出敏捷（自动化）（测试）的两大阻碍："脚本维护困难'、"断言条件繁琐'。本文针对在不失（自动化）测试有效性的前提下如何降低断言成本来分享一些实践经验。

目前业界常见的自动化（测试工具）在断言方面大多都是采用"指哪儿打哪儿'的细粒度模式，即，在（自动化测试）过程中只能对设置为断言条件的字段(页面元素)进行断言。而且这些（测试工具）即使提供录制脚本的功能，但对于断言往往还需要（测试人员）手工补充插入。

除了补充、维护断言条件的工作量大之外，这种断言模式还存在一些明显的不足，下面结合一个实际的例子(如下图)进行分析：

无法感知未设为断言对象的字段上发生的错误

以上图为例，如果在"增加用户'的测试脚本之后只对列表中的"用户姓名是否存在'进行断言，那么就可能遗漏"入职日期没有提交成功'的错误。而且由于页面的信息量往往很大，我们是不可能对所有字段都设置为断言条件的。

相关厂商内容

一路走来技术人的创业故事

未来物联网中智能硬件的角色

人工智能的技术版图

GMTC全球移动技术大会，6折优惠，最后一周!

不要写死!天猫App的动态化配置中心实践

难以对于UI样式或UI逻辑进行断言

以上图为例，有一个UI样式类的（缺陷）(左侧菜单树的根节点"console'下面多出来一条虚线)和一个UI逻辑类的（缺陷）(右侧用户列表只有一页，但"下一页'和"最后一页'图标依然是可以点击的，即没有灰显)。此类缺陷即使对于经验丰富、心思缜密的测试人员，在人工测试时也是很可能发现不了的，并且在自动化测试过程中也很难进行断言。

即使存在上述问题，测试脚本中是否有充分的断言，依然是评判自动化测试有效性的一个重要指标。但实施过自动化测试的人应该都会有这样的体会："大部分断言在大部分情况下只是佐证软件是运行正常的'。

当然，所有人都应该是非常期待看到这样的结果，毕竟谁也不希望每次（回归）测试时都是（用例）大面积不通过。只是辛辛苦苦写这些断言语句的测试人员心里未免有些"小遗憾'。

本系列上篇文章中谈到"很多人一提到自动化测试脚本，马上就想到需要提供录制工具'，但如果换个角度思考，很可能就是"柳暗花明又一村'。

在这里，我们同样换个角度思考，假设我们的自动化测试主要目标是为了证明软件运行正常，那么我们会怎么做?

笔者这边的一个经验就是"按照完整的业务流程来组织（测试用例），只对少量、必要的关键点进行断言'。以"租户对虚拟化资源的申请使用'为例，来具体看看（测试用例）的组织方式：

新租户注册;

管理员登录系统，对注册租户进行审批，然后退出系统;

审批后的租户登录系统;

租户申请所需要的虚拟化资源(比如，40G硬盘、2核CPU、2G内存)，然后退出系统;

管理员登录系统，对租户申请的资源进行审批，然后退出系统;

租户登录系统，在已申请资源的基础上创建安装指定操作系统的虚拟机;

断言虚拟机是否创建成功;

租户退出系统;

管理员登录系统，删除租户;

断言租户之前申请的资源是否被完全释放;

租户再次登录系统，断言是否无法登录;

上述测试用例就是按照完整的业务流程进行组织，并且只对少量关键点(7、10、11)进行断言，如果整个用例可以运行通过，就能证明这个业务是没有问题的。

另外还有一个值得考虑的现象，就是相对于自动化测试而言，一个优秀的测试人员在人工测试时是如何判断功能正确与否的呢?他不会死板的只盯着某几个输入域的值，他一定还会同时关注页面上所有数据的正确性、会更加关注业务流