LZ 妹子好像还是单身？

这些问题都是接口测试层面能发现的

呵呵…

我觉得可能是 gevent 的锅，但我对这玩意不太感冒，没继续研究下去
在我们这边，locust 已经承担不了压测任务了，我们现在改用 golang 去做

我的经验是：压比较快的接口（<=10ms），locust 完全不可信

其实 pyunit 足够好用，nose、pytest 我这边一般只作为测试执行器

第一题的答案不太同意，个人觉得.pth是最不好的方式

用一行代码能解决的问题，被你写成了这么多行....

requests.request(method, url, **kwargs).json()

我没理解错的话，这么写？

{k: list(filter(lambda t: t not in l, v)) for k, v in d.items()}

我以我的理解，尝试逐一回答你的问题：

1. 我认为的【接口测试】是通过接口调用来实现业务逻辑的测试，而不是接口连通性测试。但可惜的是，很多人是在做后面这些工作。
   所以你不能问是不是要把 1 到 10 到验证一遍，而是要看这些值在业务上是否有具体的语义。

2. 所谓的host 切换，我的理解是要让用例执行在多个环境下，我不清楚目前你们怎么做的。但是我们的接口用例实现层跟环境是解耦的，用例逻辑本身不用关注执行在什么环境中。

3. 其实跟第二点很像，用例层根本不用去关心 token 怎么获取、签名是如何生成，重点永远是业务逻辑，那么这些行为在哪里去实现呢？ 封装到框架的接口层

4. 特殊的测试数据我们在本地保存一份，没有特殊性的数据实时从数据库中获取，这是我们的思路。

5. 其实第一个问题的回答中提到了，关键在于你们的接口测试要解决什么：连通性？还是业务逻辑校验。如果是前者，我没什么可说的。如果是业务逻辑，那么关键字段的正确性必须是要校验的。

nginx 即可

location /benchmark {
    return 200 'pong!'
}

核心代码没多少，主要工作花在了整理支付源的各种返回值上

这个思路是可以的，我们目前就是这么做国内支付源的 mock 的， https://github.com/jacexh/grandet

如果是 python 的话，直接用 jupyter 即可

我觉得最大的问题不是 locust 产生的压力小，而是其 response time 明显偏高，特殊情况偏高数十倍
结果很难信任

我不知道你觉得 locust 性能强于 jmeter 这种结论是哪来的，你可以去搜下 locust issue，质疑其性能的有很多，如：
https://github.com/locustio/locust/issues/586

根据我很早之前的测试，locust 单节点 QPS 上限约在 600 QPS 左右，而且 response time 明显异常
也就是说在一台 4 核的 PC 机上，跑 4 个节点的测试，至多产生 2400 QPS
而 jmeter 却可以产生 22K QPS

当然 jmeter 基于 java 线程的并发也不算优秀，ab/wrk/golang 能达到 50K+QPS

locust 能复用是因为你们接口框架用的是 requests 吧，这个方案我们两年多前就用了。但 locust 性能很差，真心不推荐

加油吧，起步阶段总会遇到这样那样的问题
如果下次沙龙需要一些 topic，鄙司可以提供一些

居然需要 acm 竞赛成绩…

当你自身足够努力了，再去抱怨平台、环境

支持苏州本地技术沙龙

向毛主席保证，没有探头

晚上回去加 QQ
我目前基于 golang 实现了一套通用的性能测试工具， https://github.com/jacexh/ultron
理论支持任何协议，当然了，单实例性能肯定会弱于 wrk，不过好在改成分布式也很方便

这机器配置真实强大，wrt 表现也非常牛逼
但是 nginx 的配置我建议还可以继续优化： 不用读静态文件，直接 return 字符串