軟件性能測試步驟 軟件測試
性能測試步驟(一)——熟悉應用
這是整個性能過程最關鍵的步驟之一，毋庸質疑。
我們必須了解：應用的架構
以我熟悉的應用類型為例。了解了應用架構，我們才能知道，我們需要模擬的是：一般的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.anti-gravitydesign.com/
