軟件性能測試需求的獲取方法綜述

摘要:性能測試需求的質量直接影響性能測試的效果，在分析Web應用系統性能測試目的的基礎上，提出性能測試需求描述要達到準確、一致和特定的要求，進一步明確性能測試需求必須要確定4W1H，即性能測試的需求必須包含where，what，when，who和how，并綜述了幾種有效的獲取性能測試需求的方法。

關鍵詞:性能測試;測試需求;需求獲取

1 引言

基于Web服務器的應用系統由于提供瀏覽器界面而無須安裝，大大降低了系統部署和升級成本而得以普遍應用。目前，很多企業的核心業務系統均是Web應用，但當Web應用的數據量和訪問用戶量日益增加，系統不得不面臨性能和可靠性方面的挑戰。因此，無論是Web應用系統的開發商或最終用戶，都要求在上線前對系統進行性能，科學評價系統的性能，從而降低系統上線后的性能風險。

在很多性能測試項目中，由于不能合理定義系統的性能測試需求，不能建立和真實環境相符的負載模型，不能科學分析性能測試結果，導致性能測試項目持續時間很長或不能真正評價系統性能并提出性能改進措施。因此，性能測試需求分析的正確性是整個性能測試工作的最基本前提。若不能保證性能測試需求分析的正確性，即使性能測試工具使用的再正確，性能測試執行的再順利，也無法保證性能測試達到預期的效果，即可能無法發現性能瓶頸、或者發現不了實際情況中應該出現的瓶頸。

本文從分析性能測試的目的出發，提出性能測試需求描述的三個要求，綜述性能測試需求的獲取常用方法。

2 性能測試的目的

性能測試的目的不僅是發現軟件缺陷，還可能包括以下幾個方面:

(1)驗證能力。這是性能測試中最簡單也是最常用的一個應用領域，典型的能力驗證問題會采用這樣的描述方式:“***系統能夠在***條件下具有***能力?”。通常情況下，企業在進行項目驗收階段要求能力驗證型的性能測試或者委托第三方軟件測試機構開展獨立的性能驗證，其主要特點是在已確定的生產環境中實際使用被測系統，即這套系統能不能承受大量的并發用戶同時訪問?常以典型場景設計測試方案和用例。

(2)規劃能力。這與(1)有較大的不同，以規劃能力為目的的性能測試關注的是“應該如何才能使系統具有要求的性能能力?”或者“系統能否支持未來一段時間內的用戶增長?”，因此，這種性能測試強調對系統當前性能的評估，通過評估可以在應用實際部署之前，預見系統負載壓力的承受能力。

(3)調優性能。性能調優是以第一種或第二種為目的的性能測試實施后提供原始數據進而分析系統瓶頸和優化為目的，因此(3)常與其他的性能測試活動交雜在一起。該類性能測試需要在確定的基準環境下，采用基準負載，關注基準性能指標后，調整系統運行環境和實現方法，執行測試，記錄測試結果進行分析，再調整、執行、分析，不斷往復，直到系統性能達到要求為止。比如:用戶提出業務操作響應時間長，如何定位問題，調整性能?

3 性能測試需求描述要求

(1)準確。如**系統必須在不超過 10 秒的響應時間內，處理 20 起登錄和注銷系統任務。再如**搜索時間最大不超過5秒以及平均時間在1～3秒以內。

(2)一致。開發工程師、用戶和性能測試工程師對有關術語的理解要一致，如:并發用戶數、動態用戶數、靜態用戶數:

靜態用戶(注冊用戶):3500以上

動態用戶(在線用戶):1500以上

并發用戶:500以上

(3)特定。性能測試的需求一定是有條件的，如:

檢查系統在 200 個用戶的負載下，所有業務動作是否可用及穩定;

檢查系統在300 個用戶的負載下，連續運行 72 小時過程中，訂單上傳、轉單、詳情單查詢、發運等業務動作是否可用及穩定;

