性能測試進(jìn)階指南：Loadrunner實(shí)戰(zhàn)91-第1章 性能測試基礎(chǔ)

1、.：.； 目錄 TOC o 1-3 h z u HYPERLINK l _Toc297915338 第一章 性能測試根底 PAGEREF _Toc297915338 h 2 HYPERLINK l _Toc297915339 1.1 性能測試工程師的規(guī)范及挑戰(zhàn) PAGEREF _Toc297915339 h 2 HYPERLINK l _Toc297915340 1.1.1 性能測試工程考評目的 PAGEREF _Toc297915340 h 2 HYPERLINK l _Toc297915341 1.1.2 性能測試工程師的挑戰(zhàn) PAGEREF _Toc297915341 h 3 HYPER

2、LINK l _Toc297915342 1.2 性能測試根底 PAGEREF _Toc297915342 h 5 HYPERLINK l _Toc297915343 1.2.1 性能 PAGEREF _Toc297915343 h 5 HYPERLINK l _Toc297915344 1.2.2 性能目的 PAGEREF _Toc297915344 h 16 HYPERLINK l _Toc297915345 1.2.3 性能分析及調(diào)優(yōu) PAGEREF _Toc297915345 h 17 HYPERLINK l _Toc297915346 1.2.4 單機(jī)軟件性能與網(wǎng)絡(luò)架構(gòu)軟件 PAGE

3、REF _Toc297915346 h 22 HYPERLINK l _Toc297915347 1.2.5 性能測試的流程 PAGEREF _Toc297915347 h 23 HYPERLINK l _Toc297915348 1.2.6 性能測試的留意要點(diǎn) PAGEREF _Toc297915348 h 24 HYPERLINK l _Toc297915349 1.2.7 性能測試招聘要求 PAGEREF _Toc297915349 h 25 HYPERLINK l _Toc297915350 小結(jié) PAGEREF _Toc297915350 h 26第一章 性能測試根底軟件測試逐漸成為

4、軟件開發(fā)過程中一個必不可少的環(huán)節(jié)，隨著功能測試的必要性被認(rèn)可，自動化測試和性能測試也逐漸嶄露頭角。我們經(jīng)常會埋怨閱讀網(wǎng)頁慢、下載文件慢，其實(shí)這都是屬于性能問題。用戶在得益于功能方面的質(zhì)量提升后，開場對性能有了新的認(rèn)識和要求，而性能測試并不像功能測試那樣可以“低門檻進(jìn)展。性能測試的本質(zhì)是經(jīng)過編寫一個程序去測試另外一個程序，而正是有了這個相對的“高門檻，性能測試便成了一個“高薪、“高技術(shù)含量的任務(wù)，新人在看到高手指點(diǎn)江山(性能測試)時，充溢了羨慕的眼神，摩拳擦掌預(yù)備進(jìn)入這個行業(yè)。在開場從事性能測試任務(wù)之前，我們先來看看這個職位的考核規(guī)范和面臨的挑戰(zhàn)。1.1 性能測試工程師的規(guī)范及挑戰(zhàn)當(dāng)他掌握了性能

5、測試的根本技藝，接著就需求找到一家適宜的企業(yè)，經(jīng)過勞動換取經(jīng)濟(jì)上的報答，那么通常公司如何去招聘一個性能測試工程師，并如何進(jìn)展績效考評呢?即性能測試工程師應(yīng)該到達(dá)的任務(wù)目的究竟是什么?1.1.1 性能測試工程考評目的在引見性能測試之前，我們回想一下功能測試的考評和任務(wù)內(nèi)容。假設(shè)他是一名功能測試經(jīng)理，該如何考評他的員工呢?當(dāng)軟件測試剛剛進(jìn)入中國時，我們對測試的了解是經(jīng)過模擬用戶執(zhí)行，發(fā)現(xiàn)用戶能夠遇到的問題，而缺陷的數(shù)目成了考評的獨(dú)一目的。例如PM(Project Manager)規(guī)定，每個測試人員每天都要發(fā)現(xiàn)10個以上的缺陷，否那么闡明他在任務(wù)態(tài)度和任務(wù)才干上有一定的缺陷。綜上，作為一名功能測試工

6、程師，其考評要求可以歸結(jié)為一條，那就是測試經(jīng)過的軟件不會被用戶發(fā)現(xiàn)嚴(yán)重的缺陷。而如今，軟件測試逐漸正名，我們對測試的了解從證明軟件沒有錯誤變?yōu)樽C明軟件具備一定的質(zhì)量，而功能測試工程師的考評規(guī)范也隨之發(fā)生了變化。功能測試工程師的考評目的主要有以下幾點(diǎn)：缺陷數(shù)目缺陷的數(shù)目雖然不能作為主要的考評目的，但是從某一個角度也闡明了測試工程師發(fā)現(xiàn)問題的才干。在成熟的軟件開發(fā)公司中，我們可以經(jīng)過歷史數(shù)據(jù)生成的缺陷質(zhì)量模型準(zhǔn)確預(yù)估缺陷數(shù)目。假設(shè)他發(fā)現(xiàn)的缺陷數(shù)量明顯低于預(yù)估，那么闡明他的任務(wù)能夠存在一定問題。2缺陷質(zhì)量有量沒有質(zhì)是不行的，由于計(jì)件制的壓迫，測試人員往往為了到達(dá)數(shù)目上的目的而湊缺陷，數(shù)目是夠了，但是

7、所提的缺陷都是雞毛蒜皮的事情，缺陷的危害等級和優(yōu)先級都比較低，那么對軟件質(zhì)量的提升效果會相對較差。在缺陷的質(zhì)量中包含兩個概念：缺陷的嚴(yán)重等級和優(yōu)先級對缺陷的描畫3任務(wù)態(tài)度測試任務(wù)是一個很容易“偷懶的任務(wù)，是需求個人積極自動、追求完美的任務(wù)，對于測試工程師，只需具備擅長交流、積極自動、“視公為私的態(tài)度才干對被測對象擔(dān)任。4任務(wù)效率在較短的時間內(nèi)能否可以高質(zhì)量完成上級布置義務(wù)的才干。5文檔編寫過去所謂的軟件測試工程師只是軟件測試執(zhí)行工程師，如今被稱為Tester。如今測試工程師還需求進(jìn)展測試方案、測試方案及用例等文檔的編寫任務(wù)。6團(tuán)隊(duì)協(xié)作才干7其他相關(guān)技藝性能測試在國內(nèi)剛剛開場流行。一個公司招聘性

8、能測試工程師的主要目的是經(jīng)過對產(chǎn)品進(jìn)展專業(yè)的性能測試，獲得一份性能測試評價報告，從而向用戶證明本產(chǎn)品可以滿足預(yù)期的性能需求。隨著性能測試職位的逐漸成熟，對這個職位的要求也越來越嚴(yán)厲，性能測試的目的不僅僅是為了獲得當(dāng)前系統(tǒng)的性能評價，而是希望進(jìn)一步經(jīng)過性能測試發(fā)現(xiàn)系統(tǒng)性能瓶頸并修復(fù)性能問題。而性能問題的修復(fù)本錢普通相對較高，如何運(yùn)用最低的本錢換取最高的性能，從而在性價比上找到黃金分割點(diǎn)，將是性能調(diào)優(yōu)的重點(diǎn)。性能測試工程師的考評目的會包括以下內(nèi)容：1能否可以獨(dú)立開發(fā)腳本能否運(yùn)用一種或多種性能測試工具完成用戶行為的模擬腳本開發(fā)任務(wù)。2能否對需求進(jìn)展性能分析并獲得性能需求任何測試都是基于需求的。作為一

9、名性能測試工程師，需求具備一定的性能需求分析才干，從而根據(jù)用戶的需求進(jìn)展性能測試，得到被測系統(tǒng)與用戶需求之間的差距，從而生成性能報告并提供性能調(diào)優(yōu)方案。3能否設(shè)計(jì)場景及監(jiān)控負(fù)載系統(tǒng)完成對性能測試的實(shí)施和監(jiān)控任務(wù)對性能測試進(jìn)展實(shí)施，設(shè)計(jì)負(fù)載規(guī)那么并監(jiān)控負(fù)載下各個系統(tǒng)的形狀。4能否經(jīng)過性能測試發(fā)現(xiàn)比較詳細(xì)的性能瓶頸具備一定的性能結(jié)果分析及瓶頸定位才干。5文檔編寫與環(huán)境搭建的才干獨(dú)立編寫性能測試文檔和搭建測試環(huán)境的才干。6團(tuán)隊(duì)協(xié)作才干7其他相關(guān)技藝1.1.2 性能測試工程師的挑戰(zhàn)作為任務(wù)了幾年的功能測試工程師來說，大家覺得在功能測試任務(wù)中的挑戰(zhàn)是什么呢?1公司不注重測試2就我一個人做測試3找不到缺陷

