讓LoadRunner再次走下神壇

標籤：

1.        LoadRunner 阻礙了效能測試人員對通訊過程的理解
我希望做效能測試的人能忘掉這個工具。我們都知道VuGen有錄製的功能，其實錄製這個功能對於測試來說是個非常不好的選擇，就是跟後面的情境執行帶來很多的不定的因素。因為一些人對指令碼的不理解，或者說根本就不知道指令碼是什麼意思，導致了出現一些效能問題的時候，束手無策。也不知道如何去尋找原因。所以我覺得效能測試人員手寫指令碼是最好的選擇，但是難道錄製功能就不可用嗎？當然不是這樣，不過如果錄，就一定要知道指令碼中各個函數的含義，要徹底明白這些函數想完成什麼功能，能實現什麼，不能實現什麼。這樣才能在出現某些問題時，知道如何去解決。並且問題的解決過程要依賴其他的知識，並不是會了LR，找了協助，就可以解決得了的。所以依賴工具要有個度，不然做的效能測試也不可信。
我們都知道LR支援了很多網路通訊協定，並且根據這些具體網路通訊協定衍生出各自的專用語言，這個應該是它最大的優點了，但是LR也並不是對這些它聲明了支援的語言都支援的很好的。我們知道在8.0版本的時候，LR裡面就已經有了Java ajax的協議，但是如果不修改設定檔是不顯示出來的。那到現在9.5的版本，早已經把這個協議公開出來了，但是用這個協議還是感覺遇到很多這樣那樣的問題。同樣，其他有些協議也是這樣。會用工具，和會做效能測試，絕對是兩回事，所以不要太依賴LR。我們都知道Mercury提出了BTO的概念，所以很多LR裡的概念設計也是從business的角度來解釋的。做測試的專業人員，要瞭解它的這些概念和我們具體的環境之間的關係，否則只能照搬照套。所以也可以這麼說，LR的重點在於對協議的掌握程度，不一定都會，但是要特別精通某些一些跟自己測試密切相關的。其實我們的測試人員很多都不太瞭解上述的 ajax架構，所以即使做了效能測試也是“止於外表，不及其裡”，那麼就浪費資源了。
再說一點，LR對資料庫的支援。一直以來，我們知道，在LR裡要想直接面對資料庫測試，是比較麻煩的（相對http協議來說）。前幾天，看了一下其他的工具，有些工具中把和資料庫通訊做成了相應的模組，操作起來，很簡單，需要編寫的代碼也比較少。這樣的功能就比LR中做的要好。但是我們也要理解，LR是 BTO概念下的產品。值得注意的是，開發很多都會用到類映射資料的模式進行相應表操作（例如hibernate），這樣在效能測試的時候需要特別注意對應用伺服器的進程設定，也許會出現這樣的情境，資料庫伺服器無壓力，應用伺服器已經提前“陣亡”了。

2.        LoadRunner簡化了效能測試過程
從Mercury的效能測試執行流中可以看到，它分成了這麼幾個部分：計劃測試、建立指令碼、建立情境、執行情境、分析結果。這種分法，可以說代表了效能測試過程中的主要部分。但是這個過程也會導致結果混亂。首先，效能測試需要調研，並且需要調研的很細，可能在大部分的公司裡都沒有做到這樣，但是，這不能說明調研這部分是可以忽略的。我們經常會遇到效能測試做完了，還在討論效能測試需求的現象。這對於我們來說不能不說是難受的事情。還有建模，LR的方法論和執行流中都沒有提到建模這一過程，而在實際的應用環境中，我們還是要考慮這一過程，只有這一過程才是情境設定的前提。應該說，在LR中做不到建模，但是應該在執行流和方法論中提到它。在一個完整的效能測試過程中，還有很多的管理上的因素制約，當然，這個不能依賴工具。我們後面再談相關的問題。
在LR的市場如此強大之下，我覺得應該只考慮到它是一個工具，而不是可以完成效能測試整個過程中的事情的萬能產品。我在遇到很多初學效能測試和已經做過一段時間的效能測試的朋友，經常被問到類似這樣的一些問題：我會用LR了，我可以做效能測試了？我們公司有LR了，我們可以推廣效能測試了嗎？或者更嚴重的，有了LR，效能測試就有了保障的感覺。它並不是尚方寶劍，我們拿了誰都能砍。實際上，知道如何砍或者怎麼砍才是最重要的，竹葉也是利器。
我碰到過好幾次這樣的現象，客戶認為給了兩天的時間或者一天時間就可以把一個效能測試做完了，因為你用的是工具，並且它又能自動產生結果。而往往，一個非常非常熟悉工具的人，對過程和結果的分析都不是很清楚。並且寫報告時也只能描述表面的現象。這樣的效能測試只能說有個警示的作用，對實際的系統品質提升意義都不大。有一個80年代就開始寫程式的同事說：“這種效能測試方式，對系統品質一點都起不到保障作用，只是忽悠客戶。”並且系統層級的效能測試已經不可能從大局上去改變什麼了，只能尋找一下系統的缺陷，也談不到對調優有什麼建設性的指導意義。而LR的設計主要還是面對系統級的效能測試，所以我們使用它，要瞭解它能給我們帶來什麼。也許有人要鑽牛角尖，我就用它來做更細的代碼和整合的效能測試不可以嗎？也不能說完全不能，用牛刀殺雞也是行的，就是揮著過重，搞不好雞沒殺好反而平添肩周炎。

