之前有在自己建的測試群直播分享了一些性能測試的基礎內(nèi)容，當時有人說希望有個實戰(zhàn)的分享，想了想某些東西屬于公司機密不方便直接直播分享，
這里就拿最近我做的一個性能測試實例來舉例子說說，理解為主。。。
先看看一個完美的性能測試流程是怎樣的，如下圖：
當然，實際工作中能實現(xiàn)這種完美的流程很難，下面挑重點的介紹。。。
一、獲取測試需求
大概上周三接到這樣一個性能測試需求，大概的業(yè)務邏輯如下圖：
簡單概括下業(yè)務邏輯，就是：發(fā)起一個拼團，其他人點擊活動進去，領券，然后領券時要驗證拼團的有效性，在買單用券時，先驗證是否是會員，如果不是，先注冊會員，再將券和會員綁定！
具體的性能指標是：驗證上圖4個場景中的接口，在響應時間為3S和5S時，服務器的TPS值（這屬于系統(tǒng)性能能力驗證的應用領域）。
測試的系統(tǒng)，是公司的微信會員系統(tǒng)，系統(tǒng)架構相對熟悉，這里不過多介紹。
二、測試計劃和方案
所謂的測試計劃，無非就是某人用多久時間用什么資源什么方法完成什么事情。
由于這次性能測試需求工作量不大，且時間足夠，所以就我一個人完成測試的大部分工作，當然，一部分需要開發(fā)協(xié)助。
測試方案，就是測試計劃的補充和擴展。
比如這次性能測試，我預計用一周時間完成這些測試工作，設計用例、場景建模、準備測試數(shù)據(jù)、測試腳本開發(fā)、環(huán)境搭建等各需要多久時間，在哪一天甚至是上午還是下午完成這些工作。
三、執(zhí)行前的準備工作
環(huán)境搭建：測試環(huán)境由于之前會員系統(tǒng)也進行過性能測試，測試環(huán)境搭建這一步工作量不大，開發(fā)很快就配置完成，所以這里不贅述。
場景建模：個人理解，就是考慮哪些場景下可能存在性能瓶頸，相應的設置對應的測試腳本和測試邏輯，以盡可能模擬生產(chǎn)環(huán)境（由于對業(yè)務蠻熟悉，這里也不贅述，需要提及的一點是：
一定要理解、熟悉系統(tǒng)業(yè)務，因為需求的產(chǎn)生，就是用戶+場景）。
測試數(shù)據(jù)準備：測試數(shù)據(jù)準備常用的有這兩種方式：將生產(chǎn)數(shù)據(jù)復制一份過來、開發(fā)腳本預埋造數(shù)據(jù)（但無論哪種，一定要注意數(shù)據(jù)隔離，防止數(shù)據(jù)污染）。
測試腳本開發(fā)：首先，需要從開發(fā)那里獲取開發(fā)接口文檔和數(shù)據(jù)庫表設計文檔。
然后，通過工具或者寫測試腳本調(diào)試接口，先保證接口可以成功調(diào)用（我用的工具是jmeter+MySQL）。
四、執(zhí)行測試腳本
在保證接口可以成功調(diào)用之后，先進行單接口基準測試，即：對一個接口進行壓力測試，不斷加壓，直到響應時間達到或超過指標，觀察當前其并發(fā)數(shù)和TPS。
個人經(jīng)驗是同樣的并發(fā)數(shù)，多執(zhí)行幾次，得到一個平均值或穩(wěn)定值（即TPS和TRT曲線相對穩(wěn)定的值），并記錄下來。
如下圖：
記錄的目的，可以通過直觀的數(shù)據(jù)變化，得到單個接口的最大TPS和不同并發(fā)情況下的響應時間變化。
PS：記得前幾天從一本書上看到這樣一句話：80%的性能瓶頸可以通過分析TPS和TRT的數(shù)值變化得到（雖然有點片面，但也不失為一種方法）。
比如按照上圖記錄的數(shù)值變化來看，很明顯領券接口性能極差，這時候就可以告知開發(fā)，通過查看log、檢查代碼、SQL語句等方法來查詢原因（當然個人能力足夠的話，這些可以自己來做）。
五、監(jiān)控調(diào)試
jmeter這個性能測試工具本身就用監(jiān)聽器這個元件提供了一定的監(jiān)聽數(shù)值報告元件，但畢竟開源工具，其本身的組件功能不夠強大，可以通過下載支持jmeter的增強型功能插件來進行監(jiān)控。
jmeter插件下載地址：https://jmeter-plugins.org/
下載后可以解壓縮，將plugins-manager.jar放入jmeter安裝目錄lib/exe，然后重啟jmeter即可。
可以通過點擊下圖圈出來的按鈕檢驗是否成功安裝：
無論是對服務器資源使用率還是測試數(shù)據(jù)報表生成，甚至TPS、TRT等的監(jiān)聽，該插件都提供了組件支持，具體的使用方法請自行尋找。。。
所謂的監(jiān)控調(diào)試，就是一個不斷調(diào)整重復的過程，這個需要根據(jù)性能測試的目的，應用領域去判斷具體如何執(zhí)行。。。
六、最終報告
根據(jù)上面的幾個步驟，得到測試結果，分析系統(tǒng)存在的瓶頸，然后采用各種方法提出解決方案或優(yōu)化建議，最后對本次性能測試進行一個完整的總結，這樣，一次性能測試就完成了。
在整個過程中，費時較長一般是在測試數(shù)據(jù)準備和測試執(zhí)行、監(jiān)控調(diào)優(yōu)階段。
文章來源：網(wǎng)絡 版權歸原作者所有
上文內(nèi)容不用于商業(yè)目的，如涉及知識產(chǎn)權問題，請權利人聯(lián)系小編，我們將立即處理