10、4開發(fā)工程師不能及時修正測試中發(fā)現(xiàn)的缺陷5不熟習(xí)業(yè)務(wù)6不了解功能測試的方法及流程總結(jié)來說就是任務(wù)內(nèi)容略感反復(fù)、缺乏技術(shù)含量，并且在有限的時間和資源下難以到達(dá)理想化的目的。在實(shí)踐任務(wù)中，要確保軟件沒有缺陷是比較困難的，這是由于：1軟件不能夠不存在缺陷2測試無法發(fā)現(xiàn)一切缺陷3測試在大多數(shù)情況下都沒有足夠的資源和時間(在本錢和質(zhì)量上尋求平衡)所以無法完全保證整個軟件在交付時不存在缺陷。雖然可以經(jīng)過各種方法將嚴(yán)重級別或者優(yōu)先級別較高的問題發(fā)現(xiàn)并修復(fù)，但由于個人才干或客觀緣由還是會遺留某些缺陷。那么作為一個性能測試工程師所面臨的挑戰(zhàn)又有哪些呢?1對性能測試的實(shí)際和技術(shù)不熟習(xí)2公司不注重性能測試3就我一個

11、人做性能測試4測試出來的結(jié)果不知道怎樣分析5不熟習(xí)業(yè)務(wù)6定位出的性能問題無法修正總結(jié)來說，就是如何在有限的時間和資源下，保證提交給用戶的軟件系統(tǒng)可以到達(dá)指定的性能需求目的。從某種角度來說，如今性能測試的效果被過度放大了。以功能測試為例，最初軟件是無須測試的，由于軟件功能單一，而軟件質(zhì)量是依賴于有閱歷的開發(fā)人員本人進(jìn)展維護(hù)，隨著開發(fā)規(guī)模的逐漸擴(kuò)展，軟件越來越復(fù)雜，隨之質(zhì)量逐漸下降，這時功能測試的低本錢效果就出現(xiàn)了。各大公司開場大規(guī)模地成立測試部門，隨著功能測試部門的規(guī)模逐漸擴(kuò)展，其效率開場不斷下降，依賴于功能測試提高質(zhì)量的性價比逐漸降低，而如今大家都認(rèn)識到功能測試并不是萬能的，其主要作用是保證軟

12、件到達(dá)一定的質(zhì)量，經(jīng)過自動化可以降低功能測試的本錢。性能測試也處在這樣一個過程中，由于客戶日趨成熟，逐漸認(rèn)識到性能是繼功能后另一個重要的質(zhì)量目的，而我們經(jīng)常錯誤地以為性能測試就是滿足用戶性能需求的靈丹妙藥，掌握了性能測試仿佛就走在了軟件測試技術(shù)的最高端，卻忽略了去思索性能測試究竟能做些什么。性能問題并不像功能問題那么棘手，由于幾乎常見的性能問題都可以經(jīng)過硬件處理，也就是花點(diǎn)兒錢買個更加強(qiáng)力的硬件配置來提高軟件的效率，其次經(jīng)過性能測試后發(fā)現(xiàn)了性能瓶頸(普通性能瓶頸都是較為底層的問題)，修復(fù)的本錢和風(fēng)險也是需求思索的問題。好比功能測試在最后的BETA測試中發(fā)現(xiàn)了一個異常嚴(yán)重的功能問題，而該問題是由

13、于引擎所導(dǎo)致的，改還是不改呢?功能是必需求進(jìn)展修正的，假設(shè)不修正用戶無法正常運(yùn)用，但是從性能角度來說，系統(tǒng)處置速度慢一點(diǎn)往往還是可以接受的。往往出現(xiàn)花了很多錢進(jìn)展性能測試，并且發(fā)現(xiàn)了性能問題，但是修復(fù)該性能缺陷的本錢或風(fēng)險太高，最終不得不放棄。性能測試無非就是以相對較低的本錢模擬一個真實(shí)環(huán)境來了解系統(tǒng)上線后的性能情況，至于定位、分析及調(diào)優(yōu)，這需求一個團(tuán)隊(duì)的支持才干完成，所以軟件的性能問題不是簡簡單單靠最后進(jìn)展幾次性能測試就能定位處理的。1.2 性能測試根底1.2.1 性能性能的定義在新華字典中可以查詢到這樣的解釋：性能指器物所具有的性質(zhì)與成效。這個定義中包括了以下兩層含義：性質(zhì)性質(zhì)是指該器物具

14、有什么特性，可以做什么。成效是指該器物可以干得怎樣樣。在我們身邊的性能有哪些呢?F1賽事從競技競賽的角度來說，在競賽中獲勝的一方性能較好，那么是不是性能只包括速度呢?不是F1競賽并不是直道跑1000米，而是有很多轉(zhuǎn)彎，而且賽程也較長。車速并不是獲得冠軍的獨(dú)一目的，而車胎的類型、進(jìn)出站的次數(shù)、駕車選手的發(fā)揚(yáng)等條件組合在一同才是一個冠軍誕生的根底。個人電腦個人電腦的性能指什么呢?用起來比較快?看起來比較美麗?我們通常說電腦的性能是指運(yùn)轉(zhuǎn)常用軟件的反響迅速，但是僅僅擁有一顆高級的芯，電腦一定可以性能出眾嗎?不一定，這還取決于存儲器、顯卡等相關(guān)設(shè)備。針對CPU來說，主頻也并不是闡明CPU性能的獨(dú)一目的

15、，并不是說CPU的頻率越高，其計(jì)算速度越快。例如：如今有兩塊CPU，一塊是奔騰V3.0c主頻3GHz，另外一塊是酷睿2 T7200主頻2GHz，顯然T7200的性能遠(yuǎn)遠(yuǎn)優(yōu)于奔騰V。軟件單位時間內(nèi)能處置的業(yè)務(wù)、處置一個運(yùn)算所需求破費(fèi)的時間、翻開該軟件需求的時間，都能作為衡量軟件性能的目的。例如在一樣的電腦配置下分別安裝Windows XP和Windows Vista操作系統(tǒng)。在這兩個操作系統(tǒng)中復(fù)制大量文件至挪動硬盤時，就會發(fā)如今Vista下進(jìn)展一樣的操作會比XP慢很多，這個時候就會說在該硬件配置下Vista的磁盤讀寫性能相對XP較差。失敗案例為什么忽然開場如此注重性能測試呢?那是由于閱歷了太多慘

16、痛的閱歷，讓我們不得不注重這個以前被忽視的問題。接著來回想一下發(fā)生在2007年的一件由于性能測試缺乏而導(dǎo)致的慘痛案例奧運(yùn)會訂票系統(tǒng)癱瘓。2021年8月，對于全國人民來說，沒有什么比奧運(yùn)會更大的事情了。買到一張稱心如意的門票，也成了很多人的一個夢想。網(wǎng)上購票、先到先得、人人參與的戰(zhàn)略，讓大家覺得進(jìn)入鳥巢觀看開幕式，見證這歷史性的一刻成為能夠。然而當(dāng)大家在奧運(yùn)官方售票網(wǎng)上搶購門票時，這個夢想?yún)s被網(wǎng)上購票系統(tǒng)的癱瘓擊成碎片。我們來思索一個問題，作為一個奧運(yùn)訂票系統(tǒng)應(yīng)該會有多少人去買票呢?看一下當(dāng)時的新聞報道：境內(nèi)公眾啟動第二階段奧運(yùn)會門票預(yù)售。然而，為了讓更多的公眾實(shí)現(xiàn)奧運(yùn)夢想的“先到先得，售完為止

