二种方法可以在用例执行前,先查询下余额是否大于 100,若大于等于则继续,若小于则做 一笔充值 100 的操作,这
样即可解决。两种方式可以看具体情况使用,数据初始化方便,但有时候初始化之后可能会影响到其他自动化测试用例
的执行,而第二种 方式相对在脚本上需要稍微花点功夫。究竟使用哪种方式还需要具体情况具体分析。总之,在执行
自动化测试用例之前做好数据准备,这也是自动化测试的关键步 骤。
原则 5:自动化测试用例和手工测试用例不同,不需要每个步骤都写预期结果。
在手工测试用例的设计过程中,几乎每一个测试步骤都有一个预期结果。但是,在自动化测试用例的设计中并不
采用,在自动化测试用例中,只有准备在测试脚本 中设置成检查点的步骤才有预期结果,其他所有的步骤只将它看作
一个步骤,这样做的好处是一目了然、目的明显、层次分明,以后写测试脚本直接跟着自动化测试 用例就行了。因为
经过前面的探讨应该已经知道,自动化测试中并不是所有的东西都需要验证的。所以,作者在前面的章节中也提到过,
基本上手工测试用例多多少 少都要进行一些转换的,就是因为它们之间的格式是不一致的。举一个简单的例子,假设
需要设计一个注册页面的自动化测试用例,有 10 几个表单 需要填写,在手工测试用例中,每个表单的填写都一定会有
预期结果,因为它的确在检查每一项是对了还是错了,只是用的是你的眼睛在检查而已,所以速度非常的 快,甚至你
自己潜意识都忽略了其实你已经检查了。但是,在自动化测试中,我们知道如果你要检查,那一定需要写代码,如果每
项都检查,那代码量有多大是可想 而知的,不是说做不到,只是这样做根本不符合自动化测试的特点。所以,绝大部
分时候,这些在自动化测试中可有可无的检查,我们全部“不检查”,只当做一个业务流程和步骤,是不需要设立预期结
果的。
难以对于 UI 样式或 UI 逻辑进行断言
以上图为例,有一个 UI 样式类的缺陷(左侧菜单树的根节点“console”下面多出来一条虚 线)和一个 UI 逻辑类的缺陷
(右侧用户列表只有一页,但“下一页”和“最后一页”图标依然是可以点击的,即没有灰显)。此类缺陷即使对于经验丰富、
心思缜 密的测试人员,在人工测试时也是很可能发现不了的,并且在自动化测试过程中也很难进行断言。
即使存在上述问题,测试脚本中是否有充分的断言,依然是评判自动化测试有效性的一个重要指标。但实施过自动化测
试的人应该都会有这样的体会:“大部分断言在大部分情况下只是佐证软件是运行正常的”。
当然,所有人都应该是非常期待看到这样的结果,毕竟谁也不希望每次回归测试时都是用例大面积不通过。只是辛辛苦
苦写这些断言语句的测试人员心里未免有些“小遗憾”。
本系列上篇文章中谈到“很多人一提到自动化测试脚本,马上就想到需要提供录制工具”,但如果换个角度思考,很可能
就是“柳暗花明又一村”。
在这里,我们同样换个角度思考,假设我们的自动化测试主要目标是为了证明软件运行正常,那么我们会怎么做?
笔者这边的一个经验就是“按照完整的业务流程来组织测试用例,只对少量、必要的关键点进行断言”。以“租户对虚拟化
资源的申请使用”为例,来具体看看测试用例的组织方式:
1. 新租户注册;
2. 管理员登录系统,对注册租户进行审批,然后退出系统;
3. 审批后的租户登录系统;
4. 租户申请所需要的虚拟化资源(比如,40G 硬盘、2 核 CPU、2G 存),然后退出系统;
5. 管理员登录系统,对租户申请的资源进行审批,然后退出系统;
6. 租户登录系统,在已申请资源的基础上创建安装指定操作系统的虚拟机;
7. 断言虚拟机是否创建成功;