一个产品对应的开发有多个层面的，前端、后端、类 openstack 后端开发，去年版本频率正常的时候是有项目周会一起沟通的，也有些许成效。现在人员少了，版本频率相比增加了，缺少了之前的沟通，只是工位就近的开发去聊一下。作为测试确实也有自己身上的过错，工作做的狭隘了，没有做好产品 QA 的工作，在此也反思一下。

测试人员是提供自测用例的，加上时间排期紧，测试监控开发自测这方面做的不到位

简历之外的内容也可以关注，比如 github、论坛贡献之类的

上述测试开发技能图中，一个人会的越多当然越好，实际往往是工作中能接触到的、用到的会越来越精通，其他的只能自己在业余时间去摸索自己感兴趣的。每个分支都很深入的话，很难，也没有太大的精力，就算是学了，长时间不用也会慢慢生疏。测试是一个团队，不是单打独斗，在这个团队中需要的是某方面精通，能扛起单方面大旗的人，而不是希望整个团队中都是多面手，就像是海贼王里的草帽路飞一伙儿，各有各的长处。

这个问题向负责的项目组反馈了好几天了，还是没有变。按我的理解，这部分应该灵活可配置的，数据库里就可以将模板改掉，还是存在这个问题，要么开发设计有问题，要么制度有问题，要么对产品来说这不是问题或无所谓（最低优先级处理） 。
哎，上面的三个要么，每个都是潜在的可能会暴雷的问题。

建议收下了，当下先想办法推起来，大家都用起来了才能知道哪还需要优化，这时一点一点的细化才合大家的想法。

功能刚做出来没多久，第一部分 CICD 模块做完后也推过，没什么效果，主要是测试还是以业务测试为主，自动化率不高，我也是在业务不忙的时候去搞一下平台，只能一步一步来。整体流程也是在摸索中前进。不过平台上验收测试这个模块倒是使用率 100% 了，毕竟是平台最开始的功能。

完全用 Jenkins 也可行，不过上文也说了，公司目前没有对 Jenkins 特别精通的人，也没有人专门负责，对于 Jenkins 的操作权限也完全在开发那边，Jenkins 对于运维，公司还没有走到一步 。Jenkinsfile 也是开发的那边管控的，放在项目代码目录里，基本上配置好后就极少去动了，为了项目并行，可能一个项目组测试环境就有多套，总不能让开发经常去改 Jenkinsfile。另外一个初衷就是统一记录，后续方便测试分析。

技术要求越高的越是紧缺资源，对于门槛比较低的业务测试，永远不会紧缺，以后更是会有被淘汰的趋势

不是，看你能力，要是只会黑盒，开发说什么就认为是什么，那肯定开发认为你技术很 low，如果在开发设计的时候你能发现开发设计的缺陷，或指出开发设计模式的问题，那开发绝对不会对你产生不屑

怎么说呢，萝卜青菜各有所爱，我自己是在项目中使用过这个工具的，公司其他测试组用 jmeter 的居多，毕竟 jmeter 是一个工业级的软件，locust 要想达到 jmeter 的性能就得分布式，locust 工具达到瓶颈之后就添加 slave 就行了，jmeter 也一样存在性能的瓶颈。另外我所在的项目组开发也在用这个工具了，有的接口较低的并发就会报错，我直接把这个工具甩给开发，调试到不报错了再找我测。

这篇主要写 easy-locust 这个工具的，顺带和 jmeter 比对了一下，关于 locust 和其他工具的详细比对，testhome 上是有的，写的也挺不错的

重新传了一遍，这次应该能看到了

其实我也简单做过 locust 和 jmeter 的对比，楼主 4 核的机器，如果用 locust，不是 master-slave 模式的话，只会使用 1 个核，所以 CPU 使用率 25%，要充分利用机器资源也很简单，起 1 个 master，3 个 slave，slave 对应的 master host 是 127.0.0.1 就行，这样的话性能数据是不会太差的，另外 0.15 以后的版本都支持 FasterHttpLocust 模式，使用的是基于 gevent 的 httpclient，性能上整体来说不会太差