开发

进到对应的服务端用工具看下，再生成下火焰图分析下

混沌工程
大数据测试
云原生
AI 测试

没懂 你在 fixture 中加个 autouse=True，就可以在每个 test_case 里直接调 get_device_object 了啊，每个 class 只执行了一次 fixture，这样返回的实例其实都是同一个的

线程数当然不能等同于并发数了，难不成你想一条线程只输出一个 TPS？？ 那假如我要 30000 并发，你要开 30000 线程？ 那你 CPU 几 C 的？这会有多频繁的上下文切换？有多少资源耗费在其中？
实际并发数=发压端线程数每个线程输出的 TPS
TPS=（1000ms/平均响应事件）发压端线程数
你 TPS 不变的情况下，加线程数只能拉低响应时间，没有其他意义

建议 schema 特殊的字段校验直接写在 shchema 内了

像 nginx/open resty 这种没必要问，没有几个测试需要从零去开始测你们公司的基础建设， 中间件倒是有必要问，但是问的还不够，或者说太八股，比如缓存穿透、击穿、雪崩，可能你的整个职业生涯都遇不到几次，但是对于缓存本身的测试却没问到，比如分析 key 的合理性，Redis 与 DB 数据短暂不一致对业务的影响, 缓存的逐出逻辑，尤其是缓存在不同更新策略可能产生的问题，以及具体的做法，比延时双删和消费 binglog 更新就应该采取不同的测试方法，以及对于大 key 热 key 的关注，缓存的性能指标等等.

根据个人经验，很多代码设计导致的消息积压都是因为 ack，比如由于某些边界情况未手动 ack ，或者消费重试没手动 ack 导致消息堵塞，又或者重复消费过多或者没有超时丢弃而导致的无效执行。

测开还是要懂得测试相关的知识和思维，否则就不是测开，只是一个普通开发，而且技术能力还不一定有人家专职开发强。测开不仅要有测试相关能力，最好也要有产品思维，了解测试痛点，了解产品核心，以此为基础的测试开发。

showcase , 以及集成接口自动化 + 静态分析到流水线作为准入标准