黃兆森 蔣蜀鵬 侯建華 倪玉華

（1.珠海南方軟件網(wǎng)絡(luò)評測中心 珠海 519000）（2.北京師范大學(xué)珠海分校 珠海 519000）

1 引言

隨著信息技術(shù)的不斷發(fā)展，軟件在各行業(yè)的應(yīng)用范圍越來越廣，軟件規(guī)模也在不斷地擴(kuò)大。一些大型軟件通常存在大量用戶同時訪問的情況，具有較高的性能要求。為確認(rèn)軟件的性能是否能夠達(dá)到期望的要求，通常需要對軟件進(jìn)行性能測試。

測試模型的分析與設(shè)計是軟件性能測試項目中非常重要的一個環(huán)節(jié)，它對軟件性能測試項目的成敗起著關(guān)鍵性的決定作用［1］。只有將性能測試模型設(shè)計好，才能確保軟件性能測試的結(jié)果符合用戶的要求。

2 性能測試案例介紹

為開展軟件性能測試項目的測試模型設(shè)計技術(shù)研究，本文選擇了一個真實的電子商務(wù)網(wǎng)站性能測試項目作為研究案例。該電子商務(wù)網(wǎng)站主要實現(xiàn)采購商和供應(yīng)商的議價以及產(chǎn)品交易和支付功能。

該電子商務(wù)網(wǎng)站主要采用.NET技術(shù)構(gòu)建，采用B/S結(jié)構(gòu)框架，操作系統(tǒng)為Windows Server 2003或Windows Server 2008，數(shù)據(jù)庫為SQL Server 2008，Web服務(wù)器為IIS 6.0或IIS 7.0。

3 性能測試模型分析與設(shè)計

為確保性能測試結(jié)果的有效性，性能測試模型的設(shè)計應(yīng)盡可能地模擬真實環(huán)境［2］。下面從業(yè)務(wù)流程選取、用戶數(shù)分析、用戶數(shù)加載卸載方式分析、用戶操作間隔時間分析、業(yè)務(wù)流程迭代間隔時間分析等5個方面進(jìn)行性能測試模型設(shè)計［3］。

3.1 業(yè)務(wù)流程選取

業(yè)務(wù)流程選取就是選擇性能測試需要模擬的業(yè)務(wù)流程［4］，業(yè)務(wù)流程選取的原則如下：

1）選取業(yè)務(wù)發(fā)生頻率高的業(yè)務(wù)流程。業(yè)務(wù)發(fā)生頻率高的業(yè)務(wù)流程通常對被測軟件服務(wù)器端的性能影響較大，也比較容易出現(xiàn)并發(fā)問題，是軟件性能測試中需要重點關(guān)注的業(yè)務(wù)流程［5］。

2）選取業(yè)務(wù)發(fā)生頻率不高但對軟件服務(wù)器端性能影響較大的業(yè)務(wù)流程［6］。如每天一次的日結(jié)統(tǒng)計流程，它雖然每天只運行一次，但可能需要對大量的數(shù)據(jù)進(jìn)行查詢和計算，對軟件服務(wù)器端的性能影響較大。對于業(yè)務(wù)發(fā)生頻率不高但對軟件服務(wù)器端性能影響較大的業(yè)務(wù)流程，雖然在性能測試時不可忽略，但客戶可能不關(guān)心該業(yè)務(wù)流程的響應(yīng)時間，此時可考慮不錄制該業(yè)務(wù)流程的腳本，僅在真實的客戶端打開并運行該業(yè)務(wù)流程作為背景流程。

3）選取客戶確認(rèn)的關(guān)鍵業(yè)務(wù)流程［7］。對于關(guān)鍵的業(yè)務(wù)流程，客戶可能要求其在被測軟件服務(wù)器端壓力較大時仍然保持高可用性。

根據(jù)以上原則，本文選取了該電子商務(wù)網(wǎng)站的采購商登錄、采購商查看2個業(yè)務(wù)流程進(jìn)行性能測試模型設(shè)計研究。

3.2 用戶數(shù)分析

