精通軟件性能測(cè)試與loadrunner實(shí)戰(zhàn)

最新版LoadRunner性能測(cè)試實(shí)戰(zhàn)內(nèi)容介紹：很多使用LoadRunner的測(cè)試人員經(jīng)常面臨兩個(gè)難題：腳本開發(fā)與性能測(cè)試分析。本書就是基于幫助測(cè)試人員解決這兩個(gè)問題而編寫，致力于使讀者學(xué)精LoadRunnner這一強(qiáng)大的性能測(cè)試工具。

全書共分為四部分：入門篇、基礎(chǔ)篇、探索篇、實(shí)戰(zhàn)篇。第一篇入門篇的內(nèi)容包括第1章和第2章，著重于講解性能測(cè)試與LoadRunner的基礎(chǔ)理論知識(shí)。第二篇基礎(chǔ)篇的內(nèi)容包括第3章至第5章，是LoadRunner的基本使用部分，著重講解VirtualUserGenerator、Controller、Analysis的使用方法。第三篇探索篇的...第1部分

入門篇1第1章

性能測(cè)試基礎(chǔ)知識(shí)..31.1

性能測(cè)試基本概念...41.1.1

什么是性能測(cè)試...41.1.2

性能測(cè)試應(yīng)用領(lǐng)域...61.1.3

性能測(cè)試常見術(shù)語(yǔ)...81.2

全面性能測(cè)試模型...111.2.1

性能測(cè)試策略模型...141.2.2

性能測(cè)試用例模型...171.2.3

模型的使用方法...201.3

性能測(cè)試調(diào)整基礎(chǔ)...211.4

如何做好性能測(cè)試...241.5

本章小結(jié)...28第2章

LoadRunner基礎(chǔ)知識(shí)..292.1

LoadRunner簡(jiǎn)介...292.1.1

LoadRunner主要特點(diǎn)...292.1.2

LoadRunner常用術(shù)語(yǔ)...312.2

LoadRunner工作原理...322.3

LoadRunner測(cè)試流程...332.4

LoadRunner的部署與安裝...352.5

本章小結(jié)...41第2部分

基礎(chǔ)篇43第3章

腳本的錄制與開發(fā)..453.1

VirtualUserGenerator簡(jiǎn)介...453.1.1

VuGen錄制原理...463.1.2

VuGen功能簡(jiǎn)介...483.1.3

如何選擇協(xié)議...493.2

VuGen錄制功能詳解...503.2.1

錄制參數(shù)設(shè)置...503.2.2

腳本錄制與創(chuàng)建事務(wù)...573.2.3

回放與調(diào)試腳本...613.2.4

腳本錄制的基本原則...633.3

修改虛擬用戶腳本...643.3.1

參數(shù)化功能...643.3.2

深入集合點(diǎn)...713.3.3

巧用檢查點(diǎn)...723.3.4

關(guān)聯(lián)...783.4

配置虛擬用戶腳本...803.5

兩個(gè)常用函數(shù)介紹...843.6

本章小結(jié)...86第4章

場(chǎng)景的創(chuàng)建與執(zhí)行..874.1

Controller簡(jiǎn)介...874.2

場(chǎng)景類型介紹...884.2.1

手動(dòng)測(cè)試場(chǎng)景...884.2.2

面向目標(biāo)的測(cè)試場(chǎng)景...904.3

測(cè)試場(chǎng)景設(shè)計(jì)...934.3.1

配置測(cè)試腳本...934.3.2

配置Generator944.3.3

配置Schedule.954.3.4

集合點(diǎn)配置...994.3.5

IPSpoofer配置...1004.3.6

其他設(shè)置場(chǎng)景...1064.4

執(zhí)行測(cè)試場(chǎng)景...1084.4.1

啟動(dòng)測(cè)試場(chǎng)景...1084.4.2

控制用戶與用戶組...1084.4.3

查看場(chǎng)景與用戶狀態(tài)...1094.4.4

控制集合點(diǎn)...1104.4.5

查看運(yùn)行數(shù)據(jù)圖...1104.5

監(jiān)控系統(tǒng)資源...1114.5.1

監(jiān)控Windows系統(tǒng)資源...1124.5.2

監(jiān)控Linux/Unix系統(tǒng)資源...1144.6

本章小結(jié)...121第5章

性能測(cè)試結(jié)果分析..1235.1

如何分析性能測(cè)試結(jié)果...1245.1.1

性能分析基礎(chǔ)知識(shí)...1255.1.2

Analysis使用基礎(chǔ)...1275.1.3

一個(gè)視頻網(wǎng)站例子...1355.2

如何從分析圖中發(fā)現(xiàn)問題...1485.2.1

虛擬用戶圖...1485.2.2

事務(wù)圖...1515.2.3

Web資源圖...1605.2.4

網(wǎng)頁(yè)細(xì)分圖...1665.2.5

小結(jié)...1795.3

分析圖的處理方法...1795.3.1

修改默認(rèn)配置...1805.3.2

合并分析圖...1875.3.3

自動(dòng)關(guān)聯(lián)...1885.3.4

場(chǎng)景運(yùn)行比較...1915.4

Analysis分析報(bào)告...1935.4.1

事務(wù)活動(dòng)報(bào)告（ActivityReports）...1935.4.2

事務(wù)性能報(bào)告（PerformanceReports）...1965.4.3

HTML與Word報(bào)告...1995.5

本章小結(jié)...206第3部分

探索篇209第6章

用VisualC++增強(qiáng)虛擬用戶..2116.1

認(rèn)識(shí)LoadRunner動(dòng)態(tài)鏈接庫(kù)的調(diào)用功能...2116.1.1

動(dòng)態(tài)鏈接庫(kù)調(diào)用功能簡(jiǎn)介...2116.1.2

動(dòng)態(tài)鏈接庫(kù)調(diào)用功能適用范圍...2126.2

創(chuàng)建與調(diào)用動(dòng)態(tài)鏈接庫(kù)...2126.2.1

用VisualC++創(chuàng)建Dll2126.2.2

Dll調(diào)用方法...2156.2.3

載入頭文件方法...2176.2.4

Dll調(diào)用需注意的問題...2206.3

UDP發(fā)包應(yīng)用案例...2226.3.1

測(cè)試內(nèi)容簡(jiǎn)介...2226.3.2

測(cè)試程序設(shè)計(jì)...2226.3.3

虛擬用戶腳本...2236.3.4

測(cè)試場(chǎng)景設(shè)置...2246.3.5

測(cè)試結(jié)果分析...2256.4

本章小結(jié)...226第7章

深入Java虛擬用戶..2277.1

認(rèn)識(shí)Java虛擬用戶...2277.1.1

Java虛擬用戶協(xié)議...2277.1.2

Java虛擬用戶適用范圍...2307.1.3

腳本開發(fā)環(huán)境配置...2317.2

Java腳本開發(fā)基礎(chǔ)...2347.2.1

Java虛擬用戶開發(fā)基礎(chǔ)...2347.2.2

LoadRunner的JavaAPI.2437.3

Java算法測(cè)試案例...2457.4

本章小結(jié)...260第8章

深入.NET虛擬用戶..2618.1

認(rèn)識(shí).NET虛擬用戶...2618.1.1

.NET虛擬用戶適用范圍...2618.1.2

安裝與配置.NET插件...2628.2

創(chuàng)建.NET虛擬用戶...2648.2.1

創(chuàng)建虛擬用戶項(xiàng)目...2648.2.2

參數(shù)、集合點(diǎn)、事務(wù)...2668.3

網(wǎng)站視頻性能測(cè)試應(yīng)用案例...2718.3.1

創(chuàng)建自定義的播放器類...2728.3.2

創(chuàng)建抽象虛擬用戶類...2768.3.3

創(chuàng)建抽象并發(fā)測(cè)試類...2828.3.4

創(chuàng)建自定義虛擬用戶腳本...2848.3.5

創(chuàng)建LoadRunner.NET虛擬用戶...2878.3.6

案例總結(jié)...2908.4

本章小結(jié)...290第9章

LoadRunner特殊協(xié)議應(yīng)用..2919.1

WindowsSockets協(xié)議應(yīng)用...2919.1.1

錄制WindowsSockets協(xié)議腳本...2929.1.2

增強(qiáng)WindowsSockets協(xié)議腳本...2949.2

WAP協(xié)議應(yīng)用...2989.3

WebServices協(xié)議應(yīng)用...3029.3.1

WebServices協(xié)議簡(jiǎn)介...3029.3.2

錄制WebServices協(xié)議腳本...3039.4

FTP協(xié)議應(yīng)用...3129.5

本章小結(jié)...317第4部分

實(shí)戰(zhàn)篇319第10章

電子商務(wù)平臺(tái)測(cè)試案例..32110.1

GBE測(cè)試項(xiàng)目簡(jiǎn)介...32110.1.1

項(xiàng)目背景信息...32110.1.2

系統(tǒng)功能簡(jiǎn)介...32210.1.3

項(xiàng)目測(cè)試計(jì)劃...32310.2

性能測(cè)試規(guī)劃與設(shè)計(jì)...32310.2.1

性能測(cè)試的種類、范圍、目標(biāo)...32410.2.2

人力資源、進(jìn)度安排...32510.2.3

測(cè)試環(huán)境需求...32510.2.4

選擇測(cè)試工具...32710.2.5

用戶場(chǎng)景分析與設(shè)計(jì)...32810.2.6

性能測(cè)試計(jì)劃...33310.2.7

測(cè)試用例設(shè)計(jì)...33410.2.8

其他事項(xiàng)...34110.3

性能測(cè)試準(zhǔn)備...34110.3.1

測(cè)試環(huán)境...34110.3.2

系統(tǒng)使用培訓(xùn)...34210.3.3

測(cè)試數(shù)據(jù)...34310.3.4

虛擬用戶腳本...34610.4

測(cè)試的實(shí)施與控制...34910.4.1

設(shè)計(jì)測(cè)試用例場(chǎng)景...34910.4.2

執(zhí)行測(cè)試用例場(chǎng)景...35110.4.3

進(jìn)度與變更控制...35910.5

測(cè)試結(jié)論與建議...36010.5.1

測(cè)試結(jié)果綜述36010.5.2

系統(tǒng)性能優(yōu)化建議36110.5.3

風(fēng)險(xiǎn)分析...36210.6

本章小結(jié)...362附錄A

LoadRunner性能測(cè)試常見問題..365附錄B

LoadRunner性能測(cè)試模板..373B.1

性能測(cè)試計(jì)劃模板...373B.1.1項(xiàng)目背景簡(jiǎn)介...373B.1.2測(cè)試方案簡(jiǎn)介...373B.1.3測(cè)試環(huán)境與資源...373B.1.4項(xiàng)目里程碑...374B.1.5技能培訓(xùn)計(jì)劃...374B.1.6風(fēng)險(xiǎn)分析...374B.1.7計(jì)劃結(jié)束標(biāo)準(zhǔn)...374B.2

性能測(cè)試用例模板...374B.2.1文檔介紹...374B.2.2

測(cè)試需求分析...375B.2.3性能測(cè)試用例...375B.3

性能測(cè)試報(bào)告模板...380B.3.1基本信息...380B.3.2測(cè)試環(huán)境描述...381B.3.3性能測(cè)試用例執(zhí)行分析...381B.3.4測(cè)試結(jié)果綜合分析及建議...381B.3.5測(cè)試經(jīng)驗(yàn)總結(jié)...381后

記..383前言

