• mitmproxy grpc 代理抓包 at October 09, 2020

    赞~~
    grpc感觉越来越火~

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

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

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

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

  • 深入浅出 Locust 实现 at September 29, 2020

    棒~

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

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

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

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

打酱油