17、的銷售政策適得其反，公眾紛紛搶在第一時間訂票，致使票務(wù)官網(wǎng)壓力激增，接受了超越本身設(shè)計(jì)容量8倍的流量，導(dǎo)致系統(tǒng)癱瘓。超出8倍系統(tǒng)容量?那么接著來看看真正的系統(tǒng)容量是多少呢?昨天上午9點(diǎn)，預(yù)售一開場，公眾提交懇求空前積極。北京奧運(yùn)會官方票務(wù)網(wǎng)站的閱讀量在第一個小時內(nèi)到達(dá)800萬次，每秒鐘從網(wǎng)上提交的門票懇求超越20萬張；票務(wù)呼叫中心熱線的呼入量超越了380萬人次。由于瞬間訪問數(shù)量過大，技術(shù)系統(tǒng)應(yīng)對不暢，呵斥很多申購者無法及時提交懇求。一個小時訪問量到達(dá)800萬次，經(jīng)過計(jì)算可以得到平均每分鐘的訪問量約是12萬次，而每秒約是2000次。對比本身設(shè)計(jì)的每小時100萬次，每秒的訪問量預(yù)估為250次左右，

18、他是不是發(fā)現(xiàn)系統(tǒng)估計(jì)的訪問量少得可憐?作為一個門戶網(wǎng)站，Sina、Sohu每秒的訪問量是多少?需求是不是出了問題?作為百年一遇的奧運(yùn)會盛典，每個炎黃子孫都會希望親身在鳥巢感受奧運(yùn)開幕式的盛況，而一張奧運(yùn)會門票成了炙手可熱的香餑餑，由于采取的是先到先得的戰(zhàn)略，為了保證本人可以成為第一個進(jìn)入系統(tǒng)購票的用戶，我們需求確保本人以最快的速度進(jìn)展訂單的操作(提早預(yù)備用戶注冊、表單填寫、業(yè)務(wù)熟習(xí)、網(wǎng)絡(luò)調(diào)整、個人反響速度調(diào)整、等待好運(yùn)降臨)。當(dāng)?shù)竭_(dá)北京時間9點(diǎn)整，馬上單擊訂票按鈕。有少數(shù)人由于最先進(jìn)入系統(tǒng)，所以他們順利地訂票勝利，而更多用戶由于網(wǎng)絡(luò)的延時或者某些別的緣由，被堵在了系統(tǒng)的外面。在這種情況下就會產(chǎn)

19、生大量用戶并發(fā)訂票的操作。北京奧運(yùn)會官方票務(wù)網(wǎng)站的閱讀量在第一個小時到達(dá)800萬次，每秒鐘從網(wǎng)上提交的訂票懇求超越20萬張。從這句話可以看出，閱讀量和門票懇求的數(shù)量完全不是一個數(shù)量級，對應(yīng)每秒不過2000多次的閱讀量，系統(tǒng)卻接受了20萬張每秒的懇求量。這是由于絕大多數(shù)購票者都非常有閱歷，知道不能到9點(diǎn)鐘再來填寫訂票表單，而是應(yīng)該不斷地單擊提交按鈕將事先輸入的訂票信息提交給效力器。接著來分析一下假設(shè)想要訂到奧運(yùn)會的門票需求做哪些任務(wù)：用戶注冊當(dāng)然要先注冊訂票網(wǎng)站會員，并順便把銀行卡也預(yù)備好，確保支付順利。2表單的填寫在訂票開場前，先到奧運(yùn)會訂票系統(tǒng)上去，將要購買的開閉幕式、足球決賽等關(guān)鍵場次的表

20、單都預(yù)備好。3熟習(xí)業(yè)務(wù)整理并熟習(xí)整個購票的流程。4網(wǎng)絡(luò)調(diào)整對于整個開幕式來說，全國能夠有幾千萬的用戶在嘗試購票，而開幕式的門票一共也就3萬多張，對于如此多的需求(接近800萬的訪問量)只是杯水車薪，所以假設(shè)想要在這種供需嚴(yán)重不平衡的情況下獲得一張開幕式的門票，網(wǎng)速是一個非常重要的要素。每秒20萬的訂票懇求，也就是平均每毫秒200張。假設(shè)一個上海的網(wǎng)友和一個北京的網(wǎng)友同時在9點(diǎn)整購票，那么上海的兄弟就訂不到這張票了，由于上海電信到北京網(wǎng)通的平均延時都在200ms，按照剛剛的平均值來計(jì)算，曾經(jīng)賣掉4萬張票了。所以假設(shè)想要購買到門票，最好在北京機(jī)房進(jìn)展訂票，運(yùn)用光纖銜接，確保訂票信息到達(dá)效力器的延時

21、在1ms之內(nèi)，那么勝利的概率就會大大提升。5個人反映時間其實(shí)提交訂票信息也是有講究的，不同的人對于反映來說都有快慢之分，普通人在接受了信息到反映為動作能夠需求0406秒的時間，而經(jīng)過訓(xùn)練可以提升到0102秒，算算這是200毫秒的差距啊，又是4萬張票沒了，所以練練手速是很重要的一點(diǎn)，懂一些技術(shù)的朋友能夠會運(yùn)用按鍵精靈、QTP這類自動化工具來實(shí)現(xiàn)，將時間更加精準(zhǔn)地進(jìn)展控制，甚至可以思索做一點(diǎn)搶跑的操作。好，如今萬事俱備，時間一到9點(diǎn)，假設(shè)他是那個能在最短時間就將懇求發(fā)送到效力器的人，作為第一個沖入系統(tǒng)的用戶，就能順利地獲得想要預(yù)訂的門票。而假設(shè)他很不幸在9點(diǎn)鐘打了一個噴嚏，再去提交門票預(yù)訂懇求，那

22、么很負(fù)疚，1秒鐘過去了，有20萬人在他前面了。雖然整個系統(tǒng)在上線前進(jìn)展過性能測試，但由于錯誤的需求導(dǎo)致當(dāng)出現(xiàn)遠(yuǎn)遠(yuǎn)超出系統(tǒng)所能負(fù)載的訪問量時，系統(tǒng)來不及呼應(yīng)就癱瘓了。錯誤的需求是整個售票網(wǎng)站癱瘓的最大緣由。那么是不是需求做錯了，系統(tǒng)癱瘓就是理所當(dāng)然的呢?我們再來看看當(dāng)時的新聞解釋：從昨天上午8點(diǎn)左右開場，就有不少網(wǎng)民登錄票務(wù)官網(wǎng)排隊(duì)等待申購門票。據(jù)了解，從上午9點(diǎn)正式開場售票到中午12點(diǎn)的3個小時內(nèi)，票務(wù)網(wǎng)站的閱讀次數(shù)到達(dá)2000萬次。這與此次所提供的100萬次/小時的流量相差甚遠(yuǎn)。不停地刷新網(wǎng)頁，也是呵斥網(wǎng)絡(luò)擁堵的緣由之一。楊力說，不少網(wǎng)民在無法正常登錄后便不斷刷新，“這就相當(dāng)于一名申購者變成

23、了假設(shè)干名申購者，無形中增大網(wǎng)站流量。從技術(shù)角度上講，網(wǎng)站的流量幾乎呈幾何倍增長，導(dǎo)致其他申購者無法登錄。當(dāng)大量的用戶進(jìn)展訪問時，整個系統(tǒng)由于網(wǎng)絡(luò)瓶頸或處置瓶頸導(dǎo)致了擁堵，用戶無法訪問。既然沒有有效的網(wǎng)絡(luò)流量處置才干，假設(shè)進(jìn)展流量控制，問題就會被限制在一個可控的范圍內(nèi)。這好比一個銀行有大量人來取款，總不能聽之任之，而應(yīng)該有專人進(jìn)展協(xié)調(diào)管理，確保次序，并告知排在后面的顧客可以思索改天再來。導(dǎo)致奧運(yùn)會售票網(wǎng)站癱瘓的緣由是綜合的。假設(shè)當(dāng)時進(jìn)展了流量控制，那么可以保證登錄到效力器上的用戶可以比較正常地訪問，而超出效力器處置才干的用戶將無法進(jìn)入系統(tǒng)，從而確保系統(tǒng)不會由于負(fù)載過大而停頓呼應(yīng)。進(jìn)一步來說假設(shè)

24、剩下的用戶需求經(jīng)過排隊(duì)的方式來登錄效力器進(jìn)展購票，那么當(dāng)時為難的情況就不會出現(xiàn)。按照系統(tǒng)默許的處置才干，置信在兩個小時內(nèi)一定可以把一切的票都銷售終了。當(dāng)然，也需求以平常心來對待這個事情，作為恣意一家公司來說，開發(fā)和維護(hù)一個奧運(yùn)會門票系統(tǒng)都是有一定困難的，但是問題的出現(xiàn)通知我們，性能測試不是簡單做做就可以的，想要真正地處理性能問題需求留意以下幾個問題：1確定需求整個系統(tǒng)究竟有多少人會訪問?并發(fā)量會是多少?訪問集中在哪些業(yè)務(wù)上?根據(jù)這些需求進(jìn)展性能測試，即可保證系統(tǒng)在指定的目的下可以正常任務(wù)。如何獲得奧運(yùn)會訂票的真實(shí)需求呢?其實(shí)并不是很難。首先，在奧運(yùn)會第一次抽簽售票的過程中就能了解有多少人有意向