在作者的另一作品《Web性能測(cè)試實(shí)戰(zhàn)》中，曾經(jīng)提到過“軟件亞健康”這個(gè)概念?，F(xiàn)在，亞健康不但威脅著IT人的生活質(zhì)量，也威脅很多應(yīng)用軟件的性能。為此，在《Web性能測(cè)試實(shí)戰(zhàn)》一書中，作者提出了“全面性能測(cè)試模型”，期望能夠成為解決軟件亞健康問題的一劑“良藥”?！叭嫘阅軠y(cè)試模型”包含了測(cè)試策略制定、測(cè)試用例設(shè)計(jì)、模型使用方法三部分內(nèi)容，基本覆蓋了性能測(cè)試規(guī)劃和設(shè)計(jì)的相關(guān)內(nèi)容，為開展性能測(cè)試提供了一種可行的方案。借助本模型，軟件開發(fā)和測(cè)試人員可以更好的組織與規(guī)劃性能測(cè)試，避免在項(xiàng)目后期遭遇性能問題的被動(dòng)局面。不過要想做好性能測(cè)試，僅有性能測(cè)試模型還是遠(yuǎn)遠(yuǎn)不夠的，因?yàn)檫€缺少像LoadRunner這樣令性能測(cè)試工作如虎添翼的性能測(cè)試?yán)?。本書將和讀者一起深入LoadRunner的性能測(cè)試世界，探討在企業(yè)的性能測(cè)試項(xiàng)目中如何應(yīng)用它來(lái)發(fā)現(xiàn)應(yīng)用系統(tǒng)存在的性能問題。LoadRunner在性能測(cè)試中的地位對(duì)于很多使用LoadRunner的測(cè)試人員而言，性能測(cè)試工作中最大的障礙就是測(cè)試腳本開發(fā)與測(cè)試結(jié)果分析，這導(dǎo)致很多測(cè)試人員忽略了測(cè)試規(guī)劃與設(shè)計(jì)的重要性，反而認(rèn)為能開發(fā)測(cè)試腳本、運(yùn)行測(cè)試場(chǎng)景、分析測(cè)試結(jié)果就算做好性能測(cè)試了。要想做好性能測(cè)試，首先應(yīng)該把重心放在測(cè)試的規(guī)劃與設(shè)計(jì)上，尤其要注重測(cè)試用例的設(shè)計(jì)，僅僅能寫測(cè)試程序與運(yùn)行測(cè)試腳本是遠(yuǎn)遠(yuǎn)不夠的。諸如LoadRunner等測(cè)試工具僅僅是性能測(cè)試的執(zhí)行與分析工具，它們應(yīng)該服從于測(cè)試設(shè)計(jì)人員的意志。測(cè)試工具的使用屬于測(cè)試人員的基本功，應(yīng)該在開展性能測(cè)試工作前修煉好。只有好的測(cè)試用例或者測(cè)試場(chǎng)景才能發(fā)現(xiàn)系統(tǒng)的問題，這才是性能測(cè)試的本質(zhì)所在。性能測(cè)試分析同樣依賴于前面工作的輸出結(jié)果，不是隨便一個(gè)測(cè)試結(jié)果就能發(fā)現(xiàn)問題的。所謂“萬(wàn)丈高樓平地起”，性能分析的準(zhǔn)確性同樣取決于此前所做的設(shè)計(jì)與實(shí)施等“地基”是否可靠。可以說，性能測(cè)試分析僅僅是百米賽跑的最后二十米而已。當(dāng)然，這并不是說性能測(cè)試分析不重要，因?yàn)椤白詈鬀_刺的二十米沒有跑好”，前面工作做的再好也是徒勞的。因此不難理解，性能測(cè)試分析工作開展的根基就是前面測(cè)試場(chǎng)景執(zhí)行的結(jié)果。要想保證性能測(cè)試分析的結(jié)論是正確的，則測(cè)試結(jié)果數(shù)據(jù)首先就應(yīng)該是正確的，而這也意味著測(cè)試場(chǎng)景以及測(cè)試執(zhí)行過程都應(yīng)該是正確的。實(shí)際上，性能測(cè)試從始至終都應(yīng)該是相當(dāng)嚴(yán)謹(jǐn)?shù)囊豁?xiàng)工程，各個(gè)階段的工作環(huán)環(huán)相扣，性能測(cè)試工程師應(yīng)該認(rèn)真對(duì)待各個(gè)階段的工作。如果一味地追求找出系統(tǒng)瓶頸，無(wú)疑是舍本逐末的做法。因此，在性能測(cè)試工作中首先要做好性能測(cè)試的規(guī)劃與設(shè)計(jì)工作，然后再借助LoadRunner的強(qiáng)大功能來(lái)發(fā)現(xiàn)系統(tǒng)存在的問題。如何通過本書學(xué)習(xí)LoadRunner首先應(yīng)該弄清楚學(xué)習(xí)LoadRunner的目的，那就是在項(xiàng)目的性能測(cè)試中應(yīng)用LoadRunner來(lái)發(fā)現(xiàn)系統(tǒng)的性能問題。因此，僅僅會(huì)用LoadRunner還遠(yuǎn)遠(yuǎn)不夠，這也是為什么很多培訓(xùn)班出來(lái)的學(xué)員雖然把工具用的非常熟練，但是仍然不能做好性能測(cè)試工作。學(xué)好LoadRunner的標(biāo)準(zhǔn)是真正能夠把LoadRunner應(yīng)用到實(shí)際項(xiàng)目中去，這就要求學(xué)習(xí)LoadRunner的同時(shí)一定要學(xué)好性能測(cè)試相關(guān)知識(shí)。本書的第1章即為基本的性能測(cè)試知識(shí)，讀者需要認(rèn)真體會(huì)這些內(nèi)容，建議在學(xué)習(xí)后面的內(nèi)容時(shí)，經(jīng)常翻閱本章的內(nèi)容。如果要學(xué)習(xí)更多的性能測(cè)試規(guī)劃與設(shè)計(jì)的知識(shí)以及性能測(cè)試案例，建議讀者參考本書的姊妹篇《Web性能測(cè)試實(shí)戰(zhàn)》。本書的第2章是LoadRunner的簡(jiǎn)介部分，讀者需要通過本章了解LoadRunner的工作原理、測(cè)試流程、部署與安裝等內(nèi)容，尤其要掌握?qǐng)D2-1所示的LoadRunner工作原理，這是用LoadRunner開展工作的基礎(chǔ)。本書的第3章、第4章、第5章分別講解了LoadRunner的VirtualUserGenerator、Controller、Analysis。這三大組件分別負(fù)責(zé)腳本的錄制與開發(fā)、場(chǎng)景的創(chuàng)建與執(zhí)行、測(cè)試結(jié)果分析工作。用LoadRunner來(lái)開展性能測(cè)試，必須要掌握這三大組件的使用。如果連基本的工具都沒有用好，很難正確地執(zhí)行設(shè)計(jì)好的測(cè)試用例，更不用說根據(jù)結(jié)果來(lái)分析系統(tǒng)的瓶頸了。在第3～5章中，詳細(xì)探討了LoadRunner各個(gè)組件的使用細(xì)節(jié)，但是這還遠(yuǎn)遠(yuǎn)不夠，尤其對(duì)于那些只會(huì)錄制或者簡(jiǎn)單修改錄制結(jié)果的測(cè)試人員！學(xué)習(xí)這三章的內(nèi)容時(shí)，最好的方法是結(jié)合LoadRunner的聯(lián)機(jī)幫助文檔，這樣可以學(xué)習(xí)到更多的內(nèi)容。學(xué)習(xí)完第3～5章后，可能還有一些讀者會(huì)問：“我還是不會(huì)自己寫測(cè)試腳本，很多協(xié)議仍然不能進(jìn)行測(cè)試怎么辦？”碰到這種情況就需要補(bǔ)習(xí)自己的開發(fā)知識(shí)了。開發(fā)知識(shí)應(yīng)該分兩個(gè)方面來(lái)學(xué)習(xí)：一是面向?qū)ο蠡A(chǔ)知識(shí)的學(xué)習(xí)，二是開發(fā)語(yǔ)言的學(xué)習(xí)。很多人可能會(huì)認(rèn)為面向?qū)ο蠡A(chǔ)知識(shí)比較通用，相對(duì)容易學(xué)習(xí)；而開發(fā)語(yǔ)言種類繁多，不知道如何入手。根據(jù)作者的經(jīng)驗(yàn)，這兩個(gè)方面應(yīng)該結(jié)合起來(lái)進(jìn)行：面向?qū)ο笫乾F(xiàn)在主流開發(fā)語(yǔ)言的靈魂，一起學(xué)習(xí)可以互相促進(jìn)。具體做法就是選擇C++、Java、C#等一種主流語(yǔ)言來(lái)學(xué)習(xí)，只要這門語(yǔ)言是自己所在公司的主流語(yǔ)言即可。當(dāng)學(xué)會(huì)面向?qū)ο蠡A(chǔ)和一門語(yǔ)言后，再去學(xué)習(xí)其它的語(yǔ)言將會(huì)非常容易。具有一定的開發(fā)能力后，就可以開始本書探索篇第6～9章的學(xué)習(xí)。這四章是LoadRunner的探索篇，講解了在LoadRunner中如何應(yīng)用C++、Java、C#語(yǔ)言進(jìn)行開發(fā)以及一些特殊的腳本協(xié)議。相信通過前面9章的學(xué)習(xí)，讀者已經(jīng)掌握LoadRunner的精髓了。不過本書不是一本“LoadRunner使用百科大全”，接下來(lái)就需要讀者自己不斷地應(yīng)用與探索LoadRunner了，逐步完成成為一個(gè)LoadRunner高手的蛻變過程。如何學(xué)習(xí)本書的性能測(cè)試案例本書在第10章中，花了很大的篇幅介紹了一個(gè)電子商務(wù)平臺(tái)的性能測(cè)試案例，目的不是為了介紹如何測(cè)試電子商務(wù)系統(tǒng)，而是讓讀者在掌握前面技能的基礎(chǔ)上，更加深入地體會(huì)在項(xiàng)目中如何通過LoadRunner來(lái)實(shí)施性能測(cè)試。因此，案例的業(yè)務(wù)并不重要，讀者也沒有必要深究具體的細(xì)節(jié)。通過本案例，能清晰地了解了能測(cè)試的整個(gè)過程就已經(jīng)達(dá)到了目的。本書案例的學(xué)習(xí)重點(diǎn)在以下幾個(gè)方面：l

借助案例體會(huì)“全面性能測(cè)試模型”在GBE項(xiàng)目中的應(yīng)用；l

學(xué)習(xí)性能測(cè)試規(guī)劃與設(shè)計(jì)中的需求分析過程，例如測(cè)試環(huán)境需求、人力資源；l

學(xué)習(xí)性能測(cè)試規(guī)劃與設(shè)計(jì)中的測(cè)試場(chǎng)景分析與設(shè)計(jì)、測(cè)試用例設(shè)計(jì)；l

學(xué)習(xí)如何做好性能測(cè)試實(shí)施前的準(zhǔn)備工作；l

測(cè)試執(zhí)行過程的進(jìn)度與變更控制；l

一些分析性能問題的過程。關(guān)于性能測(cè)試案例更多的內(nèi)容，讀者可以閱讀《Web性能測(cè)試實(shí)戰(zhàn)》中的案例部分。關(guān)于本書本書的主旨在于讓讀者學(xué)會(huì)LoadRunner的應(yīng)用，并能在此基礎(chǔ)上自行探索性能測(cè)試世界。本書共分為四部分：入門篇、基礎(chǔ)篇、探索篇、實(shí)戰(zhàn)篇。第一部分：入門篇，包括第1章和第2章，著重于講解性能測(cè)試與LoadRunner的基礎(chǔ)理論知識(shí)。在第1章中，講解了性能測(cè)試基本概念、全面性能測(cè)試模型、性能測(cè)試調(diào)整等基礎(chǔ)的性能測(cè)試?yán)碚撝R(shí)；第2章則介紹了LoadRunner的特點(diǎn)與術(shù)語(yǔ)、工作原理、測(cè)試流程、部署與安裝等內(nèi)容。第二部分：基礎(chǔ)篇，包括第3章至第5章，著重講解LoadRunner三大組件的使用，是LoadRunner的基本使用部分。在第3章中，主要講解如何在VirtualUserGenerator中完成代碼的錄制與開發(fā)；第4章講解如何在Controller中創(chuàng)建與執(zhí)行場(chǎng)景；第5章中講解如何結(jié)合Analysis來(lái)分析性能測(cè)試結(jié)果。第三部分：探索篇，包括第6章至第9章，著重講解LoadRunner的高級(jí)應(yīng)用。第6章講解如何用VisualC++來(lái)增強(qiáng)虛擬用戶；第7章深入探索了Java虛擬用戶；第8章深入探索了.NET虛擬用戶；第9章則講解了Socket虛擬用戶的相關(guān)知識(shí)。第四部分：實(shí)戰(zhàn)篇，即第10章，結(jié)合案例來(lái)講解在具體項(xiàng)目中如何應(yīng)用LoadRunner來(lái)完成性能測(cè)試工作。在第10章中，通過真實(shí)的性能測(cè)試實(shí)例，向讀者展示了如何在項(xiàng)目中完成性能測(cè)試的整體規(guī)劃與設(shè)計(jì)、測(cè)試的準(zhǔn)備與實(shí)施、測(cè)試結(jié)果分析等工作。致謝感謝廣大讀者對(duì)《Web性能測(cè)試實(shí)戰(zhàn)》一書的支持，讀者的支持是作者寫作的真正動(dòng)力。正是一年來(lái)因?yàn)榇蠹覍?duì)《Web性能測(cè)試實(shí)戰(zhàn)》的肯定才促使我完成本書的寫作工作；感謝博文視點(diǎn)周筠老師對(duì)本書的支持，周老師對(duì)我這個(gè)新人一直給予很大的鼓勵(lì)；感謝電子工業(yè)出版社博文視點(diǎn)資訊有限公司的陳元玉編輯，她是本書的責(zé)任編輯；感謝師兄王玉亭，他再次為本書提供了很多素材；感謝同事關(guān)曉培、周雪松、李熠，他們?yōu)楸緯峁┝撕芏嗨夭模桓兄x電子工業(yè)出版社為本書辛勤付出的所有朋友們；特別感謝夫人小姬，她通篇審校了本書并潤(rùn)色了那些難于理解的句子，特別是她對(duì)我在公司的日常工作和編寫工作的支持，因?yàn)楸緯紦?jù)了大量可以陪她的時(shí)間；最后要感謝自己的父母和老師，能寫出本書是父母和老師多年教育的結(jié)果。軟件在性能方面的“亞健康”問題一直伴隨著國(guó)內(nèi)很多企業(yè)的軟件產(chǎn)品而存在。早期由于多數(shù)軟件應(yīng)用系統(tǒng)在企業(yè)中得不到有效的推廣應(yīng)用，因此用戶往往會(huì)忽略自己在性能方面的需求。而現(xiàn)在軟件幾乎滲透到人們工作與生活的各個(gè)方面，因而軟件的性能開始得到越來(lái)越多的重視。隨著軟件工程技術(shù)、軟件開發(fā)方法和軟件開發(fā)工具的發(fā)展，一方面使人們可以快速開發(fā)更加復(fù)雜的應(yīng)用，另一方面也使開發(fā)出的軟件規(guī)模越來(lái)越龐大，架構(gòu)越來(lái)越復(fù)雜。隨之而來(lái)的是軟件性能問題也越來(lái)越多，最終導(dǎo)致很多軟件系統(tǒng)由于性能方面存在問題而停止使用，給軟件公司以及客戶都帶來(lái)了一定的損失。因此，解決軟件性能問題是十分必要的一項(xiàng)工作中，對(duì)于企業(yè)自身以及客戶都具有重要的現(xiàn)實(shí)意義。在紹英的上一本著作《Web性能測(cè)試實(shí)戰(zhàn)》中，為接近軟件性能問題提出了“全面性能測(cè)試模型”，以期成為解決軟件亞健康問題的一劑良藥?！叭嫘阅軠y(cè)試模型”包含了性能測(cè)試策略制定、測(cè)試用例設(shè)計(jì)、模型使用方法三部分內(nèi)容，覆蓋了性能測(cè)試規(guī)劃和設(shè)計(jì)的相關(guān)內(nèi)容，為開展性能測(cè)試工作提供了一種可行的方案。但是僅有理論是不夠的，對(duì)于性能測(cè)試工作而言，不但需要好的性能測(cè)試?yán)碚撟鳛楣ぷ髦笇?dǎo)，更需要掌握好的性能測(cè)試工具，因此本書的幾位作者共同創(chuàng)作了《LoadRunner性能測(cè)試實(shí)戰(zhàn)》一書。LoadRunner是目前國(guó)內(nèi)性能測(cè)試領(lǐng)域應(yīng)用最廣泛的工具之一，它可以通過模擬成千上萬(wàn)的用戶，很快地幫助用戶確認(rèn)和查找性能問題。但是國(guó)內(nèi)圖書市場(chǎng)上卻沒有任何相關(guān)書籍，《LoadRunner性能測(cè)試實(shí)戰(zhàn)》填補(bǔ)了這個(gè)空白?！禠oadRunner性能測(cè)試實(shí)戰(zhàn)》是非常注重實(shí)際應(yīng)用的作品。書中詳細(xì)描述了LoadRunner在性能測(cè)試領(lǐng)域諸多方面的應(yīng)用，并結(jié)合具體的案例來(lái)說明如何應(yīng)用《Web性能測(cè)試實(shí)戰(zhàn)》一書中提到的“全面性能測(cè)試模型”。強(qiáng)大的性能測(cè)試工具加上合理的理論來(lái)指導(dǎo)，將為讀者打開很多新的思路。本書是由三位作者共同完成的。紹英有流媒體、P2P、電子政務(wù)、銀行、門戶網(wǎng)站等領(lǐng)域應(yīng)用軟件的性能測(cè)試經(jīng)驗(yàn)，在LoadRunner方面更有五年以上的使用經(jīng)驗(yàn)。他曾到很多公司去推廣自己的性能測(cè)試模型以及講解LoadRunner課程，對(duì)企業(yè)在軟件測(cè)試方面的需求非常熟悉；建華是在讀研究生，因此有充裕的時(shí)間來(lái)研究LoadRunner的特殊應(yīng)用；小姬在性能測(cè)試方面也有著豐富的經(jīng)驗(yàn)。相信他們的這些實(shí)踐經(jīng)驗(yàn)是很多測(cè)試人員急需的。本書對(duì)國(guó)內(nèi)軟件企業(yè)提高性能測(cè)試水平是很有價(jià)值的。我很高興能為這本實(shí)戰(zhàn)性非常強(qiáng)的作品做序，預(yù)祝《LoadRunner性能測(cè)試實(shí)戰(zhàn)》早日出版。也希望國(guó)內(nèi)有更多的人來(lái)關(guān)注軟件性能測(cè)試，探討解決軟件亞健康問題的方法！北京大學(xué)軟件與微電子學(xué)院副教授北京市軟件促進(jìn)中心專家顧問

