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

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

给大佬点赞

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

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

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

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

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

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

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

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

如果能来现场的话欢迎报名呀，这次暂无线上直播，沙龙结束后，争取把 PPT 放出来

报名链接 https://www.huodongxing.com/event/3702247290800
欢迎一起交流进步！

确实好强啊

sql 查询界面的截图中，后面的 注:xxxxx 里面的文本打错了

typo: 封号->分号

gcov lcov

请问老师，这个平台做到现在这个程度，花了多少人多少时间呢？

点赞

原来是 dray 大佬， 班门弄斧了

其实，以 client 模式运行时，调用方也就是 server 端可以自主决定什么时候让 client 来 dump，而不是非要等到程序退出。官方的 example 中是有例子的，也有 server 的例子，改造一下，然后写个定时线程，也能达到目的。
org.jacoco.examples/src/org/jacoco/examples/ExecutionDataServer.java
可以在你需要的地方 remoteControlWriter.visitDumpCommand(true, false);
或者自行扩展

By GPT-3.5:
测试一个加解密工具时，需要考虑以下场景：

输入边界条件：测试工具是否能够正确地处理所有输入边界情况，例如输入空数据、最大数据、最小数据等。

功能测试：测试工具的加解密功能是否正确，例如测试各种不同的加密和解密算法，以及密码长度和字节数等是否满足要求。

性能测试：对于大规模加解密的应用场景，进行性能测试，检测加解密过程的即时性、处理速度、缓存管理等是否健全。

安全测试：测试工具的安全性是否充分保障，例如是否有足够安全的密钥管理、密钥分配和安全验证等措施，确保加密过程不受到黑客攻击。

兼容性测试：测试工具在不同操作系统平台和应用环境下的兼容性，确保工具能够在各种操作系统和软件中正常使用。

鲁棒性测试：测试工具在异常情况下是否能够正常处理，例如网络故障、电源故障等，在异常情况下测试工具的是否能够正确处理异常情况。

用户体验测试：测试工具的用户界面是否友好，易于使用和操作，以及对其它的功能需求，像多语言支持、交互性等进行测试，提供最佳的用户体验。

总之，以上的测试场景可以帮助您对加解密工具进行综合测试，提高工具的可靠性、安全性和用户体验，保障其稳定运行。

这个从来都不能保证是正确的。
去数据库拿数据，可以视为业务的另一种异构的实现。如果正常业务的实现和异构业务的实现一致，只能说明风险较小，不代表完全正确（所以可以加上多人评审，可能能够发现更多问题）。如果不一致，则一定有一方出现了问题。

只用代码覆盖信息，不衡量代码覆盖率。
目前的实践结论是，"覆盖率高，质量不一定好，但覆盖率低，很大可能存在问题"，需要分析为什么没有覆盖，从而考虑补充测试设计或者就决定不测。

很棒的思路！非常有启发，感谢分享！