25、購票，由于中簽率非常低，那么沒有中簽的人一定會參與在線購票，所以可以得到一個比較不錯的訂票訪問量預(yù)估。其次，可以參考一下往屆奧運(yùn)會售票的閱歷和數(shù)據(jù)。最后，可以做一次模擬售票的測試，給予一定的獎勵號召大家都來嘗試一下(例如：頭200名注冊的用戶可以免費(fèi)獲贈一張門票，或者訂票尾號為多少的用戶獲贈門票)，確保在正常上線的情況下不出問題。奧運(yùn)會開幕式前就在鳥巢進(jìn)展了帶妝彩排，經(jīng)過這次性能測試了解了開幕式的真實(shí)情況，從而制定了引薦觀眾在開幕式前及早進(jìn)入場地且開幕式終了后先等待運(yùn)發(fā)動離場后觀眾再分批離場的戰(zhàn)略，確保不會出現(xiàn)擁堵的情況，這就是經(jīng)過性能測試發(fā)現(xiàn)問題并進(jìn)展修正的案例。2確保系統(tǒng)的強(qiáng)壯性系統(tǒng)應(yīng)該可

26、以在極端負(fù)載的情況下正常運(yùn)轉(zhuǎn)。這就好我們，不能由于生活壓力大就不任務(wù)了，可以任務(wù)效率低，但是不能不任務(wù)。3制定不測的處置方式在運(yùn)轉(zhuǎn)過程中有全面的監(jiān)控，并且針對各種不測制定詳細(xì)的應(yīng)急方案，才干確保系統(tǒng)有才干處置各種不測情況。對于能夠出現(xiàn)的訪問頂峰，置信很多網(wǎng)絡(luò)維護(hù)的朋友做過這樣的事情，將公司多余的效力器或者不常用的效力器騰出來，參與中心效力器的群集中，并且設(shè)置流量閾值，確保整個系統(tǒng)可以正常任務(wù)。當(dāng)出現(xiàn)網(wǎng)絡(luò)流量過大的情況時，可以經(jīng)過隊(duì)列等技術(shù)手段進(jìn)展處理。還記得我在Etang做SQA的時候，每次進(jìn)展CET查分的時候，公司都會將一切的效力器停下來，全部支持CET查分的業(yè)務(wù)。所以說，并不是奧運(yùn)會在線購

27、票的用戶懇求遠(yuǎn)遠(yuǎn)超出了我們的技術(shù)才干范圍才導(dǎo)致網(wǎng)站癱瘓。一些門戶網(wǎng)站在直播神七出倉時，其頁面的并發(fā)懇求會遠(yuǎn)遠(yuǎn)高于奧運(yùn)訂票網(wǎng)站的并發(fā)懇求，但是并沒有出現(xiàn)無法訪問或者呼應(yīng)時間較長的情況。性能測試上面談了什么是性能，忽視了性能會帶來怎樣的結(jié)果，那么什么是性能測試呢?性能測試的概念性能測試是系統(tǒng)測試的一種。作為一個優(yōu)秀的系統(tǒng)測試工程師，需求經(jīng)過“系統(tǒng)的視角來分析被測試系統(tǒng)，分析包含以下兩點(diǎn)：1功能測試：某個功能點(diǎn)2性能測試：整個系統(tǒng)，包括軟件和硬件在軟件質(zhì)量模型中，性能測試是屬于效率這一類的。我們先來了解一下這句話涉及的兩個概念。質(zhì)量模型：一組特性及特性之間的關(guān)系，它提供規(guī)定質(zhì)量需求和評價質(zhì)量的根底。

28、軟件效率(efficiency)：在規(guī)定條件下，相對于所用資源的數(shù)量，軟件產(chǎn)品可提供適當(dāng)性能的才干。其中資源能夠包括其他軟件產(chǎn)品、系統(tǒng)的軟件和硬件配置，以及物質(zhì)資料(如打印紙、磁盤等)。衡量一個軟件的性能，需求從軟件效率的以下3點(diǎn)思索：時間特性在規(guī)定條件下，軟件產(chǎn)品執(zhí)行其功能時，提供適當(dāng)?shù)暮魬?yīng)和處置時間以及吞吐率的才干。資源利用性在規(guī)定條件下，軟件產(chǎn)品執(zhí)行其功能時，運(yùn)用適宜數(shù)量和類別的資源的才干。效率依從性軟件產(chǎn)品遵照與效率相關(guān)的規(guī)范或商定的才干。也就是說我們需求確保軟件在一定的資源配置條件下到達(dá)一定的性能，并且遵守相關(guān)的規(guī)范或協(xié)議。例如我們從來不會奢望一臺80386的電腦可以在1分鐘內(nèi)啟動完

29、Windows Vista操作系統(tǒng)，由于我們知道其硬件不符合產(chǎn)品的規(guī)范。但是假設(shè)一臺高級的主流配置電腦在1分鐘內(nèi)無法完成Windows Vista操作系統(tǒng)的啟動，他就會開場疑心是不是本人的硬件存在某些問題，假設(shè)不是硬件問題，那么就會覺得這個操作系統(tǒng)很慢，性能很差。所以一個性能測試工程師的主要任務(wù)目的就是確保系統(tǒng)可以在一定的硬件、軟件環(huán)境下到達(dá)一定的性能目的。而性能測試(Performance Testing)的定義為：在一定的負(fù)載情況下，系統(tǒng)的呼應(yīng)時間等特性能否滿足特定的性能需求。從某些角度來說，性能其實(shí)是功能的一種。什么是負(fù)載?本書談到的性能問題都不是單機(jī)性能問題，而是基于網(wǎng)絡(luò)架構(gòu)(如C/S

30、架構(gòu)或者B/S架構(gòu))的性能問題。當(dāng)眾多終端用戶對系統(tǒng)進(jìn)展訪問時，用戶越多，那么效力器需求處置的客戶懇求也就越多，從而構(gòu)成了負(fù)載，而在這里負(fù)載的概念包含以下3點(diǎn)：1系統(tǒng)實(shí)踐用戶能夠會有很多人運(yùn)用同一個系統(tǒng)，但并不是一切的用戶都會同時運(yùn)用該系統(tǒng)，所以系統(tǒng)的實(shí)踐用戶是一個容量的問題，而不是負(fù)載的問題。2系統(tǒng)在線用戶當(dāng)系統(tǒng)用戶對系統(tǒng)進(jìn)展操作時，我們以為該用戶為在線用戶，這些用戶對系統(tǒng)構(gòu)成了負(fù)載，在線用戶和實(shí)踐用戶的比例是根據(jù)系統(tǒng)特性決議的。例如：對于電子郵件系統(tǒng)，每天上班后幾乎一切的實(shí)踐用戶都會進(jìn)展收取郵件的操作，這個時候在線用戶幾乎等于實(shí)踐用戶。而對于某網(wǎng)絡(luò)游戲來說，任務(wù)時間的在線用戶甚至缺乏一切用

31、戶的20。3并發(fā)操作用戶在線后會對系統(tǒng)產(chǎn)生負(fù)載，但是用戶和用戶之間的操作卻不是并發(fā)的，這是由于首先用戶的操作需求延時等待，其次每個用戶的操作并不是完全一樣。并發(fā)操作會對系統(tǒng)產(chǎn)生很大的負(fù)載，當(dāng)多個用戶同時對某個功能進(jìn)展操作時，效力器必需對這些懇求進(jìn)展隊(duì)列管理，依次處置。性能測試的分類性能測試的方法很多，名詞也很多，從運(yùn)用方便的角度來說，這里將性能測試分為6大種。負(fù)載測試(Load Testing)負(fù)載測試是指在一定的軟件、硬件及網(wǎng)絡(luò)環(huán)境下，運(yùn)轉(zhuǎn)一種或多種業(yè)務(wù)，在不同虛擬用戶數(shù)量的情況下，測試效力器的性能目的能否在用戶的要求范圍內(nèi)，以此確定系統(tǒng)所能承載的最大用戶數(shù)、最大有成效戶數(shù)以及不同用戶數(shù)下的