黎怡蘭(MelodyLe)性能測(cè)試基本概念

在一些軟件項(xiàng)目中，項(xiàng)目經(jīng)理或測(cè)試經(jīng)理經(jīng)常會(huì)安排測(cè)試工程師進(jìn)行下面的工作：l

用LoadRunner測(cè)試系統(tǒng)的最大并發(fā)用戶數(shù)。l

用LoadRunner測(cè)試系統(tǒng)8小時(shí)的最大業(yè)務(wù)吞吐量。l

用LoadRunner測(cè)試系統(tǒng)的穩(wěn)定性與健壯性。l

用LoadRunner測(cè)試系統(tǒng)在數(shù)據(jù)達(dá)到100萬(wàn)條記錄時(shí)的性能。l

用LoadRunner測(cè)試核心事務(wù)響應(yīng)時(shí)間是否滿足用戶的需求。可以說，現(xiàn)在很多IT企業(yè)的性能測(cè)試工作已經(jīng)離不開LoadRunner了。不過，盡管使用了LoadRunner這一強(qiáng)大的工具，很多企業(yè)軟件產(chǎn)品遇到的性能問題仍未能解決——因?yàn)閮H有好的測(cè)試工具是不夠的。除了比較實(shí)用的測(cè)試工具外，要想做好性能測(cè)試還應(yīng)該掌握相關(guān)的理論知識(shí)。只有以堅(jiān)實(shí)的理論作為實(shí)際工作的依托，才能讓測(cè)試工具發(fā)揮出應(yīng)有的功效。本章將介紹一些性能測(cè)試的基礎(chǔ)知識(shí)，主要內(nèi)容如下：n

性能測(cè)試基本概念n

全面性能測(cè)試模型n

性能測(cè)試調(diào)整基礎(chǔ)n

如何做好性能測(cè)試

提示：關(guān)于性能測(cè)試?yán)碚摰母鄡?nèi)容，可以參考作者性能測(cè)試方面的專著《Web性能測(cè)試實(shí)戰(zhàn)》，電子工業(yè)出版社，2006年5月出版。1.1

性能測(cè)試基本概念在軟件系統(tǒng)日益復(fù)雜的今天，性能已經(jīng)成為軟件質(zhì)量重要的衡量標(biāo)準(zhǔn)之一，這一點(diǎn)尤其體現(xiàn)在和Web相關(guān)的系統(tǒng)上。軟件幾乎無(wú)處不在，在給用戶帶來(lái)方便的同時(shí)，也對(duì)開發(fā)人員和測(cè)試人員提出了更高的要求。性能測(cè)試不但要求測(cè)試人員具備很強(qiáng)的技術(shù)能力，還要具備綜合分析問題的能力。本節(jié)從性能測(cè)試的概念入手，強(qiáng)化性能測(cè)試的基礎(chǔ)知識(shí)。1.1.1

什么是性能測(cè)試目前很少能見到性能測(cè)試的準(zhǔn)確定義，但是性能測(cè)試又似乎是涉及范圍非常廣泛的測(cè)試。壓力測(cè)試、負(fù)載測(cè)試、強(qiáng)度測(cè)試、穩(wěn)定性測(cè)試、健壯性測(cè)試、大數(shù)據(jù)量測(cè)試……都和性能測(cè)試有著密切的關(guān)系。在本書中，主要從狹義和廣義兩方面來(lái)討論性能測(cè)試。狹義的性能測(cè)試主要用于描述常規(guī)的性能測(cè)試，是指通過模擬生產(chǎn)運(yùn)行的業(yè)務(wù)壓力或用戶使用場(chǎng)景來(lái)測(cè)試系統(tǒng)的性能是否滿足生產(chǎn)性能的要求。例如，以實(shí)際投產(chǎn)環(huán)境進(jìn)行測(cè)試，來(lái)求出最大的吞吐量與最佳響應(yīng)時(shí)間，以保證上線的平穩(wěn)、安全等。性能測(cè)試是一種“正?！钡臏y(cè)試，主要測(cè)試正常使用時(shí)系統(tǒng)是否滿足要求，同時(shí)可能為了保留系統(tǒng)的擴(kuò)展空間而進(jìn)行的一些稍稍超出“正?！狈秶臏y(cè)試。廣義的性能測(cè)試則是壓力測(cè)試、負(fù)載測(cè)試、強(qiáng)度測(cè)試、并發(fā)（用戶）測(cè)試、大數(shù)據(jù)量測(cè)試、配置測(cè)試、可靠性測(cè)試等和性能相關(guān)的測(cè)試統(tǒng)稱。下面分別介紹各類測(cè)試的主要內(nèi)容和特點(diǎn)。壓力測(cè)試對(duì)系統(tǒng)不斷施加壓力的測(cè)試，是通過確定一個(gè)系統(tǒng)的瓶頸或不能接收用戶請(qǐng)求的性能點(diǎn)，來(lái)獲得系統(tǒng)能提供的最大服務(wù)級(jí)別的測(cè)試。例如測(cè)試一個(gè)Web站點(diǎn)在大量的負(fù)荷下，系統(tǒng)的事務(wù)響應(yīng)時(shí)間何時(shí)會(huì)變得不可接受或事務(wù)不能正常執(zhí)行。壓力測(cè)試的目的是發(fā)現(xiàn)在什么條件下系統(tǒng)的性能變得不可接受，并通過對(duì)應(yīng)用程序施加越來(lái)越大的負(fù)載，直到發(fā)現(xiàn)應(yīng)用程序性能下降的拐點(diǎn)。壓力測(cè)試和負(fù)載測(cè)試有些類似，但是通常把負(fù)載測(cè)試描述成一種特定類型的壓力測(cè)試——例如增加用戶數(shù)量或延長(zhǎng)壓力時(shí)間以對(duì)應(yīng)用程序進(jìn)行壓力測(cè)試。負(fù)載測(cè)試對(duì)系統(tǒng)不斷地增加壓力或增加一定壓力下的持續(xù)時(shí)間，直到系統(tǒng)的一些性能指標(biāo)達(dá)到極限，例如響應(yīng)時(shí)間超過預(yù)定指標(biāo)或某種資源已經(jīng)達(dá)到飽和狀態(tài)。這種測(cè)試可以找到系統(tǒng)的處理極限，為系統(tǒng)調(diào)優(yōu)提供依據(jù)。壓力測(cè)試側(cè)重壓力大小，而負(fù)載測(cè)試往往強(qiáng)調(diào)壓力持續(xù)的時(shí)間。在實(shí)際工作中，沒有必要嚴(yán)格區(qū)分這兩個(gè)概念，有關(guān)內(nèi)容可以參見后面1.2節(jié)的“全面性能測(cè)試模型”。強(qiáng)度測(cè)試強(qiáng)度測(cè)試主要是為了檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力。強(qiáng)度測(cè)試總是迫使系統(tǒng)在異常的資源配置下運(yùn)行。例如：l

當(dāng)正常的用戶點(diǎn)擊率為“1000次/秒”時(shí)，運(yùn)行點(diǎn)擊率為“2000次/秒”的測(cè)試用例；l

運(yùn)行需要最大存儲(chǔ)空間（或其他資源）的測(cè)試用例；l

運(yùn)行可能導(dǎo)致操作系統(tǒng)崩潰或磁盤數(shù)據(jù)劇烈抖動(dòng)的測(cè)試用例，等等。強(qiáng)度測(cè)試是一種特別重要的測(cè)試，對(duì)測(cè)試系統(tǒng)的穩(wěn)定性，以及系統(tǒng)未來(lái)的擴(kuò)展空間均具有重要的意義。在這種異常條件下進(jìn)行的測(cè)試，更容易發(fā)現(xiàn)系統(tǒng)是否穩(wěn)定以及性能方面是否容易擴(kuò)展。疲勞強(qiáng)度測(cè)試是一類特殊的強(qiáng)度測(cè)試，主要測(cè)試系統(tǒng)長(zhǎng)時(shí)間運(yùn)行后的性能表現(xiàn)，例如7×24小時(shí)的壓力測(cè)試。并發(fā)（用戶）測(cè)試主要指當(dāng)測(cè)試多個(gè)用戶并同時(shí)訪問同一個(gè)應(yīng)用程序、同一個(gè)模塊或數(shù)據(jù)記錄時(shí)是否存在死鎖或其他性能問題，幾乎所有的性能測(cè)試都會(huì)涉及并發(fā)測(cè)試。在具體的性能測(cè)試工作中，并發(fā)用戶往往都是借助工具來(lái)進(jìn)行模擬的，LoadRunner中稱之為并發(fā)虛擬用戶。大數(shù)據(jù)量測(cè)試大數(shù)據(jù)量測(cè)試分為兩種：一種是針對(duì)某些系統(tǒng)存儲(chǔ)、傳輸、統(tǒng)計(jì)查詢等業(yè)務(wù)進(jìn)行大數(shù)據(jù)量的測(cè)試；另一種是與并發(fā)測(cè)試相結(jié)合的極限狀態(tài)下的綜合數(shù)據(jù)測(cè)試。如專項(xiàng)的大數(shù)據(jù)量測(cè)試主要針對(duì)前者，后者盡量放在并發(fā)測(cè)試中。此外，也可以把大數(shù)據(jù)量測(cè)試分為“運(yùn)行時(shí)大數(shù)據(jù)量測(cè)試”與“歷史大數(shù)據(jù)量測(cè)試”來(lái)進(jìn)行測(cè)試用例設(shè)計(jì)。配置測(cè)試配置測(cè)試主要指通過測(cè)試找到系統(tǒng)各項(xiàng)資源的最優(yōu)分配原則。配置測(cè)試是系統(tǒng)調(diào)優(yōu)的重要依據(jù)。例如，可以通過不停地調(diào)整Oracle的內(nèi)存參數(shù)來(lái)進(jìn)行測(cè)試，使之達(dá)到一個(gè)較好的性能?？梢钥闯?，配置測(cè)試本質(zhì)上是前面提到的某些種類的性能測(cè)試組合在一起而進(jìn)行的測(cè)試?？煽啃詼y(cè)試在給系統(tǒng)加載一定業(yè)務(wù)壓力的情況下，使系統(tǒng)運(yùn)行一段時(shí)間，以此檢測(cè)系統(tǒng)是否穩(wěn)定。例如，可以施加讓CPU資源保持70%～90%使用率的壓力，連續(xù)對(duì)系統(tǒng)加壓8個(gè)小時(shí)，然后根據(jù)結(jié)果分析系統(tǒng)是否穩(wěn)定。這么多類型的性能測(cè)試看起來(lái)很嚇人，實(shí)際上它們大多是密切相關(guān)的。例如，運(yùn)行8個(gè)小時(shí)來(lái)測(cè)試系統(tǒng)是否可靠，而這個(gè)測(cè)試極有可能包含了可靠性測(cè)試、強(qiáng)度測(cè)試、并發(fā)（用戶）測(cè)試、負(fù)載測(cè)試，等等。因此，當(dāng)實(shí)施性能測(cè)試時(shí)絕不能割裂它們的內(nèi)部聯(lián)系去進(jìn)行，而應(yīng)分析它們之間的關(guān)系，以一種高效的方式來(lái)規(guī)劃與設(shè)計(jì)性能測(cè)試。為此，本書在1.2節(jié)提出了“全面性能測(cè)試模型”，以更好的方式來(lái)開展性能測(cè)試工作。1.1.2

