軟體性能測試

為了驗證系統是否達到用戶提出的性能指標，同時發現系統中存在的性能瓶頸，起到優化系統的目的。

軟體性能測試，英文是Performance Testing。

通常驗證軟體的性能在正常環境和系統條件下重複使用是否還能滿足性能指標。或者執行同樣任務時新版本不比舊版本慢。一般還檢查系統記憶容量在運行程序時會不會流失(memory leak)。比如，驗證程序保存一個巨大的文件新版本不比舊版本慢。

SEI負載測試計劃過程

目標：產生一個清晰、好理解、可驗證的負載測試計劃

內容：關注6個區域：目標、用戶、用例、生產環境、測試環境、測試場景

工具：IBM、HP、OpenSource工具都支持。需有文檔配合

RBI方法

目標：快速識別性能瓶頸

內容：重點測試“吞吐量”指標，因為RBI認定80%的系統性能瓶頸由吞吐量造成。

按照網路、硬體、資料庫、應用伺服器、代碼的順序自上而下分析性能

工具：IBM、HP、OpenSource工具都支持。需使用分析模塊、根據Weblogic、Oracle區別有專門的工具實現RBI。

性能下降曲線分析法

目標：性能隨著用戶數的增加而出現下降趨勢的曲線分析、查看性能下降的環境點與上下文。確定性能閥值。

內容：通過單用戶區域、性能平坦區域、壓力區域、性能拐點進行監控和分析。

工具：IBM、HP、OpenSource工具都支持。IBM報表功能更強。

HP(LoadRuner)性能分析法

特點：側重於該廠商的性能分析方法、主要體現在需求收集、VU腳本。

對於網際網路應用軟體，性能是其質量的一個非常重要的組成部分。作為解決軟體性能問題的重要手段，軟體性能測試已經廣為人們所熟悉，並受到很高的關注。一般而言，軟體性能測試都是在項目的後期才開展，被測試的對象通常是已經具備一定穩定性的產品。而實際上，軟體性能測試應貫穿於整個軟體生命周期中，和功能測試一樣，軟體性能測試也分為幾個階段。

軟體生命周期與軟體性能測試

不論哪種軟體生命周期模型，需求分析、設計、編碼、測試和運行維護這幾個階段都是其中的基本要素，只是在不同的軟體生命周期模型中可能迭代、合併、拆分或重組這幾個階段，在此不做過多的描述。與其他幾個階段相對應，測試從軟體開發過程按階段可以劃分為：單元測試、集成測試、系統測試，在其他的書上可能還能見到諸如確認測試、驗收測試等名詞，但是前3種測試確實是最基本的測試活動，而其他的測試活動只是在某些軟體開發過程中會發生。

值得注意的是，通常在談論單元測試、集成測試和系統測試時，其實僅僅談論的是不同階段的功能測試；而當討論軟體性能測試時，絕大多數的情況是，一個已經開發完畢或基本開發完畢的軟體，測試人員用一種或幾種軟體性能測試工具，以盡量模擬真實用戶行為的方式對該軟體進行併發操作，收集並比較不同場景的結果，然後對軟體的性能進行分析，這個活動通常發生在系統測試階段，甚至更往後的階段，如運行維護階段。

一直以來，軟體性能測試跟單元測試、集成測試似乎都是絕緣的。可是它們真的應該是絕緣的嗎？沒有任何理由可以說明軟體性能測試跟單元測試、集成測試無關，除非你認為“這太難了，我不會做”。

