軟件測試中性能測試過程概述

MILY: 宋體; mso-ascii-theme-font: minor-fareast; mso-fareast-font-family: 宋體; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-fareast">軟件測試中性能測試過程概述

每個系統都肯定會對性能有要求，這些要求大致被分為3類：

1.   可接受的響應時間

2.   吞吐量和并發用戶

3.   未來對性能增長要求

首先，我們先看一下性能測試的周期是怎樣的：

一階段、規劃

規劃這部分最核心的，我覺得是對用戶行為的分析和剖析。因為這是為第二個環節建立可依據的標準。對用戶行為的分析和剖析，大致分為以下3類。

1.1、吞吐量和并發用戶數設計目標

    獲取這些數據的途徑可以是：網站服務器的日志文件、系統監視數據、數據庫活動監視數據、市場調研等等。調研出來的數據，可以按照功能點來進行劃分，以便清楚的知道各個功能點的使用比率、使用次數/小時，由此來確定并發數和吞吐量的分布。

2.2、性能增長分析

    這部分的數據可以是通過市場調研來預測的，也可以是通過之前的經驗來下的定論，也可以通過系統運行一段時間以來，用戶的增長速度來確定。通過對增長趨勢的分析，同時考慮到特殊情況（如：特定節日，特定事件）對系統的沖擊，可以適當增加用戶的增長趨勢。至于增長趨勢持續的時間，可以按照實際情況而定，由此來定出系統最終的吞吐量和并發用戶數。

2.3、用戶活動剖析

    分析用戶活動，我常用的是以下的幾種方法：

1)   通過在程序中寫代碼，把登錄用戶的相關信息（登錄名、IP地址、訪問頁面、功能操作、停留時間。。。等等）記錄在數據庫中

2)   通過IIS日志來記錄用戶活動記錄，然后再對IIS日志進行分析。這個過程當然少不了必備的工具，當前市面上的工具很多。諸如AWStats、Analog、Summary、Webalizer、WebTrends等。這些工具雖然都是現成的，但是有的配置復雜，有的功能不夠強大和靈活。所以更多的是把IIS日志導入到SQL SERVER中，自行寫查詢語句進行分析，這樣靈活簡單。但是如果日志文件過大，或者數量眾多的時候，這個方法稍微有點麻煩，所以我推薦使用另外一個工具Log Parser。對于這個工具的使用說明，我會在后面進行介紹。

二階段、創建腳本、運行腳本

這個階段，根據第一階段的分析結果，對需要進行性能測試的場景錄制腳本，再根據環境分析結果對腳本進行微調（例如：加入虛擬IP、創建多用戶登錄等，各類情況根據實際決定，這里不多說）。腳本調試好，在運行之前，打開各性能指標的計數器，SQL Server開啟跟蹤，然后運行腳本，并實時監控，以及手工N+1測試。

關于計數器，我常用的如下，不含特殊情況下需要用到的一些指標：

三階段、分析優化

    運行完腳本，關閉跟蹤。接下來就是分析日志，分析跟蹤結果了。這部分很復雜，涉及很多方面的知識。以B/S結構為例，整個網絡的體系架構大致如下：

參照上圖，我大致把整個過程的時間簡單的分為以下的幾部分：

客戶端與服務器間的網絡傳輸時間：T1+T7

服務器執行時間：T2+T4+T6

服務器間網絡傳輸時間：T3+T5

客戶端運行呈現時間：T8

當然并不是每次訪問都是由這些時間相加，例如WEB和DB在同一臺服務器，或者此次訪問根本就沒有對數據庫進行訪問。

對每個部分的時間都需要用不同的方法進行確認，初步分析出最耗時的環節進行優化。優化所需的技能和知識就多了，例如：你發現在內存不斷減少，懷疑有內存泄漏，那么怎么判斷是什么導致內存泄漏？某次訪問的時候耗時很久，那么到底是哪部分耗時最久？當前系統所采用的技術是否是制約性能瓶頸？硬件是否是瓶頸，哪部分造成瓶頸？

優化需要大量的技能，是個需要不斷的、長期的積累的過程。

路，還長的很啊。