性能測(cè)試應(yīng)用領(lǐng)域性能測(cè)試往往是為了實(shí)現(xiàn)下面的一個(gè)或幾個(gè)目標(biāo)：l

判定軟件是否滿足預(yù)期的性能需求；l

根據(jù)測(cè)試結(jié)果判定軟件的性能表現(xiàn)；l

查找系統(tǒng)可能存在的性能問題，如果有，則找出并加以解決；l

發(fā)現(xiàn)一些應(yīng)用程序在功能實(shí)現(xiàn)方面的缺陷；l

對(duì)一些存在性能問題的系統(tǒng)，找出瓶頸并加以解決；l

為用戶部署系統(tǒng)提供性能參考；l

……通過分析性能測(cè)試的種種目標(biāo)，不難總結(jié)出性能測(cè)試主要應(yīng)用在幾個(gè)領(lǐng)域中，下面分別予以介紹。系統(tǒng)的性能瓶頸定位系統(tǒng)的性能瓶頸定位是性能測(cè)試最常見的應(yīng)用領(lǐng)域。借助LoadRunner等工具，可以在測(cè)試場(chǎng)景運(yùn)行過程中監(jiān)控系統(tǒng)資源、Web服務(wù)器資源等運(yùn)行數(shù)據(jù)，與響應(yīng)時(shí)間進(jìn)行同步分析，可以在一定程度上進(jìn)行性能瓶頸的分析與定位。系統(tǒng)的參數(shù)配置通過性能測(cè)試可以測(cè)試系統(tǒng)在不同參數(shù)配置下的性能表現(xiàn)，進(jìn)而找出令系統(tǒng)表現(xiàn)更優(yōu)的系統(tǒng)配置參數(shù)，為應(yīng)用系統(tǒng)投產(chǎn)提供最佳配置建議。實(shí)際上，操作系統(tǒng)、數(shù)據(jù)庫(kù)、中間件服務(wù)器等的參數(shù)配置是應(yīng)用系統(tǒng)發(fā)生性能問題的重要原因。例如分配給Oracle的內(nèi)存大小與系統(tǒng)自身的業(yè)務(wù)特點(diǎn)有極大關(guān)系，配置不同的數(shù)據(jù)庫(kù)，性能表現(xiàn)就會(huì)不同；而即使在內(nèi)存一定的情況下，SGA的分配也會(huì)對(duì)性能產(chǎn)生很大的影響。因此，要通過測(cè)試，以確定內(nèi)存的最佳配置。發(fā)現(xiàn)一些軟件算法方面的缺陷一些多線程、同步并發(fā)算法在單用戶模式下測(cè)試是很難發(fā)現(xiàn)問題的，只有通過模擬多用戶的并發(fā)操作，才能驗(yàn)證其運(yùn)行是否正常與穩(wěn)定。例如作者就經(jīng)歷過在一次性能測(cè)試過程中，測(cè)試人員模擬多個(gè)用戶并發(fā)時(shí)發(fā)現(xiàn)的一個(gè)明顯的缺陷：測(cè)試對(duì)象是一個(gè)隨機(jī)分配任務(wù)的模塊，只要有用戶申請(qǐng)，就會(huì)給用戶分配任務(wù)。這個(gè)算法在單用戶情況下調(diào)試沒有任何問題，但是當(dāng)多個(gè)用戶同時(shí)申請(qǐng)任務(wù)時(shí)，就發(fā)生了把同一任務(wù)分配給多個(gè)不同用戶的現(xiàn)象。經(jīng)證實(shí)，這個(gè)缺陷就是“同步算法”發(fā)生了問題而引起的。系統(tǒng)的驗(yàn)收測(cè)試系統(tǒng)驗(yàn)收測(cè)試經(jīng)常會(huì)驗(yàn)證一些預(yù)期的性能指標(biāo)，或者驗(yàn)證系統(tǒng)中一些事務(wù)指標(biāo)是否符合用戶期望，這時(shí)就需要借助性能測(cè)試來(lái)完成驗(yàn)證工作。隨著用戶對(duì)性能的重視，現(xiàn)在性能測(cè)試幾乎是系統(tǒng)驗(yàn)收測(cè)試中必不可少的內(nèi)容之一。用戶甚至自己進(jìn)行專門的性能測(cè)試來(lái)驗(yàn)證系統(tǒng)上線前的性能，以保證運(yùn)行時(shí)的性能穩(wěn)定。因此，性能測(cè)試在用戶驗(yàn)收測(cè)試中越來(lái)越重要。系統(tǒng)容量規(guī)劃通過總結(jié)系統(tǒng)在不同硬件環(huán)境下的性能表現(xiàn)，可以為系統(tǒng)部署時(shí)提供非常好的參考。對(duì)于一些性能要求較高的系統(tǒng)，性能測(cè)試可以為硬件規(guī)劃提供很好的參考數(shù)據(jù)，使用戶在購(gòu)買硬件時(shí)“有據(jù)可依”。例如同一系列機(jī)型：兩顆CPU系統(tǒng)支持500用戶并發(fā)、四顆CPU支持800用戶并發(fā)，這些都是用戶根據(jù)自身需求來(lái)規(guī)劃硬件的重要依據(jù)。產(chǎn)品評(píng)估/選型產(chǎn)品評(píng)估/選型是性能測(cè)試的又一應(yīng)用領(lǐng)域。通過性能測(cè)試，可以對(duì)產(chǎn)品的軟硬件性能進(jìn)行更全面的評(píng)估，選出更適合自己的產(chǎn)品類型。性能測(cè)試的應(yīng)用領(lǐng)域越來(lái)越廣，因此在實(shí)際工作中，性能測(cè)試往往會(huì)一次應(yīng)用在一個(gè)或多個(gè)領(lǐng)域。對(duì)于軟件性能測(cè)試設(shè)計(jì)人員，應(yīng)該根據(jù)測(cè)試的具體應(yīng)用領(lǐng)域、測(cè)試原則和目標(biāo)來(lái)進(jìn)行性能測(cè)試的規(guī)劃與設(shè)計(jì)。1.1.3

性能測(cè)試常見術(shù)語(yǔ)本節(jié)將介紹一些性能測(cè)試中的常見術(shù)語(yǔ)，只有掌握這些基礎(chǔ)的性能測(cè)試知識(shí)，才可以進(jìn)一步開展測(cè)試工作。性能測(cè)試常見的術(shù)語(yǔ)主要有并發(fā)、并發(fā)用戶數(shù)量、請(qǐng)求響應(yīng)時(shí)間、事務(wù)響應(yīng)時(shí)間、吞吐量、吞吐率、TPS、點(diǎn)擊率、資源利用率等，下面分別介紹它們。并發(fā)狹義的并發(fā)一般分兩種情況。一種是嚴(yán)格意義上的并發(fā)，即所有的用戶在同一時(shí)刻做同一件事情或操作，這種操作一般針對(duì)同一類型的業(yè)務(wù)。例如在信用卡審批業(yè)務(wù)中，一定數(shù)目的用戶在同一時(shí)刻對(duì)已經(jīng)完成的審批業(yè)務(wù)進(jìn)行提交（操作的不是同一記錄）；還有一種是特例，即所有用戶進(jìn)行完全一樣的操作，目的是測(cè)試數(shù)據(jù)庫(kù)和程序?qū)Σl(fā)操作的處理。例如在信用卡審批業(yè)務(wù)中，所有的用戶可以一起申請(qǐng)業(yè)務(wù)，或者修改同一條記錄。另外一種并發(fā)是廣義的并發(fā)。這種并發(fā)與狹義的并發(fā)的區(qū)別是盡管多個(gè)用戶對(duì)系統(tǒng)發(fā)出了請(qǐng)求或進(jìn)行了操作，但是這些請(qǐng)求或操作可以是相同的，也可以是不同的。對(duì)整個(gè)系統(tǒng)而言，仍然有很多用戶同時(shí)對(duì)系統(tǒng)進(jìn)行操作，因此，仍然屬于并發(fā)的范疇?？梢钥闯?，廣義的并發(fā)是包含狹義的并發(fā)的，而且廣義的并發(fā)更接近用戶的實(shí)際使用情況，因?yàn)閷?duì)大多數(shù)系統(tǒng)而言，只有數(shù)量很少的用戶進(jìn)行“嚴(yán)格意義上的并發(fā)”。對(duì)于性能測(cè)試而言，這兩種并發(fā)一般都需要進(jìn)行測(cè)試，通常做法是先進(jìn)行嚴(yán)格意義上的并發(fā)測(cè)試。嚴(yán)格意義上的并發(fā)一般發(fā)生在使用比較頻繁的模塊中，盡管發(fā)生的概率不是特別高，但是一旦發(fā)生性能問題，后果很可能是致命的。嚴(yán)格意義上的并發(fā)測(cè)試往往和功能測(cè)試關(guān)聯(lián)起來(lái)，因?yàn)橹灰l(fā)功能遇到異常通常都是程序的問題，這種測(cè)試也是健壯性和穩(wěn)定性測(cè)試的一部分。并發(fā)用戶數(shù)量關(guān)于并發(fā)用戶的數(shù)量，有兩種常見的錯(cuò)誤觀點(diǎn)。一種錯(cuò)誤觀點(diǎn)是把并發(fā)用戶數(shù)量理解為使用系統(tǒng)的全部用戶的數(shù)量，理由是這些用戶可能同時(shí)使用系統(tǒng)；還有一種比較接近正確的觀點(diǎn)是把用戶在線數(shù)量理解為并發(fā)用戶數(shù)量。實(shí)際上，在線用戶不一定會(huì)和其他用戶發(fā)生并發(fā)，例如正在瀏覽網(wǎng)頁(yè)信息的用戶，對(duì)服務(wù)器是沒有任何影響的。但是，用戶在線數(shù)量是統(tǒng)計(jì)并發(fā)用戶數(shù)量的主要依據(jù)之一。并發(fā)主要針對(duì)服務(wù)器而言，是否并發(fā)的關(guān)鍵是看用戶的操作是否對(duì)服務(wù)器產(chǎn)生了影響。因此，并發(fā)用戶數(shù)量的正確理解是，在同一時(shí)刻與服務(wù)器進(jìn)行交互的在線用戶數(shù)量。這些用戶的最大特征是和服務(wù)器發(fā)生了交互，這種交互既可以是單向傳送數(shù)據(jù)的，也可以是雙向傳送數(shù)據(jù)的。并發(fā)用戶數(shù)量的統(tǒng)計(jì)方法目前還沒有準(zhǔn)確的公式，因?yàn)椴煌南到y(tǒng)會(huì)有不同的并發(fā)特點(diǎn)。例如OA系統(tǒng)統(tǒng)計(jì)并發(fā)用戶數(shù)量的經(jīng)驗(yàn)公式為：使用系統(tǒng)的用戶數(shù)量×（5％～20％）。對(duì)于這個(gè)公式，沒有必要拘泥于計(jì)算出的結(jié)果，因?yàn)闉榱吮ＷC系統(tǒng)的擴(kuò)展空間，測(cè)試時(shí)的并發(fā)用戶數(shù)量都會(huì)稍稍大一些，除非要測(cè)試系統(tǒng)能承受的最大并發(fā)用戶數(shù)量。舉例說明：如果一個(gè)OA系統(tǒng)的期望用戶為1000個(gè)，只要測(cè)試出系統(tǒng)能支持200個(gè)并發(fā)用戶就可以了。請(qǐng)求響應(yīng)時(shí)間請(qǐng)求響應(yīng)時(shí)間是指從客戶端發(fā)出請(qǐng)求到得到響應(yīng)的整個(gè)過程的時(shí)間。這個(gè)過程從客戶端發(fā)送一個(gè)請(qǐng)求開始計(jì)時(shí)，到客戶端接到從服務(wù)器端返回的響應(yīng)結(jié)果計(jì)時(shí)結(jié)束。在某些工具中，請(qǐng)求響應(yīng)時(shí)間通常會(huì)被稱為“TTLB”，即“Timetolastbyte”，意思是從發(fā)送一個(gè)請(qǐng)求開始，到客戶端收到最后一個(gè)字節(jié)的響應(yīng)為止所耗費(fèi)的時(shí)間。請(qǐng)求響應(yīng)時(shí)間的單位一般為“秒”或“毫秒”。請(qǐng)求響應(yīng)時(shí)間的分解如圖1-1所示。圖1-1