3.        LoadRunner的監控弱點
前幾天被問到LR對資料庫和應用伺服器的監控問題，我一直在建議他們用其他的工具去做。因為LR的監控只是一個殼子，並且個人認為，是個效率不是很高的殼子。就拿對oracle的監控來說，我們都知道LR在串連了oracle之後，會有兩個表可以選擇，裡面有很多的計數器，對效能測試工程師來說，選擇什麼計數器，都是很為難的事情，因為不知道這些計數器是什麼意思。所以大部分情況下，我們看到一些人的推薦就是選擇預設的那些（在help裡有一些說明）。如果我們遇到的問題正好在我們選擇的那幾個計數器裡有體現，還真是太幸運了。不過這種現象就像走在路上撿了一百塊錢一樣不穩定。所以我們還要反覆的去執行情境以判斷問題出現的瓶頸。這對我們效能測試來說是很痛苦的事情。因為有些情境可以執行了好幾個小時，好幾天，甚至一周時間。監控Weblogic也是一樣，我寧可肯定用WebLogicScripting Tool去寫指令碼監控，也不是很推薦用LR的監控功能。就算排除工具之間的相容性不說，我覺得LR做到的監控也比效能測試過程中想達到的效率要差不少。當然，有些商業工具已經做的相當好了，並且資源佔用還可以接受。對unix的監控也是這樣，我們如果用LR來做，可能不知道什麼時候，RPC就倒塌了。我們不得不重頭再來，這一點對我們長時間的情境執行來說，都是致命的傷害。用LR監控unix，盡量的可不用就不用。用nmon或者使用UNIX內建的效能監控工具都可，什麼top啊glance啊有的咱們都上，不過最後提醒一句，它們的運行也都是需要申請主機資源的。
因為很多人喜歡在一個結果裡看到所有的資料，目的是為了保證資料的同步性，所以不遺餘力的在LR中完成這樣那樣的監控功能。但是不管資料在結果中有多全，對結果的分析還是要靠自己敏銳的嗅覺和豐富的經驗，並且，LR中實現的這樣的監控點其實效率並不高，所以我推薦的是，用最少的資源做最多的事情。不要太依賴某個工具。我現在的工作中，做一次完整的效能測試，都會用到很多個工具，組合這些工具的結果，一起分析。並且有些功能的即時查看功能要比LR強很多。再加上，LR的結果直接產生的報告，也不可能做為我們的最終報告來用，所以讓所有的資料都在分析器裡的做法，只具有無意義的個人完善感，對實際的結果意義不大。

4.        LR是個前端工具
（這裡說的前端工具，不是指頁面的展現，而是為了強調在一個應用中LR工具所在的位置）
通常情況下，在LR中能夠體現出來的問題，已經是經過了系統中一系列的處理之後拋到LR上的，所以，我們再討論LR的某個錯誤代號和列印出來的那一串串紅色的字串已經沒有實質的意義了。還需要進一步去分析應用的整個通訊過程，才能找到最終問題本質。例如某些程式員喜歡把原始SQL語句直接寫到代碼中，幾百萬行你哪裡找得到？效能出來了就很難看， LR肯定會告訴你機器IO吞吐的厲害，再細分原因就啥都沒有了，與其這樣還不如自己寫效能分析器呢。就像昨天剛給一個朋友解決的一個考慮時間放到for迴圈內部和外部就出現不同的錯誤一樣，如果僅僅看LR，肯定只能描述這個問題的現象，而找不到問題的原因。
在LR的情境執行過程中，所有的預設擷取的資料，都是從LR這個工具本身得到的，也就是說這些資料，都不能直接反應伺服器的效能狀況。我們分析這些資料的時候，一定要給出相應的伺服器端的資料，以證明我們的這個資料是有意義的。單獨說TPS有多少，回應時間有多大，輸送量有多高，一點意義都沒有。因為這些資料是有前提的，而這些前提，LR都提供不了。
當然，所有的壓力產生的工具，也都是前端工具。把它單獨拎出來說的原因是要說明，效能測試並不是一個前端工具，可以做得完的。它只能是一個承載現象的工具。真正要做的還是後面的分析。

