我开始也以为是这样，但是实际发现不是，每次都会把新的覆盖率追加写到旧的覆盖率文件上.

如果能实时返回进度就最好不过，或是否有阶段可以拆分，不同阶段对应不同进度

用户登录认证这些能 mock 就 mock 掉，关注点还是秒杀场景，线程数/并发数要一次性足够大

脑子里会想起年轻时的自己

同样遇到这个问题，最近也打算研究一下

非常同意临时创建测试案例的策略，这样节省太多维护成本了

首先 VisitorPrinter extends VoidVisitorAdapter
如果你是想定位方法的起始、结尾行位置的话，重写 visit 方法，通过 range 获取 begin、end 或直接获取，都可以确定所在行范围

酷狗呗，看技术栈像直播的？

也有想过在公司落地，技术层面还好说，但对这项工程的收益与风险还是存疑

风险

1. 既然最终要拉线上的数据，多多少少会影响到线上服务的性能，甚至功能，这块怎么能将风险降到最低
2. 敏感数据如何解决，涉及到用户敏感信息、金钱相关的，很多大公司这块审计的比较严

收益
主要体现在目前回放过程中的上游服务，数据，缓存层层 mock，覆盖面肯定比较有限，那是不是说明通过这种方式回放必然存在局限性，还是有其他解决途径？

1. 长
2. 可以通过手动设置 header，将 connection 置为 close 达到短链接的效果

主要还是尝试用在精准测试不是覆盖率，通过调用链关系 + 代码 diff 去反推本次提测需要回归的测试点，具体的测试用例和对应测试点预期还是通过手工维护

建议选择一两项深入

感谢提醒，的确忘记了 AB 这个选项