Loadrunner無(wú)疑是一個(gè)強(qiáng)大有力的壓力測(cè)試工具。它的腳本可以錄制生成，自動(dòng)關(guān)聯(lián)；測(cè)試場(chǎng)景可以面向指標(biāo)，多方監(jiān)控；測(cè)試結(jié)果圖表顯示，拆分組合。相信有人這樣想象過(guò)：拿著一張性能指標(biāo)標(biāo)準(zhǔn)列表和測(cè)試數(shù)據(jù)相比較，如同PH試紙一樣，遇堿則藍(lán)，遇酸則紅，一目了然，之后就可以大聲地喊道：我找到了軟件系統(tǒng)的性能瓶頸！
然而，我們無(wú)論在loadrunner前面加多少個(gè)“強(qiáng)大”、“智能”的形容詞，別忘了其最終修飾的只是一個(gè)名詞－“工具”?！洞笤捨饔巍分幸灿邢喈?dāng)精辟的論斷：官兵？最多也只是個(gè)長(zhǎng)了痔瘡的官兵！把loadrunner比喻成長(zhǎng)了痔瘡的官兵有點(diǎn)粗俗，但loadrunner它是個(gè)工具，那么是否能夠找到性能瓶頸就取決于使用工具的人，而不是工具本身。要做一個(gè)成功的性能測(cè)試，僅讀懂和精通了loadrunner的使用手冊(cè)是不夠的，還需要對(duì)被測(cè)軟件系統(tǒng)的方方面面都要有了解，比如軟件體系構(gòu)架，網(wǎng)絡(luò)拓?fù)涞戎R(shí)。這就如同一個(gè)技藝高超的木匠，并不是因?yàn)樗呈炝髓徸?，錘子的說(shuō)明書(shū)，而是他能結(jié)合木材的質(zhì)地和尺寸，用鑿子和錘子這些工具做出一把精巧的椅子來(lái)。那么在性能測(cè)試中，人的智慧活動(dòng)體現(xiàn)在哪里呢？
一．首先性能測(cè)試也是測(cè)試的一種，這就意味著做性能測(cè)試也要寫(xiě)測(cè)試案例。你所作的性能測(cè)試能不能足以支持找出性能測(cè)試瓶頸，和你在初期設(shè)計(jì)的測(cè)試案例關(guān)系甚為重要。我曾寫(xiě)過(guò)對(duì)一個(gè)軟件系統(tǒng)的不下十個(gè)性能測(cè)試場(chǎng)景案例，等后來(lái)運(yùn)行時(shí)卻發(fā)現(xiàn)我必須增補(bǔ)幾個(gè)案例才能找到瓶頸，而原來(lái)十多個(gè)案例其實(shí)重復(fù)甚多。如果你要寫(xiě)出好的不重復(fù)的性能測(cè)試案例來(lái)，你就得對(duì)被測(cè)軟件系統(tǒng)有一定的了解。
在這里，我順便插一句，在目前測(cè)試界總在爭(zhēng)論測(cè)試人員需不需要懂編程，需不需要有開(kāi)發(fā)經(jīng)驗(yàn)這種問(wèn)題，這完全是本末倒置，忘記了測(cè)試人員的目標(biāo)是什么，測(cè)試目標(biāo)就是寫(xiě)出好的測(cè)試案例，好的測(cè)試案例就是發(fā)現(xiàn)了一個(gè)原來(lái)未曾發(fā)現(xiàn)的軟件bug。那么一個(gè)測(cè)試人員知識(shí)體系是否夠用的標(biāo)準(zhǔn)就是能不能寫(xiě)出一個(gè)好的測(cè)試案例。而針對(duì)不同類型的測(cè)試，所需的知識(shí)深度是不一樣的，有的是不需編程知識(shí)，比如界面測(cè)試；有的是必須有開(kāi)發(fā)經(jīng)驗(yàn)的，比如接口測(cè)試，不能一概而論。
對(duì)于性能測(cè)試來(lái)講，我個(gè)人認(rèn)為，測(cè)試人員倒不一定非要有開(kāi)發(fā)經(jīng)驗(yàn)，但是應(yīng)該有一個(gè)對(duì)軟件體系結(jié)構(gòu)了解全面的知識(shí)。為什么呢？做性能測(cè)試時(shí)，如果從客戶端施壓一次就符合性能指標(biāo)，碰到這種情況您就偷著樂(lè)吧，因?yàn)樵谀愕闹笜?biāo)場(chǎng)景下，軟件系統(tǒng)中就不存在性能瓶頸，您也就不用費(fèi)心去找了。但是大多數(shù)情況下，我們?cè)谧鲂阅軠y(cè)試時(shí)，都不能順利達(dá)到性能指標(biāo)，可能server響應(yīng)超時(shí)了，也可能是用戶死掉了，在日志里拋出了一堆error，這種情形是非常常見(jiàn)，所以在我們?cè)谝婚_(kāi)始設(shè)計(jì)性能測(cè)試方案時(shí)，就應(yīng)該考慮為尋找性能瓶頸而設(shè)計(jì)測(cè)試案例。這時(shí)我們就需要知道在整個(gè)軟件系統(tǒng)中，有哪些節(jié)點(diǎn)，在哪些地方可能存在瓶頸，比如一個(gè)B/S系統(tǒng)就有IE client→物理網(wǎng)絡(luò)→web server→app server→DB這樣的一個(gè)壓力流串。每個(gè)節(jié)點(diǎn)的每個(gè)模塊都有可能成為瓶頸。瓶頸的產(chǎn)生可能由于模塊配置引起，也可能由于模塊本身引起。這都需要我們?cè)O(shè)計(jì)測(cè)試案例來(lái)發(fā)現(xiàn)的。一般地，我自己常用的感覺(jué)也比較方便的方法是，設(shè)計(jì)一組性能測(cè)試案例來(lái)驗(yàn)證一個(gè)節(jié)點(diǎn)是否存在瓶頸，這組case中盡量保持其他節(jié)點(diǎn)不變，來(lái)改變這個(gè)節(jié)點(diǎn)的配置，并監(jiān)控此節(jié)點(diǎn)的各種指標(biāo)。這里說(shuō)起來(lái)就有很多話了，不是一言兩語(yǔ)能說(shuō)得清的。以后有時(shí)間可以找個(gè)專題來(lái)慢慢跟大家討論。
二．使用loadrunner的VU生成腳本。腳本的生成方式就兩種，一種是自寫(xiě)或嵌入源代碼，一種是錄制生成。常常聽(tīng)見(jiàn)有人說(shuō)，這兩種方式中首選錄制生成腳本，因?yàn)樗?jiǎn)單且智能化。但我個(gè)人總覺(jué)得手寫(xiě)腳本要好一些，因?yàn)椋?
1．可讀性好，流程清晰，檢查點(diǎn)截取含義明確。業(yè)務(wù)級(jí)的代碼讀起來(lái)總比協(xié)議級(jí)的代碼更易讓人理解，也更容易維護(hù)，必要時(shí)可建立一個(gè)腳本庫(kù)。而錄制生成的代碼大多沒(méi)有維護(hù)的價(jià)值，現(xiàn)炒現(xiàn)賣(mài)。
2．手寫(xiě)的程序相比錄制的腳本更能真實(shí)地模擬應(yīng)用運(yùn)行。因?yàn)殇浿频哪_本是截獲了網(wǎng)絡(luò)包，生成了協(xié)議級(jí)的代碼，而略掉了client端的處理邏輯。舉個(gè)例子，用VU錄制一個(gè)運(yùn)行script和applet的IE行為，它只會(huì)生成http協(xié)議的API，在IE中運(yùn)行的applet和script不會(huì)被模擬到，這就不是一個(gè)完整的系統(tǒng)。
3．手寫(xiě)程序相比錄制腳本更能增加測(cè)試人員的技術(shù)含量。開(kāi)發(fā)和測(cè)試能力雙重提高，何樂(lè)而不為呢？loadrunner提供了java user，vb user，c user等語(yǔ)言類型的腳本，就是給我們開(kāi)發(fā)腳本用的，而不是錄制用的。
腳本不管錄制也好，還是手寫(xiě)也好，選擇的時(shí)候應(yīng)該以腳本模擬程序真實(shí)有效為準(zhǔn)，結(jié)合項(xiàng)目進(jìn)度，開(kāi)發(fā)難易程度等因素考慮。
在這里我想要說(shuō)的是，開(kāi)發(fā)一個(gè)好的腳本是成功性能測(cè)試的必要條件。一個(gè)好的腳本應(yīng)該能夠最大程度再現(xiàn)client程序行為。如上面那個(gè)例子，腳本只模擬了client端的部分行為，有一些沒(méi)有模擬到，那么client的瓶頸就有可能被忽略了。我曾吃過(guò)一個(gè)虧，自己寫(xiě)了一個(gè)java socket腳本去聯(lián)server，但是忽略了client端的界面下的業(yè)務(wù)邏輯，用我的腳本做性能測(cè)試通過(guò)，全部OK，但是真實(shí)用戶一上線，client終端界面接受了大量的server信息，導(dǎo)致client進(jìn)程死掉了。痛哉，痛哉。
三．組建并執(zhí)行性能測(cè)試場(chǎng)景。
從VU運(yùn)行成功到controller運(yùn)行成功，一般需要以下幾個(gè)步驟（我也是從英文論壇上看到的，覺(jué)得不錯(cuò)，拿出來(lái)共享）：
1. 確認(rèn)在VU里SUSI（單用戶單循環(huán)次數(shù)single user & single iteration）
2. 確認(rèn)在VU里SUMI（單用戶多循環(huán)次數(shù)single user & multi iteration）
3. 確認(rèn)在controller中MUSI（多用戶單循環(huán)次數(shù)multi user & single iteration）
4. 確認(rèn)在controller中MUMI（多用戶多循環(huán)次數(shù) multi user & multi iteration）
做這樣一個(gè)步驟劃分是有道理的，第一步驟是驗(yàn)證腳本編寫(xiě)的正確，第二步驟可以驗(yàn)證數(shù)據(jù)池是否正常運(yùn)作。第三步驟驗(yàn)證并發(fā)功能，第四步驟是最終目的，驗(yàn)證軟件系統(tǒng)的性能。在論壇上看到一些朋友提的問(wèn)題，有一些就是于此的，在controller中運(yùn)行場(chǎng)景時(shí)出現(xiàn)問(wèn)題，首先得保證VU中運(yùn)行成功，這是一個(gè)顯然的邏輯。軟件工程中把軟件開(kāi)發(fā)的種種行為都要制定一個(gè)proccess，即過(guò)程，性能測(cè)試也是如此，按照過(guò)程來(lái)調(diào)試腳本和場(chǎng)景，能及早發(fā)現(xiàn)問(wèn)題和定位問(wèn)題。除非是高手，爛熟于心中，才能超越proccess而不出問(wèn)題。
場(chǎng)景是把虛擬用戶和交易數(shù)按一定規(guī)則組織起來(lái)去模擬真實(shí)世界的業(yè)務(wù)行為。這其實(shí)是把單個(gè)用戶的行為復(fù)制，連接。場(chǎng)景的組織通常和真實(shí)世界的業(yè)務(wù)規(guī)則有很大關(guān)系。
做個(gè)如下可能并不恰當(dāng)?shù)谋扔鳎?
腳本像演員，場(chǎng)景就像表演的舞臺(tái)，而測(cè)試工程師是導(dǎo)演，多少個(gè)演員，怎么在舞臺(tái)上演出，都由導(dǎo)演說(shuō)了算，而劇情又不能離譜，脫離現(xiàn)實(shí)，否則就要砸鍋了。注意，導(dǎo)演的職責(zé)不光是確保演出能順利結(jié)束，而且還要同時(shí)觀察和收集觀眾的反饋信息，以確認(rèn)這次演出是否成功。
同樣的也是，性能測(cè)試人員不光是看場(chǎng)景是否得到順利的執(zhí)行，同時(shí)還要收集各個(gè)server的反饋信息，以確認(rèn)軟件系統(tǒng)的性能表現(xiàn)是否正常。
在真實(shí)世界中的用戶業(yè)務(wù)規(guī)則要轉(zhuǎn)換到可操作的性能指標(biāo)是需要分析和計(jì)算的。當(dāng)然這通常是市場(chǎng)需求分析人員干的活，但我覺(jué)得測(cè)試人員應(yīng)該在做性能測(cè)試時(shí)，對(duì)這些指標(biāo)進(jìn)行理解，知道為什么要這樣做。有時(shí)有的性能指標(biāo)并不清楚和準(zhǔn)確，還需要測(cè)試人員來(lái)分析。比如一個(gè)性能指標(biāo)：要求軟件系統(tǒng)支持每分鐘700用戶的登陸行為。這對(duì)于測(cè)試人員來(lái)說(shuō)，其實(shí)是一個(gè)不確切的性能需求。這指的是瞬時(shí)并發(fā)用戶700，在一分鐘的響應(yīng)時(shí)間要求下登陸系統(tǒng)？還是在一分鐘內(nèi)陸續(xù)有700個(gè)用戶登入軟件系統(tǒng)即可？這兩種場(chǎng)景其實(shí)對(duì)軟件系統(tǒng)的壓力是不同的，第一種顯然大，第二種要小一些。甚至有的性能需求就是支持50000注冊(cè)用戶，這種需求就更需要分析了，還要引入一些業(yè)務(wù)發(fā)生概率算法模型來(lái)做。這已經(jīng)不是性能測(cè)試人員的職責(zé)了，但由于目前有不少軟件公司流程不規(guī)范，或者有流程沒(méi)執(zhí)行，這些工作都要測(cè)試人員來(lái)做了，不過(guò)也好，正好是鍛煉的機(jī)會(huì)。
四．分析結(jié)果數(shù)據(jù)，找到軟件系統(tǒng)性能瓶頸
上面說(shuō)了，做了那么多，就是為了本步驟－尋找軟件系統(tǒng)性能瓶頸。
個(gè)人認(rèn)為尋找性能瓶頸是一個(gè)非常有挑戰(zhàn)性的工作，毛主席曾經(jīng)說(shuō)過(guò)：一個(gè)優(yōu)秀的指戰(zhàn)員就是能夠根據(jù)已有的客觀形勢(shì)，制定作戰(zhàn)計(jì)劃，然后在作戰(zhàn)過(guò)程中，發(fā)現(xiàn)計(jì)劃與執(zhí)行不符的地方，分析，然后調(diào)整作戰(zhàn)計(jì)劃，縮小計(jì)劃和戰(zhàn)勢(shì)的誤差。簡(jiǎn)明一句：就是一個(gè)理論和實(shí)踐結(jié)合的過(guò)程，一個(gè)人的主觀思想和客觀現(xiàn)實(shí)的結(jié)合過(guò)程（注明：本人是毛主席老人家的忠實(shí)fans）。
在性能測(cè)試中，測(cè)試方案就是我們的作戰(zhàn)計(jì)劃，執(zhí)行性能測(cè)試就是我們的作戰(zhàn)戰(zhàn)場(chǎng)。在性能測(cè)試中，可能會(huì)發(fā)現(xiàn)種種意想不到的問(wèn)題。當(dāng)然一個(gè)經(jīng)驗(yàn)足夠豐富的性能測(cè)試專家可能會(huì)在測(cè)試之前就能考慮全面，使測(cè)試方案吻合測(cè)試執(zhí)行實(shí)際情況，并一舉找出性能瓶頸。我sunshinelius不是專家水平，當(dāng)然就要匆忙應(yīng)對(duì)和分析性能測(cè)試中出現(xiàn)的問(wèn)題，并有可能會(huì)修改測(cè)試方案，增加必要的test case，刪除沒(méi)用的test case?？傊?，性能測(cè)試是一個(gè)不斷修改測(cè)試方案，反復(fù)執(zhí)行test case的過(guò)程，直至越來(lái)越逼近性能瓶頸。在此過(guò)程中，需要了解很多的知識(shí)，知識(shí)了解得越多，就越接近軟件系統(tǒng)運(yùn)行的真相，也就能找出性能瓶頸了。
比如：loadrunner要是調(diào)用程序員的程序，服務(wù)器資源占用情況可能是追查瓶頸的一個(gè)線索，但如果是標(biāo)準(zhǔn)中間件，那就沒(méi)那么簡(jiǎn)單了，比如oracle數(shù)據(jù)庫(kù)的某項(xiàng)參數(shù)設(shè)得不對(duì)，照樣會(huì)造成數(shù)據(jù)庫(kù)瓶頸，應(yīng)用程序調(diào)用數(shù)據(jù)庫(kù)的API寫(xiě)法不對(duì)，比如未使用軟解析變量，也有可能導(dǎo)致數(shù)據(jù)庫(kù)瓶頸。這些瓶頸都不會(huì)反映在cpu，內(nèi)存使用量上等指標(biāo)上的。
對(duì)于這種情況，一方面需要對(duì)中間件有一定的了解，知道哪些參數(shù)有什么作用，怎么可調(diào)的，另外還可能使用中間件的專有監(jiān)測(cè)工具，來(lái)分析。lr的性能計(jì)數(shù)器是不夠用的。
個(gè)人體會(huì)，查找瓶頸的難易程度，由易到難
服務(wù)器硬件瓶頸-〉網(wǎng)絡(luò)瓶頸-〉應(yīng)用瓶頸-〉服務(wù)器操作系統(tǒng)瓶頸（參數(shù)配置）-〉中間件瓶頸（參數(shù)配置，數(shù)據(jù)庫(kù)，web服務(wù)器等）
記憶比較深刻的一次，用lr做了兩天性能測(cè)試，指標(biāo)上不去，后來(lái)使用oracle數(shù)據(jù)庫(kù)的圖形化性能檢測(cè)工具才發(fā)現(xiàn)某個(gè)表的查詢處理時(shí)間超長(zhǎng)，原來(lái)索引創(chuàng)建得不合理，把表的索引改了之后，性能稍有提高，但還是上不去。再次排查，發(fā)現(xiàn)應(yīng)用中有一個(gè)sql語(yǔ)句寫(xiě)得有問(wèn)題，長(zhǎng)而且耗時(shí)，改了之后，測(cè)試指標(biāo)還是上不去
經(jīng)過(guò)至少四輪的排查，才大功告成，最后一個(gè)除掉的瓶頸是操作系統(tǒng)問(wèn)題（開(kāi)始沒(méi)有想到它，后來(lái)看系統(tǒng)消息，才發(fā)現(xiàn)已經(jīng)有錯(cuò)誤報(bào)出）
聯(lián)系客服
