性能測試基礎

01-29

本文介紹一下性能測試的基礎內容和一些學習經驗，主要講針對伺服器端的性能測試。其他代碼級性能測試、前端性能測試等屬於比較細分的領域，建議大家有需要的時候針對性得去學。而對於伺服器端的性能測試，即使是不做性能測試的人，最好也要有一點了解。我並不從事專職性能測試，只做過一些小項目的性能測試工作。很多公司會希望測試人員能在測功能之外兼顧一下性能測試，而不一定會雇一個專門的性能專家來做性能測試。

一、性能測試想做什麼

首先，性能測試想做的事情，類似下圖：

這是一個簡化過的關於web應用的服務端的性能測試示意圖，性能測試想要模擬真實業務場景。當一個應用上線，有很多用戶通過客戶端訪問服務端。他們把請求通過用戶界面發送給了服務端，於是在服務端接收到了大量的請求，如果用戶數很多，那麼服務端有可能承受不了這種壓力，進而崩潰，嚴重的可能導致大量經濟損失。

性能測試則是希望通過提前模擬這種壓力，來發現系統中可能的瓶頸，提前修復這些bug，減少伺服器宕機的風險。此外，性能測試還可以用來評估待測軟體在不同負載下的運作狀況，幫助管理層做一些決策。比如早期有的管理者會希望通過性能測試來評估需要買幾台伺服器。但，這種做法隨著雲計算的普及，已經過時。在雲計算平台上，硬體資源可以彈性獲取，自動調整。雲計算也會對性能測試的方式產生影響，包括服務端資源監控在內的很多工作，未來都可以交給雲計算平台了。大家也可以關注一下，雲計算對傳統測試工作的衝擊。

二、性能測試的基本流程

下圖表示了一個簡單的性能測試的基本流程中，我們怎樣得到性能測試的結果。

然後，這只是一輪性能測試的開始，得到性能測試的結果之後，還有很多工作：

可以說，這裡的調優過程才是性能測試的技術含量所在。這可能也是性能專家這個角色存在的意義之一。而測試人員通過做性能測試，進階成為性能專家，也是一種發展方向。但不得不說，這條路是比較難走的，限於我個人視野，我覺得DBA、運維、開發、這些角色都比測試更容易發展為性能專家。當然是否走這條路也要看個人興趣了。

調優的話，主要看調優小組推測的瓶頸在哪裡，比如推測瓶頸在資料庫，可能讓DBA調整一下資料庫配置，然後再測一遍。推測瓶頸在第三方提供的設備上，那就諮詢一下第三方的技術支持，然後調整一下配置再測一遍。這個調優過程，可能比較長。

從以上兩圖可以看出，在整個性能測試過程中，測試人員能做的工作其實並不多，且大多數屬於第一階段的低技術含量工作。主要集中在腳本錄製或編寫、性能監控器的配置和數據的收集上。後者還會受到雲計算平台普及的衝擊，很可能以後不用你做任何工作就能簡單得收集到想要的資源使用情況數據。而在第二階段調優時，性能調優小組的介入使測試人員存在感進一步下降。其中水平較低的測試人員將淪為腳本執行員和腳本修改操作員。

三、性能測試的前期準備

此外，還有一個性能測試還有一個前期準備階段：

這裡先補充一些名詞解釋，我只是根據自己理解寫一下，並不精確。精確定義大家可以網上搜索，另外我最後會推薦一些參考資料。

吞吐量：

表示待測應用對業務的支持量，以TPS或QPS為單位，表示每秒鐘能處理的請求數。需要分析業務場景來計算吞吐量。

請聽題：小明辦了一個電影網站，每天有2000個用戶會上來看電影，假設每個人都只看一部電影，該電影網站每本電影需要播放兩小時。每個用戶每次看一本電影會向待測應用運行的伺服器發送10個請求，其播放的電影數據存儲和傳輸在第三方，本題中不需要考慮。每天晚上7點到9點為黃金時間，在每天的用戶中會有一半人選擇在這個時間點上來看電影。請計算該網站的平均吞吐量和峰值吞吐量。

-----自己思考-----

平均吞吐量=總請求數/總時間 = 2000×10/（24×3600）

峰值吞吐量=峰值請求數/峰值時間 = 2000*0.5*10/(2*3600)