3.2.1 用戶數(shù)分析方法

用戶數(shù)分析需要確認(rèn)各業(yè)務(wù)流程在各時間段的同時在線用戶數(shù)及其變換情況［8］。如果被測軟件具有歷史數(shù)據(jù)，可對歷史數(shù)據(jù)進(jìn)行分析，繪出各業(yè)務(wù)流程用戶數(shù)隨著用戶總數(shù)變化的曲線圖，找出各業(yè)務(wù)流程用戶數(shù)的變化規(guī)律［9］。

3.2.2 用戶數(shù)分析的相關(guān)問題說明

本文選取的電子商務(wù)網(wǎng)站由于還沒有上線，所以客戶難以直接給出各業(yè)務(wù)流程在各時間段的同時在線用戶數(shù)，而是給出了一些相對比較直觀的評估數(shù)據(jù)，如下：

旺季時“采購商查看”和“采購商登錄”兩個流程當(dāng)天最高峰時兩個流程同時在線用戶數(shù)總和為4560人；

淡季時“采購商查看”和“采購商登錄”兩個流程當(dāng)天最高峰時兩個流程同時在線用戶數(shù)總和為旺季時的50%，因此淡季時“采購商查看”和“采購商登錄”兩個流程當(dāng)天最高峰時兩個流程同時在線用戶數(shù)總和為2280人；將“采購商查看”和“采購商登錄”兩個流程當(dāng)天最高峰時兩個流程同時在線用戶數(shù)總和記為UT；

旺季時“采購商查看”流程當(dāng)天最高峰時的同時在線用戶數(shù)占兩個流程的同時在線用戶數(shù)總和的80%，“采購商登錄”流程當(dāng)天最高峰時的同時在線用戶數(shù)占兩個流程的同時在線用戶數(shù)總和的20%；

淡季時“采購商查看”流程當(dāng)天最高峰時的同時在線用戶數(shù)占兩個流程的同時在線用戶數(shù)總和的20%，“采購商登錄”流程當(dāng)天最高峰時的同時在線用戶數(shù)占兩個流程的同時在線用戶數(shù)總和的80%；將各業(yè)務(wù)流程當(dāng)天最高峰時的同時在線用戶數(shù)占兩個流程的同時在線用戶數(shù)總和的百分比記為PB；

無論旺季還是淡季，4：00～9：00的用戶數(shù)均為當(dāng)前服務(wù)器當(dāng)天最高峰時同時在線用戶數(shù)的20%，9：00～16：00的用戶數(shù)均為當(dāng)前服務(wù)器當(dāng)天最高峰時同時在線用戶數(shù)的80%，16：00～21：00的用戶數(shù)均為當(dāng)前服務(wù)器當(dāng)天最高峰時同時在線用戶數(shù)的20%，21：00～4：00的用戶數(shù)均為當(dāng)前服務(wù)器當(dāng)天最高峰時同時在線用戶數(shù)的100%；將各時間段用戶數(shù)占當(dāng)前服務(wù)器當(dāng)天最高峰時同時在線用戶數(shù)的百分比記為PT。

針對該問題，評測中心根據(jù)以上用戶給出的評估數(shù)據(jù)，利用以下公式計算出了旺季和淡季各時間段的同時在線用戶數(shù)：

UC=UT*PB*PT

UC為旺季和淡季各業(yè)務(wù)流程在各時間段的同時在線用戶數(shù)。

UT為當(dāng)天最高峰時兩個流程同時在線用戶數(shù)總和。

PB為當(dāng)前業(yè)務(wù)流程當(dāng)天最高峰時的同時在線用戶數(shù)占兩個流程的同時在線用戶數(shù)總和的百分比。

PT為當(dāng)前時間段用戶數(shù)占當(dāng)前服務(wù)器當(dāng)天最高峰時同時在線用戶數(shù)的百分比。

計算結(jié)果見表1。

表1 各時間段的同時在線用戶數(shù)

3.3 用戶數(shù)加載卸載方式分析

3.3.1 用戶數(shù)加載卸載方式分析方法

