方法 1：在测试用例中构建数据
setup: 创建一条 XX 状态的产品
test steps : ....
teardown: 删除该产品

方法 2：事先准备好数据库
setup: 加载数据库
test steps : ....
teardown: 还原数据库

方法 1：在测试用例中构建数据
setup: 创建一条 XX 状态的产品
test steps : ....
teardown: 删除该产品

创建 XX 状态的产品存在如下问题

1. 如产品无货，传递给后端的参数不能为 0，如果库存为 0 则该产品不能上架，且不能使用该购买接口。
2. 如产品下架，需要先调用创建商品接口，调用设置数量的接口..等..所以在测试该接口的时候必须保证其他接口先正确，多数接口互相依赖的时候怎么办呢。

方法 2：事先准备好数据库
setup: 加载数据库
test steps : ....
teardown: 还原数据库

通过数据库创建和删除数据有如下问题
通过数据库直接操作必须特别了解各个表之间的关系，多数需要链表插入，且每个表的字段的规则都需很清楚，且同一个业务可能数据分散在多出，mysql，mongo, redis 等，这样会不会增加很大的工作量

以上，可以话再请教一下~~

数据准备的不同策略：

1 走 DB
制约条件：多数据源不适合
数据源不透明，数据源被隔离不适合
规则复杂，数据源数据结构有复杂、动态依赖性不适合
（其他都可以的）

2 走系统入口，比如页面、接口等
制约条件：业务会有依赖性，比如先要搞定商品分类等

至于如何使用数据，就看你是采用物理清除、标记无效的软清除、采用随机数据策略保证互斥等了。看场景吧。

如果使用事务策略，则接口应用本身跟测试程序必须复用同一个数据源事务，而且不能有改变 DDL 的操作，就可以的。

具体情况要看你自己系统的业务哦，比如是否商品管理系统的接口，内部跟库存或者 ERP 系统有关系等等来权衡了。

如果接口未提供 delete 的功能呢，且如果直接插入数据库，怎么测试研发在写数据到表里面的处理逻辑是正确的呢
@kanchi240 同问

只要能接触到数据源比如数据库，无论如何都建议直接读取表比对业务后的真实数据的。
否则，需要组合其他接口，间接尝试暴露录入的数据。

最后一句没有看懂呢:

从我之前接触的商城商品购买等接口来看：
1.产品下架，产品信息页应显示无法购买，这时候应该测试产品信息接口查看产品状态
2.产品无货，当购买选择数量时，会调用产品接口查看库存，如果无库存是无法进行购买的。
3.产品过期同产品下架
本身感觉 LZ 所列的接口测试用例并不是单接口测试，而是购买业务逻辑接口串联的测试。就好比 app 调用第三方支付宝支付接口，测试的前提是能调用这个接口查看返回的订单等信息数据是否正确，我需要传个产品 id,数量和单价等等，那么支付宝接口肯定不会去校验你产品状态，因为那些是有别的接口去完成的。当然也可能 LZ 公司的接口是这样写的，那样去做这样的用例设计也正确。

比如通过下订单再查询订单接口，返还商品信息给外部 API，商品跟 ERP 整合等其他接口来验证该接口本身录入数据的正确性了，在接触不到数据源的情况下

而是购买业务逻辑接口串联的测试

非常同意这句话！！