分析到这里，让我们看看createParser() 方法的执行细节。
通过方法createParser() 打开Method Invocation Details 视图
下面我们通过Method Invocation Details 视图来看看createParser() 调用慢的原因。在Execution Statistics视图中双击createParser() 方法就可以打开Method Invocation Details 视图
显示了方法createParser()的执行信息，就像你看到的一样，该方法被readData(java.lang.String)调用了一次，同时它调用了5个不同的方法，在invoked methods 表中，你能看见newSAXParser() 和newInstance() 方法可能就是createParser()方法执行慢的原因，这两个方法跟createParser()被调用24次一样，也被执行了24次。
为诊断出的性能问题定义一个解决方案
通过分析以上这些数据，我们发现改进createParser()执行时间的一个途径就是改进SAXParserFactory的两个方法的执行，既然我们无法控制这些方法的实现，唯一的途径就是减少调用这些方法的次数。
解决方案是创建一个parser实例，并且复用其去解析所有的xml文件，取代原来每解析一个文件就创建一个parser实例的做法。让我们打开源代码并且修复它。
提示：在进行任何之类优化之前，要确保被代码支持。例如，当SAXParser不能同时被多线程使用时，实例能被复用;严格来将，实例在复用之前应该被重置(reset)，拥有一套全面的单元测试集来检验这些修改是个不错的主意。
在源代码中应用性能优化
可以在Method Invocation Details视图中右键-->Open Source来打开源代码。
显示了createParser()方法的源代码。注意该方法每次调用都创建一个新的SAX parser 。更新代码，只创建一个parser实例，复用于解析每个xml文件定义了一个全局的SAXParser 实例变量parser，createParser()方法初始化parser然后在每次被调用时返回该实例。
让我们再次执行一下Product catalog程序，验证修复的结果。 软件测试
验证性能优化
在Java透视图中选择Product类，右键--->Profile As -->Java Application,程序执行完后，打开Execution Statistics 视图，比较执行时间，正如你看到的，createParser()方法的执行时间已经仅有19%,而在优化执行却是将近 43%。注意，随着xml文件数量的增加，提升的值将更加明显，所以，随着product文件的增加而减少的程序执行时间将是指数级的。
总结：
本文论述了TPTP性能测试工具能被用于分析和解决性能问题，本文没有涉及TPTP工具更多的其他使用方面，
如果你想了解更多的关于TPTP工具的能力，有一套的教程和用户手册在这里。
文章来源于领测软件测试网 https://www.ltesting.net/