檢查系統在 8.0 GB 業務數據、1500 個用戶、500 個并發用戶運行的負載下，連續運行 72 小時過程中，以上業務動作是否可用及穩定。

因此，性能測試需求必須要包含有多少用戶(who)在什么時間(when)或者持續多久(when)進行了什么業務(what)，最終需要關注怎樣的指標(how)。除此以外，需要根據項目性質和性能測試的目標來獲得性能測試需求的來源(where)，歸納為4W1H。下面將介紹一些常用的性能測試需求獲取的方法。

4 獲取性能測試需求的方法

性能測試需求是應用需求的衍生，既需要借助于相關的理論知識，又要依靠測試工程師在相關領域的經驗積累，根據前面4W1H的性能測試需求的要求，即對性能測試需求進行整理，確定恰當的并發用戶數、在適當的時間進行典型的業務活動時，關注的性能指標有怎樣的結果，筆者根據多次性能測試實踐經驗，總結獲取性能測試需求的方法如下。

4.1 性能需求信息來源(where)

(1)開發過程相關文檔。這是性能測試需求的主要來源，項目開發計劃書、需求規格說明書、設計說明書、測試計劃等文檔都可能涉及性能測試的要求，通過收集這些資料，可以找到初步的性能需求。相關的項目干系人有客戶代表、項目經理、需求分析員、系統架構設計師、產品經理等。

(2)相似項目性能需求。公司的其他產品或項目會累積出一些數據，如:**技術論壇一小時最多能發1000新帖;****博客平均每天新增800篇，以這些數據為確認新項目測試需求的基礎。

(3)業界公認標準。如響應時間，根據服務器的不同和項目的具體情況可能有兩類標準:

A類標準——

4秒以內，用戶可以接受

4-9秒，30%用戶離開

8-10秒，60%用戶離開

超過10秒，90%用戶離開

B類標準——

8秒，用戶可接受

16秒，50%用戶離開

32秒，90%用戶離開

(4)用戶使用模型。性能測試要通過一系列場景的執行來完成，分析用戶的使用模型是獲取性能測試需求的有效手段，即定義系統的典型使用方式，考慮哪些用戶使用系統的哪些典型業務，在什么時間段和用戶數量的估計值，因此需要和最終的用戶有很好的溝通，最好能夠實地考察用戶的應用情況。如某OA系統的每天早上8:00會有200個用戶在10分鐘內登錄系統;每天查詢交易的高峰是在9:00-11:00和下午的14:00-16:00等。

4.2 80～20原則估算測試強度(how)

80～20原理:每個工作日中80%的業務在20%的時間內完成。

舉例:

每年業務量集中在8個月，每個月20個工作日，每個工作日8小時即每天80%的業務在1.6小時完成。去年全年處理業務約100萬筆，其中15%的業務處理中每筆業務需對應用服務器提交7次請求;其中70%的業務處理中每筆業務需對應用服務器提交5次請求;其余15%的業務處理中每筆業務需對應用服務器提交3次請求。根據以往統計結果，每年的業務增量為15%，考慮到今后3年業務發展的需要，測試需按現有業務量的兩倍進行。

每年總的請求數為:

(100x15%x7+100x70%x5+100x15%x3)x2=1000萬次/年

每天請求數為:

1000/(20x8)=6.25萬次/天

每秒請求數為:

(62500x80%)/(8x20%x3600)=8.68次/秒

即服務器處理請求的能力應達到9次/秒。

4.3 任務分布圖(what + when + who)

任務分布圖是以一種直觀的方式展示性能測試需求，描述一些交易任務在24小時內的交易情況，重點關注并發用戶的數量以及典型的業務操作。如表1是某網上書店的任務分布圖，從中可見:12:00~16:00的交易混合程度較高，“預定圖書”任務的并發用戶在14:00達到最大。

如果需要進一步了解典型任務的平均值、峰值以及對web服務器、數據庫服務器的壓力等信息，可以建立交易混合表。

4.4 web服務器訪問日志

