我有一个在生产中运行的基于java web的应用程序.我需要一些方法来通过最终用户的操作来查看实际使用的代码的所有部分.
只是为了进一步澄清我的要求.
我不想放置基于日志的解决方案.任何需要我放置一些日志并分析日志的解决方案都不是我所期待的.
我需要一些解决方案,可以在类似测试覆盖率报告器的类似行上工作 像cobertura或emma报告一样,在运行单元测试之后,它会向我显示我的代码的所有部分都是由单元测试激发的.我需要能够在生产中监听JVM的东西,并告诉我我的代码的哪些部分是由最终用户的操作在生产中激发的.
我为什么要这样做？我有一个我继承的代码.这是一个很大的部分 - 大约25,000个课程.我需要做的一件事就是切掉那些没有被过多使用的应用程序部分.如果我可以向管理层证明应用程序的某些部分几乎没有被使用,我可以从这个产品中删除这些部分并有效地使这个产品更易于管理(如需要运行每个的手动回归测试套件)一个星期左右,需要几天,可以缩短).
希望有一些现成的解决方案.
正如 Joachim Sauer 在您的问题下面的评论中所说：最直接的方法是仅使用用于单元测试的代码覆盖工具，并用它来检测生产代码。
有一个主要问题：开销。代码覆盖率分析确实会减慢速度，虽然知情的用户群会容忍一些暂时的性能下降，但整个事情需要保持可用。
根据我的经验，JaCoCo 相对较轻，不会产生太多开销，而 Cobertura 会造成巨大的减速。另一方面，JaCoCo 仅标记“命中或未命中”，而 Cobertura 则为您提供每行命中计数。这意味着 JaCoCo 只会让你找到死点，而 Cobertura 会让你找到很少命中的点。
无论您使用这两种工具中的哪一种（可能一个接一个），您最终都可能会得到巨大的类白名单和类黑名单，以将覆盖计数限制在有意义的地方，从而降低性能开销。例如，如果整个事物有一个前端控制器 Servlet，则将其包含在分析中将最大化性能开销，同时不会提供任何有价值的信息。这可能会导致大量工作和大量应用程序部署。
实际上，识别特定子系统的瓶颈/网关并在每个子系统上设置一个计数器（例如perf4j甚至完整的 Nagios）可能会更快、更少的工作。查询是另一个值得反击的好地方。如果您怀疑应用程序的某些部分很少使用，请在那里放置一些计数器，看看会发生什么。