问答 关于接口自动化测试用例思路的两种方案，应该选哪种呢
需要测试的接口：
接口名称：根据商品状态进行查询
关键参数：status（0：未上架，1：已上架，2：已下架）
商品状态：未上架、已上架、已下架
商品状态流转： 未上架 →（上架操作）→ 已上架 →（下架操作）→ 已下架
方案一：
1.分别构造 未上架、已上架、已下架 状态的商品数据；
2.调用接口，依次传入 status=0、status=1、status=2，验证返回结果是否符合预期
方案二：
1. 构造一个 未上架 的商品；
2.传 status=0 查询，验证结果；
3.上架该商品，使其变为 “已上架” 状态；
4.传 status=1 查询，验证结果；
5.下架该商品，使其变为 “已下架” 状态；
6.传 status=2 查询，验证结果。
问下大家，应该选择哪种方案呢，问了两个 AI，两种答案都有
明显方案一更合适，对于人类而言操作步骤简单，单位时间内测试效率更高。对于 AI 而言，往往不会站在人类惰性上面去考虑问题。
如何分别构造 未上架、已上架、已下架 状态的商品数据?
是按照方案二的 1、3、5 流程构造吗, 那么你需要执行 3 次 , 那还不如直接使用方案一效率更高
还是通过改数据? 或者从数据库里捞取已有的数据?, 各有优缺点
方案一简单，方案二链路长，如果依赖的多个服务部稳定，用例稳定性会低一些；个人感觉是。方案二 + 稳定的测试换 应该也可
除非有什么特殊要求，不然首选第一种；接口自动化用例需要有原子性，每个 case 只测一个东西，保持简单
我喜欢方案二，可以一条用例跑完，数据也只产生一条，数据清理也简单，我做自动化不是为了找 bug，而是验证业务流转，提效。方案一要多产生 2 条数据，清理的时候也要麻烦点。当然每个人思路不一样 我看大家好像都喜欢方案一
吼猴
回复
就是按照方案二的 1.3.5，构造的数据，都是通过接口造的
通过数据库造的话，应该不建议吧？可能会有数据库字段变了、或者写入读取逻辑变了
方案 1 适合已产品状态为基地的测试流。方案二适合以围绕产品配置的测试流。一个是静态数据，一个是动态数据。
看心情，不重要
方案 2 是最符合使用流程的，接口测试就应该是这样的流程场景的测试。
如果提前造好了数据，只是验证这个接口是否 OK，没有验证到整个流程是否 OK。
如果上架和下架的操作有其他的自动化测试 case 验证是否成功，操作之后数据入库是否正确，那也可以使用方案一。
如果有单独的上架和下架操作的测试步骤；感觉还是写在一起更好。
简而言之就是，方案 1 验证单一的查询接口，方案 2 验证的是流程场景，我觉得方案 1 和方案 2 都应该存在，可以分两类跑，一类单一接口跑不同参数（这类还可以作为线上的一个巡检的方案），另一类可以单独跑，因为这类的稳定性可能会偏差一些
单纯的验证查询，肯定必须是方案 1，方案 2 你没法确认查询 status=0 在只有状态=0 的数据的情况下，是否还会查询出其他的数据。
如果是测试接口的话，这种如果希望测试的又全面，不遗漏的话，可以写一个脚本，遍历组合测试下，不要管他需求是啥，先不管他的结果是否满足要求，把结果记录下来，人工对结果进行审查，这样比较全面，可能会有一些意想不到的 bug 可以捡漏
方案 1 主要就是单个接口独立测试，就是单纯的接口测试 ； 方案 2 你可以理解成多个接口串起来的一种业务场景，一般就是串起来一些场景实现成自动化，作为开发提测的冒烟自动化测试，可以把项目各个模块核心重要的业务链路搞成冒烟测试场景。仅个人理解
补充一点，方案 1 就是单纯各个接口进行测试，不用考虑接口之间的依赖，之前我一般就是把接口文档梳理到 excel 中，然后 pytest 直接读取该 excel 进行全量接口测试，算是 excel 驱动的接口自动化的方式，excel 内容就是接口名称、地址、参数、预期返回这些