接口自动化设计时其中注意事项中最主要的一点是用例独立，但是登录接口又必须保证用户已经注册才能进行登录，类似的场景如何通过更合理的设计，做到解除这样的依赖关系，使每个用例能够单独运行呢。
参数带已登录或者已注册用户的 token 或者 cookie，然后调后面的业务接口不可以吗？或者每次跑接口自动化的时候同一账号执行前在 setup 里面先校验一下当前用户的登录或者注册状态，如果过期或者未注册，先登录注册再继续，应该也不复杂
如果你们的业务有比较复杂的登录或者注册流程，就需要详细根据实际情况重新设计了
注册的用例：注册 + 验证
登录的用例：注册->登录->验证
很独立啊，哪个不能单独运行？
首先接口自动化可做单接口和多接口的，不太清楚楼主说要表达的意思，只能各自分析。
单接口测试，只需对 为后续接口提供前置信息的登录类接口 做个全局参数即可，无依赖可言
多接口测试，按流程顺序做接口就完了，也谈不上什么单独运行。
楼主是不是想问登录和注册这种逻辑顺序在自动化时应该怎么处理？注意接口执行顺序和参数传递即可。
还是想问怎么使每个用例可单独运行？做好前置信息供给即可，也就是先注册才能登录，登录后才能提供 token 进行内部操作
接口用例是接口用例 他们是独立的 运行的时候自动按参数依赖执行前置用例
接口间只要存在参数引用，就必须存在依赖关系，完全可以根据依赖关系推导出来，执行顺序，执行 A 接口时他引用了 B 接口的参数 你只执行的是 A 但会自动帮你先执行 B 然后才执行 A 。下面这图引用了其他接口提取的参数 就建立了他们的依赖关系 ，我认为接口的依赖关系在开发的时候 就决定了他们的关系 依赖是客观存在的 不是测试的时候才存在 ,所以只要按业务要求做好相关相关的引用就行了 ，平台给你推荐他们的关系拼按依赖帮你把所依赖的也执行了
根本不需要你来关注依赖 详见下面贴子 ，这里有关于接口测试的创新的想法
登录直接拿现成数据登不就好了吗
登录的用例不一定要用到注册的账号啊，也可以用老账号，这样就不用依赖注册了。
codes
回复
感谢大佬回复，正你所说 有些依赖是接口产生的时候就自带的 ，这在接口测试中只要用例设计得合理其实也不会有什么问题。但考虑用例设计的解耦其实是我在做性能的时候萌生的，举这个例子只是为了更易懂 抛砖引玉，可能我问题描述得没在点上。举个🌰，场景 A 执行前必须拿到有效的登录凭证 (通过接口 B 获取)，但是 A 和 B 不是同一个微服务，此时只想对对 A 做性能测试，那么是不是就会受到 B 所在微服务的性能的影响呢
Aaww
回复
和是不是压测没关系 压测和接口测试时他的依赖你必须跑呀，再说了出了问题你分析他的调用链么,如果慢的话 。就拿你的 B 来说 要是压 A 受 B 的影响 , B 很慢也能找原因的 ,照你说的方式你只压 A 性能很好 ,到了生产环境真实是要调 B 的 , B 把 A 拖慢了 ,是不是也要找你 ,谁压的 。压测 我要是要压单一接口估计还得要开发配合, 要是我我不管这些 肯定是按真实场景压 ,要是慢能找到原因就行 ,或是让开发自己去找。 要不然生产慢得要死 是不是要找你麻 烦。一句话压也是要按真实的场景 (或是依赖) 去压。准确来说是压以 A 接口为入口的接口, A 依赖的接口都要一起压了 ，致于是哪个该死的接口拖慢了 A 你能找出来更好 ,找不出来 就让开发来,不是用调用链吗,这很好分析出来，没问就让开发去排查
mark 一下
自动化用例一定要保证每个用例可以单独执行，
对于账号登录场景 可以建立一个账号池，把账号分为不同的类型。自动化用例 用户从池子里获取，执行测试场景。执行完毕之后 归还账号。
这样也可以做到用例并发执行 提高执行效率。
狂天
回复
自动化用例一定要保证每个用例可以单独执行,简单的依赖就是我昨天说的 ,场景就是把多个接口用例编排为场景
也就是接口用例是原子的, 可复用他们来构造业务场景
说起来抽象 试试 itest work 你就明白 了
get~~
观望
grt
腾讯有一篇关于微服务接口设计的文章，很深入，可供参考https://mp.weixin.qq.com/s/3UNL1EZfgfGkQcdbwuMj8Q
微服务性能方面的话可以看看这篇https://zhuanlan.zhihu.com/p/497225464
有更好的想法和文章希望各位不吝分享
按照 step case suite 来分层解耦即可
又是在评论中学习的一天～
学习了
登录这种接口一般是用来获取 token 的，所有的接口基本上都是基于它的，一般都是把登录做成公共方法去调用的
