讓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中運行成功，這是一個顯然的邏輯。軟件工程中把軟件開發的種種行為都要制定一個proclearcase/" target="_blank" >ccess，即過程，性能測試也是如此，按照過程來調試腳本和場景，能及早發現問題和定位問題。除非是高手，爛熟于心中，才能超越proccess而不出問題。
        場景是把虛擬用戶和交易數按一定規則組織起來去模擬真實世界的業務行為。這其實是把單個用戶的行為復制，連接。場景的組織通常和真實世界的業務規則有很大關系。 
       

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