用戶數(shù)加載卸載方式分析需要確認(rèn)各業(yè)務(wù)流程用戶數(shù)加載和卸載的時間間隔和步長，以觀察用戶數(shù)逐漸增加和用戶數(shù)逐漸減少的情況下軟件的性能變化狀況。

3.3.2 用戶數(shù)加載卸載方式分析的相關(guān)問題說明

對于本文選取的電子商務(wù)網(wǎng)站，客戶沒有直接給出各業(yè)務(wù)流程用戶數(shù)加載和卸載的時間間隔和步長，而是給出了一個相對比較直觀的需求，如下：

無論淡季還是旺季，采購商均在30分鐘內(nèi)完成加載和卸載。

評測中心根據(jù)該需求，同時結(jié)合計算出來的同時在線用戶數(shù)，利用以下公式計算出了各業(yè)務(wù)流程單個用戶加載和卸載的時間間隔：

TV=（abs（UB-UA））/30*60

TV為各業(yè)務(wù)流程單個用戶加載和卸載的時間間隔；

abs為絕對值；

UB為加載或卸載后的用戶數(shù)；

UA為加載或卸載前的用戶數(shù)；

30分鐘為加載或卸載的時間；

60代表60秒每分鐘。

計算結(jié)果如下：

淡季時，“采購商查看”流程4：00～4：30加載91個用戶，平均每20s加載一個用戶；9：00～9：30用戶數(shù)從91增加到365，平均每6s加載一個用戶；16：00～16：30用戶數(shù)從365下降到91，平均每6s卸載一個用戶；21：00～21：30用戶數(shù)從91增加到456，平均每6s加載一個用戶；4：00～4：30用戶數(shù)從456下降到0，平均每4s卸載一個用戶。

旺季時，“采購商查看”流程 4：00～4：30 加載730個用戶，平均每2s加載一個用戶；9：00～9：30用戶數(shù)從730增加到2918，平均每1s加載一個用戶；16：00～16：30用戶數(shù)從2918下降到730，平均每4s卸載一個用戶；21：00～21：30用戶數(shù)從730增加到3648，平均每0.5s加載一個用戶；4：00～4：30用戶數(shù)從3648下降到0，平均每0.5s卸載一個用戶。

淡季時，“采購商登錄”流程 4：00～4：30 加載365個用戶，平均每4s加載一個用戶；9：00～9：30用戶數(shù)從365增加到1459，平均每2秒加載一個用戶；16：00～16：30用戶數(shù)從1459下降到365，平均每2s卸載一個用戶；21：00～21：30用戶數(shù)從365增加到1824，平均每1s加載一個用戶；4：00～4：30用戶數(shù)從1824下降到0，平均每1s卸載一個用戶。

旺季時，“采購商登錄”流程 4：00～4：30 加載182個用戶，平均每10s加載一個用戶；9：00～9：30用戶數(shù)從182增加到730，平均每3s加載一個用戶；16：00～16：30用戶數(shù)從730下降到182，平均每3s卸載一個用戶；21：00～21：30用戶數(shù)從182增加到912，平均每3s加載一個用戶；4：00～4：30用戶數(shù)從912下降到0，平均每2s卸載一個用戶。

3.4 用戶操作間隔時間分析

用戶操作間隔時間是指用戶連續(xù)兩次向服務(wù)器提交請求之間的間隔時間，用戶操作間隔時間分析需要確認(rèn)用戶在執(zhí)行業(yè)務(wù)流程操作時的詳細(xì)操作步驟以及操作步驟之間的間隔時間［10］。操作步驟之間的間隔時間可在編寫性能測試腳本時作為用戶思考時間。

通常用戶不會直接給出各業(yè)務(wù)流程的詳細(xì)操作步驟之間的間隔時間，而是給出完成整個業(yè)務(wù)流程操作的大概時間。此時可在錄制腳本時適當(dāng)控制操作的速度，加入合理的思考時間。

本文的電子商務(wù)網(wǎng)站案例客戶直接給出了各業(yè)務(wù)流程的操作時間（即完成整個業(yè)務(wù)流程操作的大概時間）。

