如何開展性能測試

以前有在本身建的測試羣直播分享了一些性能測試的基礎內容，當時有人說但願有個實戰的分享，想了想某些東西屬於公司機密不方便直接直播分享，

這裏就拿最近我作的一個性能測試實例來舉例子說說，理解爲主。。。

先看看一個完美的性能測試流程是怎樣的，以下圖：

固然，實際工做中能實現這種完美的流程很難，下面挑重點的介紹。。。

 

1、獲取測試需求

大概上週三接到這樣一個性能測試需求，大概的業務邏輯以下圖：

簡單歸納下業務邏輯，就是：發起一個拼團，其餘人點擊活動進去，領券，而後領券時要驗證拼團的有效性，在買單用券時，先驗證是不是會員，若是不是，先註冊會員，再將券和會員綁定！

具體的性能指標是：驗證上圖4個場景中的接口，在響應時間爲3S和5S時，服務器的TPS值（這屬於系統性能能力驗證的應用領域）。

測試的系統，是公司的微信會員系統，系統架構相對熟悉，這裏不過多介紹。

 

2、測試計劃和方案

所謂的測試計劃，無非就是某人用多久時間用什麼資源什麼方法完成什麼事情。

因爲此次性能測試需求工做量不大，且時間足夠，因此就我一我的完成測試的大部分工做，固然，一部分須要開發協助。

測試方案，就是測試計劃的補充和擴展。

好比此次性能測試，我預計用一週時間完成這些測試工做，設計用例、場景建模、準備測試數據、測試腳本開發、環境搭建等各須要多久時間，在哪一天甚至是上午仍是下午完成這些工做。

 

3、執行前的準備工做

環境搭建：測試環境因爲以前會員系統也進行過性能測試，測試環境搭建這一步工做量不大，開發很快就配置完成，因此這裏不贅述。

場景建模：我的理解，就是考慮哪些場景下可能存在性能瓶頸，相應的設置對應的測試腳本和測試邏輯，以儘量模擬生產環境（因爲對業務蠻熟悉，這裏也不贅述，須要說起的一點是：

        必定要理解、熟悉系統業務，由於需求的產生，就是用戶+場景）。

測試數據準備：測試數據準備經常使用的有這兩種方式：將生產數據複製一份過來、開發腳本預埋造數據（但不管哪一種，必定要注意數據隔離，防止數據污染）。

測試腳本開發：首先，須要從開發那裏獲取開發接口文檔和數據庫表設計文檔。

　　　　　　　而後，經過工具或者寫測試腳本調試接口，先保證接口能夠成功調用（我用的工具是jmeter+MySQL）。

 

4、執行測試腳本

在保證接口能夠成功調用以後，先進行單接口基準測試，即：對一個接口進行壓力測試，不斷加壓，直到響應時間達到或超過指標，觀察當前其併發數和TPS。

我的經驗是一樣的併發數，多執行幾回，獲得一個平均值或穩定值（即TPS和TRT曲線相對穩定的值），並記錄下來。

以下圖：

記錄的目的，能夠經過直觀的數據變化，獲得單個接口的最大TPS和不一樣併發狀況下的響應時間變化。

PS：記得前幾天從一本書上看到這樣一句話：80%的性能瓶頸能夠經過分析TPS和TRT的數值變化獲得（雖然有點片面，但也不失爲一種方法）。

好比按照上圖記錄的數值變化來看，很明顯領券接口性能極差，這時候就能夠告知開發，經過查看log、檢查代碼、SQL語句等方法來查詢緣由（固然我的能力足夠的話，這些能夠本身來作）。

 

5、監控調試

jmeter這個性能測試工具自己就用監聽器這個元件提供了必定的監聽數值報告元件，但畢竟開源工具，其自己的組件功能不夠強大，能夠經過下載支持jmeter的加強型功能插件來進行監控。

jmeter插件下載地址：https://jmeter-plugins.org/

下載後能夠解壓縮，將plugins-manager.jar放入jmeter安裝目錄lib/exe，而後重啓jmeter便可。

能夠經過點擊下圖圈出來的按鈕檢驗是否成功安裝：

不管是對服務器資源使用率仍是測試數據報表生成，甚至TPS、TRT等的監聽，該插件都提供了組件支持，具體的使用方法請自行尋找。。。

所謂的監控調試，就是一個不斷調整重複的過程，這個須要根據性能測試的目的，應用領域去判斷具體如何執行。。。

 

6、最終報告

根據上面的幾個步驟，獲得測試結果，分析系統存在的瓶頸，而後採用各類方法提出解決方案或優化建議，最後對本次性能測試進行一個完整的總結，這樣，一次性能測試就完成了。

在整個過程當中，費時較長通常是在測試數據準備和測試執行、監控調優階段。

最後吐槽一句：性能測試水太深，想潛水的作好準備，別稀裏糊塗扎進來，太刺激。。。