Web請(qǐng)求過程分解圖從圖1-1可以看出，請(qǐng)求響應(yīng)時(shí)間為“網(wǎng)絡(luò)響應(yīng)時(shí)間”和“應(yīng)用程序與系統(tǒng)響應(yīng)時(shí)間”之和，具體由7個(gè)部分組成，即(N1+N2+N3+N4)+(A1+A2+A3)。事務(wù)響應(yīng)時(shí)間事務(wù)可能由一系列請(qǐng)求組成，事務(wù)的響應(yīng)時(shí)間主要針對(duì)用戶而言，屬于宏觀上的概念，是為了向用戶說明業(yè)務(wù)響應(yīng)時(shí)間而提出的。例如：跨行取款事務(wù)的響應(yīng)時(shí)間就是由一系列的請(qǐng)求組成的。事務(wù)響應(yīng)時(shí)間和后面的業(yè)務(wù)吞吐率都是直接衡量系統(tǒng)性能的參數(shù)。吞吐量指在一次性能測(cè)試過程中網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量的總和。吞吐量/傳輸時(shí)間，就是吞吐率。吞吐率（Throughput）通常用來(lái)指單位時(shí)間內(nèi)網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量，也可以指單位時(shí)間內(nèi)處理的客戶端請(qǐng)求數(shù)量。它是衡量網(wǎng)絡(luò)性能的重要指標(biāo)。但是從用戶或業(yè)務(wù)角度來(lái)看，吞吐率也可以用“請(qǐng)求數(shù)/秒”或“頁(yè)面數(shù)/秒”、“業(yè)務(wù)數(shù)/小時(shí)或天”、“訪問人數(shù)/天”、“頁(yè)面訪問量/天”來(lái)衡量。例如在銀行卡審批系統(tǒng)中，可以用“千件/每小時(shí)”來(lái)衡量系統(tǒng)的業(yè)務(wù)處理能力。TPS(TransactionPerSecond)每秒鐘系統(tǒng)能夠處理的交易或事務(wù)的數(shù)量。它是衡量系統(tǒng)處理能力的重要指標(biāo)。TPS是LoadRunner中重要的性能參數(shù)指標(biāo)。點(diǎn)擊率（HitPerSecond）每秒鐘用戶向Web服務(wù)器提交的HTTP請(qǐng)求數(shù)。這個(gè)指標(biāo)是Web應(yīng)用特有的一個(gè)指標(biāo)：Web應(yīng)用是“請(qǐng)求-響應(yīng)”模式，用戶發(fā)出一次申請(qǐng)，服務(wù)器就要處理一次，所以“點(diǎn)擊”是Web應(yīng)用能夠處理交易的最小單位。如果把每次點(diǎn)擊定義為一次交易，點(diǎn)擊率和TPS就是一個(gè)概念。不難看出，點(diǎn)擊率越大，對(duì)服務(wù)器的壓力也越大。點(diǎn)擊率只是一個(gè)性能參考指標(biāo)，重要的是分析點(diǎn)擊時(shí)產(chǎn)生的影響。需要注意的是，這里的點(diǎn)擊不是指鼠標(biāo)的一次“單擊”操作，因?yàn)樵谝淮巍皢螕簟辈僮髦?，客戶端可能向服?wù)器發(fā)出多個(gè)HTTP請(qǐng)求。資源利用率資源利用率指的是對(duì)不同系統(tǒng)資源的使用程度，例如服務(wù)器的CPU利用率、磁盤利用率等。資源利用率是分析系統(tǒng)性能指標(biāo)進(jìn)而改善性能的主要依據(jù)，因此，它是Web性能測(cè)試工作的重點(diǎn)。資源利用率主要針對(duì)Web服務(wù)器、操作系統(tǒng)、數(shù)據(jù)庫(kù)服務(wù)器、網(wǎng)絡(luò)等，是測(cè)試和分析瓶頸的主要參數(shù)。在性能測(cè)試中，要根據(jù)需要采集具體的資源利用率參數(shù)來(lái)進(jìn)行分析。1.2全面性能測(cè)試模型

1.2

全面性能測(cè)試模型通過前面的內(nèi)容可以看出，性能測(cè)試的很多內(nèi)容都是關(guān)聯(lián)的。這就提供了一條思路：性能測(cè)試的很多內(nèi)容可以經(jīng)過一定的組織來(lái)統(tǒng)一進(jìn)行。統(tǒng)一開展性能測(cè)試的最大好處是，可以按照由淺入深的層次對(duì)系統(tǒng)進(jìn)行測(cè)試，進(jìn)而減少不必要的工作量，以實(shí)現(xiàn)節(jié)約測(cè)試成本的目的。為此，本書提出了“全面性能測(cè)試模型”?！叭嫘阅軠y(cè)試模型”提出的主要依據(jù)是：一種類型的性能測(cè)試可以在某些條件下轉(zhuǎn)化成為另一種類型的性能測(cè)試，而這些測(cè)試的實(shí)施方式很類似。例如：對(duì)一個(gè)網(wǎng)站進(jìn)行測(cè)試，模擬10個(gè)到50個(gè)用戶就是常規(guī)的性能測(cè)試。當(dāng)用戶增加到1000乃至上萬(wàn)時(shí)就變成了壓力/負(fù)載測(cè)試。如果同時(shí)對(duì)系統(tǒng)進(jìn)行大量的數(shù)據(jù)查詢操作，就包含了大數(shù)據(jù)量測(cè)試。在“全面性能測(cè)試模型”中，把常見的性能測(cè)試分為8個(gè)類別，然后結(jié)合測(cè)試工具把性能測(cè)試用例歸納為5類來(lái)進(jìn)行設(shè)計(jì)。下面首先介紹這8個(gè)性能測(cè)試類別的主要內(nèi)容：預(yù)期指標(biāo)的性能測(cè)試系統(tǒng)在需求分析和設(shè)計(jì)階段都會(huì)提出一些性能指標(biāo)，完成和這些指標(biāo)相關(guān)的測(cè)試是性能測(cè)試的首要工作。本模型把針對(duì)預(yù)先確定的一些性能指標(biāo)而進(jìn)行的測(cè)試稱為預(yù)期指標(biāo)的性能測(cè)試。這些指標(biāo)主要指諸如“系統(tǒng)可以支持1000個(gè)并發(fā)用戶”、“系統(tǒng)響應(yīng)時(shí)間不得長(zhǎng)于10秒”等這些在產(chǎn)品說明書等文檔中規(guī)定得十分明確的內(nèi)容。對(duì)這種預(yù)先承諾的性能要求，測(cè)試小組應(yīng)該首先進(jìn)行測(cè)試驗(yàn)證。獨(dú)立業(yè)務(wù)性能測(cè)試獨(dú)立業(yè)務(wù)實(shí)際是指一些與核心業(yè)務(wù)模塊對(duì)應(yīng)的業(yè)務(wù)，這些模塊通常具有功能比較復(fù)雜、使用比較頻繁、屬于核心業(yè)務(wù)等特點(diǎn)。這類特殊的、功能比較獨(dú)立的業(yè)務(wù)模塊始終都是性能測(cè)試的重點(diǎn)。因此，不但要測(cè)試這類模塊和性能相關(guān)的一些算法，還要測(cè)試這類模塊對(duì)并發(fā)用戶的響應(yīng)情況。核心業(yè)務(wù)模塊在需求設(shè)計(jì)階段就可以確定，在集成或系統(tǒng)測(cè)試階段開始單獨(dú)測(cè)試其性能。如果是系統(tǒng)類軟件或特殊應(yīng)用領(lǐng)域的軟件，通常從單元測(cè)試階段就開始進(jìn)行測(cè)試，并在后繼的集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試中進(jìn)一步進(jìn)行，以保證核心業(yè)務(wù)模塊的性能穩(wěn)定。何時(shí)開始測(cè)試核心模塊主要由性能測(cè)試策略決定，讀者可以參考1.2.2節(jié)“性能測(cè)試用例模型”部分。組合業(yè)務(wù)性能測(cè)試通常所有的用戶不會(huì)只使用一個(gè)或幾個(gè)核心業(yè)務(wù)模塊，一個(gè)應(yīng)用系統(tǒng)的每個(gè)功能模塊都可能被使用到。所以性能測(cè)試既要模擬多用戶的“相同”操作（這里的“相同”指很多用戶使用同一功能），又要模擬多用戶的“不同”操作（這里的“不同”指很多用戶同時(shí)對(duì)一個(gè)或多個(gè)模塊的不同功能進(jìn)行操作），對(duì)多項(xiàng)業(yè)務(wù)進(jìn)行組合性能測(cè)試。組合業(yè)務(wù)測(cè)試是最接近用戶實(shí)際使用情況的測(cè)試，也是性能測(cè)試的核心內(nèi)容。通常按照用戶的實(shí)際使用人數(shù)比例來(lái)模擬各個(gè)模板的組合并發(fā)情況。由于組合業(yè)務(wù)測(cè)試是最能反映用戶使用情況的測(cè)試，因而組合測(cè)試往往和服務(wù)器（操作系統(tǒng)、Web服務(wù)器、數(shù)據(jù)庫(kù)服務(wù)器）性能測(cè)試結(jié)合起來(lái)進(jìn)行。在通過工具模擬用戶操作的同時(shí)，還通過測(cè)試工具的監(jiān)控功能采集服務(wù)器的計(jì)數(shù)器信息，進(jìn)而全面分析系統(tǒng)的瓶頸，為改進(jìn)系統(tǒng)提供有利的依據(jù)。疲勞強(qiáng)度性能測(cè)試疲勞強(qiáng)度測(cè)試是指在系統(tǒng)穩(wěn)定運(yùn)行的情況下，以一定的負(fù)載壓力來(lái)長(zhǎng)時(shí)間運(yùn)行系統(tǒng)的測(cè)試。其主要目的是確定系統(tǒng)長(zhǎng)時(shí)間處理較大業(yè)務(wù)量時(shí)的性能。通過疲勞強(qiáng)度測(cè)試基本可以判斷系統(tǒng)運(yùn)行一段時(shí)間后是否穩(wěn)定。大數(shù)據(jù)量性能測(cè)試大數(shù)據(jù)量測(cè)試通常是針對(duì)某些系統(tǒng)存儲(chǔ)、傳輸、統(tǒng)計(jì)查詢等業(yè)務(wù)進(jìn)行大數(shù)據(jù)量的測(cè)試。主要測(cè)試運(yùn)行時(shí)數(shù)據(jù)量較大或歷史數(shù)據(jù)量較大時(shí)的性能情況，這類測(cè)試一般都是針對(duì)某些特殊的核心業(yè)務(wù)或一些日常比較常用的組合業(yè)務(wù)的測(cè)試。由于大數(shù)據(jù)量測(cè)試一般在投產(chǎn)環(huán)境下進(jìn)行，所以把它獨(dú)立出來(lái)并和疲勞強(qiáng)度測(cè)試放在一起，在整個(gè)性能測(cè)試的后期進(jìn)行。大數(shù)據(jù)量測(cè)試可以理解為特定條件下的核心業(yè)務(wù)或組合業(yè)務(wù)測(cè)試。網(wǎng)絡(luò)性能測(cè)試網(wǎng)絡(luò)性能測(cè)試主要是為了準(zhǔn)確展示帶寬、延遲、負(fù)載和端口的變化是如何影響用戶響應(yīng)時(shí)間的。在實(shí)際的軟件項(xiàng)目中，主要是測(cè)試應(yīng)用系統(tǒng)的用戶數(shù)目與網(wǎng)絡(luò)帶寬的關(guān)系。網(wǎng)絡(luò)性能測(cè)試一般有專門的工具，本書不加詳述。網(wǎng)絡(luò)測(cè)試的任務(wù)通常由系統(tǒng)集成人員來(lái)完成。服務(wù)器性能測(cè)試（操作系統(tǒng)、Web服務(wù)器、數(shù)據(jù)庫(kù)服務(wù)器）服務(wù)器性能測(cè)試主要是對(duì)數(shù)據(jù)庫(kù)、Web服務(wù)器、操作系統(tǒng)的測(cè)試，目的是通過性能測(cè)試找出各種服務(wù)器的瓶頸，為系統(tǒng)擴(kuò)展、優(yōu)化提供相關(guān)的依據(jù)。一些特殊測(cè)試主要是指配置測(cè)試、內(nèi)存泄漏測(cè)試等一些特殊的Web性能測(cè)試。這類性能測(cè)試或/和前面的測(cè)試結(jié)合起來(lái)進(jìn)行，或者在一些特殊的情況下獨(dú)立進(jìn)行，本書重點(diǎn)討論前一種情況。后一種情況由于投入較大往往通過特有的工具進(jìn)行，可以不納入性能測(cè)試的范疇。“全面性能測(cè)試模型”是在以上性能測(cè)試分類和總結(jié)的基礎(chǔ)上提出來(lái)的，主要包含3部分內(nèi)容：第1部分：性能測(cè)試策略模型，這是整個(gè)性能測(cè)試模型的基礎(chǔ)。軟件類型決定著性能測(cè)試的策略，同時(shí)用戶對(duì)待軟件性能的態(tài)度也影響性能測(cè)試策略的制定。本部分內(nèi)容主要結(jié)合軟件類型和用戶特點(diǎn)來(lái)討論性能測(cè)試策略制定的基本原則和方法。第2部分：性能測(cè)試用例模型，這是整個(gè)性能測(cè)試模型的核心部分。其主要思想就是結(jié)合測(cè)試工具，把以上性能測(cè)試的8項(xiàng)內(nèi)容進(jìn)一步歸納，形成5類測(cè)試用例：l

預(yù)期指標(biāo)的性能測(cè)試；l

并發(fā)用戶的性能測(cè)試；l

疲勞強(qiáng)度和大數(shù)據(jù)量的性能測(cè)試；l

服務(wù)器性能測(cè)試；l

網(wǎng)絡(luò)性能測(cè)試。在具體的測(cè)試設(shè)計(jì)中，性能測(cè)試用例往往和測(cè)試工具結(jié)合起來(lái)，把服務(wù)器、網(wǎng)絡(luò)性能測(cè)試的用例設(shè)計(jì)與前三種類型結(jié)合起來(lái)。例如LoadRunner就可以在進(jìn)行壓力測(cè)試的同時(shí)，完成后面兩類測(cè)試的數(shù)據(jù)采集工作。因此，后面兩部分的測(cè)試用例只進(jìn)行總體設(shè)計(jì)就可以了。第3部分：模型的使用方法。本部分內(nèi)容討論如何在工作中使用“全面性能測(cè)試模型”。1.2.1

