性能測試步驟

　　性能測試步驟(一)——熟悉應用

　　這是整個性能過程最關鍵的步驟之一，毋庸質疑。

　　我們必須了解：應用的架構

　　以我熟悉的應用類型為例。了解了應用架構，我們才能知道，我們需要模擬的是：一般的html靜態文件請求、一般的servlet和jsp請求、AJAX請求、還是遠程調用請求等。

　　我們必須了解：應用的功能邏輯

　　性能測試步驟(二)——測試需求

　　我們得到的測試需求往往是這么描述的：這個系統能否支撐100萬的uv(每天登錄系統的人次)。

　　言下之意是：按照目前的硬件性能和數量，系統能否支撐100萬的uv。

　　然而，我們了解的是吞吐量、響應時間等指標

　　吞吐量：系統每秒能處理的請求數，這個指標從服務器的視角，表征系統容量

　　響應時間：從請求發出到第一個字節返回所需要的時間，這個指標從用戶的視角，表征系統響應速度。

　　那么，請問開發同事：能把測試需求轉化成我們熟悉的吞吐量和響應時間嗎?

　　......

　　答案常常是否定的

　　怎么辦：只能由我們根據經驗，把100萬uv轉化成一系列的指標。

　　響應時間：根據國外的一些資料，一般操作的響應時間不能高于3~5秒;重要操作，如結賬操作的響應時間不能高于15秒。

　　吞吐量：可以根據已經上線的類似產品進行估計?；蛘?，采用80/20原則進行估計。我們經常使用的是80/20原則。

　　雖然已經有了響應時間和吞吐量指標，但是測試需求還是不明確的。

　　我們的測試目的是什么?

　　是驗證當前硬件和軟件配置能否支撐100萬uv?是測試當前的硬件和軟件配置最多能支撐多少uv?是幫助開發尋找性能瓶頸?

　　答案往往是：都要!

　　根據我們的經驗，開發的需求往往是這樣的(當然開發一般不會說得那么詳細，^_^)：

　　首先，請你們驗證能否支撐100萬uv。如果不能支撐，請找一下性能瓶頸。主要性能瓶頸解決后，請估計能支撐多少uv，如果不到100w，請估計要加多少機器。如果能支撐100萬，請再加壓，看看達到300萬uv的時候，系統的性能。這么一細化，需求基本明確了。

　　性能測試步驟(三)——測試準備

　　測試準備包括測試客戶端機器準備、測試數據準備、測試腳本準備。

　　客戶端機器：要足夠，否則，如果瓶頸在客戶端，就無法評估服務端。要和服務器保持網絡通暢，否則，如果瓶頸在網絡，也無法評估服務端。包括：網絡帶寬要高于服務器吞吐量、網絡帶寬要穩定。

　　測試數據

　　如果被測功能涉及數據庫和高速緩存，通常需要預設很大的數據量才能凸顯性能瓶頸，這通常是挺困難的一個環節。

　　如果是已經上線的應用，數據可以從線上拷貝得到;如果還沒有上線，那需要構造類似于線上的數據量。

　　比如，要測試群聊性能，我們首先需要注冊大量用戶;然后把測試用戶都加入到聊天群中。

　　測試數據準備的腳本，有時候比測試腳本本身還要多。

　　對于實在沒有辦法構造大數據量的情況，如果要測試高速緩存，我們有時候會按數據量的比例減少高速緩存，以使測試結果盡量準確。

　　測試腳本

　　Grinder腳本用jython實現

　　測試腳本的實現往往會花費比較長的時間

　　因為涉及到應用實現的細節，需要和開發不斷交流才能完成。這也是需要了解應用架構的原因之一。

　　關于sleep time

　　基于真實模擬的考慮，sleep time還是盡量按照真實時間，并給一定的偏差。

　　不過對于測試客戶端來說，sleep time往往會引起很多客戶端測試線程的調度，浪費客戶端系統資源。

　　Sleep time越小，客戶端能模擬的吞吐量就越大，所以，實際測試中，我們往往會把sleep time設置為0 。

　　性能測試步驟(四)——測試執行

　　測試的執行中，需要監控測試客戶端和服務器性能，監控服務器端應用情況：

　　客戶端的系統資源(cpu、io、memory)情況

　　服務端的系統資源(cpu、io、memory)情況

　　服務器的jvm運行情況

　　服務端的應用情況，看是否有異常

　　響應時間、吞吐量等指標

　　系統資源監控，linux下可以采用的工具有：vmstat、top、meminfo等。

原文轉自：http://www.uml.org.cn/Test/20114111.asp