宋士濤，張佳佳，張　燕，劉文杰

(國家網(wǎng)絡(luò)軟件產(chǎn)品質(zhì)量監(jiān)督檢驗中心(濟南)、山東省軟件產(chǎn)品質(zhì)量監(jiān)督檢驗中心，山東　濟南 250014)

?

基于Web 2.0的系統(tǒng)性能測試技術(shù)研究

宋士濤，張佳佳，張燕，劉文杰

(國家網(wǎng)絡(luò)軟件產(chǎn)品質(zhì)量監(jiān)督檢驗中心(濟南)、山東省軟件產(chǎn)品質(zhì)量監(jiān)督檢驗中心，山東濟南 250014)

摘要：在分析Web性能測試模型WPTM (Web Performance Testing Model)的基礎(chǔ)上，參考軟件測試V模型和W模型，提出了一種性能測試PV模型(Performance V Model)。增加了用戶思考時間、請求放棄率等用戶特征，與其它性能指標結(jié)合，綜合評價系統(tǒng)性能。該模型引入了項目管理，對性能測試各階段進行明確規(guī)定，并評審以保證質(zhì)量。測試結(jié)果表明，該模型能夠客觀、準確地評價被測軟件的性能。

關(guān)鍵詞：性能測試；Web 2.0系統(tǒng)；性能測試模型；WPTM

Web應(yīng)用系統(tǒng)已經(jīng)成為目前應(yīng)用軟件的主流，特別是隨著Web 2.0時代的到來，基于Web 2.0的系統(tǒng)以其交互性、廣泛性、易用性和快捷性等特點，受到了越來越多的企業(yè)和個人的青睞[1]。Web 2.0 是相對于Web 1.0的新的時代，主要包括異步 Java和XML(Ajax)、Adobe Flex、Web Services等技術(shù)。相對于之前的Web應(yīng)用的性能測試，Web 2.0應(yīng)用中對于請求和響應(yīng)的匹配、Web Services相關(guān)的RFC文件等都對系統(tǒng)性能測試提出了新的挑戰(zhàn)[2]。本文在分析原有的軟件性能測試模型的基礎(chǔ)上，結(jié)合用戶的訪問特征，加入項目管理過程，提出了一種新的基于Web 2.0的系統(tǒng)性能測試模型，并應(yīng)用到性能測試過程中，說明該模型是有效和可靠的。

一、Web 2.0 性能測試模型的分析

(一)國內(nèi)外性能測試研究現(xiàn)狀

對于Web系統(tǒng)的性能測試研究，在國內(nèi)外均已有了一定的成果，如印度Infosys Technologies公司提出了對象驅(qū)動性能測試模型，國內(nèi)性能測試專家段念提出了Performance Testing General Model(性能測試通用過程模型，簡稱PTGM)等，這些模型，對于性能測試理論研究和實踐均有一定的指導(dǎo)意義，并開發(fā)出了很多優(yōu)秀的性能測試工具。

(二)現(xiàn)有性能測試模型(Web Perfoanance Testing Model, WPTM)

所有的Web系統(tǒng)的性能都可用3種模型來表示：負載模型、性能模型和成本模型。其中性能模型用來預(yù)測響應(yīng)時問、系統(tǒng)吞吐量和資源利用率等性能指標[3]。

性能測試模型(Web Perfoanance Testing Model, WPTM)主要由性能指標、性能參數(shù)、性能指示器三個維度構(gòu)成。通過在性能指示器中設(shè)置性能參數(shù)，得到性能指標，性能指標提供了性能度量的標準。性能指標是性能測試的出發(fā)點，測試前必須先確定要測試的性能指標[4]，常用的性能指標主要有以下幾項：

1.響應(yīng)時間

從用戶觀點來看，響應(yīng)時間是從發(fā)出一個請求到客戶端收到服務(wù)器的響應(yīng)所經(jīng)歷的延遲[5]，通常以秒或毫秒來衡量。一般而言，響應(yīng)時間與尚未利用的系統(tǒng)容量成反比，隨著尚未利用的系統(tǒng)容量的減少而逐步變長。在性能測試中，一般取事務(wù)平均響應(yīng)時間。

2.資源利用率

資源利用率指系統(tǒng)在運行過程中，所耗費的服務(wù)器各類資源的狀況。資源利用率是分析系統(tǒng)性能的重要指標，實際測試時，通?？紤]CPU利用率、內(nèi)存占用率等服務(wù)器指標。

3.并發(fā)用戶數(shù)

在同一時刻與服務(wù)器進行交互的在線用戶數(shù)量，稱為并發(fā)用戶數(shù)。在測試時，要區(qū)分并發(fā)用戶數(shù)和在線用戶數(shù)、系統(tǒng)用戶數(shù)的區(qū)別。在并發(fā)用戶數(shù)增加時，一般資源利用率也會增加、并導(dǎo)致響應(yīng)時間延長。

