我是这么干的：比如 场景 1：新建 ，场景 2：新建、删除。 当然场景 2 可以用测试框架设置依赖，场景 1 不成功就跳过

我是设计新建->查询->删除保证我的全流程可以跑通，又不影响整体的自动化案例执行

你的用例是指代码里用例的实现还是指文档中的写法?

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

首先删除的功能注定了必须要有个目标 id，单接口用例的话需要你给个参数，而多接口场景可以用删除接口来进行数据清理，也可以从前面自动获取到目标 id。
至于所谓的 “保障执行成功”
我感觉你要问的是用什么信息来进行结果比对，是 code 即可还是部分参数比对，是全参数比对还是直接数据库查询验证，这些是没有定论的，但是性价比较强的应该是部分参数比对

要做到每个接口验证的功能能够单独运行的话，是会存在一条用例冗余的情况，不过这样可以保证你在跑自动化整体的时候不会因为一条失败而阻塞

单接口的话会需要用到前置后置，删除接口 可以在前置中在数据库加入数据，新增接口 ，可以在后置中在数据库删除数据

现在不少平台已经把接口、用例区分的很清楚了。接口是接口，用例是用例。用例可以有多个接口组成。怎么设计，前面的同学回答的很清楚，我就不再赘述了。