"但对于维护项目来说，测试覆盖点都是增量或修改需求点，那未覆盖的处会很多，那分析测试遗漏就不好搞了"

1. 可以考虑采用增量的方案，只关注本次的变更是否都覆盖到了，虽然 “覆盖率高” 和 “质量好” 画不了等号，但增量（或者说变动代码）的覆盖率低可能说明确实存在遗漏的场景没有执行到，可以进行分析并决定要不要补充。
2. 给测试人员及相关人员提供信心，有时候信心也是一个关键的要素，覆盖率高比覆盖率低总是要多一些信心，多一点信心总是好的。

如果是 Java 的话，一般来说都是 Spring 全家桶需要掌握，最好能自己有开发能力，知道这些组件和框架都怎么用的，并且自己也会用，熟悉了这些机制之后，能够更好的帮你分析代码。

前端访问接口不通，访问的接口应该是宿主机的端口。你用了端口映射，应用内本来是 B，容器启动时映射到宿主机的 A 端口，则前端打包的时候也应该是 A 端口而不是 B 端口，可以考虑把 AB 设置成一样，或者前端重新打包。

你是需要测试鉴权？还是测需要鉴权的接口？
测试鉴权本身，需要你了解对应鉴权字段的生成算法；测业务接口的话，按照鉴权规则在请求中传递即可

参考贝尔宾团队角色中，每个角色的可容忍缺点

会有，可能有异构的业务处理逻辑等情况。或者处在灰度发布，蓝绿发布，金丝雀发布等过程中的情况下，部分服务器上的包较新，其余一些较老。

嗯，目前看来应该是企业版才有的功能

metersphere 目前支持接口和性能测试，UI 自动化正在内测，官方主打一站式持续测试平台，可以关注下

docker in docker

备份数据库，禅道使用的是 MySQL 数据库，相关连接信息在禅道的配置文件中有

“如果某位用户既是发帖数 Top 3 之一也是技术贴获赞 Top 3 之一，那么该用户将获得 1000 积分”，不应该是 1600 积分嘛？

ms 本来就可以直接添加数据库类型的接口，这里用 beanshell 感觉有点画蛇添足了

读到一半血压就上来了

同意四楼的观点。应当解决业务测试流程中真正的痛点，测试执行可能只是其中一部分，环境准备，数据构造，报告分析等等环节就非常通顺么？有没有可能进一步提效呢？也可以多方面考虑下

个人认为，前两个可以结合在一起来。
1.以实际需求驱动、以实际需求驱动、以实际需求驱动的测试平台，直接学习 SpringBoot 相关技术栈，同时学习 Vue、Vuex 及一个主流的 UI 组件库即可。写完之后可以用 docker 方式部署。如果是自动化测试平台，则可以利用 k8s 的能力动态创建测试和被测资源。k8s 推荐赵班长的课程，跟着学还是不错的。
2.性能测试方面，推荐极客时间 高楼老师 的课程，https://time.geekbang.org/column/intro/100042501 https://time.geekbang.org/column/intro/100074001

好东西！

这种情况下如果没有功劳，那一定是组织和文化的问题 。

要在具有上下文的运行中才有效，在接口自动化的场景里面这样用是对的。

生成前端资源的时候文件名后方加个随机串

MeterSphere 目前支持接口自动化和性能测试，官方后续有计划做 UI 自动化 可以了解下

看用途吧，如果是用作冒烟和准入，写场景用例会多些

vars.putObject 试试呢

转成字符串类型，再 put

期待您的后续内容

我司测试部门同事针对此问题有过一些思考，发在了我们的公众号上，欢迎大家共同探讨哈，链接如下
为什么测试人员要懂代码？https://mp.weixin.qq.com/s/uFJcgh7KlZnzBMb9LoxoNw
谈看代码 1 https://mp.weixin.qq.com/s/0c29QAQ_jm3ERUxUDKgytQ
谈看代码 2 https://mp.weixin.qq.com/s/w0ju6SSQiWy0hKDqRnmsSA
谈看代码 3 https://mp.weixin.qq.com/s/bBUtf1lu599h7CV-8RSRUg