2010年軟件水平考試軟件測(cè)評(píng)師自動(dòng)化測(cè)試(12)

　　讓loadrunner走下神壇

　　無疑是一個(gè)強(qiáng)大有力的壓力測(cè)試工具。它的腳本可以錄制生成，自動(dòng)關(guān)聯(lián);測(cè)試場(chǎng)景可以面向指標(biāo)，多方監(jiān)控;測(cè)試結(jié)果圖表顯示，拆分組合。相信有人這樣想象過：拿著一張性能指標(biāo)標(biāo)準(zhǔn)列表和測(cè)試數(shù)據(jù)相比較，如同PH試紙一樣，遇堿則藍(lán)，遇酸則紅，一目了然，之后就可以大聲地喊道：我找到了軟件系統(tǒng)的性能瓶頸!

　　然而，我們無論在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ù)涞戎�識(shí)。這就如同一個(gè)技藝高超的木匠，并不是因?yàn)樗�背熟了鑿子，錘子的說明書，而是他能結(jié)合木材的質(zhì)地和尺寸，用鑿子和錘子這些工具做出一把精巧的椅子來。那么在性能測(cè)試中，人的智慧活動(dòng)體現(xiàn)在哪里呢?

　　一、首先性能測(cè)試也是測(cè)試的一種，這就意味著做性能測(cè)試也要寫測(cè)試案例。你所作的性能測(cè)試能不能足以支持找出性能測(cè)試瓶頸，和你在初期設(shè)計(jì)的測(cè)試案例關(guān)系甚為重要。我曾寫過對(duì)一個(gè)軟件系統(tǒng)的不下十個(gè)性能測(cè)試場(chǎng)景案例，等后來運(yùn)行時(shí)卻發(fā)現(xiàn)我必須增補(bǔ)幾個(gè)案例才能找到瓶頸，而原來十多個(gè)案例其實(shí)重復(fù)甚多。如果你要寫出好的不重復(fù)的性能測(cè)試案例來，你就得對(duì)被測(cè)軟件系統(tǒng)有一定的了解。

　　在這里，我順便插一句，在目前測(cè)試界總在爭(zhēng)論測(cè)試人員需不需要懂編程，需不需要有開發(fā)經(jīng)驗(yàn)這種問題，這完全是本末倒置，忘記了測(cè)試人員的目標(biāo)是什么，測(cè)試目標(biāo)就是寫出好的測(cè)試案例，好的測(cè)試案例就是發(fā)現(xiàn)了一個(gè)原來未曾發(fā)現(xiàn)的軟件bug。那么一個(gè)測(cè)試人員知識(shí)體系是否夠用的標(biāo)準(zhǔn)就是能不能寫出一個(gè)好的測(cè)試案例。而針對(duì)不同類型的測(cè)試，所需的知識(shí)深度是不一樣的，有的是不需編程知識(shí)，比如界面測(cè)試;有的是必須有開發(fā)經(jīng)驗(yàn)的，比如接口測(cè)試，不能一概而論。

　　對(duì)于性能測(cè)試來講，我個(gè)人認(rèn)為，測(cè)試人員倒不一定非要有開發(fā)經(jīng)驗(yàn)，但是應(yīng)該有一個(gè)對(duì)軟件體系結(jié)構(gòu)了解全面的知識(shí)。為什么呢?做性能測(cè)試時(shí)，如果從客戶端施壓一次就符合性能指標(biāo)，碰到這種情況您就偷著樂吧，因?yàn)樵谀愕闹笜?biāo)場(chǎng)景下，軟件系統(tǒng)中就不存在性能瓶頸，您也就不用費(fèi)心去找了。但是大多數(shù)情況下，我們?cè)谧鲂阅軠y(cè)試時(shí)，都不能順利達(dá)到性能指標(biāo)，可能server響應(yīng)超時(shí)了，也可能是用戶死掉了，在日志里拋出了一堆error，這種情形是非常常見，所以在我們?cè)谝婚_始設(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è)試案例來發(fā)現(xiàn)的。一般地，我自己常用的感覺也比較方便的方法是，設(shè)計(jì)一組性能測(cè)試案例來驗(yàn)證一個(gè)節(jié)點(diǎn)是否存在瓶頸，這組case中盡量保持其他節(jié)點(diǎn)不變，來改變這個(gè)節(jié)點(diǎn)的配置，并監(jiān)控此節(jié)點(diǎn)的各種指標(biāo)。這里說起來就有很多話了，不是一言兩語能說得清的。以后有時(shí)間可以找個(gè)專題來慢慢跟大家討論。

　　二、使用loadrunner的VU生成腳本。腳本的生成方式就兩種，一種是自寫或嵌入源代碼，一種是錄制生成。常常聽見有人說，這兩種方式中首選錄制生成腳本，因?yàn)樗��?jiǎn)單且智能化。但我個(gè)人總覺得手寫腳本要好一些，因?yàn)椋?/P>

　　1 .可讀性好，流程清晰，檢查點(diǎn)截取含義明確。業(yè)務(wù)級(jí)的代碼讀起來總比協(xié)議級(jí)的代碼更易讓人理解，也更容易維護(hù)，必要時(shí)可建立一個(gè)腳本庫。而錄制生成的代碼大多沒有維護(hù)的價(jià)值，現(xiàn)炒現(xiàn)賣。

　　2 .手寫的程序相比錄制的腳本更能真實(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 .手寫程序相比錄制腳本更能增加測(cè)試人員的技術(shù)含量。開發(fā)和測(cè)試能力雙重提高，何樂而不為呢?loadrunner提供了java user，vb user，c user等語言類型的腳本，就是給我們開發(fā)腳本用的，而不是錄制用的。

　　腳本不管錄制也好，還是手寫也好，選擇的時(shí)候應(yīng)該以腳本模擬程序真實(shí)有效為準(zhǔn)，結(jié)合項(xiàng)目進(jìn)度，開發(fā)難易程度等因素考慮。

　　在這里我想要說的是，開發(fā)一個(gè)好的腳本是成功性能測(cè)試的必要條件。一個(gè)好的腳本應(yīng)該能夠最大程度再現(xiàn)client程序行為。如上面那個(gè)例子，腳本只模擬了client端的部分行為，有一些沒有模擬到，那么client的瓶頸就有可能被忽略了。我曾吃過一個(gè)虧，自己寫了一個(gè)java socket腳本去聯(lián)server，但是忽略了client端的界面下的業(yè)務(wù)邏輯，用我的腳本做性能測(cè)試通過，全部OK，但是真實(shí)用戶一上線，client終端界面接受了大量的server信息，導(dǎo)致client進(jìn)程死掉了。痛哉，痛哉。