32、系統(tǒng)呼應(yīng)時間及效力器的資源利用率。負(fù)載測試強(qiáng)調(diào)的是在一定的環(huán)境下系統(tǒng)可以到達(dá)的峰值目的，大多數(shù)的性能測試都是負(fù)載測試。例如在各大網(wǎng)站上看到的各種顯卡測試，都是經(jīng)過運(yùn)轉(zhuǎn)3D Mark或者某種游戲得到的最終數(shù)據(jù)，經(jīng)過這個數(shù)據(jù)來闡明顯卡的峰值處置才干，這就是負(fù)載測試的一種方式。經(jīng)過運(yùn)轉(zhuǎn)EVEREST的性能測試功能對當(dāng)前硬件平臺下CPU Queen進(jìn)展負(fù)載測試，負(fù)載結(jié)果如圖1.1所示，最終得分為8392分。壓力測試(Stress Testing)壓力測試是指在一定的軟件、硬件及網(wǎng)絡(luò)環(huán)境下，模擬大量的虛擬用戶向效力器產(chǎn)生負(fù)載，使效力器的資源處于極限形狀下并長時間延續(xù)運(yùn)轉(zhuǎn)，以測試效力器在高負(fù)載情況下能否可

33、以穩(wěn)定任務(wù)。與負(fù)載測試獲得峰值性能數(shù)據(jù)不同，壓力測試強(qiáng)調(diào)在極端情況下系統(tǒng)的穩(wěn)定性，這個時候處置才干曾經(jīng)不重要了。例如在CPU超頻后經(jīng)常需求對系統(tǒng)的穩(wěn)定性進(jìn)展測試，那么可以經(jīng)過Prime95工具來進(jìn)展穩(wěn)定性測試，如圖1.2所示，該軟件可以讓系統(tǒng)的一切資源長時間處于耗費(fèi)殆盡的形狀。經(jīng)過這樣一段時間的“烤機(jī)后，假設(shè)沒有出現(xiàn)死機(jī)等情況，可以以為系統(tǒng)經(jīng)過了壓力測試，即可以在各種情況下穩(wěn)定地運(yùn)轉(zhuǎn)。圖1.1 EVEREST CPU Queen測試結(jié)果 圖1.2 壓力測試工具Prime95容量測試(Volume Testing)容量測試是指在一定的軟件、硬件及網(wǎng)絡(luò)環(huán)境下，在數(shù)據(jù)庫中構(gòu)造不同數(shù)量級別的數(shù)據(jù)記錄，

34、運(yùn)轉(zhuǎn)一種或多種業(yè)務(wù)在一定虛擬用戶數(shù)量的情況下，獲取不同數(shù)量級別的效力器性能目的，以確定數(shù)據(jù)庫的最正確容量和最大容量。容量測試不僅可以對數(shù)據(jù)庫進(jìn)展，還可以對硬件處置才干、各種效力器的銜接才干等進(jìn)展，以此來測試系統(tǒng)在不同容量級別下能否能到達(dá)指定的性能。容量測試和負(fù)載測試的區(qū)別在于，容量測試主要關(guān)懷how much，而負(fù)載測試那么同時強(qiáng)調(diào)how much和how fast。例如測試一個Word2003文檔中最多可以存放多少個漢字。容量測試中也包含了可伸縮性測試的概念，可伸縮性可以從硬件和軟件兩個方面來了解：1硬件的可伸縮性能否可以經(jīng)過硬件設(shè)備的添加來支持更多的用戶，比如經(jīng)過添加CPU個數(shù)或者存儲器空

35、間大小等。2軟件的可伸縮性能否可以經(jīng)過運(yùn)轉(zhuǎn)更多的實(shí)例或者采用分布式處置來支持更多的用戶。再詳細(xì)一點(diǎn)就是一個可伸縮系統(tǒng)必需具有隨負(fù)荷添加呼應(yīng)時間也線性添加的特點(diǎn)。這樣就可以經(jīng)過線性添加硬件設(shè)備、實(shí)例個數(shù)或者分布式處置點(diǎn)來處置更多的數(shù)據(jù)量，也就能更好地在不添加呼應(yīng)時間的前提下支持更多的用戶。可伸縮性測試詳細(xì)的測試過程為：進(jìn)展負(fù)載測試，記錄不同負(fù)載下的平均呼應(yīng)時間，然后查看平均呼應(yīng)時間能否線性添加。如線性添加，那么闡明系統(tǒng)具有可伸縮性；否那么闡明系統(tǒng)可伸縮性較差或者沒有可伸縮性配置測試(Configuration Testing)配置測試是指在不同的軟件、硬件以及網(wǎng)絡(luò)環(huán)境配置下，運(yùn)轉(zhuǎn)一種或多種業(yè)務(wù)，

36、在一定的虛擬用戶數(shù)量情況下，獲得不同配置的性能目的，用f選擇最正確的設(shè)備及參數(shù)配置。經(jīng)過產(chǎn)生不同的配置，來得到系統(tǒng)性能的變化情況。在購買電腦前，我們通常會參考各種硬件評測，經(jīng)過這些評測可以得知如何花最少的錢獲得最高的性能報答，而這些測試都是經(jīng)過在一樣的平臺下切換CPU或者顯卡等硬件來獲得對應(yīng)的性能目的。例如可以運(yùn)用EVEREST Ultimate、Iometer、Sisoft Sandra這類工具來獲得當(dāng)前系統(tǒng)整體或者某個硬件的性能數(shù)據(jù)。經(jīng)過配置測試可以將性能缺陷放大，方便定位性能瓶頸。經(jīng)過EVEREST測試內(nèi)存讀寫速度，得出當(dāng)前系統(tǒng)的內(nèi)存寫入速度為3029MBs，如圖1.3所示。圖1.3 E

37、VEREST內(nèi)存寫入測試結(jié)果基準(zhǔn)測試(Benchmark Testing)基準(zhǔn)測試是指在一定的軟件、硬件及網(wǎng)絡(luò)環(huán)境下，模擬一定數(shù)量的虛擬用戶運(yùn)轉(zhuǎn)一種或多種業(yè)務(wù)，將測試結(jié)果作為基線數(shù)據(jù)，在系統(tǒng)調(diào)優(yōu)或系統(tǒng)評測的過程中，經(jīng)過運(yùn)轉(zhuǎn)一樣的業(yè)務(wù)場景比較測試結(jié)果，確定調(diào)優(yōu)的結(jié)果能否到達(dá)預(yù)期效果或者為系統(tǒng)的選擇提供決策數(shù)據(jù)?；鶞?zhǔn)測試普通基于配置測試，經(jīng)過配置測試得到數(shù)據(jù)，并將這個數(shù)據(jù)作為基準(zhǔn)來比較每次調(diào)優(yōu)后的性能能否有所改善。例如前面經(jīng)過EVEREST Ultimate工具獲得了當(dāng)前的內(nèi)存讀寫速度數(shù)據(jù)，然后對系統(tǒng)進(jìn)展調(diào)優(yōu)(修正內(nèi)存時序)，再做一次一樣的測試，假設(shè)內(nèi)存讀寫速度上升了，就闡明前面的調(diào)優(yōu)是正確有效的

38、，反之那么闡明調(diào)優(yōu)無效。并發(fā)測試(Concurrency Testing)并發(fā)測試是指經(jīng)過模擬多個用戶并發(fā)訪問同一個運(yùn)用、存儲過程或數(shù)據(jù)記錄以及其他并發(fā)操作，測試能否存在死鎖、數(shù)據(jù)錯誤等缺點(diǎn)。為了防止數(shù)據(jù)庫或函數(shù)方法在并發(fā)下的錯誤，需求專門針對每個模塊進(jìn)展并發(fā)測試。例如軟件系統(tǒng)中有以下類似的存儲過程：Create proc newuserunamevarchar(100)AsDeclare ucount intSelect ucount=count(*) from usersIf ucount5000Insert into USers(uname) values(uname)e1Se-提示VI

