Memory Statistics视图显示了应用程序创建的对象的数量。结果可以按照软件包来组织（以树视图的形式），或者显示为类或实例的一个列表。这些数据可以让您了解每种类型创建了多少个对象；应该对创建的对象（特别是高级对象，例如域对象）不正常的高数量持怀疑态度。
用于检测内存泄漏的另一个有用工具是Object References视图。为了获得这些数据，您需要激活引用收集。启动分析之后，点击monitoring项，然后在上下文菜单中选择Collect Object References（参见图6）。接下来，通过上下文菜单（Open with -> Object References）打开Object References视图。您将获得一个类的列表，它带有对每个类的引用的次数。这可以为可能的内存泄漏提供一些线索。
图 6: 激活引用收集
如图7所示，从Execution Statistics视图可以清楚地了解到应用程序执行到了哪里。"organization by"软件包可以帮助您找出执行时间最长的类和方法。点击一个方法将打开Method Invocation Details视图，它将显示有关方法被调用次数、调用地点以及它本身调用了哪些其他方法的更详细信息。尽管与一些可以向下发掘到源代码本身的商业工具相比，这个视图与源代码视图的集成度没有那么高，但是它还是可以给出一些重要线索，帮助您找出执行错误的方法。
图 7: Execution Statistics视图
Coverage Statistics视图（参见图8）提供的信息是关于，您刚刚运行的测试用例使用了（因此至少在某种程度上测试了）哪些方法。覆盖统计数据是一项优秀的功能，尽管它们提供的信息的详细程度还无法与像Cobertura、Clover和jcoverage这样的专业覆盖工具相提并论（它们可以提供行精度的覆盖数据，以及行和分支覆盖的统计数据）。尽管如此，它也有自身的优点，那就是可以提供实时的覆盖结果，而目前，只有商业的代码覆盖工具，例如Clover和jcoverage，才能提供行级别的覆盖报告和完整的IDE集成。
图 8: Coverage Statistics视图
文章来源于领测软件测试网 https://www.ltesting.net/
