比如某个较为复杂的客户管理系统，录一个客户后有 1000 条相关的用例。你们是选择录 1000 个客户去测试，还是录 1 个客户执行 1000 条用例。
没太懂，具体点？
同样权限的用户，选一个执行一次 1000 个用例？
不知道理解的对不对。
我认为不互相影响的目的是为了减少错误率，降低排查问题的难度
- 自动化有类似有要求（或者叫建议，原则比较好？）
- 哪个地方写着 "接口用例不能相互影响成原则了"? 请先把问题写清楚。
一个是并发，一个是：一个用户做了 1000 个用例的持续度 重度用户可以理解为。
你说的场景是属于集成测试了吧。
能不能把问题描述清楚
- 一般来说，你这里的登录是一个用例/场景里面的一个 step，而不是一个孤立的用例，互不依赖主要还是指多个相互不存在直接关系的业务场景的测试执行之间不能依赖；
- 如恒温所说，你这是集成测试，只不过是拿 API 测试的用例/脚本去做集成而已，没人说集成测试不能相互依赖，但是单纯的 API 测的确不应该存在相互依赖关系，因为不利于数据、环境治理，自动化稳定性和有效性不容易得到保证。
综上，“接口用例” 不能相互影响是你自己生造的概念或者你理解错了其他信息而产生的说法，只有相互依赖的测试执行场景，没有相互依赖的用例，用例天生独立。
请正确区分测试用例和 UML 中的用例（需求用例）。
你没有理解何时依赖，何时不依赖的原则，即多情形场景测试与单个测试用例的执行区别
自动化测试要做到较高的 运行稳定性 和 用例可维护性
这个要具体看下你业务的需求，单个用户是否满足（如是否存在角色问题和权限问题）
任何事情是有前提的，你如果要进行单接口日常测试。用 1 条数据，被 1000 个接口去测，没问题，因为运行完了就完了，这条数据删了也就删了，接口变也就变了，因为你测过了你不用管了，后面别人也不会用。但是！
但是！如果你要是写自动化脚本，用一条数据被 1000 个接口去调，会被打死。或者说，长得帅的人，一般不干这种事。
我给你举个简单例子
假设你这条客户数据 “小明，18 岁，男，高级管理员，自由从业者”，满足 1000 个接口的调用。有一天，你的接口当中有个做了调整，它需要查询，19 岁以上的客户。好了，你这条数据不满足了，于是你又造了一条，或者更糟糕的情况是你直接把小明改成了 20 岁。然后又有一天，另外一个接口又变了，它需要女性客户，你又增加数据。又变了一个接口，需要普通管理员等等等等，于是终于你造了一大堆客户。但是某天，数据库表被一顿操作不知道啥时候被清空了，数据丢了，当然这种情况还可以挽回，如果你批量化造数据。但是你发现 5000 个接口执行时间太长，需要分布执行自动化脚本，你又发现数据被同时操作又有冲突。。。。。。等等等等问题会等着。为了仅仅一开始偷的懒，后面要弥补多少操作?? 所以为什么一开始就不把事情做好呢??
自动化脚本写不难，难的是维护
等你维护 3w 条自动化用例的时候，你会发现，隔离，太他 niang 的正确了！而且要从框架搭建一开始就就要做！必须每条 case 是 0 耦合度！从用例执行前客户新建，到用例执行完删除客户，数据库每次都新的像舔过一样