数据驱动
# 数据驱动
# 数据驱动
概念：将测试数据与脚本分离，提高脚本复用性
作用：
- 解决了大量重复脚本的问题，实现了“测试脚本和数据的解耦”
- 数据文件中不仅可以包含测试输入数据，还可以包含测试验证结果数据，甚至可以包含测试逻辑分支的控制变量
- 不仅适用于 GUI 测试，还可以用于 API 测试、接口测试、单元测试等
# 测试数据
常见数据类型：
- 测试输入的数据
- 为测试准备的数据
测试数据创建的方式
从创建的技术角度，测试数据创建方式：
- API 调用
优势：测试数据的准确性直接由产品 API 保证
缺点：并不是所有的测试数据都有相关的 API 来支持，对需要大量创建数据，基于 API 调用方式的执行效率
- 数据库操作
存在的问题：
创建或修改一条测试数据可能会涉及很多业务表，任何的遗漏都会造成测试数据的不准确，从而导致有些测试因为数据问题而无法进行
解决思路：
- 手工方式
查阅设计文档和产品代码，找到相关的 SQL 语句集合，或直接找开发人员索要相关的 SQL 语句集合
- 自动方式
测试环境中，先在只有一个活跃用户的情况下，通过 GUI 界面操作完成数据的创建、修改，然后利用数据库监控工具获取这段时间内所有的业务表修改记录，以此为依据开发 SQL 语句集
好处：可以创建和修改 API 不支持的测试数据，执行效率高于 API 调用方法
缺点：数据库表操作的任何变更，都必须同步更新测试数据工具中的 SQL 语句
- 综合运用 API 调用和数据库操作
从创建的时机角度，测试数据的创建方式：
- On-the-fly：用例执行过程中，实时创建测试数据
优点：不依赖被测试系统中的任何原有数据，也不会对原有数据产生影响，从数据层面隔离测试用例
存在的问题：
在用例执行过程中实时创建数据，导致测试的执行时间比较长
业务数据的连带关系，导致测试数据的创建效率非常低
比如：需要创建一个订单数据，而这个订单必然会绑定买家和卖家，以及订单商品信息
如果完全基于 On-the-fly 模式，需要先实时创建买家和卖家这两个用户，然后再创建订单中的商品，最后才是创建这个订单本身。显然，这样的测试数据创建方式虽然是“自包含”的，但创建效率非常低，会使得测试用例执行时间变得更长，而这恰恰与互联网产品的测试策略产生冲突
- 实时创建测试数据的方式对测试环境的依赖性很强
比如：测试用户登录功能，基于 On-the-fly 方式，应该先调用测试数据工具实时创建一个用户，然后再用这个用户完成登录测试。这时，创建用户的 API 由于各种原因处于不可用的状态那么这时就会因为无法创建用户，而无法完成用户登录测试。
使用场景：对于只能一次性使用的测试数据，比如商品、订单、优惠券等，往往采用 On-the-fly 的方式以保证不存在脏数据问题
- Out-of-box：用例执行前，事先创建好“开箱即用”的测试数据
优点：开箱即用，在被测系统中预先创建好了充足的、典型的测试数据，后续的测试用例可以直接使用
使用场景：对于相对稳定的测试数据，比如商品类型、图书类型等，往往采用 Out-of-box 的方式
存在的问题：
测试用例中需要硬编码（hardcode）测试数据，额外引入了测试数据和用例之间的依赖
只能被一次性使用的测试数据不适合 Out-of-box 的方式
比如：优惠券在一个订单中被使用后，就失效了
- “预埋”的测试数据的可靠性远不如实时创建的数据
On-the-fly 和 Out-of-box 的互补：
- 对于相对稳定、很少有修改的数据，建议采用 Out-of-box 的方式
比如：商品类目、厂商品牌、部分标准的卖家和买家账号等
对于一次性使用、经常需要修改、状态经常变化的数据，建议使用 On-the-fly 的方式
用 On-the-fly 方式创建测试数据时，上游数据的创建可以采用 Out-of-box 方式，以提高测试数据创建的效率
比如：订单的创建可以采用 On-the-fly 方式，而与订单相关联的卖家、买家和商品信息可以使用 Out-of-box 方式创建
（完）