一般的web server有兩部分日志:一是運行中的日志，它主要記錄運行的一些信息，尤其是一些異常錯誤日志信息;二是訪問日志信息，它記錄訪問的時間、IP、訪問的資料等相關信息。為了獲取系統性能測試的需求，可以分析web server的訪問日志以了解系統更多真實負載和主要的業務場景。下面介紹一下利用tomcat產生的訪問日志數據所做的有效分析。

首先是配置tomcat訪問日志數據，默認情況下訪問日志沒有打開，配置的方式如下:

編輯 ${catalina}/conf/server.xml文件:(注:${catalina}是tomcat的安裝目錄)

把以下的注釋()去掉即可。

其中 directory是產生的目錄 tomcat安裝${catalina}作為當前目錄;pattern表示日志生產的格式，common是tomcat提供的一個標準設置格式。其具體的表達式為 %h %l %u %t \"%r\" %s %b。通過這個配置能得到的數據有:

%h 訪問的用戶IP地址

%l 訪問邏輯用戶名，通常返回'-'

%u 訪問驗證用戶名，通常返回'-'

%t 訪問日時

%r 訪問的方式(post或者是get)，訪問的資源和使用的http協議版本

%s 訪問返回的http狀態

%b 訪問資源返回的流量

%T 訪問所使用的時間

有了這些數據，可以根據時間段做以下的分析處理:

(1)獨立IP數統計

(2)訪問請求數統計

(3)訪問資料文件數統計

(4)訪問流量統計

(5)訪問處理響應時間統計

(6)統計所有404錯誤頁面

(7)統計所有500錯誤的頁面

(8)統計訪問最頻繁頁面

(9)統計訪問處理時間最久頁面

(10)統計并發訪問頻率最高的頁面

如圖1所示，將系統運行一段時間后獲取的數據分析匯總后形成的圖示，為性能測試工程師提供了非常有價值的數據，從圖中可見，并發用戶數在7:00-11:00之間明顯增大，平均值在40左右。

4.5 UCMLTM

UCMLTM(User Community Modeling Language)是一個符號集合，這些符號可以創建虛擬系統用法模型，以及描述相關參數。當把它應用到負載壓力性能測試時，這些符號可用于表示工作量分配、操作流程、重點工作表、矩陣和馬爾可夫鏈等。負載壓力性能測試工程師在決定測試中用到什么活動，以及它們發生的頻率時，經常用到這些參量。

通常應用SmartDraw 或者 Microsoft visio 繪制UCML，進行負載壓力測試需求分析。UCML的數據來源有兩種方式:一是通過與最終用戶的溝通，詳細詢問應用情景，根據一定的常識推理得到;二是通過分析已有的數據，如數據庫的日志，web server的訪問日志等獲得。UCML的好處在于提供了一種易于理解、便于溝通的表現形式，尤其在應用自動化性能測試工具時，方便性能測試計劃、分析、設計和實施人員的溝通。圖2是一個在線書店的 UCMLTM 圖表，為負載壓力測試提供了需求。

5 總結

Web應用項目的性能測試成功的關鍵不在于性能測試工具，而在于有效的性能測試分析方法和實踐。只有切實掌握性能測試需求分析方法，性能測試實踐經驗，才能保證一個Web應用性能測試的成功。基于4W1H的性能測試需求描述標準能夠為獲取有效的性能測試需求提供一個依據，結合性能測試目的而選取適用的性能測試需求獲取方法才是有效的。

參考文獻

[1]柳純錄，黃子河，陳淥萍.軟件評測師教程[M].北京:清華大學出版社，2005.

[2]趙艷玲.軟件開發中的需求獲取[J].現代電子技術，2007(11):580-581.

[3]馮錚.基于WEB的軟件測試規范與質量標準體系的研究[J].計算機與數字工程，2007(12):71-74.

[4]談姝辰，尹軍.基于負載的WEB性能測試研究與應用[J].現代電子技術，2007(14):139-142.

[5]常廣炎.基于WEB系統的性能測試[J].辦公自動化，2008(2):25-27.