3.5 業(yè)務(wù)流程迭代間隔時間分析

迭代間隔時間分析需要確定模擬的用戶每隔多少時間后進(jìn)行下一次業(yè)務(wù)流程操作。迭代間隔時間通常難以由客戶直接給出，因為性能測試中模擬的用戶不一定總是同一個用戶，可能每個時間段都會有新的用戶進(jìn)行該業(yè)務(wù)流程的操作，同時也會有用戶退出該業(yè)務(wù)流程的操作，但性能測試只關(guān)心用戶數(shù)的變化情況，而不會關(guān)心是否仍然為同一個用戶在操作該業(yè)務(wù)流程。

為確定業(yè)務(wù)流程的迭代間隔時間，需要利用用戶提供的相關(guān)數(shù)據(jù)進(jìn)行計算。通常來說可以利用用戶提供的在指定時間段（如一天）的業(yè)務(wù)流程交易總數(shù)計算出業(yè)務(wù)流程的迭代間隔時間。計算公式如下：

業(yè)務(wù)流程迭代間隔時間=（用戶數(shù)*時間段時長/該時間段業(yè)務(wù)流程交易總數(shù)）-業(yè)務(wù)流程操作時間。

下面以計算旺季時“采購商查看”業(yè)務(wù)流程4：00～9：00的業(yè)務(wù)流程迭代間隔時間為例進(jìn)行說明：

該時間段用戶數(shù)為730；

該時間段的時長為：3600s/h*5h=18000s；

假設(shè)該時間段所有采購商進(jìn)行“采購商查看”的總次數(shù)為31285次；

每個用戶完成“采購商查看”業(yè)務(wù)流程的操作時間約為2min（120s）；

因此“采購商查看”業(yè)務(wù)流程的迭代間隔時間為

（730*18000/31285）-120=300s

4 測試模型建立過程

根據(jù)以上性能模型的分析和設(shè)計，筆者選取了采購商登錄、采購商全看2個業(yè)務(wù)流程，按照表1確定了每個業(yè)務(wù)流程的用戶數(shù)，按照3.3節(jié)的結(jié)果明確了用戶數(shù)的加載和卸載方式，按照3.4節(jié)的結(jié)果確定了用戶操作間隔時間，并根據(jù)3.5節(jié)的結(jié)果明確了每個業(yè)務(wù)流程的迭代間隔時間，完成了測試模型的建立。

5 測試結(jié)果

利用為該電子商務(wù)網(wǎng)站設(shè)計的性能測試模型，獲得的性能測試結(jié)果見表2、表3、表4。

表2 各業(yè)務(wù)流程各時間段的事務(wù)平均響應(yīng)時間（單位：秒）

表3 各服務(wù)器各時間段的平均CPU占用率

表4各服務(wù)器各時間段的平均可用內(nèi)存（單位：MB）

從表2的響應(yīng)時間數(shù)據(jù)可以看出，該電子商務(wù)網(wǎng)站的性能非常差，即使是淡季非高峰時間，采購商登錄也需要17.61s，采購選項查看需要84.07s，在旺季高峰時間，采購商登錄需要53.79s，采購選項查看業(yè)務(wù)流程已沒有成功事務(wù)。

從表3的CPU占用率數(shù)據(jù)可以看出，無論淡季還是旺季，無論高峰時間還是非高峰時間，數(shù)據(jù)庫服務(wù)器的CPU占用率均一直在90%以上，說明數(shù)據(jù)庫服務(wù)器的CPU資源已無法滿足業(yè)務(wù)需求。

從表4的可用內(nèi)存數(shù)據(jù)可以看出，應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器和數(shù)據(jù)庫鏡像服務(wù)器的內(nèi)存資源能夠滿足業(yè)務(wù)需求。

6 小結(jié)

本案例具有以下創(chuàng)新點：

1）借助選取的案例和相關(guān)數(shù)據(jù)，通過分析和計算完成了性能測試模型的設(shè)計；