39、P用戶活動曾經(jīng)終了，會員已滿go當(dāng)大量用戶并發(fā)運(yùn)轉(zhuǎn)該存儲過程時就會出現(xiàn)注冊勝利的會員數(shù)目大于5000的情況，由于有多個會員可以同時得到系統(tǒng)當(dāng)前的用戶數(shù)，而產(chǎn)生多個用戶同時插入會員信息的情況，導(dǎo)致功能的最終錯誤。對于這種情況需求在查詢用戶數(shù)的時候添加查詢鎖來防止查詢功能的并發(fā)操作。性能測試進(jìn)展的時間好比幾年前功能測試剛剛起步，其實(shí)就是一次出廠驗(yàn)貨，卻美其名日QA。如今我們知道了功能測試包括單元測試、集成測試、系統(tǒng)測試，知道了需求盡能夠早地介入測試，甚至應(yīng)該對需求進(jìn)展測試，從而有效地、全方位地保證軟件質(zhì)量。是一篇小學(xué)時的課文，相對于看病來說，軟件測試也是一種類似的任務(wù)，即應(yīng)該及早進(jìn)展診斷及預(yù)防。如

40、今的性能測試往往都是在工程后期才開場進(jìn)展的，就算經(jīng)過性能測試發(fā)現(xiàn)系統(tǒng)的性能曾經(jīng)完全無法到達(dá)預(yù)期的需求，在多數(shù)情況下曾經(jīng)于事無補(bǔ)了。一個有效的缺陷就是可以被修復(fù)的缺陷!一個軟件的缺陷，特別是性能上的缺陷不是簡單地改改代碼就行。當(dāng)一棟高樓曾經(jīng)建到第40層，才發(fā)現(xiàn)地基打得不夠深，沒方法繼續(xù)往下建筑了，而主梁的強(qiáng)度也不夠，這時除了推倒重建也沒什么其他有效的方法了。軟件也是如此，當(dāng)后期才發(fā)現(xiàn)存在嚴(yán)重的性能問題時，再想修正它的本錢和難度相對功能問題來說要大很多。接著來看看理想情況下性能測試應(yīng)該在哪些階段介入，如圖1.4所示。圖1.4 性能測試的進(jìn)展時間編碼階段(壓力/并發(fā))在編碼階段，當(dāng)每個函數(shù)、方法、存

41、儲過程被開發(fā)出來并經(jīng)過單元測試后，都應(yīng)該進(jìn)展壓力和并發(fā)測試，確認(rèn)接口和被測對象能否強(qiáng)壯地處置極端情況，并且能否正確處置并發(fā)懇求。在大多數(shù)情況下，這個階段的性能測試都是開發(fā)人員自行擔(dān)任。而作為一個架構(gòu)設(shè)計(jì)師，在設(shè)計(jì)軟件時即應(yīng)該思索整個系統(tǒng)的性能，并進(jìn)展建模測試，確保設(shè)計(jì)的正確。隨后程序員對架構(gòu)進(jìn)展實(shí)現(xiàn)時就需求對本人編寫的代碼進(jìn)展并發(fā)測試和壓力測試。編碼一測試之間(容量測試)在系統(tǒng)編碼完成時，應(yīng)該及時進(jìn)展容量測試，確認(rèn)系統(tǒng)能否滿足在指定容量下的性能需求。例如導(dǎo)入5年的歷史數(shù)據(jù)量，檢查在這種容量下系統(tǒng)的性能能否可以接受，進(jìn)一步再構(gòu)造未來5年的數(shù)據(jù)量，檢查系統(tǒng)能否正常任務(wù)。測試階段(負(fù)載/配置/基準(zhǔn))

42、在進(jìn)入測試階段之后，在確保功能正確實(shí)現(xiàn)后需求進(jìn)展負(fù)載測試，得到系統(tǒng)在當(dāng)前硬件及軟件環(huán)境下的性能目的(呼應(yīng)時間、吞吐量、資源利用率)，進(jìn)一步構(gòu)成性能數(shù)據(jù)基準(zhǔn)，然后經(jīng)過配置測試進(jìn)展性能瓶頸的定位和優(yōu)化。在負(fù)載測試后可以得到系統(tǒng)的性能，假設(shè)該結(jié)果滿足用戶需求，那么可以思索終了性能測試，也可以思索進(jìn)一步進(jìn)展配置和基準(zhǔn)測試，定位系統(tǒng)中的性能瓶頸，并進(jìn)展進(jìn)一步的優(yōu)化。1.2.2 性能目的前面了解了什么是性能，忽視性能會帶來什么結(jié)果以及什么是性能測試，那么性能測試究竟要測什么呢?在討論軟件的性能目的之前，請思索一下汽車和家用電腦的性能目的是經(jīng)過什么數(shù)據(jù)來闡明的。對于一個運(yùn)用系統(tǒng)來說，我們所需求監(jiān)控的性能目的

43、主要有以下3點(diǎn)：呼應(yīng)時間呼應(yīng)時間反映完成某個業(yè)務(wù)所需求的時間。例如從單擊登錄按鈕到登錄完成前往登錄勝利頁面需求耗費(fèi)1秒鐘，那么就說這個操作的呼應(yīng)時間是1秒。在性能測試中是經(jīng)過事務(wù)函數(shù)來完成對呼應(yīng)時間的統(tǒng)計(jì)，事務(wù)是指做某件事情的操作，事務(wù)函數(shù)會記錄開場做這件事情和該事情做完之間的時間差，運(yùn)用Transaction Response Time這個詞來闡明，也稱為事務(wù)呼應(yīng)時間。吞吐量吞吐量反映單位時間內(nèi)可以處置的事務(wù)數(shù)目。例如對于系統(tǒng)來說一個用戶登錄需求1秒鐘，假設(shè)系統(tǒng)同時支持10個用戶登錄，且呼應(yīng)時間是1秒鐘，那么系統(tǒng)的吞吐量就是10個秒。在性能測試工具中，吞吐量也被稱為TPS(Transacti

44、on Per Second，每秒事務(wù)數(shù))也就是說在單位時間內(nèi)能完成的事務(wù)數(shù)目。TPS的計(jì)算普通是經(jīng)過的事務(wù)數(shù)除以時間。效力器資源占用效力器資源占用反映在負(fù)載下系統(tǒng)的資源利用率。資源的占用越低，闡明系統(tǒng)越優(yōu)秀。資源并不僅僅指運(yùn)轉(zhuǎn)系統(tǒng)的硬件，而是支持整個系統(tǒng)運(yùn)轉(zhuǎn)程序的一切軟硬件平臺。在性能測試中，我們需求監(jiān)控系統(tǒng)在負(fù)載下的硬件或者軟件上各種資源的占用情況，例如CPU的占用率、內(nèi)存運(yùn)用率、查詢cache命中率等。對于一個終端用戶來說，最關(guān)懷的目的只需呼應(yīng)時間，假設(shè)呼應(yīng)時間長了，那么用戶就會覺得系統(tǒng)慢。用戶并不關(guān)懷有多少人運(yùn)用這個系統(tǒng)以及系統(tǒng)的資源是不是足夠，所以從某個角度來說，性能測試必需保證在恣意

45、情況下終端用戶運(yùn)用的操作呼應(yīng)時間不大于5秒。有調(diào)查統(tǒng)計(jì)，對于一個用戶來說，假設(shè)訪問某系統(tǒng)的呼應(yīng)時間小于2秒，那么用戶會覺得系統(tǒng)很快，比較稱心；假設(shè)訪問某系統(tǒng)的呼應(yīng)時間在25秒，那么用戶可以接受，但是對速度有些不滿；假設(shè)某系統(tǒng)的呼應(yīng)時間超越10秒，用戶將無法接受。所以對于一個系統(tǒng)來說，需求盡能夠保證每一個操作的呼應(yīng)時間在5秒以內(nèi)，當(dāng)然某些特殊的操作能夠會大大超出這個呼應(yīng)時間，可以經(jīng)過Loading Bar的方式來提早通知用戶。1.2.3 性能分析及調(diào)優(yōu)性能測試的目的是為了發(fā)現(xiàn)性能瓶頸并處理。性能分析是為了確定導(dǎo)致性能瓶頸的緣由，而調(diào)優(yōu)就是用來處理性能瓶頸。經(jīng)過某些手段來讓系統(tǒng)的性能得到提升是性能

46、調(diào)優(yōu)的主要目的。性能分析主要有以下兩種方法：目的達(dá)成法將測試結(jié)果與用戶需求進(jìn)展比較，假設(shè)到達(dá)用戶需求那么測試經(jīng)過。1系統(tǒng)滿足10萬注冊用戶(其中活潑用戶數(shù)為1萬)訪問；2系統(tǒng)處置才干：20個注冊秒、45個并發(fā)閱讀秒、30個登錄操作秒；3效力器資源利用率在滿負(fù)荷的情況下，忙時峰值CPU負(fù)載不超越75，內(nèi)存占用不超越80。例如：需求對一個參與100米跑的選手在競賽前進(jìn)展性能測試，確保其能獲得冠軍，那么首先需求明確第一名所需求到達(dá)的性能目的(100米短跑總時間)，對其進(jìn)展性能測試，當(dāng)發(fā)現(xiàn)測試結(jié)果可以到達(dá)冠軍所具備的條件后，性能測試即可終了。最優(yōu)化分析法經(jīng)過分析并消除系統(tǒng)性能瓶頸，使系統(tǒng)的處置才干最大