性能測(cè)試策略模型本節(jié)主要介紹性能測(cè)試策略的制定方法。性能測(cè)試策略一般從需求設(shè)計(jì)階段就開始討論如何制定了，它決定著性能測(cè)試工作將要投入多少資源、什么時(shí)間開始實(shí)施等后繼工作的安排。其制定的主要依據(jù)是“軟件自身特點(diǎn)”和“用戶對(duì)性能的關(guān)注程度”兩個(gè)因素，其中軟件的自身特點(diǎn)起決定作用。軟件按照用途的不同可以分為兩大類：系統(tǒng)類軟件和應(yīng)用類軟件。系統(tǒng)類軟件通常對(duì)性能要求比較高，因此性能測(cè)試應(yīng)該盡早介入。應(yīng)用類軟件分為特殊類應(yīng)用和一般類應(yīng)用，特殊類應(yīng)用主要指銀行、電信、電力、保險(xiǎn)、醫(yī)療、安全等領(lǐng)域類的軟件，這類軟件使用比較頻繁，用戶較多，一般也要較早進(jìn)行性能測(cè)試；一般類應(yīng)用主要指一些普通應(yīng)用，例如辦公自動(dòng)化軟件、MIS系統(tǒng)等。一般應(yīng)用類軟件多根據(jù)實(shí)際情況來(lái)制定性能測(cè)試策略，例如OA系統(tǒng)，既可以早開始，也可以最后進(jìn)行性能測(cè)試，這類軟件受用戶因素影響比較大。按對(duì)性能重視程度的不同一般可以將用戶分為4類，即高度重視、中等重視、一般重視、不重視。這么劃分主要是為了說明用戶對(duì)性能測(cè)試的影響。實(shí)際上，用戶不關(guān)注性能并不意味著測(cè)試人員就可以忽略性能測(cè)試，但是如果用戶特別關(guān)注系統(tǒng)性能，那么測(cè)試人員也要特別重視性能測(cè)試工作。表1-1列出了性能測(cè)試策略制定的基本原則。

注意：這里的用戶是廣義范圍的用戶，包括所有和產(chǎn)品有利害關(guān)系的群體。因而不單單指最終使用產(chǎn)品的用戶，這些用戶既可以是提出需求的產(chǎn)品經(jīng)理，也可以是公司的董事會(huì)成員，甚至是項(xiàng)目的研發(fā)人員。表1-1

性能測(cè)試策略制定的基本原則

軟件類別用戶重視程度系統(tǒng)類軟件應(yīng)用類軟件一般類應(yīng)用特殊類應(yīng)用高度重視從設(shè)計(jì)階段就開始針對(duì)系統(tǒng)架構(gòu)、數(shù)據(jù)庫(kù)設(shè)計(jì)等方面進(jìn)行規(guī)劃，從根源來(lái)提高性能;系統(tǒng)類軟件一般從單元測(cè)試階段開始進(jìn)行性能測(cè)試實(shí)施工作，主要是測(cè)試一些和性能相關(guān)的算法或模塊設(shè)計(jì)階段開始進(jìn)行一些規(guī)劃工作，主要在系統(tǒng)測(cè)試階段開始進(jìn)行性能測(cè)試實(shí)施從設(shè)計(jì)階段就開始針對(duì)系統(tǒng)架構(gòu)、數(shù)據(jù)庫(kù)設(shè)計(jì)等方面進(jìn)行規(guī)劃，從根源來(lái)提高性能;特殊應(yīng)用類軟件一般從單元測(cè)試階段開始進(jìn)行性能測(cè)試實(shí)施工作，主要是測(cè)試一些和性能相關(guān)的算法或模塊中等重視/一般重視可以在系統(tǒng)測(cè)試階段的功能測(cè)試結(jié)束后進(jìn)行性能測(cè)試不重視可以在軟件發(fā)布前進(jìn)行性能測(cè)試，提交測(cè)試報(bào)告即可從表1-1中可以看出：（1）“系統(tǒng)類軟件”、“特殊應(yīng)用類軟件”應(yīng)該從設(shè)計(jì)階段開始進(jìn)行性能測(cè)試；（2）制定性能測(cè)試策略的主要依據(jù)是軟件的特點(diǎn)，用戶對(duì)待系統(tǒng)性能的態(tài)度影響性能測(cè)試策略，但不起決定作用。軟件的特點(diǎn)決定性能測(cè)試策略的另外一個(gè)重要原因是“一般應(yīng)用類軟件”本身對(duì)性能要求不高，發(fā)生性能問題的概率較小。因此可以通過提高硬件配置來(lái)改善運(yùn)行環(huán)境，進(jìn)而提高性能。不過這也不是普遍適用的原則。例如一個(gè)幾千用戶使用的OA系統(tǒng)，仍然要高度重視性能，不管客戶對(duì)待系統(tǒng)性能是什么態(tài)度。雖然從硬件方面解決性能問題往往更容易做到，同時(shí)還可以降低開發(fā)成本，但是也不能要求用戶進(jìn)行過大的硬件投入，否則會(huì)降低“客戶滿意度”。調(diào)整性能最好的辦法還是軟硬件相結(jié)合?！坝脩魧?duì)待系統(tǒng)性能的態(tài)度影響性能測(cè)試策略，但不起決定作用”的根本原因是，產(chǎn)品最終是要交付給用戶使用的，而不是做出來(lái)給用戶欣賞的。因此，不管用戶是否重視性能測(cè)試，甚至根本不關(guān)心，對(duì)于性能要求較高的軟件產(chǎn)品也應(yīng)按照表1-1的策略來(lái)執(zhí)行性能測(cè)試。只是如果用戶特別重視產(chǎn)品性能，意味著測(cè)試團(tuán)隊(duì)可能要進(jìn)行更多的成本投入。下面是一些性能測(cè)試策略制定的案例。

案例一一個(gè)銀行卡審批業(yè)務(wù)系統(tǒng)的性能測(cè)試策略制定。這個(gè)項(xiàng)目的性能測(cè)試策略從立項(xiàng)時(shí)開始制定，貫穿整個(gè)項(xiàng)目的執(zhí)行過程。銀行卡業(yè)務(wù)系統(tǒng)屬于特殊應(yīng)用軟件，加上用戶高度重視性能，因而采取的策略是從設(shè)計(jì)階段就開始進(jìn)行性能測(cè)試的準(zhǔn)備工作。案例的詳細(xì)內(nèi)容如表1-2所示。表1-2

某銀行項(xiàng)目測(cè)試策略制定案例產(chǎn)品類型銀行卡審批業(yè)務(wù)系統(tǒng)，使用非常頻繁，業(yè)務(wù)量每年達(dá)到200萬(wàn)次左右，屬于銀行領(lǐng)域的特殊應(yīng)用軟件項(xiàng)目背景系統(tǒng)屬于二次開發(fā)。前一開發(fā)商在系統(tǒng)開發(fā)完成后沒有通過性能測(cè)試，當(dāng)100個(gè)用戶并發(fā)訪問系統(tǒng)時(shí)就會(huì)造成數(shù)據(jù)庫(kù)服務(wù)器崩潰。因此從項(xiàng)目啟動(dòng)開始，性能測(cè)試就已經(jīng)成為用戶關(guān)注的焦點(diǎn)用戶要求用戶提出性能首先要過關(guān)，否則功能再好也不會(huì)投產(chǎn)性能測(cè)試策略從系統(tǒng)設(shè)計(jì)階段開始進(jìn)行性能測(cè)試準(zhǔn)備工作。測(cè)試人員主要參加系統(tǒng)的設(shè)計(jì)、評(píng)審。前一開發(fā)商失利的重要原因是數(shù)據(jù)庫(kù)設(shè)計(jì)不合理，所以重點(diǎn)討論了數(shù)據(jù)庫(kù)的設(shè)計(jì)系統(tǒng)設(shè)計(jì)階段，完成了性能測(cè)試方案的設(shè)計(jì)單元測(cè)試階段，通過測(cè)試工具對(duì)一些重要模塊的算法進(jìn)行了測(cè)試。主要是一些并發(fā)控制算法的性能測(cè)試，測(cè)試對(duì)象是一些核心業(yè)務(wù)模塊集成測(cè)試階段進(jìn)行組合模塊的性能測(cè)試整個(gè)系統(tǒng)測(cè)試階段都在進(jìn)行性能測(cè)試，性能測(cè)試和功能測(cè)試同步進(jìn)行。對(duì)功能測(cè)試引起的一些相關(guān)修改，立刻進(jìn)行性能測(cè)試驗(yàn)收測(cè)試階段，在用戶現(xiàn)場(chǎng)的投產(chǎn)環(huán)境進(jìn)行性能測(cè)試，根據(jù)測(cè)試結(jié)果對(duì)系統(tǒng)運(yùn)行環(huán)境進(jìn)行調(diào)優(yōu)，以達(dá)到更好的運(yùn)行效果

案例二一個(gè)OA系統(tǒng)的測(cè)試案例，其性能測(cè)試策略和案例一差別很大，具體內(nèi)容如表1-3所示。表1-3

某OA項(xiàng)目測(cè)試策略制定案例產(chǎn)品類型企業(yè)辦公系統(tǒng)，用戶數(shù)目在1000人以內(nèi)，主要是一些信息的發(fā)布，以及公文流轉(zhuǎn)、收發(fā)郵件等功能。軟件系統(tǒng)的地位屬于輔助辦公功能。因此該類軟件屬于一般類型的應(yīng)用軟件，對(duì)性能要求不高，性能測(cè)試不屬于重要工作項(xiàng)目背景已有穩(wěn)定產(chǎn)品在工作。主要是按照客戶的個(gè)性化需求進(jìn)行二次開發(fā)用戶要求客戶提出了性能方面的需求：要求系統(tǒng)響應(yīng)時(shí)間要加快，可以滿足2000個(gè)用戶使用的需要性能測(cè)試策略系統(tǒng)測(cè)試階段開始進(jìn)行性能測(cè)試準(zhǔn)備工作，完成測(cè)試用例設(shè)計(jì)。其目標(biāo)主要是評(píng)估系統(tǒng)性能，根據(jù)測(cè)試結(jié)果對(duì)系統(tǒng)進(jìn)行一定的優(yōu)化驗(yàn)收測(cè)試階段在用戶現(xiàn)場(chǎng)執(zhí)行性能測(cè)試用例，根據(jù)測(cè)試結(jié)果進(jìn)行一定的調(diào)優(yōu)工作，提交測(cè)試報(bào)告給用戶以便進(jìn)行系統(tǒng)驗(yàn)收

案例三一個(gè)門戶系統(tǒng)的測(cè)試案例，具體內(nèi)容如表1-4所示。表1-4

某門戶項(xiàng)目測(cè)試策略制定案例產(chǎn)品類型主要用于一些單位信息的發(fā)布，用戶在50人以下。因此該類軟件屬于一般類型的應(yīng)用軟件，對(duì)性能要求很低項(xiàng)目背景軟件運(yùn)行的硬件環(huán)境較好用戶要求用戶沒有提出具體的要求性能測(cè)試策略驗(yàn)收測(cè)試在使用現(xiàn)場(chǎng)進(jìn)行，根據(jù)測(cè)試結(jié)果進(jìn)行一定的調(diào)優(yōu)工作，提交測(cè)試報(bào)告給用戶，以便進(jìn)行系統(tǒng)驗(yàn)收僅僅三個(gè)案例不足以說明所有性能測(cè)試策略制定的方法，但是通過這三個(gè)案例可以對(duì)性能測(cè)試策略的制定有更進(jìn)一步的了解，能夠認(rèn)識(shí)到性能測(cè)試策略的制定由軟件自身特點(diǎn)決定，同時(shí)受用戶態(tài)度的影響。實(shí)際上，軟件項(xiàng)目的背景、軟件運(yùn)行環(huán)境等許多方面都會(huì)影響性能測(cè)試策略的制定。因此，本節(jié)提出的只是基本的參考方案。制定測(cè)試策略是十分復(fù)雜的工作，最有效的方法就是“從實(shí)際出發(fā)”。項(xiàng)目的特點(diǎn)千差萬(wàn)別，只有把用戶當(dāng)成“上帝”，充分為用戶考慮，才可以制定出合理的性能測(cè)試策略。本節(jié)介紹了性能測(cè)試策略制定的基本思路和方法。性能測(cè)試策略是后期性能測(cè)試工作的基礎(chǔ)，決定著性能測(cè)試工作的投入。因此，要充分意識(shí)到這一工作的重要性，認(rèn)識(shí)到只有做好了前期的“路線”制定工作，才可以走對(duì)后面的“道路”。1.2.2

