讓loadrunner走下神壇(全）

Loadrunner無疑是一個強大有力的壓力測試工具。它的指令碼可以錄製產生，自動關聯；測試情境可以面向指標，多方監控；測試結果圖表顯示，拆分組合。相信有人這樣想象過：拿著一張效能指標標準列表和測試資料相比較，如同PH試紙一樣，遇堿則藍，遇酸則紅，一目瞭然，之後就可以大聲地喊道：我找到了軟體系統的效能瓶頸！
然而，我們無論在loadrunner前面加多少個“強大”、“智能”的形容詞，別忘了其最終修飾的只是一個名詞－“工具”。《大話西遊》中也有相當精闢的論斷：官兵？最多也只是個長了痔瘡的官兵！把loadrunner比喻成長了痔瘡的官兵有點粗俗，但loadrunner它是個工具，那麼是否能夠找到效能瓶頸就取決於使用工具的人，而不是工具本身。要做一個成功的效能測試，僅讀懂和精通了loadrunner的使用手冊是不夠的，還需要對被測軟體系統的方方面面都要有瞭解，比如軟體體系構架，網路拓撲等知識。這就如同一個技藝高超的木匠，並不是因為他背熟了鑿子，鎚子的說明書，而是他能結合木材的質地和尺寸，用鑿子和鎚子這些工具做出一把精巧的椅子來。那麼在效能測試中，人的智慧活動體現在哪裡呢？
一．首先效能測試也是測試的一種，這就意味著做效能測試也要寫測試案例。你所作的效能測試能不能足以支援找出效能測試瓶頸，和你在初期設計的測試案例關係甚為重要。我曾寫過對一個軟體系統的不下十個效能測試情境案例，等後來運行時卻發現我必須增補幾個案例才能找到瓶頸，而原來十多個案例其實重複甚多。如果你要寫出好的不重複的效能測試案例來，你就得對被測軟體系統有一定的瞭解。
在這裡，我順便插一句，在目前測試界總在爭論測試人員需不需要懂編程，需不需要有開發經驗這種問題，這完全是本末倒置，忘記了測試人員的目標是什麼，測試目標就是寫出好的測試案例，好的測試案例就是發現了一個原來未曾發現的軟體bug。那麼一個測試人員知識體系是否夠用的標準就是能不能寫出一個好的測試案例。而針對不同類型的測試，所需的知識深度是不一樣的，有的是不需編程知識，比如介面測試；有的是必須有開發經驗的，比如介面測試，不能一概而論。
對於效能測試來講，我個人認為，測試人員倒不一定非要有開發經驗，但是應該有一個對軟體體繫結構瞭解全面的知識。為什麼呢？做效能測試時，如果從用戶端施壓一次就符合效能指標，碰到這種情況您就偷著樂吧，因為在你的指標情境下，軟體系統中就不存在效能瓶頸，您也就不用費心去找了。但是大多數情況下，我們在做效能測試時，都不能順利達到效能指標，可能server響應逾時了，也可能是使用者死掉了，在日誌裡拋出了一堆error，這種情形是非常常見，所以在我們在一開始設計效能測試方案時，就應該考慮為尋找效能瓶頸而設計測試案例。這時我們就需要知道在整個軟體系統中，有哪些節點，在哪些地方可能存在瓶頸，比如一個B/S系統就有IE client→物理網路→web server→app server→DB這樣的一個壓力流串。每個節點的每個模組都有可能成為瓶頸。瓶頸的產生可能由於模組配置引起，也可能由於模組本身引起。這都需要我們設計測試案例來發現的。一般地，我自己常用的感覺也比較方便的方法是，設計一組效能測試案例來驗證一個節點是否存在瓶頸，這組case中盡量保持其他節點不變，來改變這個節點的配置，並監控此節點的各種指標。這裡說起來就有很多話了，不是一言兩語能說得清的。以後有時間可以找個專題來慢慢跟大家討論。
二．使用loadrunner的VU產生指令碼。指令碼的產生方式就兩種，一種是自寫或嵌入原始碼，一種是錄製產生。常常聽見有人說，這兩種方式中首選錄製產生指令碼，因為它簡單且智能化。但我個人總覺得手寫指令碼要好一些，因為：
1．可讀性好，流程清晰，檢查點截取含義明確。業務級的代碼讀起來總比協議級的代碼更易讓人理解，也更容易維護，必要時可建立一個指令碼庫。而錄製產生的程式碼大多沒有維護的價值，現炒現賣。
2．手寫的程式相比錄製的指令碼更能真實地類比應用運行。因為錄製的指令碼是截獲了網路包，產生了協議級的代碼，而略掉了client端的處理邏輯。舉個例子，用VU錄製一個運行script和applet的IE行為，它只會產生http協議的API，在IE中啟動並執行applet和script不會被類比到，這就不是一個完整的系統。
3．手寫程式相比錄製指令碼更能增加測試人員的技術含量。開發與測試能力雙重提高，何樂而不為呢？loadrunner提供了java user，vb user，c user等語言類型的指令碼，就是給我們開發指令碼用的，而不是錄製用的。
指令碼不管錄製也好，還是手寫也好，選擇的時候應該以指令碼類比程式真實有效為準，結合項目進度，開發難易程度等因素考慮。
在這裡我想要說的是，開發一個好的指令碼是成功效能測試的必要條件。一個好的指令碼應該能夠最大程度再現client程式行為。如上面那個例子，指令碼只類比了client端的部分行為，有一些沒有類比到，那麼client的瓶頸就有可能被忽略了。我曾吃過一個虧，自己寫了一個java socket指令碼去聯server，但是忽略了client端的介面下的商務邏輯，用我的指令碼做效能測試通過，全部OK，但是真實使用者一上線，client終端介面接受了大量的server資訊，導致client進程死掉了。痛哉，痛哉。
三．組建並執行效能測試情境。
從VU運行成功到controller運行成功，一般需要以下幾個步驟（我也是從英文論壇上看到的，覺得不錯，拿出來共用）：
1.        確認在VU裡SUSI（單使用者單迴圈次數single user & single iteration）
2.        確認在VU裡SUMI（單使用者多迴圈次數single user & multi iteration）
3.        確認在controller中MUSI（多使用者單迴圈次數multi user & single iteration）
4.        確認在controller中MUMI（多使用者多迴圈次數 multi user & multi iteration）
做這樣一個步驟劃分是有道理的，第一步驟是驗證指令碼編寫的正確，第二步驟可以驗證資料池是否正常運作。第三步驟驗證並發功能，第四步驟是最終目的，驗證軟體系統的效能。在論壇上看到一些朋友提的問題，有一些就是於此的，在controller中運行情境時出現問題，首先得保證VU中運行成功，這是一個顯然的邏輯。軟體工程中把軟體開發的種種行為都要制定一個proccess，即過程，效能測試也是如此，按照過程來調試指令碼和情境，能及早發現問題和定位問題。除非是高手，爛熟於心中，才能超越proccess而不出問題。
情境是把虛擬使用者和交易數按一定規則群組織起來去類比真實世界的業務行為。這其實是把單個使用者的行為複製，串連。情境的組織通常和真實世界的商務規則有很大關係。
做個如下可能並不恰當的比喻：
指令碼像演員，情境就像表演的舞台，而測試工程師是導演，多少個演員，怎麼在舞台上演出，都由導演說了算，而劇情又不能離譜，脫離現實，否則就要砸鍋了。注意，導演的職責不光是確保演出能順利結束，而且還要同時觀察和收集觀眾的反饋資訊，以確認這次演出是否成功。
同樣的也是，效能測試人員不光是看情境是否得到順利的執行，同時還要收集各個server的反饋資訊，以確認軟體系統的效能表現是否正常。
在真實世界中的使用者商務規則要轉換到可操作的效能指標是需要分析和計算的。當然這通常是市場需求分析人員乾的活，但我覺得測試人員應該在做效能測試時，對這些指標進行理解，知道為什麼要這樣做。有時有的效能指標並不清楚和準確，還需要測試人員來分析。比如一個效能指標：要求軟體系統支援每分鐘700使用者的登陸行為。這對於測試人員來說，其實是一個不確切的效能需求。這指的是瞬時並發使用者700，在一分鐘的回應時間要求下登陸系統？還是在一分鐘內陸續有700個使用者登入軟體系統即可？這兩種情境其實對軟體系統的壓力是不同的，第一種顯然大，第二種要小一些。甚至有的效能需求就是支援50000註冊使用者，這種需求就更需要分析了，還要引入一些業務發生機率演算法模型來做。這已經不是效能測試人員的職責了，但由於目前有不少軟體公司流程不規範，或者有流程沒執行，這些工作都要測試人員來做了，不過也好，正好是鍛煉的機會。
四．分析結果資料，找到軟體系統效能瓶頸
上面說了，做了那麼多，就是為了本步驟－尋找軟體系統效能瓶頸。
個人認為尋找效能瓶頸是一個非常有挑戰性的工作，毛主席曾經說過：一個優秀的指戰員就是能夠根據已有的客觀形勢，制定作戰計劃，然後在作戰過程中，發現計劃與執行不符的地方，分析，然後調整作戰計劃，縮小計劃和戰勢的誤差。簡明一句：就是一個理論和實踐結合的過程，一個人的主觀思想和客觀現實的結合過程（註明：本人是毛主席老人家的忠實fans）。
在效能測試中，測試方案就是我們的作戰計劃，執行效能測試就是我們的作戰戰場。在效能測試中，可能會發現種種意想不到的問題。當然一個經驗足夠豐富的效能測試專家可能會在測試之前就能考慮全面，使測試方案吻合測試執行實際情況，並一舉找出效能瓶頸。我sunshinelius不是專家水平，當然就要匆忙應對和分析效能測試中出現的問題，並有可能會修改測試方案，增加必要的test case，刪除沒用的test case。總之，效能測試是一個不斷修改測試方案，反覆執行test case的過程，直至越來越逼近效能瓶頸。在此過程中，需要瞭解很多的知識，知識瞭解得越多，就越接近軟體系統啟動並執行真相，也就能找出效能瓶頸了。
比如：loadrunner要是調用程式員的程式，伺服器資源佔用情況可能是追查瓶頸的一個線索，但如果是標準中介軟體，那就沒那麼簡單了，比如oracle資料庫的某項參數設得不對，照樣會造成資料庫瓶頸，應用程式調用資料庫的API寫法不對，比如未使用軟解析變數，也有可能導致資料庫瓶頸。這些瓶頸都不會反映在cpu，記憶體使用量量上等指標上的。
對於這種情況，一方面需要對中介軟體有一定的瞭解，知道哪些參數有什麼作用，怎麼可調的，另外還可能使用中介軟體的專有監測工具，來分析。lr的效能計數器是不夠用的。
個人體會，尋找瓶頸的難易程度，由易到難
伺服器硬體瓶頸-〉網路瓶頸-〉應用瓶頸-〉伺服器作業系統瓶頸（參數配置）-〉中介軟體瓶頸（參數配置，資料庫，web伺服器等）
記憶比較深刻的一次，用lr做了兩天效能測試，指標上不去，後來使用oracle資料庫的圖形化效能偵查工具才發現某個表的查詢處理時間超長，原來索引建立得不合理，把表的索引改了之後，效能稍有提高，但還是上不去。再次排查，發現應用中有一個sql語句寫得有問題，長而且耗時，改了之後，測試單位還是上不去
經過至少四輪的排查，才大功告成，最後一個除掉的瓶頸是作業系統問題（開始沒有想到它，後來看系統訊息，才發現已經有錯誤判出）
五．我再說兩句
每個系統的效能測試都是一個全新的挑戰！
轉自：http://bbs.51testing.com/thread-6154-1-1.html