47、化，系統(tǒng)資源實(shí)現(xiàn)充分利用。例如：需求對一個參與100米跑的選手進(jìn)展技術(shù)指點(diǎn)，并不在乎他能否可以拿到冠軍，而是重點(diǎn)強(qiáng)調(diào)能否提升本人的競賽成果，那么就需求進(jìn)展系統(tǒng)的訓(xùn)練和指點(diǎn)，如規(guī)范起跑動作、強(qiáng)化肌肉及協(xié)調(diào)性等，最終實(shí)現(xiàn)運(yùn)動成果的提高。對應(yīng)的性能調(diào)優(yōu)方法也分為兩大方向，如圖15所示。圖15性能調(diào)優(yōu)方向1運(yùn)用程序診斷運(yùn)用程序的診斷是性能測試的最初目的。經(jīng)過模擬多用戶操作構(gòu)成負(fù)載，檢驗(yàn)運(yùn)用程序能否可以滿足用戶性能需求。假設(shè)不能滿足，那么定位運(yùn)用瓶頸，并尋覓處理該瓶頸的方案，確保系統(tǒng)在修正后可以滿足用戶需求。對于一個工程來說，普通都以運(yùn)用診斷為主。2系統(tǒng)調(diào)優(yōu)性能測試的目的不是為了滿足用戶，而是超越本人，

48、這個時候需求做的是讓系統(tǒng)可以比以前更加優(yōu)秀地運(yùn)轉(zhuǎn)，經(jīng)過生成負(fù)載，對測試結(jié)果進(jìn)展分析，并且預(yù)備大量的軟硬件環(huán)境進(jìn)展迭代測試，找出影響性能的要素，最終提升系統(tǒng)的性能。普通產(chǎn)品都會采用系統(tǒng)調(diào)優(yōu)的方式來逐漸完善系統(tǒng)性能。常見的性能瓶頸有如下一些情況：1硬件上的性能瓶頸普通指的是CPU、RAM方面的問題，分為效力器硬件瓶頸、網(wǎng)絡(luò)瓶頸(對局域網(wǎng)可以不思索)、效力器操作系統(tǒng)瓶頸(參數(shù)配置)、中間件瓶頸(參數(shù)配置、數(shù)據(jù)庫、Web效力器等)、運(yùn)用瓶頸(SQL語句、數(shù)據(jù)庫設(shè)計(jì)、業(yè)務(wù)邏輯、算法等)。例如：確定了在數(shù)據(jù)庫效力器上需求6個CPU、12GB內(nèi)存。但是在測試時，發(fā)現(xiàn)CPU的繼續(xù)利用率超越95，這時可以以為在

49、硬件上出現(xiàn)了性能瓶頸。2運(yùn)用軟件上的性能瓶頸普通指的是運(yùn)用效力器、Web效力器等運(yùn)用軟件，還包括數(shù)據(jù)庫系統(tǒng)。例如：在WebLogic平臺上配置了JDBC銜接池的參數(shù)，最大銜接數(shù)為50，最小銜接數(shù)為5，添加量為10。在測試時發(fā)現(xiàn)，當(dāng)負(fù)載添加時，現(xiàn)有的銜接數(shù)缺乏，系統(tǒng)會動態(tài)生成10個新的銜接，導(dǎo)致買賣處置的呼應(yīng)時間大大添加。這時可以以為在運(yùn)用軟件上出現(xiàn)了性能瓶頸。3運(yùn)用程序上的性能瓶頸普通指的是開發(fā)人員新開發(fā)出來的運(yùn)用程序。例如：某程序員開發(fā)了一個繳費(fèi)處置程序。在測試時發(fā)現(xiàn)，這個繳費(fèi)處置程序在處置用戶的并發(fā)繳費(fèi)懇求時，只能串行處置，無法并行處置，導(dǎo)致繳費(fèi)買賣的處置呼應(yīng)時間非常長，這時可以以為在運(yùn)用

50、程序上出現(xiàn)了性能瓶頸。4操作系統(tǒng)上的性能瓶頸普通指的是Windows、UNIX、Linux等操作系統(tǒng)。例如：在Windows操作系統(tǒng)中，對某軟件進(jìn)展性能測試，出現(xiàn)物理內(nèi)存缺乏時，假設(shè)虛擬內(nèi)存設(shè)置也不合理，虛擬內(nèi)存的交換效率就會大大降低，從而導(dǎo)致行為的呼應(yīng)時間大大添加。這時可以以為在操作系統(tǒng)上出現(xiàn)了性能瓶頸。5網(wǎng)絡(luò)設(shè)備上的性能瓶頸普通指的是防火墻、動態(tài)負(fù)載平衡器、交換機(jī)等設(shè)備。例如：在動態(tài)負(fù)載平衡器上設(shè)置了動態(tài)分發(fā)負(fù)載的機(jī)制，當(dāng)發(fā)現(xiàn)某個運(yùn)用效力器上的硬件資源曾經(jīng)到達(dá)極限時，動態(tài)負(fù)載平衡器將后續(xù)的買賣懇求發(fā)送到其他負(fù)載較輕的運(yùn)用效力器上。在測試時發(fā)現(xiàn)，動態(tài)負(fù)載平衡機(jī)制沒有起到相應(yīng)的作用，這時可以以

51、為在網(wǎng)絡(luò)設(shè)備上出現(xiàn)了性能瓶頸。性能瓶頸出現(xiàn)的緣由及其定位是非常復(fù)雜的，這里只是簡單引見一下常見的幾種瓶頸類型和特征，而性能測試所需求做的就是根據(jù)各種情況要素綜合思索，然后協(xié)助開發(fā)人員一同定位性能瓶頸。普通性能問題調(diào)優(yōu)的步驟Step1 確定問題運(yùn)用程序代碼：在通常情況下，很多程序的性能問題都是寫出來的，因此對于發(fā)現(xiàn)瓶頸的模塊，應(yīng)該首先檢查一下代碼。數(shù)據(jù)庫配置：數(shù)據(jù)庫配置經(jīng)常引起整個系統(tǒng)運(yùn)轉(zhuǎn)緩慢，一些諸如Oracle的大型數(shù)據(jù)庫都是需求DBA進(jìn)展正確的參數(shù)調(diào)整才干投產(chǎn)的。操作系統(tǒng)配置：操作系統(tǒng)配置不合理也能夠引起系統(tǒng)瓶頸。硬件設(shè)置：硬盤速度、內(nèi)存大小等都是容易引起瓶頸的緣由，因此這些都是分析的重點(diǎn)

52、。網(wǎng)絡(luò)：網(wǎng)絡(luò)負(fù)載過重導(dǎo)致網(wǎng)絡(luò)沖突和網(wǎng)絡(luò)延遲。Step2 確定緣由當(dāng)確定了問題之后，我們要明確這個問題影響的是呼應(yīng)時間吞吐量，還是其他問題?是多數(shù)用戶還是少數(shù)用戶遇到了問題？假設(shè)是少數(shù)用戶，這幾個用戶與其他用戶的操作有什么不同?系統(tǒng)資源監(jiān)控的結(jié)果能否正常？CPU的運(yùn)用能否到達(dá)極限？I/O情況如何?問題能否集中在某一類模塊中？是客戶端還是效力器出現(xiàn)問題？系統(tǒng)硬件配置能否夠用？實(shí)踐負(fù)載能否超越了系統(tǒng)的負(fù)載才干？能否未對系統(tǒng)進(jìn)展優(yōu)化？經(jīng)過這些分析以及一些與系統(tǒng)相關(guān)的問題，可以對系統(tǒng)瓶頸有更深化的了解，進(jìn)而分析出真正的緣由。Step3 確定調(diào)整目的和處理方案提高系統(tǒng)吞吐量；縮短呼應(yīng)時間；更好地支持并發(fā)。