性能測(cè)試用例模型“性能測(cè)試用例模型”是“全面性能測(cè)試模型”的核心內(nèi)容。限于篇幅和本書主旨，本節(jié)僅對(duì)“性能測(cè)試用例模型”做概要介紹。關(guān)于“性能測(cè)試用例模型”以及“全面性能測(cè)試模型”更詳細(xì)的內(nèi)容，讀者可以參考作者的另一本專著《Web性能測(cè)試實(shí)戰(zhàn)》。在前面的內(nèi)容中，已經(jīng)介紹了性能測(cè)試分為8個(gè)方面。而在“性能測(cè)試用例模型”中，則融合了性能、強(qiáng)度、壓力、負(fù)載等多方面測(cè)試內(nèi)容，對(duì)性能測(cè)試進(jìn)行了重新組織和分類，最終歸納出五類性能測(cè)試用例。下面介紹各類性能測(cè)試用例包含的內(nèi)容以及設(shè)計(jì)方法。預(yù)期性能指標(biāo)測(cè)試用例所謂預(yù)期或預(yù)定性能指標(biāo)，就是指一些十分明確的、在系統(tǒng)需求設(shè)計(jì)階段預(yù)先提出的、期望系統(tǒng)達(dá)到的，或者向用戶保證的性能指標(biāo)，這些指標(biāo)是性能測(cè)試的首要任務(wù)。針對(duì)每個(gè)指標(biāo)都要編寫一個(gè)或多個(gè)測(cè)試用例來(lái)驗(yàn)證系統(tǒng)是否達(dá)到要求，如果達(dá)不到目標(biāo)，則需根據(jù)測(cè)試結(jié)果來(lái)改進(jìn)系統(tǒng)的性能。預(yù)期指標(biāo)的用例設(shè)計(jì)比較簡(jiǎn)單，主要參考需求和設(shè)計(jì)文檔，把里面十分明確的性能要求提取出來(lái)即可。指標(biāo)中通常以單用戶為主，如果涉及并發(fā)用戶內(nèi)容，則歸并到并發(fā)用戶測(cè)試用例中進(jìn)行設(shè)計(jì)，遇到其他內(nèi)容亦可采用同樣的方法處理。用戶并發(fā)性能測(cè)試用例本節(jié)的用戶并發(fā)測(cè)試融合了前面提到的“獨(dú)立業(yè)務(wù)性能測(cè)試”和“組合業(yè)務(wù)性能測(cè)試”兩類內(nèi)容，主要是為了使性能測(cè)試按照一定的層次來(lái)開展。獨(dú)立業(yè)務(wù)性能測(cè)試實(shí)際上就是核心業(yè)務(wù)模塊的某一業(yè)務(wù)的并發(fā)性能測(cè)試，可以理解為“單元性能測(cè)試”；組合業(yè)務(wù)的性能測(cè)試是一個(gè)或多個(gè)模塊的多項(xiàng)業(yè)務(wù)同時(shí)進(jìn)行并發(fā)性能測(cè)試，可以理解為“集成性能測(cè)試”?！皢卧阅軠y(cè)試”和“集成性能測(cè)試”兩者緊密相連，由于這兩部分內(nèi)容都是以并發(fā)用戶測(cè)試為主，因此把這兩類測(cè)試合并起來(lái)通稱為“用戶并發(fā)性能測(cè)試”。用戶并發(fā)性能測(cè)試要求選擇具有代表性的、關(guān)鍵的業(yè)務(wù)來(lái)設(shè)計(jì)測(cè)試用例，以便更有效地評(píng)測(cè)系統(tǒng)性能。當(dāng)編寫具體的測(cè)試用例設(shè)計(jì)文檔時(shí)，一般不會(huì)像功能測(cè)試那樣進(jìn)行明確的分類，其基本的編寫思想是按照系統(tǒng)的體系結(jié)構(gòu)進(jìn)行編寫的。很多時(shí)候，“獨(dú)立業(yè)務(wù)”和“組合業(yè)務(wù)”是混合在一起進(jìn)行設(shè)計(jì)的。單一模塊本身就存在“獨(dú)立業(yè)務(wù)”和“組合業(yè)務(wù)”，所以性能測(cè)試用例的設(shè)計(jì)應(yīng)該面向“模塊”，而不是具體的業(yè)務(wù)。在性能測(cè)試用例設(shè)計(jì)模型中，用戶并發(fā)測(cè)試實(shí)際就是關(guān)于“獨(dú)立核心模塊并發(fā)”和“組合模塊并發(fā)”的性能測(cè)試。用戶并發(fā)性能測(cè)試的詳細(xì)分類如圖1-2所示。圖1-2

用戶并發(fā)性能測(cè)試的分類示意圖獨(dú)立核心模塊（以下簡(jiǎn)稱“核心模塊”）并發(fā)性能測(cè)試的重點(diǎn)是測(cè)試一些系統(tǒng)重要模塊獨(dú)立運(yùn)行的情況，因此可以將其理解為“單元性能測(cè)試”。只有這些決定系統(tǒng)性能的“核心單元”性能穩(wěn)定，后面的性能測(cè)試才有意義。核心模塊并發(fā)性能測(cè)試是整個(gè)性能測(cè)試工作的基礎(chǔ)。組合模塊并發(fā)性能測(cè)試是最能反映用戶實(shí)際使用情況的測(cè)試，是在前面各個(gè)核心模塊運(yùn)行良好的基礎(chǔ)上、把系統(tǒng)的一些具有耦合關(guān)系的模塊組合起來(lái)的測(cè)試，因此可以理解成“集成性能測(cè)試”。組合模塊用戶并發(fā)性能測(cè)試最重要的是模擬實(shí)際用戶比較常見的場(chǎng)景，只有這樣才可以真實(shí)地反映用戶使用系統(tǒng)的情況，進(jìn)而發(fā)現(xiàn)系統(tǒng)的瓶頸和其他一些性能問題。疲勞強(qiáng)度與大數(shù)據(jù)量測(cè)試疲勞強(qiáng)度測(cè)試屬于用戶并發(fā)測(cè)試的延續(xù)，因此測(cè)試內(nèi)容仍然是“核心模塊用戶并發(fā)”與“組合模塊用戶并發(fā)”。在實(shí)際工作中，一般通過工具模擬用戶的一些核心或典型的業(yè)務(wù)，然后長(zhǎng)時(shí)間地運(yùn)行系統(tǒng)，以檢測(cè)系統(tǒng)是否穩(wěn)定。大數(shù)據(jù)量測(cè)試主要是針對(duì)那些對(duì)數(shù)據(jù)庫(kù)有特殊要求的系統(tǒng)而進(jìn)行的測(cè)試，例如電信業(yè)務(wù)系統(tǒng)的手機(jī)短信業(yè)務(wù)。由于有的用戶關(guān)機(jī)或不在服務(wù)區(qū)，每秒鐘需要有大量的短信息保存，同時(shí)在用戶聯(lián)機(jī)后還要及時(shí)發(fā)送，因此對(duì)數(shù)據(jù)庫(kù)性能有極高的要求，需要進(jìn)行專門測(cè)試。編寫本類用例前，應(yīng)對(duì)需求設(shè)計(jì)文檔進(jìn)行仔細(xì)分析，提出測(cè)試點(diǎn)。大數(shù)據(jù)量測(cè)試分為3種：l

實(shí)時(shí)大數(shù)據(jù)量測(cè)試：模擬用戶工作時(shí)的實(shí)時(shí)大數(shù)據(jù)量，主要目的是測(cè)試用戶較多或某些業(yè)務(wù)產(chǎn)生較大數(shù)據(jù)量時(shí)，系統(tǒng)能否穩(wěn)定地運(yùn)行；l

極限狀態(tài)下的測(cè)試：主要是測(cè)試系統(tǒng)使用一段時(shí)間后，即系統(tǒng)累積一定量的數(shù)據(jù)后，能否正常地運(yùn)行業(yè)務(wù)；l

前面兩種的結(jié)合：測(cè)試系統(tǒng)已經(jīng)累積較大數(shù)據(jù)量時(shí)，一些運(yùn)行時(shí)產(chǎn)生較大數(shù)據(jù)量的模塊能否穩(wěn)定地工作。網(wǎng)絡(luò)性能測(cè)試網(wǎng)絡(luò)性能測(cè)試的用例設(shè)計(jì)主要有以下兩類：l

基于硬件的測(cè)試：主要通過各種專用軟件工具、儀器等來(lái)測(cè)試整個(gè)系統(tǒng)的網(wǎng)絡(luò)運(yùn)行環(huán)境，一般由專門的系統(tǒng)集成人員來(lái)負(fù)責(zé)，不在本書的研究范圍之內(nèi)；l

基于應(yīng)用系統(tǒng)的測(cè)試：在實(shí)際的軟件項(xiàng)目中，主要測(cè)試用戶數(shù)目與網(wǎng)絡(luò)帶寬的關(guān)系。通過測(cè)試工具準(zhǔn)確展示帶寬、延遲、負(fù)載和端口的變化是如何影響用戶響應(yīng)時(shí)間的。例如，可以分別測(cè)試不同帶寬條件下系統(tǒng)的響應(yīng)時(shí)間。服務(wù)器性能測(cè)試服務(wù)器性能測(cè)試主要有兩種類型：l

高級(jí)服務(wù)器性能測(cè)試：主要指在特定的硬件條件下，由數(shù)據(jù)庫(kù)、Web服務(wù)器、操作系統(tǒng)相應(yīng)領(lǐng)域的專家進(jìn)行的性能測(cè)試。例如，數(shù)據(jù)庫(kù)服務(wù)器由專門的DBA來(lái)進(jìn)行測(cè)試和調(diào)優(yōu)。這類測(cè)試一般不由測(cè)試工程師來(lái)完成，所以不在本書的研究范圍之內(nèi)；l

初級(jí)服務(wù)器性能測(cè)試：主要指在業(yè)務(wù)系統(tǒng)工作或進(jìn)行前面其他種類性能測(cè)試的時(shí)候，監(jiān)控服務(wù)器的一些計(jì)數(shù)器信息。通過這些計(jì)數(shù)器對(duì)服務(wù)器進(jìn)行綜合性能分析，找出系統(tǒng)瓶頸，為調(diào)優(yōu)或提高性能提供依據(jù)。1.2.3

模型的使用方法“全面性能測(cè)試模型”是針對(duì)性能測(cè)試而提出的一種方法，主要是為了比較全面地開展性能測(cè)試，使性能測(cè)試更容易組織和開展。本模型包含了測(cè)試策略制定的通用方法和測(cè)試用例設(shè)計(jì)的通用方案。其中測(cè)試用例的設(shè)計(jì)覆蓋了應(yīng)用軟件、服務(wù)器、操作系統(tǒng)等多方面內(nèi)容，按照由淺入深的層次對(duì)性能測(cè)試進(jìn)行合理的組織?！叭嫘阅軠y(cè)試模型”是一種從很多性能測(cè)試項(xiàng)目抽象出來(lái)的方法論，主要用來(lái)指導(dǎo)測(cè)試，一般不適合具體的性能測(cè)試項(xiàng)目，因?yàn)槿魏我粋€(gè)項(xiàng)目都會(huì)有它的特定背景。要想通過“全面性能測(cè)試模型”做好性能測(cè)試工作，首先要制定好性能測(cè)試策略，同時(shí)還要按照一些基本指導(dǎo)原則來(lái)使用“性能測(cè)試用例模型”的內(nèi)容。這些原則主要包括如下內(nèi)容：l

測(cè)試策略遵從最低成本原則。全面性能測(cè)試本身是一種高投入的測(cè)試，而很多公司在測(cè)試上的投入都比較低；性能測(cè)試同時(shí)又是全部測(cè)試工作的一部分，很多項(xiàng)目只能進(jìn)行一些重要的性能測(cè)試內(nèi)容。這就決定了測(cè)試負(fù)責(zé)人制定性能測(cè)試策略時(shí)在資源投入方面一定要遵從最低成本化原則。最低成本的衡量標(biāo)準(zhǔn)主要指“投入的測(cè)試成本能否使系統(tǒng)滿足預(yù)先確定的性能目標(biāo)”。只要經(jīng)過反復(fù)的“測(cè)試—系統(tǒng)調(diào)優(yōu)—測(cè)試”后，系統(tǒng)符合性能需求并有一定的擴(kuò)展空間，就可以認(rèn)為性能測(cè)試工作是成功的。反之，如果系統(tǒng)經(jīng)過測(cè)試后不能滿足性能需求或滿足性能需求后仍須繼續(xù)投入資源進(jìn)行測(cè)試，則可以認(rèn)為是不合理的。l

策略為中心原則。本原則不但對(duì)性能測(cè)試工作有效，對(duì)其他類型的測(cè)試工作同樣具有指導(dǎo)意義。測(cè)試策略不但決定了測(cè)試用例設(shè)計(jì)的主要內(nèi)容，還決定著實(shí)施測(cè)試工作時(shí)如何根據(jù)項(xiàng)目的實(shí)際情況進(jìn)行處理。例如當(dāng)項(xiàng)目時(shí)間比較緊張時(shí)，就可以按照測(cè)試用例的優(yōu)先級(jí)只執(zhí)行一部分性能測(cè)試用例。因此，性能測(cè)試策略應(yīng)該貫穿整個(gè)性能測(cè)試的全過程。l

適當(dāng)裁剪原則。裁剪原則主要是針對(duì)性能用例設(shè)計(jì)而言的。性能測(cè)試用例設(shè)計(jì)模型主要是針對(duì)電信、銀行等特殊領(lǐng)域的應(yīng)用而提出的，包含的測(cè)試內(nèi)容比較全面，而這類項(xiàng)目的性能測(cè)試一般周期較長(zhǎng)、投入較大。一些銀行項(xiàng)目的性能測(cè)試周期可能會(huì)超過一年。要想性能測(cè)試用例設(shè)計(jì)模型在大多數(shù)測(cè)試項(xiàng)目中適用，就必須對(duì)測(cè)試用例模型包含的內(nèi)容進(jìn)行合理的裁剪。這樣做主要是為了適合特定項(xiàng)目的測(cè)試需求，進(jìn)而節(jié)約測(cè)試成本。裁減的主要依據(jù)是性能測(cè)試策略。根據(jù)策略制定方法制定出測(cè)試策略，然后從“5類性能測(cè)試用例”中選擇適當(dāng)?shù)念悇e來(lái)編寫測(cè)試用例。例如有些要求不高的靜態(tài)門戶網(wǎng)站，用戶沒有提出性能方面的要求，可以只測(cè)試用戶并發(fā)情況作為系統(tǒng)性能的參考。l

完善模型原則。本模型只是作者工作經(jīng)驗(yàn)的總結(jié)，由于性能測(cè)試任務(wù)都有自己的項(xiàng)目背景，因而需要對(duì)模型內(nèi)容進(jìn)行不斷的調(diào)整、補(bǔ)充、完善，使之適合更多的性能測(cè)試工作。具體來(lái)說，不斷完善就是要在工作中不斷總結(jié)經(jīng)驗(yàn)，形成自己的“全面性能測(cè)試模型”。只有“自己的”測(cè)試模型，才是最符合需要的模型。l

模型具體化原則。模型具體化是指把模型運(yùn)用到具體的項(xiàng)目中去，這是前面所有指導(dǎo)原則的終極目標(biāo)。如果只記住模型的條條框框，生搬硬套框架來(lái)設(shè)計(jì)測(cè)試，只能得到適得其反的結(jié)果。要想使模型在性能測(cè)試工作中發(fā)揮作用，只有根據(jù)實(shí)際項(xiàng)目的特點(diǎn)制定合理的性能測(cè)試策略、編寫適當(dāng)?shù)男阅軠y(cè)試用例，并在測(cè)試實(shí)施中靈活地執(zhí)行測(cè)試方案才是上策。綜合上面的分析可以看出，模型的使用可以概括為兩個(gè)字——活用。要想真正做好性能測(cè)試工作，最有效的辦法就是在掌握基本理論和方法后，在工作中不斷地探索和總結(jié)，形成自己的“全面性能測(cè)試模型”。1.3