4.吞吐量

系統(tǒng)吞吐量是指在單位時間內(nèi)系統(tǒng)所處理的用戶請求數(shù)目，直接反映系統(tǒng)的性能承載能力，常用請求數(shù)/秒衡量。通常吞吐量與客戶端請求數(shù)成正比。

(三)性能測試模型 (WPTM)的不足

現(xiàn)有的性能測試模型，對于Web 2.0系統(tǒng)的性能測試具有一定的指導(dǎo)意義，為性能測試指明了方向，但是也存在一定的不足。首先，在實際測試中，每個指標不能單獨地說明系統(tǒng)性能的情況，比如驗證響應(yīng)時間是否滿足用戶需求，離不開一定的并發(fā)用戶數(shù)、系統(tǒng)資源占用情況等前提條件。所以需要綜合分析測試模型中的各個性能指標，形成一個整體的Web性能測試體系[6]。其次，該模型缺少對用戶使用特征的分析，沒有從用戶行為出發(fā)，充分考慮用戶實際行為對系統(tǒng)性能的影響[7]。因為不同用戶的行為是不一樣的，如不同用戶操作速度不同，或者有些用戶在提出一些請求后會放棄該請求，轉(zhuǎn)而去進行其他業(yè)務(wù)操作，這些都會對系統(tǒng)的性能產(chǎn)生不同的影響。最后，該模型沒有對性能測試各個階段進行說明，也沒有對性能測試過程進行質(zhì)量控制。

二、改進的Web 2.0系統(tǒng)性能測試模型的提出

基于上文提到的性能測試模型的種種不足，本文根據(jù)多年Web 2.0系統(tǒng)性能測試實踐，在WPTM模型的基礎(chǔ)上，結(jié)合軟件測試V模型和W模型[8]，提出了一種改進的Web 2.0系統(tǒng)性能測試PV(Performance V)模型。如下圖所示：

圖1　性能測試PV(Performance V)模型

Fig.1 Chart of performance testing PV(Performance V) model

本模型針對原有的性能測試模型，不再孤立地對系統(tǒng)的性能指標進行單獨考察，而是綜合各個性能指標，從各個指標的相互影響去評價系統(tǒng)性能。同時為了更貼近用戶的真實操作行為，加入了以下指標對用戶使用特征進行模擬。

(一)思考時間

思考時間是指用戶在使用系統(tǒng)過程中，兩次操作或兩個事務(wù)之間等待的時間間隔。由于不同用戶的思考時間是不一樣的，所以在性能測試時，不同的思考時間會對系統(tǒng)的性能造成不一樣的影響，較短的思考時間一般會造成較大的系統(tǒng)壓力，從而使得系統(tǒng)性能指標下降。

(二)請求放棄率

請求放棄率是針對放棄瀏覽這個用戶特征的，它是請求放棄的次數(shù)與總的請求次數(shù)之間的比值。請求放棄分為主動放棄與被動放棄兩種情況。主動放棄指用戶提交一個請求后不等服務(wù)器返回響應(yīng)，而直接去提交其它請求；被動放棄常常由于請求超時而產(chǎn)生。請求放棄是多個性能指標共同作用的結(jié)果，包括響應(yīng)時間、CPU和內(nèi)存的利用率、并發(fā)用戶數(shù)等。例如，當服務(wù)器可利用資源過少或網(wǎng)絡(luò)帶寬不足時，繼續(xù)提交大量用戶請求，使系統(tǒng)不堪重負，從而處理速度變慢，此時用戶或失去耐性主動放棄請求，或服務(wù)器響應(yīng)超時造成用戶被迫放棄請求，最終導(dǎo)致Web系統(tǒng)的請求放棄率提高[9]。

在性能測試PV模型中，還引入了項目管理的概念，不僅對測試過程中各個階段的工作進行明確劃分，而且對于每個階段產(chǎn)生的中間結(jié)果進行評審，驗證其正確性，并加入控制庫作為基線進行嚴格控制，以對測試過程提供質(zhì)量保障。

三、Web 2.0系統(tǒng)性能測試實例

本文將采用上文中描述的性能測試PV模型制定測試流程，對中國合格評定國家認可委員會(CNAS)于2014年11月份組織的性能測試實驗室能力驗證樣品“信息報送平臺”，進行性能測試，以驗證該模型的可靠性和有效性。“信息報送平臺”是一個用于信息報送的Web 2.0系統(tǒng)，不同權(quán)限的用戶可通過本系統(tǒng)執(zhí)行創(chuàng)建信息、報送至其它部門、審核等功能操作。

(一)測試需求分析

