2010年軟件水平考試軟件測評師自動化測試(12)

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

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

　　1. 確認在VU里SUSI(單用戶單循環(huán)次數(shù)single user & single iteration)

　　2. 確認在VU里SUMI(單用戶多循環(huán)次數(shù)single user & multi iteration)

　　3. 確認在controller中MUSI(多用戶單循環(huán)次數(shù)multi user & single iteration)

　　4. 確認在controller中MUMI(多用戶多循環(huán)次數(shù) multi user & multi iteration)

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

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

　　做個如下可能并不恰當?shù)谋扔鳎?/P>

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

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

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

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

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

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

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

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

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

　　個人體會，查找瓶頸的難易程度，由易到難

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

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

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

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