不容易，测试这条路其实不好走，越来越卷了。

感谢反馈。已完善 readme

可参考：https://blog.csdn.net/qq_24601279/article/details/122942046

该构想，是受到极客时间《软件测试 52 讲》里面基于 Docker 实现的 Selenium Grid 测试基础架构的启发。本质上是想通过运维的手段，实现流程的标准化、自动化，包括环境部署、执行项目。

我们可以看到，其实测试脚本的开发过程和业务代码开发过程是类似的。测试脚本算是入门的，不懂就不懂，其实没必要说让全部测试都懂，毕竟术业有专攻。现在市面上很多自动化测试平台，其实效益是相对低下的，除了要投入人力去研发和维护自动化测试平台（各种技术栈），还要不断开发脚本。我这个是直接用 jenkins 作为统一管理平台，会写脚本的（测试开发、自动化测试），那么直接维护脚本就行，无需花更多成本去建设一个平台；不会写脚本的（例如产品、功能测试人员），只需知道直接在 jenkins 上构建就行，构建完，就意味着项目的自动化执行完了，就完成了对项目的回归。

k8s 架构下，每次版本的迭代，只需更新服务，实际上就是更新代码。那么，测试也一样，我们只关心版本迭代下测试脚本的变动，每次版本的迭代，测试的脚本代码也迭代即可。对平台方面的建设无需关注过多，因为 Jenkins 就是我们的平台，里面的功能，相信已经比较完备了。Jenkins 在操作体验方面有所牺牲，但我们追求的只是系统的质量，检测系统质量是否达标是我们更为关注的。

亮点并不是很突出，其实就是以 Jenkins 作为统一管理平台，同时，在从机加进测试集群的时候，只需将其加入配置里面，执行一下脚本，就可以完成从机的环境部署和初始化，无需再登录新从机的终端手动执行才能得到自动化测试和压测所依赖的环境。也能够确保环境的一致性。很多功能，交由第三方去完成了，例如接口自动化用的是比较流行的 HttpRunner 框架，分布式性能压测用的是 Locust。

你说打开看到只是个 jenkins，你可以仔细看下构建的过程，会发现每个过程都遵循这样的顺序。jenkins，我也只是放了一个小的 demo 项目作为展示之用，我的设想是项目是否可以根据业务领域去开发自动化脚本，像 k8s 架构下划分多个服务一样。这样子，每个项目也显得足够小，缓解接口自动化没有分布式执行而执行周期过长的问题。jenkins Master-slave 解决的是资源分配的问题。

至于如何使用，在 readme 里面已经有说明的，快速开始三步走。

说得有点乱，大概意思就这样。

谢谢指点，已通过修改配置文件搞定了。

在创建容器的时候，docker 内 Jenkins 的端口绑定了主机的，但是 locust 没有。你的意思是，我需要重新创建容器，然后绑定新的端口？