測試需求分析一般包含三個過程：測試需求采集、測試需求分析、測試需求評審。測試需求分析主要解決“測什么”的問題，即細化測試對象，它通常以軟件開發(fā)需求為基礎(chǔ)進行分析，通過對開發(fā)需求的細化和分解，形成可測試的內(nèi)容。在本次測試中，確定了事務(wù)平均響應(yīng)時間、并發(fā)用戶數(shù)、吞吐量、資源利用率等性能指標，同時綜合考慮用戶思考時間、請求放棄率等用戶特征。

(二)測試計劃

測試計劃從組織管理的角度對測試活動進行規(guī)劃，對整個測試過程的組織、資源等進行規(guī)定和約束，并制訂測試全過程各個階段的任務(wù)以及時間進度安排，提出對各項任務(wù)的評估、風(fēng)險分析和需求管理。本過程中，核心是明確測試工作任務(wù)，包括進行測試工作量估計、測試任務(wù)的劃分、人員和物質(zhì)資源分配、明確任務(wù)時間進度和安排、以及測試應(yīng)交付的工作產(chǎn)品等。測試計劃制定完成后需經(jīng)評審加入控制庫，以指導(dǎo)測試方案的制定等后續(xù)環(huán)節(jié)的有序進行。

(三)測試方案

測試方案是測試過程的根本，是測試設(shè)計、測試執(zhí)行階段的指導(dǎo)性文件[10]。測試方案從技術(shù)的角度對測試活動進行規(guī)劃，描述測試方法、測試策略、測試環(huán)境的規(guī)劃、測試工具設(shè)計和選擇原則、測試用例的設(shè)計方法、測試代碼的設(shè)計方案等。本過程要形成最終的測試方案，并經(jīng)過評審后加入控制庫形成基線。

(四)測試設(shè)計

在性能測試PV模型中，測試設(shè)計特指測試用例的設(shè)計。測試用例需要描述所測功能的執(zhí)行步驟、需要參數(shù)化的參數(shù)項、并發(fā)時集合點的位置及策略、測試執(zhí)行過程中的運行時設(shè)置、需要監(jiān)控的性能指標及其預(yù)期結(jié)果等。本次測試中，將設(shè)計多個測試用例，包括單功能場景、混合功能場景、單用戶場景、并發(fā)場景等，對“信息報送平臺”的性能進行綜合評估。用例設(shè)計完成后，必須經(jīng)過評審后才能作為后續(xù)測試執(zhí)行過程的依據(jù)。

(五)測試環(huán)境準備及工具選擇

本過程主要是根據(jù)軟件需求中的運行環(huán)境準備測試環(huán)境，測試環(huán)境應(yīng)完全符合需求，以保證性能測試結(jié)果的有效性。

由于被測軟件為Web 2.0系統(tǒng)，Web 2.0對軟件測試帶來的挑戰(zhàn)之一是將不同的中間件技術(shù)結(jié)合應(yīng)用在一個獨立的客戶端上，因此需要測試工具提供“多種協(xié)議”的錄制方式，此外結(jié)合測試需求中對并發(fā)用戶數(shù)等的要求，本次測試采用HP LoadRunner作為測試工具。

(六)測試執(zhí)行

測試執(zhí)行是執(zhí)行測試用例的過程，與功能測試不同，性能測試的用例執(zhí)行包括腳本錄制、腳本編輯、場景創(chuàng)建、場景運行及結(jié)果分析等過程。首先根據(jù)測試用例錄制腳本，并對腳本進行參數(shù)化、關(guān)聯(lián)等一系列的編輯，使腳本能夠模擬多用戶同時運行，在編輯成功的基礎(chǔ)上，創(chuàng)建運行場景，并根據(jù)測試方案中的測試策略進行并發(fā)用戶數(shù)設(shè)定、運行時設(shè)置、選取監(jiān)控指標等操作，最終得到運行完成之后的結(jié)果分析。

在本次測試中，為了模擬用戶特征，需要錄制前一個請求尚未返回結(jié)果之前，又提交另一請求的操作，所得到的腳本與執(zhí)行其它功能的腳本組成混合功能場景；同時在運行時設(shè)置中，設(shè)置思考時間為錄制時思考時間值的50%-150%之間的隨機數(shù)，并在一次執(zhí)行過程中同時考察事務(wù)平均響應(yīng)時間、并發(fā)用戶數(shù)、資源利用率、吞吐量等多項指標。

(七)測試結(jié)果評估

測試執(zhí)行完成后，需要對測試結(jié)果進行評估、分析、回溯，以驗證測試結(jié)果的合理性，為軟件性能的評價提供客觀依據(jù)。結(jié)果評估時，要綜合考慮各項性能指標的表現(xiàn)，找出各個指標間的相應(yīng)關(guān)系，對軟件性能進行正確合理的評價。評估完成后，要填寫結(jié)果評估審核表，并加入控制庫進行統(tǒng)一管理。下圖為本次測試中，多用戶并發(fā)操作某功能點時，數(shù)據(jù)庫服務(wù)器CPU資源利用率、內(nèi)存占用情況、并發(fā)用戶數(shù)、事務(wù)平均響應(yīng)時間等的性能指標。

