这是我购买的"极客时间"上的一套课程的笔记,总共52讲,定期对其中的内容做一笔记,巩固学习内容。
15 过不了的坎:聊聊GUI自动化过程中的测试数据
测试数据准备是实现测试用例解耦的重要手段。本篇从创建测试数据的技术手段和时机两个方面,介绍GUI测试数据的准备。
GUI测试中两种常见的数据类型
- 第一大类:测试输入数据,也就是GUI测试过程中,通过界面输入的数据。
- 第二大类:为了完成GUI测试而需要准备的测试数据。
创建测试数据的方法
- API调用
- 数据库操作
- 综合运用API调用和数据库操作
实际项目中,对于创建数据的技术手段而言,最佳的选择是利用API来创建数据。当API不能满足需要时,才使用数据库操作的手段。
实际上,许多测试数据的创建时基API和数据库操作两者的结合来完成,即先通过API创建基本的数据,然后调用数据库操作来修改数据,以达到对测试数据的特定要求。
创建的时机
- 测试用例执行过程中,实时创建测试数据。通常称为 On-the-fly 。
- 测试用例执行前,事先创建好“开箱即用”的测试数据。通常称为 Out-of-box 。
而对于创建数据的时机,实际项目中,往往是二者结合在一起使用。
下面作者结合具体的例子做出了说明,我就不再复述例子了,简单总结一下:
基于API调用创建测试数据
当数据的创建和修改,可以通过API调用进行的时候,就能够基于API调用创建测试数据。
实际项目中,通常会把对这些API的调用以代码的形式封装为测试数据工具。
基于API的方式,优点是,测试数据的准确性直接由产品API保证,缺点是并不是所有的测试数据都有相关API来支持。
但是,对需要大量创建数据的测试来说,基于API调用方式的执行效率会比较低。
基于数据库操作创建测试数据
当数据的创建和修改直接在产品代码内完成,并且没有对外暴露供测试使用的接口时,就需要通过操作数据库来产生测试数据。
同样地,可以把创建和修改数据的相关SQL语句封装成测试数据工具,以方便测试用例的使用。
有两个思路:
- 手工方式。查阅设计文档和产品代码,找到相关SQL语句集合。
- 自动方式。测试环境中,先在只有一个活跃用户的情况下,通过GUI界面操作完成数据的创建、修改,然后利用数据库监控工具获取这段时间内所有的业务表修改记录,以此为依据开发SQL语句集。
这两种思路的前提,都是假定产品功能正确。
基于数据库的方式,优点是,可以直接创建和修改API不支持的测试数据,并且执行效率远高于API调用方式。缺点是,数据库表操作的任何变更,都必须同步更新测试数据工具中的SQL语句。
所以,在实际工程项目中,需要引入测试数据工具的版本管理,并通过开发流程来保证SQL的变更能够及时通知到测试数据工具团队。
综合运用API调用和数据库操作创建测试数据
具体来讲就是,可以通过API先创建一个基本的数据,然后再通过修改数据库的方式来更新这个数据,达到创建特定测试数据的要求。
实时创建数据 On-the-fly
GUI测试脚本中,在开始执行界面操作前,通过调用测试数据工具实时创建测试数据,就是 On-the-fly 方式。
实际项目中往往会存在三个问题:
- 用例执行过程中实时创建数据,导致测试的执行时间比较长。
- 业务数据的连带关系,导致测试数据的创建效率非常低。
- 对测试环境的依赖性很强。比如创建数据相关的API需要处于可用状态,但是很有可能在测试用例执行的时候它是不可用的(在采用微服务架构的系统中很常见)。
事先创建测试数据 Out-of-box
在被测系统中预先创建好了充足的、典型的测试数据。
有效解决了实时创建数据的很多问题,但是缺点也很明显,主要体现在以下三个方面:
- 测试用例中需要硬编码测试数据,额外引入了测试数据和用例之间的依赖。
- 只能被一次性使用的测试数据不适合这种方式。
- “预埋”的测试数据的可靠性远不如实时创建的数据。
On-the-fly 和 Out-of-box 的互补
针对应该选择什么时机创建测试数据,总结了如下三点:
- 对于相对稳定、很少有修改的数据,建议采用 Out-of-box 方式。
- 对于一次性使用、经常需要修改、状态经常变化的数据,建议使用 On-the-fly 的方式。
- 用 On-the-fly 方式创建测试数据时,上游数据的创建可以采用 Out-of-box 方式,以提高测试数据创建的效率。
【心得】
作者这一篇写的太清晰了有木有!!!
仔细看看,作者提到的各种方式都有用到过。但是,可能由于经历的项目没有作者公司的大,团队对于测试数据的准备并没有特别重视,只是觉得能用就好,有些时候效率低一点也能够接受。所以从来没有想过还可以这样好好的总结,并且在不同的时机选择不同的方式,提升效率!
果然还是要做比较复杂的大项目,才能遇到更多的坑,从而提出更优化的解决方式,然后才能有这么详尽的总结和相关的心路历程。