具體數字就不算了，算出來你發現吞吐量很低很低。這是因為這些數據我是隨便造的，並且我之前工作過的電影網站吞吐量確實也很低，沒多少用戶。然後除了這些，還有很多估算。比如故意誇大一點，乘以一個估算係數之類的。總得來說，算出來的吞吐量不一定很精確，對計算公式感興趣的話，可以搜索一下，有很多人給出更具體的例子。

虛擬用戶數：

性能測試要模擬的用戶數量。

性能測試結果：

包括響應數據和性能指標。

響應數據相關的常見指標有：90%平均響應時間、錯誤率等

性能指標包括CPU,I/O,Memory,Network四個方面，每個方面都有幾個指標。

關於這塊，相信你能在網上找到相關文章教你的，我這裡就不展開了。

測試策略，代表設計這些場景的依據，在這裡主要有以下幾種：

注意，這裡的名字並不是全球統一的，不同的公司，不同的人可能對同一種測試策略有不同的叫法。

1）基線測試，又叫基準測試：

測一下單個用戶做主要業務流程的場景。其性能測試結果會作為比對依據。

2）性能測試：

逐步增加用戶數，比如10個，20個，50個，80個，130個，得到不同用戶數情況下的性能測試結果變化趨勢圖。這個圖裡常常可以發現性能瓶頸。比如用戶數到某個值時突然性能指標下降了很多，錯誤率大幅上升了。那就需要進一步分析是軟體的問題還是硬體的問題，還是環境的問題等。

3）壓力測試：

使用超過系統設計的最大用戶數，看看待測應用會不會崩潰，會怎麼樣，有沒有隱患和風險等。

4）負載測試：

在比較高的用戶數情況下，較長時間得執行測試，觀察系統在較高負載較長時間下的穩定性。

5）根據性能測試的負載生成器所在位置，還可以分出本地同網路的測試和跨網路的測試。

6）還有當下比較時髦的全鏈路測試，其實就是把真實環境划出一塊來做測試。這樣來解決估算不準的問題。這塊網上有一些資料，但不太多。

關於分析生產環境和建立估算模型。可以去搜搜阿里研究員對全鏈路壓測的演講。或者去找其他資料。我也沒估算過，不展開了。我只做過最簡單的，在沒上線的生產環境上做性能測試。但估算的問題很明顯就是：很難估算準確。

其他在前期要做的事情，還有確定測試通過標準，比如吞吐量要達到多少，錯誤率低於多少，響應時間要多快，伺服器CPU佔用率要多少以下等等。

以及確定測試環境用什麼設備，怎麼搭建。等等。

四、性能測試的工具及相關學習建議

然後說到測試工具，再吐槽一下一上來就問工具的人。上面這麼多原理你如果不了解的話，只會用工具是沒什麼用的。

現在的主流性能測試工具是：Jmeter

其次Grinder，Gatling，Locust，Loadrunner等等等等，此處排名不分先後。我也不知道哪個工具是第二流行的。

jmeter的學習主要通過官方用戶手冊。現在這個工具對我來說最大的問題就是圖形界面用起來挺麻煩。後來的很多工具已支持純腳本或代碼方式描述測試場景。不過幸好我也不經常做性能測試。我的建議是大家都要學jmeter，其他工具可以選學，loadrunner除非真的你公司要用否則不用學。

而監控伺服器指標方面，jmeter有插件支持。也可以用linux命令行工具做。也有人用商業工具做。總之要把伺服器性能指標和請求響應時間兩組數據的時間線對上，讓我們可以看到什麼時候發送了多少請求，響應時間多少，錯誤率多少，此時伺服器負載又是多少。

此外再推薦blazemeter的博客。blazemeter雖然是付費工具，但他的博客里有很多乾貨，比如性能測試指標怎麼分析，看到性能指標圖在什麼地方出現拐點最可能的瓶頸在哪裡。他有很多不錯的文章，是我近期研究性能測試工具時常常查看的。

另外強烈推薦這本書，可以帶你了解一下web應用的性能測試到底是怎麼回事：

微軟MSDN上的：Performance Testing Guidance for Web Applications

不懂英文沒關係，這本應該是有中文翻譯本的。

總而言之，不管你做不做性能測試，多多少少要知道是怎麼回事，可能什麼時候你領導就要你做個簡單的性能測試呢。也要有逐步加壓的做性能測試的這種概念和思路。性能測試本身也是很系統化的一種測試，其中各個步驟環環相扣的特點，也是其最有意思的地方。

最後，喜歡的話幫忙點個贊啦。

首發於公眾號：測試進階（test_up）