5.        關於分析和調優
在分析這一塊，analysis還是給出了不少好用的工具的，當然這些工具對資料的處理，也是有一定的原因和規律的。我們還要瞭解到這些，才能對一個結果做非常完善的分析。就拿一個簡單的例子來說，LR中提供的回應時間在summary裡為什麼是最大、最小、平均、標準方差、90%這幾個值？我們要瞭解這些的原因，再去做詳細的分析，從而可以完善的對前端的資料做分析了。但是這些分析，都不能成為報告中的關鍵資料，因為還需要對一個系統的所有層面做分析才能在報告中寫上有建議性意義的部分。我們做效能測試，不能說，可能是什麼原因引起了什麼問題，我經常看到這樣的報告。這樣的報告，如果是寫給我看的話，我肯定是打回去重寫。我們面對客戶的時候，也會出現這樣的問題，前一陣子剛做了一個項目，另一個同事寫的報告，就讓我從頭到尾的改了一遍，因為原來的報告中只是資料的羅列。
相對來說，LR在羅列資料這一塊，做的還是最好的。但是，LR不會告訴你你測試的結果怎麼樣，當然你可以設定SLA，但是也沒有什麼用，因為這個設定是在你知道你的目標的前提下，這裡僅是拿SLA和測試結果做個對比，以供寫報告時好看而已。當然分析資料中包括DB、APP、Middleware等等的資料時，我們還要查看相應的監控結果。分析是一個順藤摸瓜的過程，千萬不能斷，斷了就只能描述過程，而得不到結果了。上面說監控時，我強調的是用一些廠商自己的監控功能，這時就會有非常好的效果了。我們不能讓LR告訴我們Top 5 of SQL，但是Statspack可以告訴我們。其他的監控工具類似。所以如果你想做好分析，還是用更好的監控工具，這裡言下之意就是：LR在很多方面都不是最好的監控工具。
調優，同樣，LR絕對做不到調優，因為它連分析都做不到。只有靠我們自己順著藤摸到了瓜之後，再想辦法把它摘下來。如果這個過程中用LR的監控功能，很容易斷線，所以調優靠這些資料，會更累。

6.         軟體效能工程
前幾天，我在修改自己的7點測試論壇中的效能分區名稱的時候，一直想不起來給效能測試這個大分區取一個合適的名字。最後終於定位到一個詞：軟體效能工程。
在每一個軟體效能測試項目中，這都是一個工程，工程就要有角色劃分，有職責劃分，有時間進度控制，有風險控制，等等內容。而這些都不是一個工具可以代表的，管中窺豹，永遠不知道它長什麼樣子。我們也不能拿著LR到處去說，我可以做效能測試。而在整個軟體效能工程中，我們要做的更多的是管理和控制的工作，這些才是我們效能測試關注的重點。一上來就拿著LR錄製指令碼加壓的效能測試工程師，我認為肯定不是好的效能測試工程師。但是每個人都要從拿著工具去錄製指令碼加壓這個過程認認真真的學習過來。也要對每一個操作和步驟認真的思考和理解，以完善對軟體效能工程的認識。也許有一天效能測試版塊裡能加入一些真正的系統專家，那確實是效能測試領域之福了。
軟體效能工程，是一個完善的整體的概念，需要有大局觀的認識。要從需要到最後的產品交付的每個階段去關注效能（這裡不包括營運的階段），也要明確的知道效能測試所佔的整個軟體效能工程的位置。從架構設計、模組設計、資料庫設計，編碼都要關注效能，往往發現效能瓶頸後，由於整個系統設計上的問題，無法改變，所以效能無法調優，只能起到評價的作用。在這樣的時候，即使效能測試人員能力再強，也翻不出什麼花樣來。
另外，軟體效能工程是需要配合的，並不是一個拿著工具的效能測試工程師可以完成的事情，上面已經說到工程要有角色劃分、職責劃分，那我們的軟體效能工程需要什嗎？軟體效能工程需要的是：作業系統人員、資料庫人員、網路人員、中介軟體人員、應用伺服器人員等等的配合，這一過程中，哪裡有了問題，就需要相應的人去檢查原因和解決問題。而有些公司和客戶認為一個或幾個會工具的效能測試工程師就能完成一個完整的效能工程，我只能說，這些人都是全才（這樣的人應該很值錢）。應用測試知識和技術手段，在多角色相互配合之下，使得軟體效能工程實施起來更具有可操作性，一個軟體系統的效能才能更有保障。

僅以此文，記錄我所理解的的效能測試和LoadRunner之間的關係。

 

轉載：http://www.51testing.com/html/48/202848-130049.html

讓LoadRunner再次走下神壇