性能測(cè)試調(diào)整基礎(chǔ)所謂性能測(cè)試調(diào)整是為了改善系統(tǒng)某些方面的性能而對(duì)系統(tǒng)軟件或硬件進(jìn)行的修改。性能調(diào)整不是測(cè)試人員的職責(zé)，性能測(cè)試工程師的主要任務(wù)是發(fā)現(xiàn)并定位性能問題。對(duì)于性能測(cè)試中發(fā)現(xiàn)的問題，通常由性能測(cè)試工程師、DBA、系統(tǒng)管理員、開發(fā)人員共同來(lái)解決。但是對(duì)于測(cè)試人員，了解調(diào)整的相關(guān)知識(shí)則是十分必要的。在性能測(cè)試工作中經(jīng)常會(huì)提到“性能調(diào)優(yōu)”或“系統(tǒng)調(diào)優(yōu)”等概念。實(shí)際上，“性能調(diào)優(yōu)”或“系統(tǒng)調(diào)優(yōu)”只是性能調(diào)整的一部分內(nèi)容。例如，可能為了讓某些部分“更優(yōu)”而把某些部分調(diào)得“不優(yōu)”，因此本書使用“性能調(diào)整”這一說法。本節(jié)主要討論性能調(diào)整的基礎(chǔ)知識(shí)。性能調(diào)整應(yīng)該按照一定的順序進(jìn)行，主要包括下面五個(gè)步驟：確定問題首先根據(jù)測(cè)試結(jié)果確定系統(tǒng)是否存在問題，重點(diǎn)是發(fā)現(xiàn)系統(tǒng)的瓶頸。如果存在，就應(yīng)該確定是什么問題，并對(duì)問題進(jìn)行正確的定位。確定系統(tǒng)問題可從下面幾個(gè)方面入手：l

檢查應(yīng)用程序代碼：通常情況下，很多程序的性能問題都是“寫”出來(lái)的。因此對(duì)于發(fā)現(xiàn)瓶頸的模塊，應(yīng)該首先檢查代碼；l

調(diào)整數(shù)據(jù)庫(kù)配置：數(shù)據(jù)庫(kù)配置經(jīng)常會(huì)引起整個(gè)系統(tǒng)運(yùn)行緩慢，一些諸如Oracle的大型數(shù)據(jù)庫(kù)都需要DBA進(jìn)行正確的參數(shù)調(diào)整才能投產(chǎn)；l

調(diào)整操作系統(tǒng)配置：操作系統(tǒng)配置不合理也可能引起系統(tǒng)瓶頸；l

檢查硬件設(shè)置：磁盤速度、內(nèi)存大小等都是引起瓶頸的原因，因此這些也是分析的重點(diǎn)；l

檢查網(wǎng)絡(luò)：網(wǎng)絡(luò)負(fù)載過重會(huì)導(dǎo)致網(wǎng)絡(luò)沖突和網(wǎng)絡(luò)延遲。同時(shí)，還要對(duì)系統(tǒng)的使用情況進(jìn)行調(diào)查，例如：l

是否聽到了很多用戶的抱怨？l

某些操作的響應(yīng)時(shí)間是否隨著使用時(shí)間的增長(zhǎng)而增長(zhǎng)？l

CPU的使用率是否很低而I/O的使用率卻很高？l

使用過程中性能是否穩(wěn)定？系統(tǒng)性能問題不是顯而易見的，要仔細(xì)查找才能正確地定位。確定原因確定系統(tǒng)存在問題后就要仔細(xì)進(jìn)行分析，進(jìn)而確定引起問題的原因。確定原因很大程度上靠的是團(tuán)隊(duì)的經(jīng)驗(yàn)和技術(shù)能力，涉及的知識(shí)有操作系統(tǒng)、數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)、程序開發(fā)等許多方面。和確定性能問題一樣，確定原因仍然要廣泛地搜集信息。通常要進(jìn)行以下的分析：l

問題的影響是什么：響應(yīng)速度還是吞吐量，或者其他問題？l

是大多數(shù)用戶還是少數(shù)用戶遇到了問題？如果是少數(shù)用戶，這幾個(gè)用戶與其他用戶的操作有什么不同？l

系統(tǒng)資源監(jiān)控的結(jié)果是否正常，如CPU的使用是否到了極限？I/O情況如何？l

問題是否集中在某一類模塊中？l

是客戶端還是服務(wù)器出現(xiàn)問題？l

系統(tǒng)硬件配置是否合理？l

實(shí)際負(fù)載是否超過了系統(tǒng)的負(fù)載能力？l

是否未對(duì)系統(tǒng)進(jìn)行優(yōu)化？通過這些分析以及系統(tǒng)的一些具體表現(xiàn)，可以對(duì)系統(tǒng)瓶頸有更深入的了解，進(jìn)而分析出真正的原因。確定調(diào)整目標(biāo)和解決方案在分析出問題發(fā)生的原因后，測(cè)試人員和系統(tǒng)調(diào)整人員首先要確定調(diào)整目標(biāo)，然后設(shè)計(jì)解決方案。確定調(diào)整目標(biāo)的主要作用是明確何時(shí)停止系統(tǒng)調(diào)整，否則工作將永無(wú)盡頭。每個(gè)系統(tǒng)都有不同的特點(diǎn)，因此調(diào)整目標(biāo)可能各有不同。例如，下面這些都是系統(tǒng)的調(diào)整目標(biāo)：l

提高系統(tǒng)吞吐量；l

縮短響應(yīng)時(shí)間；l

更好地支持并發(fā)；設(shè)計(jì)解決方案的主要依據(jù)就是這些調(diào)整目標(biāo)。有了明確的方案和目標(biāo)，就可以進(jìn)行后面的工作了。測(cè)試解決方案實(shí)施解決方案后，就要對(duì)方案進(jìn)行測(cè)試?？梢允褂靡郧暗臏y(cè)試用例來(lái)進(jìn)行測(cè)試，驗(yàn)證系統(tǒng)是否解決了性能問題。測(cè)試解決方案盡量要在仿真環(huán)境下進(jìn)行，因?yàn)樵谏a(chǎn)環(huán)境下可能會(huì)帶來(lái)破壞，除非充分估計(jì)了測(cè)試的風(fēng)險(xiǎn)，并且準(zhǔn)備了萬(wàn)全的補(bǔ)救方案。分析調(diào)整結(jié)果性能調(diào)整的最后一步是分析調(diào)整結(jié)果，如果問題沒有得到解決，則要重復(fù)前面的工作。在測(cè)試系統(tǒng)調(diào)整方案過程中，要經(jīng)常分析所做的工作。如果沒能準(zhǔn)確定位問題或調(diào)整方案不正確，可能會(huì)達(dá)不到預(yù)期目標(biāo)。要盡早發(fā)現(xiàn)這些錯(cuò)誤，以使工作早些回到正確的軌道上來(lái)。分析結(jié)果時(shí)主要考慮下面的問題：l

系統(tǒng)調(diào)整是否達(dá)到或超出了預(yù)定目標(biāo)？l

系統(tǒng)是整體性能得到了改善，還是犧牲了某部分性能來(lái)解決問題的？l

調(diào)整是否可以結(jié)束了？達(dá)到預(yù)期目標(biāo)后，調(diào)整工作基本就可以結(jié)束了。1.4

如何做好性能測(cè)試多數(shù)企業(yè)都想使產(chǎn)品獲得高性能，以降低投產(chǎn)后的風(fēng)險(xiǎn)。但是現(xiàn)實(shí)中的性能測(cè)試工作卻經(jīng)常不受重視，常會(huì)碰到“走過場(chǎng)”或“拖到整個(gè)項(xiàng)目最后進(jìn)行”的情況，甚至有時(shí)會(huì)做很多無(wú)意義的性能測(cè)試。此外，多數(shù)企業(yè)的測(cè)試人員能力水平不高，這也是導(dǎo)致性能測(cè)試不過關(guān)的原因。根據(jù)作者多年的經(jīng)驗(yàn)，要想做對(duì)性能測(cè)試應(yīng)該從管理與技術(shù)兩個(gè)方面入手。按照規(guī)范的管理流程開展測(cè)試工作軟件性能的低下很多時(shí)候是由于系統(tǒng)架構(gòu)設(shè)計(jì)不好或代碼效率低下而引起的，如果上線后發(fā)現(xiàn)性能問題往往已很難補(bǔ)救。因此性能測(cè)試應(yīng)該按照規(guī)范的流程來(lái)執(zhí)行，盡量把問題消滅在產(chǎn)品上線以前。根據(jù)多數(shù)企業(yè)的實(shí)際情況，性能測(cè)試應(yīng)該分為開發(fā)與用戶現(xiàn)場(chǎng)兩個(gè)階段來(lái)進(jìn)行。嚴(yán)格地講，性能測(cè)試應(yīng)該按照測(cè)試環(huán)境的軟、硬件配置高低分為兩個(gè)階段。只是由于開發(fā)階段的軟、硬件配置相對(duì)較低，而用戶現(xiàn)場(chǎng)的投產(chǎn)環(huán)境軟、硬件配置較高，因此才把性能測(cè)試分為開發(fā)與用戶現(xiàn)場(chǎng)兩個(gè)階段。對(duì)于擁有先進(jìn)實(shí)驗(yàn)設(shè)備甚至實(shí)驗(yàn)室的公司，完全可以在開發(fā)階段完成全部的性能測(cè)試工作，如果用戶現(xiàn)場(chǎng)仍要進(jìn)行性能測(cè)試，則只是簡(jiǎn)單的驗(yàn)收測(cè)試而已。l

開發(fā)階段的性能測(cè)試實(shí)施

開發(fā)階段的性能測(cè)試主要指軟件試運(yùn)行前的性能測(cè)試，即團(tuán)隊(duì)內(nèi)部的性能測(cè)試。這一階段的性能測(cè)試是一個(gè)反復(fù)迭代的過程。性能測(cè)試不是特別重要的項(xiàng)目，這一階段的性能測(cè)試較多關(guān)注于軟件功能而引起的缺陷。因此主要進(jìn)行用戶并發(fā)性能測(cè)試，即核心模塊并發(fā)用戶測(cè)試與組合模塊并發(fā)用戶測(cè)試。此外，可能還會(huì)進(jìn)行一些預(yù)期性能指標(biāo)的性能測(cè)試。通過開發(fā)階段的性能測(cè)試可以發(fā)現(xiàn)一些核心算法問題，最大限度地排除由軟件本身引起的問題。對(duì)于系統(tǒng)類軟件或特殊應(yīng)用系統(tǒng)的性能測(cè)試，解決其性能問題可能很耗時(shí)，所以應(yīng)該較早地組織硬件資源進(jìn)行各類性能測(cè)試，例如疲勞強(qiáng)度與大數(shù)據(jù)量測(cè)試、服務(wù)器性能測(cè)試等。l

用戶現(xiàn)場(chǎng)性能測(cè)試的實(shí)施

用戶現(xiàn)場(chǎng)的性能測(cè)試有驗(yàn)收測(cè)試的“味道”，是開發(fā)階段性能測(cè)試工作的延續(xù)。這一階段的性能重點(diǎn)是關(guān)注性能測(cè)試的整體表現(xiàn)。可以看出，用戶現(xiàn)場(chǎng)的性能測(cè)試主要是為了驗(yàn)收與調(diào)優(yōu)。因此對(duì)于系統(tǒng)軟件和特殊應(yīng)用系統(tǒng)，性能測(cè)試應(yīng)該盡可能全方位覆蓋。而對(duì)于一般應(yīng)用系統(tǒng)，由于風(fēng)險(xiǎn)較低，所以測(cè)試范圍可以適當(dāng)縮小以節(jié)省成本。用戶現(xiàn)場(chǎng)的性能測(cè)試主要基于投產(chǎn)環(huán)境，測(cè)試對(duì)象多是即將準(zhǔn)備投產(chǎn)的系統(tǒng)，甚至可能是已經(jīng)投產(chǎn)的系統(tǒng)。投產(chǎn)環(huán)境的硬件資源配置通常較高，各類性能測(cè)試基本都可以開展。對(duì)于系統(tǒng)軟件和特殊領(lǐng)域的應(yīng)用系統(tǒng)，這一階段的性能測(cè)試主要包含預(yù)期指標(biāo)性能測(cè)試、并發(fā)用戶性能測(cè)試、各類服務(wù)器性能測(cè)試、疲勞強(qiáng)度與大數(shù)據(jù)量性能測(cè)試等內(nèi)容，基本覆蓋了“全面性能測(cè)試模型”的各個(gè)方面。與開發(fā)階段的性能測(cè)試相比，本階段執(zhí)行的性能測(cè)試用例數(shù)量可能會(huì)少一些，但是測(cè)試用例覆蓋的范圍與開發(fā)階段的性能測(cè)試基本一致。一般應(yīng)用系統(tǒng)在用戶現(xiàn)場(chǎng)的性能測(cè)試通常包含預(yù)期指標(biāo)性能測(cè)試與用戶并發(fā)性能測(cè)試，可能也會(huì)對(duì)服務(wù)器進(jìn)行一定的測(cè)試，不過內(nèi)容通常比較簡(jiǎn)單。一般應(yīng)用系統(tǒng)發(fā)生性能問題的風(fēng)險(xiǎn)通常不會(huì)太高，因此只要通過驗(yàn)收測(cè)試即可。這兩個(gè)階段的性能測(cè)試都應(yīng)該按照“需求分析—規(guī)劃與設(shè)計(jì)—執(zhí)行—調(diào)優(yōu)—驗(yàn)證”的順序來(lái)執(zhí)行。提高測(cè)試人員在性能測(cè)試方面的技能很多時(shí)候，由于性能測(cè)試人員水平較低，即使進(jìn)行了測(cè)試也不能發(fā)現(xiàn)系統(tǒng)潛在的問題，而最終把問題留給了用戶。因