数据准备是软件测试过程中非常重要的一个环节，特别是自动化测试。对于复杂的系统，数据准备会占用相当多的时间，因此好的数据准备工具对提高测试的效率非常重要。
目前，数据准备工具实现方法主要有以下几个：
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语句，直接修改记录的方式实现（当然前提是不需要验证数据完整性和一致性）。
