如何检查非常大的java项目中的动态类使用情况
我有一个相当大的 Java 项目，代码覆盖率非常低，并且想要增加测试用例的数量。有什么方法可以衡量哪些类在运行时使用最多？这样我们就可以衡量我们需要首先涵盖哪些类别。该项目是一个运行在 tomcat 和 Tomcat 上的 Web 应用程序。 websphere 如果它很重要的话。
I have a pretty big Java project with very low code coverage, and want to increase the number of test cases. Is there any way to measure which classes are used the most in runtime? This way we can measure which classes we need to cover first. The project is a web app running over tomcat & websphere if it is important.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
是的。
有些工具可以替代标准类加载器，以便在加载类时检测类的覆盖范围。
我认为 Clover 和 Emma 是我用过的最好的。艾玛是自由的，但自 2005 年以来似乎不太活跃。
Yes.
There are tools that replace the standard Classloader so that they instrument classes for coverage as those classes are loaded.
I think that Clover and Emma were the best ones that I've used. Emma is free, but doesn't appear to be very active since 2005.
另一种方法是“分析”应用程序并在打开分析器的情况下逐步完成各种工作流程。
然后，您可以对加载的类、方法调用（带有计数）进行排序，以了解哪些类最常用。
An alternative approach will be to "profile" the application and walk through the various workflows with profiler on.
You can then sort on loaded classes, method invocations (with count) to get an idea of what classes are used the most.
代码覆盖率背后的想法不是覆盖尽可能多的代码，而是覆盖对您来说最昂贵的代码。
因此，一个好的开始是查看您的错误数据库：代码中是否有某个位置经常出现？或者您是否知道一段代码，您首先想到的是“我不想碰那个......永远”
向您的同事询问弱点。每个项目都有它们，每个人都知道它们；只是没有人敢去那里冒险。
这些是测试用例开始的绝佳位置，因为这些是缺少覆盖范围的地方。伤害。
理由：测试代码是否有效是没有意义的。经常执行的代码通常会起作用，因为错误很快被发现，并且修复它们的压力很大。
The idea behind code coverage is not to cover as much code as possible but to cover the code that is most expensive for you.
So a good start is to look at your bug database: Is there a place in the code that shows up often? Or do you know a piece of code where you're first thought is "I don't want to touch that ... ever"
Ask your colleagues about weak spots. Every project has them and everyone knows about them; it's just that nobody dares to venture there.
These are excellent places to start with test cases because those are the places where the missing coverage hurts.
Rationale: There is no point to test code that works. Code that is executed often usually works because bugs were found quickly and there was a lot of pressure to fix them.
根据服务器设置，您可以附加外部分析工具（有很多）进行处理。您还可以通过 JDK 提供的 jConsole 工具获得一些初步见解。但我最喜欢的是仔细研究来源或网络应用程序统计数据以确定可能最常用的类。最终，您必须测试所有这些。
Depending on server setting you can atatch external profiling tool (there is a lot) to process. You cal also get some first insights via jConsole tool provided with JDK. But my favorite is carefull look into sources or webapp statistics to determine possible most used classes. Ultimately, you will have to test all of them.
询问熟悉系统的开发人员，哪些部分最有问题（例如，产生最多错误、必须经常更改、最难添加功能等）。答案将比任何数字测量更有用。
Ask a developer who's familiar with the system which parts are the most problematic (as in, produce the most bugs, have to be changed often, are the hardest to add features to, etc). The answer will be far more useful than any numerical measurement.
你研究过AOP吗？基本上，您编写一些“方面”，AOP 运行时将它们与您指定的类编织在一起。完全非侵入性。 AOP 的一个应用是覆盖测试。如果你这样下去，你可以查看 Spring AOP。
Have you looked into AOP? Basically you write some 'aspects' and the AOP runtime weaves them with classes you specified. Totally non-intrusive. One application of AOP is coverage test. If you go down this way, you can check out Spring AOP.