大概一周哇

有两种解决办法，第一种是一个 case 下仅涉及一个接口，那么你可以 case1 新建，然后断言成功够将 id 存储起来 (可以是全局变量形式)，然后 case2 删除，在 case2 中先判断 id 是否有效 (是否被 case1 成功赋值)，然后再拿着 id 编写删除的相关 case。这种方式就会导致 case 间的耦合性很强，不太适合经常只执行脚本中部分 case 的场景。第二种方式就是一条 case 下涉及多个接口，也就是在一条 case 下先写新建接口的用例，然后断言通过后取到新建的 id，可以保存为局部变量 (在一个 case 里变量存储就方便多了)，然后再写删除接口相关的 case。第二种方式的优势就是降低了 case 间的相互依赖，适用于经常单独运行脚本中部分 case 的场景。但是这种方式我总感觉每一条 case 都不太纯粹 (这条 case 到底是验证新建呢，还是验证删除呢)，还有就是如果遇到复杂点的场景，那么一条 case 就会很长，臃肿。以上仅仅是我个人的一点经验， 。

这并不是懒，你这套是前期投入产出比最高的组合，能立竿见影，随着接口测试的收益越来越大，工具的局限性越来越多的时候，才会促使我们向更深层次的地方探索呀。

“所以在有限的环境内找到更适合落地的尝试对于小厂的测试人员来说算是最佳的选项了”

很开心你能读文，很开心你能给我留言。

好的，谢谢，我实践一下先。

谢谢阅读和回复 ，我会着手学习 allure 相关，待我实践后再来发文。

哈哈，摸索的过程确实有趣，也希望佬哥们可以纠正，指点。

谢谢阅读和回复 我想了下您给的解决方案，还有一点疑问。
TO 问题 1：是将期望 response 存储吗？我们当下业务，比如新增接口，新增成功后会返回新增产品的 id，所以这个期望响应好像没办法提前写好；
TO 问题 2：我想过利用查询数据库对查询类的接口做断言，但是仅限于测试环境，因为测试人员很少会拥有正式环境数据库的访问权限；

这就要看你用例的粒度控制了，为了严谨你可以选择全覆盖，也就是你说的笛卡尔积；当然你也可以选择策略覆盖，我也提前声明了参数间没有依赖关系，且参数的对应的参数值选择也不涉及重要与否的优先级，在这种前提下我选择遍历所有参数中参数值最多的一个 (也就是 A，因为他有 5 个参数值)，又因为都是必填项，所以参数 B 和参数 C 就轮询取各自的可选值。其实针对这种多参数组合测试的覆盖策略是我用于编写功能测试用例的，因为毕竟在写功能测试用例时不可能把用例写到笛卡尔积这么细的程度。其实这也是我为什么选择编写方法来生成测试数据，而不是去手动在 excel 中插入数据，就像你说的，我就担心用例遗漏，我就想笛卡尔积，那么可以，只需要编写相应的测试数据生成函数就可以了。*~^

这回够完整吗