使用LoadRunner不容易解決的問題(2)

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

　　做個如下可能并不恰當的比喻：

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

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

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

　　四.分析結果數據，找到軟件系統性能瓶頸

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

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

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

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

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

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

　　服務器硬件瓶頸-〉網絡瓶頸-〉應用瓶頸-〉服務器操作系統瓶頸(參數配置)-〉中間件瓶頸(參數配置，數據庫，web服務器等)

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

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

　　五.我再說兩句

　　每個系統的性能測試都是一個全新的挑戰!

原文轉自：http://www.anti-gravitydesign.com