架构设计是否合理（一般适用于新项目），帮开发写单测（？有待讨论），代码扫描，参与 CodeReview，质量门禁与质量卡点，每次交付给测试进行系统测试之前，用自动化跑一遍作为冒烟（如果有自动化的话），能做的事挺多的

我们公司内部环境还算不错：
1.领导都是懂行的人，不会有外行指挥内行的情况，知道这个东西有价值，也愿意投入资源让我们尝试
2.之前有成功的案例，于是大家现在也都愿意去当这个种子团队，形成了良性的循环了，持续积累

对落地过程深有体会，概括来说：
内部有痛点，外部有方法，取其精华去其糟粕，进行 “本地化” 改造。
综合考虑人员能力水平，项目开展方式，选择种子团队，自动化（非自动化测试，而是将方案以平台或者脚本方式提供）以降低门槛，保姆式的手把手教学，练习并持续的改进方案，与用户（测试团队）共同获益，种子团队试点成功，进一步向其他团队推广，种子团队失败，分析问题，重头再来。整个过程会持续 1-2 年，对推动者来说是极大的考验，对团队来说是肉眼可见的成长，绝非一朝一夕之力，浅尝辄止之能。

具体正确性的定义是什么呢？如果是满足某种业务规则的话，你也可以写个脚本读库然后校验

数据库 + 文件系统。数据库保存元数据，文件系统保存具体的用例内容。采用这种结合的方式既方便平台管理，也方便实际使用。

两方面看待：
1.可能确实是和 “具体的测试” 工作无关，但是是质量保障的动作，往往测试人员是熟悉产品的，可能比开发人员更合适，之前听过某老师讲过，测试可能更适合做实施环节，因此编写手册和答疑也似乎合理
2.确实是一些无关工作，那就不发表简介了

docker exec 进去的时候的 root 是 no-login 的 shell ，你进入容器后再 su - root 一下试试，应该就有了，或者把容器内 ssh 服务启动，22 端口对外映射出来，直接通过 xshell 等工具 login 进去，就也是 login 的 shell 了

https://gitee.com/Dray/jacoco

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

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

好东西！

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