数据准备实现的几种方法
数据准备是软件测试过程中非常重要的一个环节,特别是自动化测试。对于复杂的系统,数据准备会占用相当多的时间,因此好的数据准备工具对提高测试的效率非常重要。
目前,数据准备工具实现方法主要有以下几个:
1. 前端UI自动化脚本
2. 通过DML操作数据库
3. 调用应用提供的接口
4. 通过发送请求方式
一、UI自动化脚本实现数据准备:
实现方法:
通过UI的自动化脚本实现数据准备比较直观,并且能直接调用已经实现的UI自动化脚本代码。比如,测试搜索功能时,翻页是必需要测试的,而且测试翻页会涉及很多用例,比如单关键词,多关键词组合查询后,翻页是否保留初始查询条件等。当然,可以通过修改代码把每页显示条数减少测试翻页,但不严谨,易出问题,如若测试完成后代码没有改为原始值。
对于这类问题,使用UI自动化脚本准备数据就很方便了。测试翻页前,首先多次调用添加数据的脚本,然后做后续必要操作,比如更新索引,更新缓存等。所有都通过后,进行查询操作,验证翻页是否正确。
优点:
1. 实现比较简单,UI自动化的框架和工具较多,并且有不错的录制回放工具,在录制的基础上再修改脚本就可以
2. 数据完整性和一致性好
3. 若已有相关功能的自动化脚本,可复用,节约时间
缺点:
1. 对UI依赖大,执行效率低
2. 变化频繁,维护成本高
3. 复用性差,不利于其他测试,比如接口测试、性能测试调用
4. 和UI自动化测试结合紧密,很难成为独立的工具
二、通过DML操纵数据库:
实现方法:
通过DML操纵数据库进行数据准备是很高效的,因为这种方法抛开了前端页面,抛开了程序逻辑,直接把数据写入DB,或者进行更新、删除等操作。以上搜索测试,使用这种方式准备数据,效率会很高,而且如果性能测试需要大量的干扰数据而非正常的业务数据,也可以采用这种方式。
优点:
1. 高效、直观。
2. 复用性好,可被性能测试、接口测试等调用。
3. 维护成本相对较低。
缺点:
1. 对于比较复杂的系统,表间关系依赖较多,字段间依赖复杂且多时,这样的方式往往会很复杂,一旦sql语句有问题,也会影响效率。
2. 这样的数据被用于自动化测试时,可能与系统的实际功能不一致,导致验证失败。比如一般系统查询时先查缓存,返回结果。通过DML方式插入的数据,缓存不会自动更新,可能查询结果中没有新的数据。
三、通过调用应用接口:
实现方法:
通过调用应用的hsf接口实现数据准备,这样方式可以很好的规避UI和DML方式的缺点,实现比较高效而且与实际功能一致的数据。但实现相对难一些,需要对hsf接口有较深的了解。
优点:
1. 适用于复杂业务,更高效。
2. 数据完整性、一致性好
3. 复用性好,可被性能测试、接口测试等调用。
4. 维护成本相对较低。
缺点:
1. 实现相对难一些,需要对接口了解较多;
四、通过提交http请求:
实现方法:
提交http请求方式准备数据,相对于UI的方式效率较高,不需要等待页面、控件加载,而是通过程序语言直接提交请求,此时应用接收到的请求与用户通过页面操作提交的请求是一样的,因此程序逻辑均会被执行,如插入数据后会更新缓存等。这样的方式准备的数据完整性和一致性好。
优点:
1. 数据完整性和一致性好。
2. 维护成本相对较低。
缺点:
1. 实现时相对麻烦,需要考虑cookie,tb_token等变量,比如创建订单需要用户信息,提交这个请求嵌,首先需要先发送登录请求,然后从response header中获取cookie及token,创建订单时需要带上cookie和token,这样应用才能认为是正常的请求,才会继续执行。
2. 请求中包含的内容较多时,拼接请求也比较耗时,因此代码量相对较大
3. 若服务器端验证浏览器安全控件时,如支付时,实现很困难。
五:总结
每种准备数据的方法都有优缺点,实际工作中,可以灵活运用,把不同方法组合起来,比如创建订单时,可以使用调用hsf接口方式实现,但支付状态,可以通过sql语句,直接修改记录的方式实现(当然前提是不需要验证数据完整性和一致性)。