53、Step 4 測試處理方案對經(jīng)過處理方案調(diào)優(yōu)后的系統(tǒng)進(jìn)展基準(zhǔn)測試。Step 5 分析調(diào)優(yōu)結(jié)果系統(tǒng)調(diào)優(yōu)能否到達(dá)或者超出了預(yù)定目的？系統(tǒng)是整體性能得到了改善，還是以犧牲某部分性能來處理其他問題。調(diào)優(yōu)能否可以終了了？最后，假設(shè)到達(dá)了預(yù)期目的，調(diào)優(yōu)任務(wù)就根本可以終了了。性能問題分析原那么原那么1：把現(xiàn)實(shí)與推測分開，總是用實(shí)踐的證據(jù)來證明他的推測。原那么2：在沒有足夠證據(jù)之前，不對程序進(jìn)展優(yōu)化。原那么3：優(yōu)先驗(yàn)證簡單的假設(shè)。原那么4：日志文件中沒有錯誤并不代表真的沒有錯誤。原那么5：從系統(tǒng)到運(yùn)用、從外到內(nèi)進(jìn)展層層剝離，減少范圍。確認(rèn)是系統(tǒng)級問題還是運(yùn)用級問題；確認(rèn)能否為外部系統(tǒng)問題(如密碼鑒權(quán)問題、EJ

54、B問題等)；確認(rèn)是運(yùn)用程序問題還是數(shù)據(jù)庫問題。原那么6：范圍減少后，再分割成多個小單元，對每個小單元反復(fù)進(jìn)展壓力測試，來確定是哪個單元引起性能問題。診斷性能問題，最常見的也是較難的判別的問題是：是運(yùn)用程序還是數(shù)據(jù)庫出了問題？或者兩者都有？這是由于運(yùn)用程序、數(shù)據(jù)庫、WebLogic Server(Tomcat)都不是孤立運(yùn)轉(zhuǎn)的。因此脫離運(yùn)用架構(gòu)單獨(dú)運(yùn)轉(zhuǎn)測試(如SQL計(jì)時、JDBC計(jì)時、線程計(jì)時等)幾乎沒有作用。關(guān)鍵是對相互作用的了解。要熟知系統(tǒng)的性能度量方法，了解SQL的構(gòu)造，了解用戶發(fā)出的懇求在跨越整個系統(tǒng)時的端對端點(diǎn)對點(diǎn)計(jì)時、SQL的計(jì)時等；了解用戶發(fā)出懇求后所關(guān)聯(lián)的線程、JDBC銜接、數(shù)據(jù)

55、庫的活動及其之間的交互關(guān)系。運(yùn)用數(shù)據(jù)庫典型的三大類性能問題分析如下。1過量的數(shù)據(jù)庫調(diào)用問題：常見的性能瓶頸過量的數(shù)據(jù)庫調(diào)用，引發(fā)這些問題不一定是SQL查詢的Execute()或Update()，而是運(yùn)用程序與數(shù)據(jù)庫的交互有關(guān)，例如Result Set操作，常見的問題是指定了過于精細(xì)的查詢條件，然后運(yùn)用Result SetNext()詳細(xì)搜索前往的數(shù)據(jù)。處理方法：從數(shù)據(jù)庫中大量獲得所要求的數(shù)據(jù)，防止運(yùn)用程序反復(fù)回調(diào)數(shù)據(jù)庫。2數(shù)據(jù)庫銜接池問題問題1：銜接池資源走漏雖然可以經(jīng)過WebLogic自帶工具、Jprofiler工具或自編工具檢測到數(shù)據(jù)庫銜接池資源走漏，但是很難在運(yùn)用程序代碼本身準(zhǔn)確定位走漏

56、的源頭!處理方法：仔細(xì)分析程序代碼，能否沒有close()銜接？能否脫漏了finally塊？或者雖然有close()但并沒有勝利？問題2：銜接池大小銜接池過小會導(dǎo)致銜接池滿后，新的客戶無法銜接上系統(tǒng)，在日志中出現(xiàn)錯誤信息。普通的處理方法是增大銜接池。但另一方面，銜接池過大會呵斥資源無效損耗，能夠會出現(xiàn)新的性能問題，那么銜接池調(diào)到多大比較適宜呢？處理方法：閱歷法那么1：數(shù)據(jù)庫銜接池數(shù)=線程池數(shù)每個線程需求銜接數(shù)據(jù)庫的平均數(shù)x1.1(1.1的含義是添加10的峰值期負(fù)載)，通常每個線程需求銜接數(shù)據(jù)庫的平均數(shù)是1，即當(dāng)線程池數(shù)為120時，數(shù)據(jù)庫銜接池數(shù)就是132。閱歷法那么2：設(shè)置最初池大小=最大池大

57、小。3：SQL語句及其索引或鎖定屬性問題問題：SQL語句及其索引或鎖定屬性不合理能夠引發(fā)DISK IO過忙(磁盤讀寫數(shù)據(jù))或者CPU過忙(在內(nèi)存中索引排序)，呵斥執(zhí)行時間過長，阻塞線程的執(zhí)行，最終引發(fā)系統(tǒng)掛起或者執(zhí)行超時引發(fā)系統(tǒng)掛起，例如錯誤信息：Oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2857) at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate死鎖引發(fā)系統(tǒng)掛起，例如錯誤信息：Java.sql.SQLExcept

58、ion:ORA-00060:Deadlockdetectedwhilewaitingforresourceatoracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:170)處理方法：優(yōu)化SQL語句及其索引或鎖定屬性。性能調(diào)優(yōu)應(yīng)該留意的要點(diǎn)要點(diǎn)1：在運(yùn)用系統(tǒng)的設(shè)計(jì)開發(fā)過程中，應(yīng)一直把性能放在思索的范圍內(nèi)。要點(diǎn)2：確定明晰明確的性能目的是關(guān)鍵。要點(diǎn)3：必需保證調(diào)優(yōu)后的程序運(yùn)轉(zhuǎn)正確。要點(diǎn)4：系統(tǒng)的性能更大程度上取決于良好的設(shè)計(jì)，調(diào)優(yōu)技巧只是一個輔助手段。要點(diǎn)5：調(diào)優(yōu)過程是迭代漸進(jìn)的過程，每次調(diào)優(yōu)的結(jié)果都要反響到后續(xù)的代碼開發(fā)中去要點(diǎn)6

59、：性能調(diào)優(yōu)不能以犧牲代碼的可讀性和可維護(hù)性為代價。性能調(diào)優(yōu)是一個很復(fù)雜的過程，就好比一個人每天在上班路上需求耗費(fèi)1個半小時，如何調(diào)優(yōu)讓這個人上班路上開銷的時間變小。性能調(diào)優(yōu)需求有全面的知識和背景，需求對被調(diào)優(yōu)對象有全面的了解和跟蹤，才干逐漸抽絲剝繭找到某塊短板，將這塊短板加長后，再找到下一塊短板，以此類推。很多公司在招聘性能測試工程師的時候都會提及性能調(diào)優(yōu)這個職責(zé)，但是只靠一個性能測試專家是很難的，由于假設(shè)他想要對一個三層架構(gòu)的網(wǎng)絡(luò)運(yùn)用進(jìn)展調(diào)優(yōu)，那么需求對網(wǎng)絡(luò)架構(gòu)、www效力、APP運(yùn)用、DB數(shù)據(jù)庫都相當(dāng)知曉，才干完成所謂的調(diào)優(yōu)任務(wù)，而這樣的人曾經(jīng)可以勝任架構(gòu)設(shè)計(jì)師的職位了，假設(shè)讓他去做性能測

60、試工程師能否有些大材小用了呢？不過作為一個性能測試工程師，在生長的初期需求對性能測試調(diào)優(yōu)的各個對象都有所了解，經(jīng)過相關(guān)部門的人員協(xié)助完成調(diào)優(yōu)任務(wù)，隨后就是逐漸加深，并且選擇一個詳細(xì)的方向進(jìn)展深化并成為某一方面的性能測試及調(diào)優(yōu)專家。1.2.4 單機(jī)軟件性能與網(wǎng)絡(luò)架構(gòu)軟件性能在性能測試初期，測試對象都是單機(jī)軟件，測試目的是確認(rèn)一個軟件在一定的配置下可以以多快的速度完成一個義務(wù)，甚至同時完成幾個義務(wù)。例如測試Windows下的計(jì)算器計(jì)算999999的999999次方需求耗費(fèi)的時間。假設(shè)需求對單機(jī)軟件進(jìn)展性能測試，關(guān)注的目的普通為：1能否存在內(nèi)存走漏？有沒有懇求一些沒必要的資源？資源的釋放能否完全？2