分析到這里，讓我們看看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工具的能力，有一套的教程和用戶手冊在這里。
文章來源于領測軟件測試網 http://www.k11sc111.com/