2）測試模型的實測結(jié)果真實反映了選取案例的性能狀況；

3）本文推薦的性能測試模型的分析方法對相關(guān)行業(yè)開展性能測試具有一定的指導(dǎo)和借鑒作用。

7 結(jié)語

軟件性能測試是一種非常專業(yè)的測試，無論是電子商務(wù)網(wǎng)站還是其他行業(yè)的軟件，在執(zhí)行性能測試之前均應(yīng)對性能測試的需求進(jìn)行充分的調(diào)研，并根據(jù)客戶需求設(shè)計一個合理的性能測試模型。當(dāng)客戶無法直接給出性能測試模型設(shè)計需要的數(shù)據(jù)時，可依據(jù)上述案例給出的方法進(jìn)行性能測試模型的設(shè)計，最大程度地保證性能測試結(jié)果的合理性和有效性。

［1］柳純錄，黃子河，陳淥萍.軟件評測師教程［M］.北京：清華大學(xué)出版社，2005：223-343.

LIU Chunlu，HUANG Zihe，CHEN Luping.Tutorial of Software Evaluation and Testing Engineer［M］.Beijing：Ts?inghua University Press，2005：223-343.

［2］石磊.Web應(yīng)用系統(tǒng)性能測試模型研究與應(yīng)用［J］.軟件導(dǎo)刊，2012，11（6）：83-85.

SHI Lei.The Research and Application of Performance Test Model on Web Application System Software Testing［J］.Software Guide，2012，11（6）：83-85.

［3］肖新鳳.Web應(yīng)用程序性能測試技術(shù)的研究及應(yīng)用［J］.科技信息，2010（27）：37-38.

XIAO Xinfeng.Study and Application of the Performance Test on Web Application Program［J］.Information Tech?nology，2010（27）：37-38.

［4］劉巖松.軟件性能測試要點探討［J］.科技風(fēng)，2015（7）：73.

LIU Yansong.Discussion on Key Points of Software Perfor?mance Testing［J］.Technology Wind，2015（7）：73.

［5］胡乃靜，俞新梅，王穎穎.HIS的性能測試設(shè)計與應(yīng)用實現(xiàn)［J］.計算機(jī)工程，2004，30（15）：172-174.

HU Naijing，YU Xinmei，WANG Yingying.Design and Im?plementation of Performance Test on HIS［J］.Computer Engineering，2004，30（15）：172-174.

［6］韓明軍.軟件性能測試過程［J］.信息技術(shù)與標(biāo)準(zhǔn)化，2007（11）：41-43.

HAN Mingjun.Software Performance Testing Process［J］.Information Technology&Standardization，2007（11）：41-43.

［7］佟雪松，王喜偉，于春玲，等.軟件性能測試方法研究［J］.電力信息化，2010，8（1）：96-99.

TONG Xuesong，WANG Xiwei，YU Chunling，et al.Meth?od Research for Software Performance Testing［J］.Electric Power Information Technology，2010，8（1）：96-99.

［8］王軼.山西省互聯(lián)網(wǎng)用戶數(shù)預(yù)測分析［J］.山西科技，2010，25（1）：47-48，56.

WANG Yi.Forecast Research on the Number of Internet Users in Shanxi Province［J］.Shanxi Science and Technol?ogy，2010，25（1）：47-48，56.

［9］林克強(qiáng)，趙秀娟.Loadrunner的并發(fā)用戶數(shù)和集合點分析［J］.無線電通信技術(shù)，2012，38（5）：67-70.

LIN Keqiang，ZHAO Xiujuan.Study on Vuser Number and Rendezvous of Loadrunner［J］.Radio Communica?tions Technology，2012，38（5）：67-70.

［10］王鑫，苗春雨，袁芳.Web應(yīng)用性能評測的研究與應(yīng)用［J］.實驗技術(shù)與管理，2008，25（8）：15-19.

WANG Xin，MIAO Chunyu，YUAN Fang.Research and application of Web-based system performance evaluation［J］.Experimental Technology and Managemen，2008，25（8）：15-19.