赞～～
grpc 感觉越来越火～

优秀的文章～
这几年身边的项目都由朝着这个方向改造的趋势，不管是对 APP 生态对影响还是基于后台服务化对接 mqtt
核心思想都是基于长连接的状态下实现业务多样化的动态支持扩展，带来效率的提升

前段时间有点忙，今天才看到回复
1、可以分享一下你的 case 转化为性能脚本吗，提供一下核心思路和做法
-- 后续可以撸个文章，个人觉的这个问题最本质的是快速实现压测接口，然后接口组合压测场景，想要从 1 人/天 10 接口提升到 100 个，确实需要改造，还有第二点，是接口模版的改动，可以最小代价落地

2、你目前的做法在能 web 端能统计到相关的请求数据吗
-- locust 虽然提供了图表，但是只是一个辅助手段，压测数据都是要以服务环境数据指标做第一优先；而且分布式 slave 多，数据会有几秒的滞后，但是不影响整体的准确性，现在监控体系都非常成熟了，从普罗米修斯到 elk+grf 日志分析 各个组件的监控，各种云上面都有自建都指标，如果是自建的，本身就有监控数据视图，locust 本身最重要的功能还是提供一个压测能力，相比 jmt 分布式部署会很便捷，而且对扩展协议压测支持很便捷，最是最大的优点

第 1 个问题，只有相对解最优解；而且在实际压测过程中，需要控制分布式参数唯一性的问题，自动化 case 过来的数据，需要做一轮抽象，然后组合初始化压测数据满足动态大并发要求。

棒～

locust 本身对协议扩展支持是非常灵活和便捷的
看下来，只是为了怎么更优雅的整合 api 接口压测场景封装和调用。最好是复用接口平台里面的 case。
核心思路，不在于 request
用 locust 也有一段时间，从之前一天 5～6 个接口支持，现在经过改装一天可以撸个 50+ 接口也很快，也可以很灵活的对接从自动化平台过来的场景 case

接口的设计 对应是业务实现的抽象
接口的测试的核心；是检查业务变更点是否全面生效以及业务相关影响点检查
接口的返回，特别是 msg 描述 不是接口测试的核心内容
想法很好～用在搜索算法匹配上面测试很好

优秀～～
用真实的业务参数 + 决策算法组合生成了检查数据权限场景
不知道用户角色多 token 的匹配怎么落地的

支持 http2.0 或则 响应式返回接口不～