04丨JMeter和LoadRunner：要知道工具僅僅只是工具
- 2020 年 2 月 24 日
- 筆記
性能測試第4篇文章
本文約6000字，約15分鐘
做性能測試工作的人總是離不了性能測試工具，但當我們剛開始接觸這類工具或者壓測平台的時候，總是難免處在一種顧此失彼，焦慮又沒想法的狀態。
性能工程師的三大學習階段
在我看來，對性能測試工程師本身來，多半會處在以下三個大的階段。
1、性能工具學習期
JMeter 和 LoadRunner 是我們常用的兩個性能測試工具。曾經有人問我，應該學 JMeter 還是 LoadRunner 呢？我反問的是，你學這樣的工具需要多久呢？一般對方因為初學並不清楚要多久，然後我會告訴他，如果你是認真努力的，想要全職學習，那麼我覺得一個工具，純從功能的使用的角度來說，自學兩個星期應該就差不多了。如果你是在工作中學習，那就更簡單了，工作中需要什麼就學習什麼，不用糾結。
而應該糾結的是什麼呢？當你把 JMeter、LoadRunner 的基本功能學會了，你會發現這些工具其實就做了兩件事情，做腳本和發壓力。
但問題在於，腳本的邏輯和壓力場景的邏輯，和工具本身無關，和業務場景有關。這時你可能就會問，場景怎麼配置呢？
這才進入到了另一個階段。
通常在這個階段的時候，你會覺得自己有非常明確的疑問，有經驗的人可能一句話就可以指點你了，解決掉你的疑問，就是告訴你選擇什麼工具，如何來用。
2、性能場景學習期
第二個階段就是性能場景學習期。我們平時在很多場合下所說的場景範圍都有些狹隘，覺得場景就是業務比例，就是用多少數據。而實際做過多個性能項目之後，你就會發現，工具中的一個小小的配置，也會對結果產生巨大的影響。
比如說壓力策略，應該用一秒 Ramp up 10 個用戶，還是 20 個用戶，還是 100 個用戶？這應該怎麼判斷呢？
比如說，參數化數據應該用 100 條，還是 100 萬條？還是有確定的值呢？有人說根據場景配置，可是根據什麼樣的場景怎麼配置才合理呢？
比如說，在執行場景時應該看哪些數據？壓力工具中的 TPS、響應時間這些常規數據都會去看，其他的還要看什麼呢？這就涉及到了監控策略。
再比如說，業務應該用什麼樣的比例設置到壓力工具中？有人說直接在線上做測試不是挺直接？但是你知道什麼樣的業務可以，什麼樣的業務不可以嗎？如何控制線上的性能測試？
在性能場景學習期這個階段，你關心的將不再是工具的使用操作，而是如何做一個合理的性能測試。你可以學會調整業務比例，並設計到壓力工具中；你可以學會參數化數據的提取邏輯；你可以學會場景中要觀察哪些數據。
按照這個思路，再做幾個項目，你就會慢慢摸著一些門道。
3、性能分析學習期
學會使用工具了，也有了場景設計的經驗，通過監控工具也拿到了一堆大大小小的數據。可是，數據也太多了，還在不斷的變化。我又怎麼判斷性能瓶頸在哪裡呢？
做性能的人都會有這樣的一個茫然。當你把一個性能測試結果發給了別人，別人會順理成章地去問你：「響應時間為什麼這麼長？有沒有優化空間？」
聽到這種問題，你有沒有無助的感覺？心裡台詞是：「我怎麼知道？」但是嘴上卻不敢說出來，因為似乎這是我應該給出的答案？
但是當你嘗試給出答案時，你就進入了一個大坑，對這個問題做出回答，近乎一個無底洞，需要太多的基礎知識，需要很強的邏輯分析，需要清晰的判斷思路。
如果你到了這個階段，你可能會發現自己走得非常痛苦，好像自己也不知道自己會什麼，不會什麼。要說工具吧，也完全會用，場景吧，也會配置，但為什麼就是不會分析結果，不會整理數據，不會下結論呢？
但實際上，我覺得你不要焦慮自己不會什麼，而應該把目光聚焦到你要解決的問題上。問題的解決，靠的是思維邏輯，靠的是判斷，而不是靠工具。
也就是說，這時面對問題，你應該說的是「我想要看什麼數據」，而不是「把數據都給我看看」。
看到這裡，希望你能清晰地理解這兩者之間的區別。
公司性能團隊成長階段
我剛才分析了一下作為個人的性能工程師是如何一步步成長的，在實際工作中，我們更多的需要與團隊合作，團隊的成長與我們個人的成長息息相關。
對於一個公司的一個性能團隊來說，大概會處在這些階段。
1、性能團隊初建
這時的團隊，可以執行場景，可以拿出數據，但工作出的結果並不理想。團隊整體的價值就體現在每天跟著版本跑來跑去，一輪輪地測試下去，一個版本短則一兩個星期，長則一個月。沒有時間去考慮測試結果對整個軟體生命周期的價值，在各種瑣碎的項目中疲於奔命。做腳本，拿出 TPS 和響應時間，做版本基準線比對，出數據羅列式的性能測試報告。
唉，想想人生就這麼過去了，真是心有不甘。這時有多少人希望能有一個性能測試平台來拯救團隊啊。
2、性能團隊初成熟
到了這個階段，團隊已經可以應付版本的更迭帶來的性能工作壓力，團隊合作良好，稍有餘力，開始考慮團隊價值所在，在公司的組織結構中應該承擔什麼樣的職責。在產品的流水線上終於可以佔有一席之地了。這樣很好，只是從實際的技術細節上來說，仍然沒有擺脫第一階段中瑣碎的工作，沒有把性能的價值體現出來，只是一個報告提供機器。
這時就需要考慮平台上是不是可以加個 SLA 來限制一下？在各個流程的關卡上，是不是可以做些性能標準？是不是該考慮下准入准出規則了？是的，這時一個團隊開始慢慢走向成熟，站住腳之後要開始爭取尊重了。
3、性能團隊已成熟
有了標準、流程，團隊的合作能力也成熟了之後，團隊「是時候展示真正的實力了」。但問題來了，什麼才是性能團隊的真正實力呢？
直觀上說，主要體現在一下幾個方面。
- 通過你的測試和分析優化之後，性能提升了多少？ 這是一句非常簡單直接的話。但是我相信有很多做性能測試工程師的人回答不出這樣的問題。因為看著混亂的 TPS 曲線，自己都已經暈了，誰還知道性能提升了多少呢？而一個成熟的團隊應該回答的是：提升了 10 倍，我們調優了什麼。這樣的回答有理有據，底氣十足。
- 通過你的測試和分析優化之後，節省了多少成本？ 這個問題就沒有那麼好回答了，因為你要知道整體的容量規劃，線上的真實運營性能。如果之前的版本用了 200 台機器，而通過我們的測試分析優化之後，只用到了 100 台機器，那成本就很明顯了。
對個人以及團隊來說，工具應該如何選擇
理順了性能測試工程師和性能團隊的成長路徑，下面我們來說說個人或者團隊選擇工具的時候，應該如何考量。
在我十幾年工作的生涯中，可以說有很多性能工具都是知道的，但是要說起用得熟練的，也無非就是那幾個市場佔有率非常高的工具。
下面列一下市場上大大小小、老老少少、長長短短的性能測試工具，以備大家查閱。
市面上大大小小的性能測試工作一共有四十餘種。這裡面有收費的，也有免費的；有開源的，有閉源的；有新鮮的，有不新鮮的；有活躍的，有半死不活的；有可以監控系統資源的，有隻能做壓力發起的。
你是不是有一種生無可戀的感覺？一個性能測試而已，有必要搞出這麼多工具嗎？
然而，你要記住，這些都是壓力發起工具。
下面我對一些比較常見的工具做下比對，這些工具主要包括 Apache JMeter、HP LoadRunner、Silk Performer、Gatling、nGrinder、Locust 和 Tsung。
僅比對這幾個工具吧，因為從市場上來說，這幾個算是經常看到的工具，以後我們再加入其他的工具和其他的屬性。我們現在只說性能工具，不說一些企業做的性能平台雲服務，因為雲服務都是對企業來說的，我們放到後面再講。
你從網路上可以很容易地找到這幾個工具的特點，這幾個都支援分散式。從上面那張表格中，你可以很容易對比出來，知道自己應該學什麼工具了。
Gatling 有免費版和收費版，基於 Scala 語言，而 Scala 又是基於 Java 的，你看這複雜的關係就讓人不想用，但是這個工具性能很高，雖說只支援 HTTP，但是由於支援 Akka Actors 和 Async IO，可以達到很高的性能。Actors 簡化並發編譯的非同步消息特性讓 Gatling 性能很高。
Locust 這個工具是基於 Python 的，中文名翻譯過來就是蝗蟲，這名字取得挺有意思。在一個壓力場景下，對伺服器來說確實就像一堆蝗蟲來了。
對市場的佔有率來說，JMeter 和 LoadRunner 以絕對的優勢佔據前兩名，同時 JMeter 又以絕對的優勢佔據第一名。
下面來看一下，這兩個工具的熱度趨勢。
這是全球範圍近 5 年 JMeter 和 LoadRunner 熱度（紅色線是 LoadRunner，藍色線是 JMeter）：
中國範圍近 5 年 JMeter 和 LoadRunner 熱度：
從上面的比對來看，我們可以很容易發現，近五年來，LoadRunner 就一直在走下坡路，而 JMeter 一直處在上升的趨勢。
JMeter 和 LoadRunner 的歷史興衰
我下面只說一下 JMeter 和 LoadRunner 的歷史，讓你對性能工具的興衰史有一定的了解。
先說說 LoadRunner 吧，應該說，LoadRunner 的歷史，就是一段悲慘的回憶。2006 年 11 月份以前，在 Mercury 時代，LoadRunner 由於市場策略和工具優勢很快佔了第一名，勢頭很猛。當時還有另一個同樣功能的工具 Silk Performer，被打壓得幾乎抬不起頭來。06 年以後，Mercury 以 45 億美元被 HP 收購，包括 QC、QTP 等工具。但從那之後，LoadRunner 的體積就在飛速膨脹，8.1 的 LoadRunner 只有 600M 左右（如果我沒記錯的話），經歷了幾個版本的迭代，LoadRunner 成功膨脹到 4 個 G，並在後面規劃 performance center，在各地做品質中心。HP 這一步步走得理直氣壯，把市場折騰沒了。現在 LoadRunner 如果想裝到一台壓力機上，都是很吃力的事情。我要是用的話，寧願在 XP 系統上安裝 8.1 版本，速度飛快。2016 年，HPE 和 MicroFocus 合併，LoadRunner 也成了 MicroFous 產品線的一部分，搞到現在，在中國的市場依然疲軟。
而擁有同樣競品工具 Silk Performer、Silk Test 和 Silk Test Manager 的 Segue 公司，同年僅以 1 億美元被另一個企業 Borland 收購。3 年之後，Borland 連同自己，以 7500 萬美元賣給了 MicroFocus。
至此，MicroFocus 同時擁有了 LoadRunner 和 Silk Performer。但可惜的是，這也照樣干不過一個無心插柳柳成蔭的開源工具 JMeter。
JMeter 的歷史，可以說是屌絲逆襲的典型案例。1998 年，Apache 基金會的 Stefano Mazzocchi 是它最初的開發者，當時他只是為了測試 Apache JServlet 的性能（這個項目後來被 Tomcat 取代），後來 JMeter 被重構，又被用來測試 Tomcat。其實一開始，JMeter 的功能很簡單。但是 Apache Tomcat 的勢頭實在是阻擋不住，再加上 Java 市場覆蓋率實在是太高了，而 JMeter 做為一個開源免費的 Java 壓力工具，有著眾多的 contributors，頂著 Apache 的大旗，想失敗都難。就像 ab 工具是為了測試 Apache HTTP server 一樣，JMeter 應該說是和 Apache Tomcat 一起成長的。
與此同時，還有另一個 Java 開源工具 The Grinder，這個工具的主要貢獻者是 Philip Aston、Calum Fitzgerald。
當時有一個開源測試平台叫 NGrinder，是韓國公司 NHN 開源的。有很多所謂企業內部自研發的性能測試平台，就是從 NGrinder 借鑒來的，而 NGrinder 就是以 The Grinder 為基礎開發的。可惜的是，The Grinder 沒有 Apache 這樣的平台，作為一個很優秀的工具，它的維護更新還是不夠快，不過 NGrinder 也給它帶來了一定的榮耀。
到現在為止，JMeter 還沒有一個非常成熟的雲測試平台支撐它，只有一些商業公司改動，加一些管理和項目屬性，做為企業內部平台使用。還有一些企業把 JMeter 改造成商業產品，加上雲基礎架構的管理功能，就成了一套完整的商業平台，再加上炫麗的操作頁面，棒棒的，有沒有？
那麼你有沒有想過，為什麼沒有以 JMeter 為基礎的開源雲測試平台呢？難道 JMeter 的熱愛者看不到雲測試平台的價值嗎？在我看來，做為性能測試工具，它實在是沒有必要做成一個開源的測試平台，因為輪子就是輪子，要裝成什麼樣的車就自己裝吧。要是再換個角度來說，性能測試真的有必要用平台嗎？
使用性能測試工具的誤區在哪裡
現在很多人都是看互聯網大廠的技術棧，但是有沒有想過自己企業需要的到底是什麼樣的產品？曾經有個測試工程師跟我說，他們公司為了解決性能問題，特意買了壓測雲服務，花了 20 萬，結果問題還是沒找出來。
所以工具應該如何用，完全取決於用的人，而不是工具本身。
壓測工具也好，壓測平台也好，都沒有一個工具可以直接告訴你瓶頸在哪裡，能告訴你的只是數據是什麼。分析只有靠自己，在這個過程中，我們也會用到很多的分析剖析工具，用這些工具的人也都會知道，工具也只提供數據，不會告訴你瓶頸點在哪裡。
那這個時候就有人提出疑問了：「有些工具不是說，上了這個工具之後，耗時一眼看透嘛？」是的呀，關鍵是你看過是什麼耗時了嗎？給你一個 Java 棧，那麼長的棧，每個方法的消耗都給你，但是長的就肯定有問題嗎？
關於剖析工具的，我們後面再寫。本篇重點在壓測工具上。
有人說 JMeter BIO 有問題，應該用 AIO；有人說，壓測工具沒有後端系統性能監控數據，應該加一個監控插件。像 JMeter 中就有一個插件叫 perfmon，把後端的系統資源拉到 JMeter 的介面中來看。在這一點上，LoadRunner 老早就做過了，並且在之前的版本中還有個專門的組件叫 tuning，目的就是把後端所有的系統、應用、資料庫都配置到一個架構圖中，壓力一發起，就把有問題的組件標紅。想法很好，可是這個功能為什麼沒有被廣泛使用？當然，後面被 HP 收購後，這和 HP 的市場策略有關，但是在收購前的 Mercury 時代，該功能也沒有被廣泛使用。
我們從實際的生產場景來看，壓測工具模擬的是真實用戶，而監控在哪裡，在運維後台里，數據的流向都不一樣。如果你使用壓測工具的同時，也把它做為收集性能監控數據的工具，本身流量就會衝突。
所以在壓測工具中同時收集監控計數器，就是不符合真實場景的。
這樣壓測平台就有出現的必要了，我們可以看到出現了五花八門的壓測平台，也會有後端監控數據的曲線，乍看起來，就兩個字：全面！
可是，同樣也沒有告訴你瓶頸在哪裡。
如果選擇合適自己的工具？
所以我們用工具，一定要知道幾點：
- 工具能做什麼？
- 工具不能做什麼？
- 我們用工具的目標是什麼？
- 當工具達不到目標時，我們怎麼辦？
把這幾個問題在用工具之前就想清楚，才是個成熟的測試工程師，有這樣的工程師的團隊，才是成熟的性能測試團隊（當然，成熟的測試團隊還要有其他的技術）。
對企業，舉例來說：
如果是一個需要支援萬級、億級 TPS 的電商網站，本身就是雲基礎架構，那麼可能最簡單的就是直接買這家的雲壓測工具就好了。
這樣做的優點是不用再買機器做壓力了。壓力發起，主要就是靠壓力機的量堆出來大並發。
但缺點也很明顯，一是不能長期使用，長期用，費用就高了。二是數據也只能自己保存比對，如果測試和版本跨度大，還是要自己比對，無法自動比對。最後一個缺點就是 壓力機不受控了。
所以如果有這樣需求的企業，也基本上可以自己開發一套雲壓測工具了，從使用周期和長遠的成本上來看，自已開發，都是最划算的。
如果是一個需要支援每秒 100TPS 的企業內部業務系統，就完全沒必要買什麼雲服務了，自己找一台 4C8G 的機器，可能就壓得夠了。
這樣的話完全可控，壓測結果數據也都可以隨時查看，可以留存。
如果是一個需要支援萬級 TPS，但又不能用雲服務的事業單位或政企，比如，軍工業，那隻能自己搭建一套測試環境了。這樣做的優點是完全內部可控，數據非常安全，但缺點就是投入成本高。
對私企來說，開源永遠是最好的選擇，成本低，但是需要相關人員能力稍強一些，因為沒有技術支援。
對政企和事業單位來說，收費是一個好的選擇，因為有第三方服務可以叫過來隨時支援。
對一個做短平快項目的企業來說，雲服務會是一個好選擇，成本低，不用長期維護數據。
對想做百年老店的企業來說，肯定是自己開發平台，盡量不選擇雲服務，因為技術是需要積累的。
對個人來說呢，不用舉例，壓測工具市場，現在肯定是首選學習 JMeter，其次是 LoadRunner。
JMeter 的勢頭已經很明顯了，並且功能在慢慢擴展。開源免費是巨大的優勢。
而 LoadRunner，不管它的市場現在有多凋零，它仍然是性能測試市場上，功能最為齊全的工具，沒有之一。
總結
總體來說，性能測試工具的市場中，可以說現在的工具已經種類繁多了，並且各有優點。在項目中，根據具體的實施成本及企業中的規劃，選擇一個最適合的就可以了。也可以用它們來組建自己的平台。但是請注意， 不要覺得做平台可以解決性能測試的問題，其實平台只是解決了人工的成本。
如果單純為了追潮流而把性能測試工具的使用成本升得特別高，那就不划算了。
思考題
今天的內容有點多，我提幾個思考題，你就當是對文章的回顧吧。
你覺得企業選擇性能工具應該考慮哪些方面呢？以及性能測試工具中是否必須做監控呢？
歡迎你留言寫下你的思考，也歡迎把這篇文章分享給你的朋友或者同事，一起交流一下。
