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

轉載于:https://www.cnblogs.com/zhangyublogs/p/5325004.html

總結

以上是生活随笔為你收集整理的让LoadRunner再次走下神坛的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。