三、組建并執(zhí)行性能測試場景。

　　從VU運(yùn)行成功到controller運(yùn)行成功，一般需要以下幾個(gè)步驟(我也是從英文論壇上看到的，覺得不錯(cuò)，拿出來共享)：

　　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)證腳本編寫的正確，第二步驟可以驗(yàn)證數(shù)據(jù)池是否正常運(yùn)作。第三步驟驗(yàn)證并發(fā)功能，第四步驟是最終目的，驗(yàn)證軟件系統(tǒng)的性能。在論壇上看到一些朋友提的問題，有一些就是于此的，在controller中運(yùn)行場景時(shí)出現(xiàn)問題，首先得保證VU中運(yùn)行成功，這是一個(gè)顯然的邏輯。軟件工程中把軟件開發(fā)的種種行為都要制定一個(gè)proccess，即過程，性能測試也是如此，按照過程來調(diào)試腳本和場景，能及早發(fā)現(xiàn)問題和定位問題。除非是高手，爛熟于心中，才能超越proccess而不出問題。

　　場景是把虛擬用戶和交易數(shù)按一定規(guī)則組織起來去模擬真實(shí)世界的業(yè)務(wù)行為。這其實(shí)是把單個(gè)用戶的行為復(fù)制，連接。場景的組織通常和真實(shí)世界的業(yè)務(wù)規(guī)則有很大關(guān)系。

　　做個(gè)如下可能并不恰當(dāng)?shù)谋扔鳎?/P>

　　腳本像演員，場景就像表演的舞臺，而測試工程師是導(dǎo)演，多少個(gè)演員，怎么在舞臺上演出，都由導(dǎo)演說了算，而劇情又不能離譜，脫離現(xiàn)實(shí)，否則就要砸鍋了。注意，導(dǎo)演的職責(zé)不光是確保演出能順利結(jié)束，而且還要同時(shí)觀察和收集觀眾的反饋信息，以確認(rèn)這次演出是否成功。

　　同樣的也是，性能測試人員不光是看場景是否得到順利的執(zhí)行，同時(shí)還要收集各個(gè)server的反饋信息，以確認(rèn)軟件系統(tǒng)的性能表現(xiàn)是否正常。

　　在真實(shí)世界中的用戶業(yè)務(wù)規(guī)則要轉(zhuǎn)換到可操作的性能指標(biāo)是需要分析和計(jì)算的。當(dāng)然這通常是市場需求分析人員干的活，但我覺得測試人員應(yīng)該在做性能測試時(shí)，對這些指標(biāo)進(jìn)行理解，知道為什么要這樣做。有時(shí)有的性能指標(biāo)并不清楚和準(zhǔn)確，還需要測試人員來分析。比如一個(gè)性能指標(biāo)：要求軟件系統(tǒng)支持每分鐘700用戶的登陸行為。這對于測試人員來說，其實(shí)是一個(gè)不確切的性能需求。這指的是瞬時(shí)并發(fā)用戶700，在一分鐘的響應(yīng)時(shí)間要求下登陸系統(tǒng)?還是在一分鐘內(nèi)陸續(xù)有700個(gè)用戶登入軟件系統(tǒng)即可?這兩種場景其實(shí)對軟件系統(tǒng)的壓力是不同的，第一種顯然大，第二種要小一些。甚至有的性能需求就是支持50000注冊用戶，這種需求就更需要分析了，還要引入一些業(yè)務(wù)發(fā)生概率算法模型來做。這已經(jīng)不是性能測試人員的職責(zé)了，但由于目前有不少軟件公司流程不規(guī)范，或者有流程沒執(zhí)行，這些工作都要測試人員來做了，不過也好，正好是鍛煉的機(jī)會(huì)。

　　四、分析結(jié)果數(shù)據(jù)，找到軟件系統(tǒng)性能瓶頸

　　上面說了，做了那么多，就是為了本步驟-尋找軟件系統(tǒng)性能瓶頸。

