在這一階段測試你要不斷的跟據系數的測試目標進行變化，一開始由于系統過于龐大，所以我們要分成若干個子系統，各個子系統的性能目標必需明確，主要是并發指標定一個閥值，同時設定一些與系統相關的測試參數，應用服務器，數據庫服務器都要有，對達不到閥值的與一些通用參數有問題的子系統進行深入分析。比如它的并發達不到你的要求，證明子系統性能有問題，或是數據庫用戶連接過高，程序沒有釋放用戶連接等等。
這個我們要對子系統進行詳細測試，由于B/S 結構下,圖片的請求對性能的影響較大，所以我們對子系統測試時要分兩個部分進行，一、非程序部分，即圖片等等;二、應用程序本身。通過事務或函數的分離，可以把這兩塊實現單獨的測試，具體做法參考各個工具的手冊，我這里就不做說明。
對子系統的測試參數的設置要求則更高，它有助你后面精確的定位問題，比如對異常，死鎖，網絡流量等等前面沒有注意到的情況的增加，同時你要注意增加測試參數的收集對系統的性能影響比較大，所以一般不要超過10個，剛剛介紹的整體的性能測試指標也不要增加很多，這樣影響會小一點。最后在這一階段要說明的是數據庫的數據量會很大程度的影響性能，所以要根據前面的性能需求說明書向數據庫中模擬相應的數據量，來進行測試，這樣才有更高的可信度。
上面所說的是對問題的發現，下面就是分析問題原因，這一步的要求比較高，一般由測試人員與程序員配合完成，當然如果你有相當的開發經驗，再做這方面的測試，就更為難得。下面我們說說如何精確定位問題，出現問題的可能性可能有很多種，大致分以下幾種：
一、性能達不到目標；
二、性能達到目標，但有一些其它的問題，比如異常，死鎖，緩存命中過低，網絡流量較大；
三、服務器穩定性的問題，比如內存泄漏……。
要發現這些問題起馬的要求要有一款使用的比較稱心的性能分析與優化工具，比如微軟的.NET下就有自己開發的工具，對Borland的Java開發工具中也有類似的工具，但我個人認為更好的工具是Rose下的Purify與Quantify,主要是他對.net 與java ,C++都有支持，而且分析效果特別專業，我們先了解一下Rational Purify, Rational Purify 能自動找出Visual C/C++ 和Java 代碼中與內存有關的錯誤，確保整個應用程序的質量和可靠性。在查找典型的Visual C/C++ 程序中的傳統內存訪問錯誤，以及Java，C# 代碼中與垃圾內存收集相關的錯誤方面；Rational Quantity 則是一款針對函數級的性能分析利器，使用它你可以從圖形化的界面中得到函數調用的時間，百分比與次數，以及子函數所占時間，使你可以更快的定位性能瓶頸。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
