性能測試“從小做起”
軟件是否在上線之前進行性能測試就能解決問題呢？不一定，如果性能測試進行得太晚，會帶來修改上的風險。很多軟件系統在設計的時候并沒有很好地考慮性能問題和優化方案，等到整個軟件系統開發出來后，測試人員忙著集成測試，開發人員也疲于應付發現的功能上的Bug，當所有功能上的問題都得到解決后，才想到要進行性能測試。性能測試結果表明系統存在嚴重的問題，如響應時間遲緩、內存占用過多、不能支持大量的數據請求，在大量用戶并發訪問的情況下會造成系統崩潰。如果此時再去修改程序已經非常困難了，因為要徹底地解決性能問題，需要重新調整系統的架構設計，大量的代碼需要重構，這時的程序員已經筋疲力盡，不想再進行代碼的調整了，因為調整帶來的是大量的編碼工作，同時可能引發大量的功能上的不穩定性和再次出現大量的Bug。
這給測試人員一個啟示，性能測試不應該只是一種后期的測試活動，更不應該是軟件系統上線前才進行的“演練”，而應該是貫穿軟件的生產全過程，如圖所示。
對于性能的考慮應該在架構設計時就開始，對于架構原型要進行充分的評審和驗證。由于架構設計是一個軟件系統的基礎平臺，如果基礎不好，也就是根基不牢，性能問題就會根深蒂固，后患無窮。
性能測試應該在單元測試階段就開始。從代碼的每一行效率，到一個方法的執行效率，再到一個邏輯實現的算法效率；從代碼的效率，到存儲過程的效率，都應該進行優化。單元階段的性能測試可以考慮從以下幾個方面進行：
代碼效率評估；
應用單元性能測試工具；
數據庫優化。
應該注意每一行代碼的效率，所謂“積少成多，水滴石穿”，一些看似細小的問題可以經過多次的執行累積成一個大的問題，也是一個量變到質變的過程。例如，在用C#編寫代碼的時候，有些程序員喜歡在一個循環體中使用string字符串變量，類似下面的代碼：
static void Loop1()
{
string digits = string.Empty;
for(int i=0;i<100;i++)
{
//累加字符串
digits+=i.ToString();
}
Console.WriteLine(digits);
}
這樣一段代碼其實是低效率的，因為string是不可變對象，字符串連接操作并不改變當前字符串，只是創建并返回新的字符串，因此速度慢，尤其是在多次循環中。應該采用StringBuilder對象來改善性能，例如下面的代碼就會快很多：
static void Loop2()
{
//新建一個StringBuilder類
Stringbuilder digits = new StringBuilder();
for(int i=0;i<100;i++)
{
//通過StringBuilder類來累加字符串
Digits.Append(i.ToString());
}
Console.WriteLine(digits.ToString());
}
類似的問題有很多，它們的特點是單個問題都很小，但是在一個龐大的系統中，經過多次的調用，問題會逐漸地被放大，直到爆發。這些問題都可以通過代碼走查來發現。
技巧：如果測試人員不熟悉代碼怎么辦呢？那么可以借助一些代碼標準檢查工具，例如FxCop、.TEST等，來幫助自動查找類似的問題。
文章來源于領測軟件測試網 http://www.k11sc111.com/