我把“響應時間”的概念確定為“對請求作出響應所需要的時間”，把響應時間作`為用戶視角的軟體性能的主要體現。響應時間劃分為“呈現時間”和“系統響應時間”兩個部分。

其中“呈現時間”取決於數據在被客戶端收到響應數據后呈現頁面所消耗的時間、而“響應時間”指J2EE應用伺服器從請求發出開始到客戶端接受到數據所消耗的時間。軟體性能測試一般不關注“呈現時間”，因為呈現時間很大程度上取決於客戶端的表現。在這裡我們沒有使用很多軟體性能測試定義中的概念——“系統響應時間”定義為“應用系統從請求發出開始到客戶端接收到最後一個位元組數據所消耗的時間”，沒有使用這種標準的原因是，可以使用一些編程技巧在數據尚未完全接收完成時進行呈現來減少用戶感受到的響應時間，對於HNDLZCGLXT的這個項目中，我們針對C/S系統採用前者標準，對於B/S我們依然採用后一種標準。

我把“併發用戶數”與“同時在線數”進行區別對待，我的“併發用戶數”的標準是：併發用戶數取決於測試對象的目標業務場景，因此，在確定這個“併發用戶數”前，必須(必要)先對用戶的業務進行分解、分析出典型的業務場景(也就是用戶最常使用、最關注的業務操作)，然後基於場景採用某些方法(有多種計算併發用戶數的數學模型與公式)獲得“併發用戶數”。

這樣做的原因是：假設一個應用系統、最高峰有500人同時在線、但這500人卻不是併發用戶數、因為假設在一個時間點上、有50%的人在填寫複雜的表格(填寫表格動作對伺服器沒有任何負擔、只有在“提交”動作的時候才會對伺服器系統構成壓力)、有40%的人在不停的從一個頁面跳轉到另外一個頁面(不停發出請求與回應、產生伺服器壓力)、還有10%的人掛在線上，沒有任何操作在發獃：)(沒有對伺服器構成壓力的動作)。因此只有那40%的人真正對伺服器產生了壓力，從這裡例子可以看出、併發用戶數關心的是不但是業務併發用戶數、還取決於業務邏輯、業務場景。因此我們需要本文第六部分軟體性能測試文檔4、5、6。

我把吞吐量定義為“單位時間內系統處理的客戶請求的數量”，直接體現軟體系統的性能承載能力，對於互動式應用系統來說、吞吐量反映的是伺服器承受的壓力、在容量規劃的測試中、吞吐量是一個重要指標、它不但反映在中間件、資料庫上、更加體現在硬體上。我們在以下方面利用這個指標：

(1) 用來協助設計軟體性能測試場景，衡量軟體性能測試是否達到了預計的設計目標、比如J2EE應用系統的連接池、資料庫事務發生頻率、事務發生次數。

(2) 用來協助分析性能瓶頸、參照本文第二部分總的RBI方法。

性能計數器式描述伺服器或操作系統性能的一些數據指標、例如對WINDOWS來說使用內存數、CPU使用率、進程時間等都是常見的計數器。 [Page]

對於性能計數器這個指標來說、需要考慮到的不但有硬體計數器、web伺服器計數器、Weblogic伺服器計數器、Servlet性能計數器、EJB2的性能計數器、JSF性能計數器、JMS性能計數器。找到這些指標是使用性能計數器的第一步、關鍵是找到性能瓶頸、確定系統閥值、提供優化建議才是性能計數器使用的關鍵。性能計數器複雜而繁多、與代碼上下文環境、系統配置情況、系統架構、開發方式、使用到的規範實現、工具、類庫版本都有緊密的聯繫、在此不作贅述。

我把思考時間確定為“休眠時間”。從業務系統的角度來說，這個時間指的是用戶在驚醒操作時、每個請求之間的時間間隔、從自動化測試的角度來說、要真實的測試模擬用戶操作、就必須在測試腳本中讓各個操作之間等待一段時間、體現在腳本上就是在操作之間放置一個Think的函數，體現為腳本中兩個請求語句之間的間隔時間、不同的測試工具提供了不同的函數或方法來實現思考時間、比如HP LoadRuner和IBM Rational Performance Tester的方式就完全不同。

1、軟體性能測試是在功能測試完成之後進行。

2、軟體性能測試計劃、方案一般與測試用例統一在一個文檔里。

3、測試環境應盡量與用戶環境保持一致。

4、軟體性能測試一般使用測試工具和測試人員編製測試腳本來完成，軟體性能測試的環境應單獨運行盡量避免與其他軟體同時使用。

5、軟體性能測試的重點在於前期數據的設計與後期數據的分析。

6、軟體性能測試的用例主要涉及到整個系統架構的問題，所以測試用例一旦生成，改動一般不大，所以做軟體性能測試的重複使用率一般比較高。(說明：當系統中出現的某個功能點需要修改，它一般只會影響到功能測試的設計用例，而對於軟體性能測試，很少影響到軟體性能測試的設計用例。但是如果某個功能有較大的修改，軟體性能測試也應該進行重新測試。)

1、軟體性能測試指標的來源：測試的依據是產品的需求規格說明書；如果用戶沒有提出性能指標則根據用戶需求、測試設計人員的經驗來設計各項測試指標。

2、軟體性能測試的目的：通過測試確認軟體是否滿足產品的性能需求，同時發現系統中存在的性能瓶頸，起到優化系統的目的。

3、軟體性能測試的指標：伺服器的各項指標(CPU使用率、內存佔用率、硬碟佔用率等)、後台資料庫的各項指標和軟體的響應時間：

(1) 操作系統有關的指標：CPU平均利用率、內存平均佔用率、硬碟佔用率、I/O數量、網路時延

(2) 資料庫有關的指標：I/Owait、Mem平均使用率、cpu平均使用率、在一次I/O操作中所讀的最大BLOCKS數、Log的增長情況、資料庫的訪問速度、資料庫能支持的最大用戶數、資料庫CACHE命中率、不同資料庫參數下的性能情況、鎖的處理

(3) 軟體有關的指標：交易的平均響應時間(從接收請求到回復響應的時間)、每秒交易數量(單位時間裡的執行次數)、對中間件功能的調用、遠程處理延遲

4、查看性能指標的命令和方法：

vmstat：虛擬內存的統計(cpu/io)

iostat：設備的IO統計

netstat：網路活動信息統計

top：內存統計

cat /proc/meninfo：查看系統的總men大小

cat /proc/cpuinfo：查看系統總CPU大小

df –k：查看系統硬碟大小

free -m：查看內存使用情況

舉例說明：

(1)查看CPU使用情況的命令

每5秒刷新一次，最右側有CPU的佔用率的數據：$ vmstat 5

top 然後按Shift+P，按照進程處理器佔用率排序：$ top

(2)查看內存使用情況的命令

用free命令查看內存佔用情況：$ free

top 然後按Shift+M, 按照進程內存佔用率排序：$ top

(3)查看網路流量