　　個(gè)人認(rèn)為尋找性能瓶頸是一個(gè)非常有挑戰(zhàn)性的工作，毛主席曾經(jīng)說過：一個(gè)優(yōu)秀的指戰(zhàn)員就是能夠根據(jù)已有的客觀形勢，制定作戰(zhàn)計(jì)劃，然后在作戰(zhàn)過程中，發(fā)現(xiàn)計(jì)劃與執(zhí)行不符的地方，分析，然后調(diào)整作戰(zhàn)計(jì)劃，縮小計(jì)劃和戰(zhàn)勢的誤差。簡明一句：就是一個(gè)理論和實(shí)踐結(jié)合的過程，一個(gè)人的主觀思想和客觀現(xiàn)實(shí)的結(jié)合過程(注明：本人是毛主席老人家的忠實(shí)fans)。

　　在性能測試中，測試方案就是我們的作戰(zhàn)計(jì)劃，執(zhí)行性能測試就是我們的作戰(zhàn)戰(zhàn)場。在性能測試中，可能會(huì)發(fā)現(xiàn)種種意想不到的問題。當(dāng)然一個(gè)經(jīng)驗(yàn)足夠豐富的性能測試專家可能會(huì)在測試之前就能考慮全面，使測試方案吻合測試執(zhí)行實(shí)際情況，并一舉找出性能瓶頸。我sunshinelius不是專家水平，當(dāng)然就要匆忙應(yīng)對和分析性能測試中出現(xiàn)的問題，并有可能會(huì)修改測試方案，增加必要的test case，刪除沒用的test case�？傊�，性能測試是一個(gè)不斷修改測試方案，反復(fù)執(zhí)行test case的過程，直至越來越逼近性能瓶頸。在此過程中，需要了解很多的知識，知識了解得越多，就越接近軟件系統(tǒng)運(yùn)行的真相，也就能找出性能瓶頸了。

　　比如：loadrunner要是調(diào)用程序員的程序，服務(wù)器資源占用情況可能是追查瓶頸的一個(gè)線索，但如果是標(biāo)準(zhǔn)中間件，那就沒那么簡單了，比如oracle數(shù)據(jù)庫的某項(xiàng)參數(shù)設(shè)得不對，照樣會(huì)造成數(shù)據(jù)庫瓶頸，應(yīng)用程序調(diào)用數(shù)據(jù)庫的API寫法不對，比如未使用軟解析變量，也有可能導(dǎo)致數(shù)據(jù)庫瓶頸。這些瓶頸都不會(huì)反映在cpu，內(nèi)存使用量上等指標(biāo)上的。

　　對于這種情況，一方面需要對中間件有一定的了解，知道哪些參數(shù)有什么作用，怎么可調(diào)的，另外還可能使用中間件的專有監(jiān)測工具，來分析。lr的性能計(jì)數(shù)器是不夠用的。

　　個(gè)人體會(huì)，查找瓶頸的難易程度，由易到難

　　服務(wù)器硬件瓶頸-〉網(wǎng)絡(luò)瓶頸-〉應(yīng)用瓶頸-〉服務(wù)器操作系統(tǒng)瓶頸(參數(shù)配置)-〉中間件瓶頸(參數(shù)配置，數(shù)據(jù)庫，web服務(wù)器等)

　　記憶比較深刻的一次，用lr做了兩天性能測試，指標(biāo)上不去，后來使用oracle數(shù)據(jù)庫的圖形化性能檢測工具才發(fā)現(xiàn)某個(gè)表的查詢處理時(shí)間超長，原來索引創(chuàng)建得不合理，把表的索引改了之后，性能稍有提高，但還是上不去。再次排查，發(fā)現(xiàn)應(yīng)用中有一個(gè)sql語句寫得有問題，長而且耗時(shí)，改了之后，測試指標(biāo)還是上不去

　　經(jīng)過至少四輪的排查，才大功告成，最后一個(gè)除掉的瓶頸是操作系統(tǒng)問題(開始沒有想到它，后來看系統(tǒng)消息，才發(fā)現(xiàn)已經(jīng)有錯(cuò)誤報(bào)出)

　　五、每個(gè)系統(tǒng)的性能測試都是一個(gè)全新的挑戰(zhàn)!