算上外包，有 500 多人的技术团队

建议从内部的需求出发吧，我们对测试平台加了前端埋点监控，可以知道哪些是用户（测试人员）用到的高频功能，哪些是低频功能，高频功能就向着更易用，更好用的目标持续迭代

比 xxx 强就一定去干 xxx，我不认可这个观点。测开是可以提供独特价值的，既有开发的视角，又可以有测试的思维，可以充当开发及测试团队中的桥梁。另外一点，其实根本不需要纠结到底是啥，团队需要什么，我就干什么。需要测试，我就是测试，需要开发，我就是开发，需要测开，我就是测开，都会，都能干，也都能干好，具体岗位啥的根本不需要纠结，只要能贡献价值，用正确的方式持续的做正确的事情，别的都无所谓。

“测开的开发水平也比不了开发” 不一定

你的这个诉求可以通过分析调用链变更来解决。如果调用链上的代码在本次发布中发生了变更，可以清空调用链上方法的覆盖记录

引用陈老师的一篇文章 https://mp.weixin.qq.com/s/iW75qatF2oN7BpzACUf58Q 希望能有启发

可以参考下我们在 MTSC2021 上做的分享，我们是期货行业，主要是私有协议，依赖 socket 编程

看看团队需要什么？对标一下类似的组织，还有哪些可以改进&提高的地方？先有目标，然后再行动吧~

某些情况下，你可能 new 不了对象，比如构造函数私有的情况

目前测试团队用的禅道，开源版可以免费使用，内置有定时备份功能，管理员开启就好

每个版本都延期，也是一种不延期

那说明你生成报告的时候输入的源代码范围不全。如果你们是 maven 多模块开发，想看到其他模块的有代码行的覆盖数据，那就也需要输入这部分的源代码才可以。jacoco 命令行中--sourcefile 参数可以写多个，分别指向各个模块下的 src/main/java

按照你的需要，你可以看 PlanQuery 这个类的覆盖报告呀，不用盯着 controller 的报告看

宝，你有考虑过，为啥一定要扫到方法上的注解呢？你截图中的注解，一堆都是 swagger 文档的，然后 PostMapping 和 ResponseBody 是 SpringBoot 框架的，然后没了，这样扫到或者没扫到，又有什么意义呢？另外要理解 jacoco 扫描的原理呀，也要理解注解的实现原理

对，但创建周边环境足够方便，运维也足够方便（通过配套平台支持），基本上一套周边环境（大概三四十个系统）可以在十分钟内准备完毕。

我们的做法是直接在 k8s 上拉一套独立的周边系统（这个操作依赖于各个系统的容器化），这套测试环境就是这个团队独占的

给大佬点赞

问题 5 引申出来一个遇到的坑，Java 后端使用 long 类型时，直接传递给前端，前端 js 处理会有精度丢失问题，反而需要把 long 转为 string 传给前端，才能保证精度不丢失

学到了，之前搞脚手架总是复制已有的代码再删

不打算解释说明什么，也没必要。我们团队内部觉得这并没有啥，而且一般很少出现延期，大家都很遵守约定，也很乐意去聚餐（纯吃纯玩，完全没有应酬啥的）。

对于前后端分离的系统来说，前端往往都是 React,Vue 这些框架渲染出来的，这要如何使用 data-test-id 来定位呢

忘了说，我们每天八点半上班，下午五点下班，周末双休 ，确实有时间准备

持续学习，持续输入，持续输出，至少我们团队内部是认可这种方式的

上面这些搞不完。。。水太深了

我们的分享坚持了很长时间，每周都有人分享，每个人三周轮一次，一般来说会选择极客时间的某一门自己感兴趣的课程，学习并在组内讲出来，不局限于形式，PPT，markdown，xmind 均可，关键在于讲出来，可以不是完整的知识体系，哪怕只是其中一个小的点，小的启发，都可以，平均每次分享的准备时间一般来说需要 1-5 个小时不等，实际分享时间在 15-60 分钟，取决于内容多少，这个模式我们团队已经运行了五年多了，除了节假日从未中断。（有惩罚措施，如果本周轮到你了但是没有分享，则可以按照 300 标准请大家吃个饭，多的部分 AA，正好也有理由聚餐了，这个请吃饭只能延后一周，并不能免除本次分享）。