圖2　功能點多用戶并發(fā)時各性能指標

Fig.2 Performance metrics of multiple users concurrency operation

本次測試結(jié)果表明，在模仿用戶實際使用特征的情況下，被測軟件能夠滿足至少100用戶并發(fā)進行功能操作，事務(wù)平均響應(yīng)時間在100用戶并發(fā)時不超過10s，CPU資源利用率、內(nèi)存占用率均不超過35%，能夠符合系統(tǒng)需求。

(八)回歸測試

經(jīng)結(jié)果評審及回溯后，在確認測試過程及方法不存在問題的情況下，對于需要修改的軟件錯誤或缺陷，需反饋開發(fā)方進行修改。修改完成之后，對修改模塊及相關(guān)聯(lián)模塊進行回歸測試。本次測試由于為實驗室能力驗證項目，不存在修改軟件并回歸測試的問題，所以本步驟在本次測試中可省略。在此也說明，本文提出的性能測試PV模型，是一個靈活的測試過程，每一個環(huán)節(jié)并不是要必須存在的。如除了回歸測試外，對于一些比較小的測試項目，也可將測試方案合并到測試計劃中，以提高測試效率。

(九)測試報告

測試結(jié)果評估完成后，進入測試報告編制階段。測試報告要包括被測軟件介紹、測試需求、測試方法與策略的簡要介紹、測試環(huán)境與工具、測試結(jié)果評價原則、測試評價最終結(jié)論等各個方面，確保測試報告的說服力。測試報告經(jīng)評審后，分發(fā)給測試委托方，并在控制庫中保留副本。

四、結(jié)語

Web 2.0系統(tǒng)性能已經(jīng)受到了越來越多的關(guān)注。本文根據(jù)原有的性能測試模型，提出了改進的性能測試PV模型，并將該模型應(yīng)用到了實際項目中。經(jīng)過與實驗室能力驗證組織方提供的被測軟件性能指標參考值進行比較，本次測試所得結(jié)果完全在參考范圍之內(nèi)，并以滿分的成績通過了本次性能測試能力驗證。說明了本文提出的PV模型是可靠、有效的，通過該模型的應(yīng)用，能客觀、準確地評價軟件性能。我們將在此后的性能測試項目中繼續(xù)應(yīng)用本文提出的PV模型，在實踐中不斷改進，使之能夠更加完善。

參考文獻：

[1]杜香和. Web性能測試模型研究[D].重慶:西南大學(xué)，2008.

[2]Ian Molyneaux. The Art of Application Performance Testiong[M]. New York: O'Reilly Media, Inc.，2009：23-24.

[3]張熙. Web應(yīng)用性能優(yōu)化模型及測試框架的研究[D].南京:南京航空航天大學(xué)，2008.

[4]惠斌武，陳明銳，楊登攀.Web應(yīng)用系統(tǒng)性能測試研究與應(yīng)用[J]．計算機應(yīng)用，2011,31(7)：1769-1772.

[5]Menasce, D.A. Load testing of Web sites. Internet Computing,IEEE, 2005：70-74.

[6]Rahurm S. Thpuri，"Automatic Functional Test Generation- A Reality”. ITC’99, EEE1999.

[7]喬志杰，田劍.基于用戶訪問特征的Web性能測試模型[J]．智能計算機與應(yīng)用，2015,5(4)：5-8.

[8]柳純錄. 軟件評測師教程[M].北京: 清華大學(xué)出版社，2005：13-15.

[9]鄧璐娟，范乃梅等．基于Web應(yīng)用的性能測試模型研究[J]．計算機工程與應(yīng)用，2013,49(1)：75-77.

[10]宋士濤．一種Web應(yīng)用系統(tǒng)性能測試流程及其應(yīng)用研究[J]．山東科學(xué)，2015,28(4)：94-100.

收稿日期：2016-04-22

基金項目：山東省質(zhì)量技術(shù)監(jiān)督局科技計劃項目(2013KY22)。

作者簡介：宋士濤(1983-)，男，山東聊城人，工程師，碩士，主要從事軟件工程、軟件測試技術(shù)研究和應(yīng)用。

中圖分類號：：TP311

文獻標識碼：A

文章編號：1008—3340(2016)03—0086—04

張佳佳，女，工程師，碩士，研究方向：軟件測試。

張燕，女，工程師，碩士，研究方向：軟件測試及管理。

劉文杰，男，工程師，碩士，研究方向：軟件工程。