數據庫的分析原則是先索引，后存儲過程，最后表結構視圖的優化，索引的優化是最簡單也是通常最有效的方法，如果合理的使用會帶來意想不到不到的效果。在這里我要給大家簡單的介紹一下我的最愛，SQLProfile,SQL查詢分析器，Precise,SQLProfile是一個SQL語句跟蹤器，可以跟蹤程序流程使用的SQL語句與存儲過程，結合查詢分析器對SQL的分析，可以對索引的優化做出很好的判斷，但索引也不是萬能的，在增刪改較多的表，索引過多會引起這些操作的性能下降，所以判斷還是需要一定的經驗。
同時針對用戶使用頻度最高的SQL進行優化也是最行之有效的，這時我則需要Precise，它可以觀測某一個較長時間內的SQL語句的執行情況。數據庫優化的潛能挖光后，如果還是達不到性能要求或是還有問題，則要從程序來進行優化，這是程序員做的事，測試人員要做的，就是告訴他們，哪個函數執行過多引起了性能下降，比如異常過多，某個循環過多，或是DCOM調用過多等等，但說服程序員也是一件不容易的事，你要在這一階段做的出色一定要有幾年的編程經驗，并且要讓程序員感到聽你的性能會有提升，這是一件很不容易的事情。
內存的分析，一般是一個長期分析的過程，要做好不容易，首先要有長期奮戰的準備，其次內存泄漏的分析最好是放在單元測試之中同步進行，而不是要等到最后再去發現問題，當然出了問題也只好面對，一般這類問題都是在服務器運行了很久才暴露出來，一旦發現問題后，則需要定位問題，分析的原則采用子系統相互獨立運行，找到最小問題的系統集,或是借助內存分析工具觀察內存對象情況，初步定位問題，再用Purify進行運行時分析，通常C++ 內存問題比較多，Java與.NET比較少，一般由GC不合理引起。C++的內存錯誤就比較多了，主要常見的有:
1、 Array Bounds Read (ABR) ：數組越界讀
2、 Array Bounds Write (ABW)：數組越界寫
3、 Beyond stack Read (BSR)：堆棧越界讀
4、 Free Memory Read(FMR)：空閑內存讀
5、 Invalid pointer Read(IPR)：非法指針閱讀
6、 Null Pointer Read(NPR)：空指針閱讀
7、 Uninitialized Memory Read(UMR)：未初始化內存讀寫
8、 Memory Leak：內存泄漏
注：如果需要更多的信息，可以參見Purify的幫助信息。
順便提一句，為什么我要說單元測試時做這個比較好，由于單元測試針對的是單一功能，這時結合單元測試案例做內存分析會更快的定位問題，同時由于問題較早的發現，則后期的風險則會減少，當然如果結合代碼覆蓋工具PureCoverage 來做就更完美了。
注：本篇只是對B/S應用的測試過程作一個整體的描述，對某一個階段使用的工具只是作大概的介紹,你也可使用你比較熟悉的工具達到相同的目標。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
