軟件性能測試步驟詳解

        軟件性能測試步驟詳解    軟件測試

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

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

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

　　以我熟悉的應用類型為例。了解了應用架構，我們才能知道，我們需要模擬的是：一般的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的時候，系統的性能。這么一細化，需求基本明確了。

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

原文轉自：http://www.kjueaiud.com