不知道你们后端是怎么响应的，不过我司是正常响应 http 状态码 200，responseBody 里面还有个 errorCode，比如这种情况为 2020，那么你做性能的时候，肯定需要判断当前请求是否成功，可以在判断 http 状态码为 200 的前提下再判断 errorCode。我这边有好几种这样的场景，我是定义一个比如 code_list，把这种业务限制的 code 丢进去，校验时判断如果当前的 errorCode 存在 code_list 中时，不向统计中心上报此条数据（可以根据这个业务场景的代码覆盖链条深不深来决定是否上报这条数据，比如如果在最外面的 api 网关层没做过多的业务判断就直接返回，这种请求可以直接丢弃，如果是走到了业务链最后端之后才返回，那么此条数据可以视为有效压力，就可以保留上报）

test

我们后端的接口 responseBody 中也是有个 code 字段，返回 code_200 或 code_500 这些，但是接口有依赖数据这种情况，因为单接口的访问限制了并发，所以并发时上层接口没成功返回数据，下层接口也就获取不到数据，这样还可以视为有效压力吗？就比如说创建单据的接口，并发时接口失败了没有实际的创建单据，也就没有数据的插入，但是接口响应 http 状态码是 200 的，而且这种情况我观察到平均响应时间貌似要比正常的短

这种有必要做压测么？

对 token 服务做一个 mock，然后就可以进行压测了

限制 2s 内不能重复访问，这个应该是针对单个用户而言嘛
所以应该是要提前登录一批测试账号获取到 token，然后再来压测吧？

那就没必要压了。
或者像楼下说的这样，这种情况主要是针对单用户的。比如我们也是限制单用户三秒内不能重复下单。
这种情况只能用海量用户去压，而不能单用户重复去压

让开发给你加一个白名单去掉限制

那这样的情况，有海量用户操作时怎么确定系统不崩呢

这种情况需要开发改啊？我们小团队性能这块刚开始探索

就是只能用多个账号去跑压测，但是这样怎么确定压测的结果是否能到达多少量级的用户在访问

既然知道了有限制，在代码做一个开关，然后关了不就行了么？做任何测试一定要考虑可测性问题

看用户需求啊，比如 200 并发就先注册 200 个用户，然后 200 用户分别取 token。用户名和 token 作为参数化，然后设置集合点，进行并发测试。当然如果开发配合的话做个开关最方便。

200 个用户来做 200 并发？这样做吗?模拟的是 200 个用户同时登录操作？这实际就是 200 个用户同时了，不是压的吧。。？？

因为你接口的限制啊。200 用户登录后在你需要压的那个接口加个集合点就行了，在同一秒 200 个该接口的请求一起发送