一、性能三連問
1、何時進行性能測試？
性能測試的工作是基於系統功能已經完備或者已經趨於完備之上的，在功能還不夠完備的情況下沒有多大的意義。因為后期功能完善上會對系統的性能有影響，過早進入性能測試會出現測試結果不准確、浪費測試資源。因此，性能測試首先是基於功能測試的，必須了解其功能需求才能開展性能測試。
2、如何進行性能測試？
一個被測系統，我們需要分3部分來分析：
-
入口：需要怎么發送請求，施壓方應該施加多大的壓力，用什么方法施壓；
-
被測系統：系統怎么應對單個請求，系統業務流程是怎么樣的，系統網元節點、數據流向等，整體性能需求有沒有，需要考察哪些指標，怎么監控；
-
出口：接收數據有哪些，怎么獲取和比對；
是不是感覺就和功能測試差不了多少?是的，就是先分析單個用戶的功能流程以及系統的數據流向（包括后台的數據流向）結構圖，然后再考慮大量的用戶操作。
3、開展性能測試的步驟？
一般系統的性能測試步驟大體如下：
1.確認測試目標;
2.分析被測系統業務需求;
3.分析被測系統的系統結構;
4.分析被測系統的性能測試點;
5.設計測試方案、檢測方案和測試案例;
6.選擇測試工具;
7.測試開發;
8.測試執行;
9.測試結果分析;
10.測試調優、測試驗證、測試分析;
11.輸出測試報告;
二、性能測試開展前的准備
測試准備工作越充分，后期的測試執行越順利，一般測試准備工作如下：
1.確認測試目標;
2.分析被測系統的業務;
3.分析被測系統的結構;
4.分析被測系統可能產生性能瓶頸的節點;
5.設計測試方案、檢測方案和測試方案;
以下具體分析以上5個步驟：
1、確認測試目標
任何一個任務首先都要確認任務的目標是什么，如果不知道目標，任何努力得到的結果有可能都不是最終所需要的結果。性能測試也一樣，首先需要確立明確的目標。無論是隨機測試系統的當前性能情況，還是奔着對系統進行優化而去，或是檢驗一下系統的性能是否滿足需求等等，這些都是開展性能測試之前的一個目標。之后的分析到方案和用例設計，到測試執行監控，再到最后的測試分析和報告，都是要圍繞這個目標展開。所以，首要的任務就是確認測試的目標要求，需要達到怎樣的一個測試目的和目標。
假如有一些測試任務沒有明確的目標或者要求，並不說明它沒有目的和目標，這需要我們進行溝通和分析。及時與項目組達成一致的目的要求，分析需求，分析系統，最后明確項目或者系統測試任務的目的要求。
2、分析被測系統的業務
朋友曾經在一次面試中，有一位面試官給了他這樣一個題目：“有一個網站，只知道它的總訪問量一天是300萬，怎么測試它的性能？”
大家想一想要怎么設計方案？
猜想面試官是想面試者回答，正態分布、二八原理等基本的測試原則應用。朋友當時沒有回答任何與正態分布、二八原理相關的東西。當時面試官對他的回答好像是“蔑視”的笑了笑，可能是覺着連基本的正態分布、二八原理都不知道，還搞性能測試？。其實，性能測試並不是想象的那樣簡單，並不是一個簡單的原理的應用就行的，如果這么容易，那豈不是誰都能搞定。
性能測試的基礎是基於系統的業務功能基本趨於穩定，首要的任務就是性能在系統滿足業務功能需求上展開，因此我們必須要分析系統的業務。不管是普通的網站也好還是比較專業的系統也好，它都是有業務功能需求，所有的性能測試都要基於這些功能才能進行，脫離了業務功能的性能測試沒有意義。性能測試首要的任務就是分析系統的業務功能，分析系統業務上的性能限制，也就是業務需求。
那么，怎么分析系統的業務需求呢？
-
如果有用戶需求規格說明，首要的任務就是閱讀和理解分析用戶需求規格說明；
-
如果沒有用戶需求規格說明，那么就需要分析系統功能，提煉出系統的業務需求。如果可能，項目組比較熟悉的人講述一遍是最好的了。
-
最后無論哪一種，最好的方法就是按照自己的理解畫出系統的業務流程或者系統的功能結構圖，拿到項目組進行確認。一定要進行確認，和整個項目組達成一致的認同。
有人會問，我們項目組沒有可確認的業務需求時候怎么辦？
首先依然需要從分析入手。如果不分析，你就不會知道系統的功能數據流向，請求的數據構成，系統的網元結構，以及系統可能出現的瓶頸在哪一個節點，你又怎么進行優化呢？
當然面對一種全新的知識領域的時候，可能需要我們多積累經驗，更多的進行分析；我們可能需要結合實踐，多次實際運行系統或者執行測試，在測試中不斷的進行優化和完善我們的分析過程、分析結果、測試方案、測試開發甚至是測試執行等等。
分析被測系統的業務，有時候不是一蹴而就，需要我們進行多次反復的分析、確認和再分析、再確認，直到把系統弄明白，甚至有可能在測試執行的最后階段你還需要再次進行分析和確認，然后重新規划測試。
3、分析被測系統的結構
系統的結構和系統的業務一樣重要，不知道系統的網元結構可能就沒有辦法進行監控，就沒有辦法知道瓶頸在哪個節點，就不能進行優化。
分析系統的結構，最好的方法就是項目組提供系統的部署和構成圖；如果項目組不能提供或者沒有項目組，那就需要用TCPDUMP等抓包工具，分析數據流向。
TCPDUMP的使用：
bash tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap (1)tcp: ip icmp arp rarp 和 tcp、udp、icmp這些選項等都要放到第一個參數的位置，用來過濾數據報的類型； (2)-i eth1 : 只抓經過接口eth1的包； (3)-t : 不顯示時間戳； (4)-s 0 : 抓取數據包時默認抓取長度為68字節。加上-S 0 后可以抓到完整的數據包； (5)-c 100 : 只抓取100個數據包； (6)dst port ! 22 : 不抓取目標端口是22的數據包； (7)src net 192.168.1.0/24 : 數據包的源網絡地址為192.168.1.0/24； (8)-w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析；
從第一個節點分析流向到哪，確定第二層的節點；然后從第二層每個節點分析第三層節點，逐層分析，完善系統的數據流向的所有結構層次和節點；再弄明白每個節點部署的應用程序或者進程隊列；對每一個節點的應用程序或者進程隊列進行測試監控；最后才能得出哪些應用或者進程隊列需要進行優化。
弄明白系統的節點構成之外，還需要弄明白各個節點之間的通訊協議和數據格式，之后測試工具選擇和測試數據准備以及測試腳本開發就需要以此作為依據。這一切的基礎就是要分析和弄明白系統的所有節點，也就是要分析清楚系統的結構。
4、分析系統可能的性能瓶頸
分析系統的業務需求和系統的結構組成，同時預判系統可能存在的性能瓶頸，這是分析中的一個目標；得到預判的性能瓶頸后我們后面需要在監控的時候多注意一下這些節點。
當然有一些常見的可能會是系統瓶頸的節點我們需要注意:
1. 登錄，一般系統登錄要進行多種校驗，可能數據交互比較頻繁；
2.下單，搶單、搶紅包這個時候會有一定量的並發需求；
3.大數據的查詢、統計和報表分析，會對系統產生壓力；
4.視頻、動畫等會對網絡產生壓力；
5.消息比較集中的系統功能節點，會對系統產生壓力；
6.一些特殊的業務需求會對系統產生壓力；
常見的瓶頸：
1. 數據庫的瓶頸一般在磁盤IOPS過高造成進程阻塞；
2.系統進程數過多一般會消耗系統的內存空間；
3.消息隊列和緩存服務，開啟持久化后會需要考察磁盤IOPS，不開啟持久化則需要考察內存占用；
4.頻繁的管道開辟和銷毀會導致CPU占用較高；
5. 有部分程序結構上不能利用多個CPU；
在分析業務和系統結構的過程中，我們就需要考慮這個業務點或者結構點會不會有大量的數據訪問，會不會產生壓力，我們的設計會不會產生性能瓶頸。
5、測試計划和測試用例的設計
測試計划的設計以及最后測試總結文檔的形成，實際就是所有分析工作的總結。
寫測試計划的過程就是明確測試目的、分析業務需求、系統結構以及評估測試方法、測試安排、測試風險等等的過程總結。而這些全部來源於在測試執行之前的分析，有時候可能你在測試過程中還需要做出一些分析和調整。
測試計划包含了分析和整理的各個方面，一個好的測試計划包含的內容：測試目的、測試目標、測試內容（可能包含業務性能、可靠性、穩定性等等），業務需求目標，系統業務構成，系統節點構成，測試方法流程，需要監控的指標要求和節點等等。
測試用例一般包含在測試計划中，測試用例實際上就是普通的業務操作流程，用測試工具或者其他測試手段來模擬大的數據量業務操作，並對系統的各個節點進行監控，獲取監控數據。預期的監控數據和實際監控數據的對比，滿足要求就是預期要求，實際對比結果就是測試結果。
6、測試前的准備
環境搭建：測試環境搭建這一步工作量不大，如果有必要可以請開發協助配置完成。
場景建模：考慮哪些場景下可能存在性能瓶頸，相應的設置對應的測試腳本和測試邏輯，以盡可能模擬生產環境（ 一定要熟悉系統業務，因為需求的產生，就是用戶+場景）。
測試數據准備：測試數據准備常用的有這兩種方式：將生產數據復制一份過來、開發腳本預埋造數據（但無論哪種，一定要注意數據隔離，防止數據污染）。
測試腳本開發：首先，需要從開發那里獲取開發接口文檔和數據庫表設計文檔。然后，通過工具或者寫測試腳本調試接口，先保證接口可以成功調用。
三、性能測試的正式開展
1、執行測試腳本
在保證接口可以成功調用之后，先進行單接口基准測試，即：對一個接口進行壓力測試，不斷加壓，直到響應時間達到或超過指標，觀察當前其並發數和TPS。同樣的並發數，多執行幾次，得到一個平均值或穩定值（即TPS和TRT曲線相對穩定的值），並記錄下來。
記錄的目的是通過直觀的數據變化，得到單個接口的最大TPS和不同並發情況下的響應時間變化。
“80%的性能瓶頸可以通過分析TPS和TRT的數值變化得到”。雖然有點片面，但也不失為一種方法。比如按照上圖記錄的數值變化來看，很明顯領券接口性能極差，這時候就可以告知開發，通過查看log、檢查代碼、SQL語句等方法來查詢原因。當然個人能力足夠的話，這些可以自己來做。
2、監控調試
所謂的監控調試，就是一個不斷調整重復的過程，這個需要根據性能測試的目的去判斷具體如何執行。
Jmeter本身就用監聽器這個元件提供了一定的監聽數值報告元件，但畢竟是開源工具，其本身的組件功能不夠強大，可以通過下載支持jmeter的增強型功能插件來進行監控。
Jmeter插件下載地址：https://jmeter-plugins.org/
下載后可以解壓縮，將plugins-manager.jar放入jmeter安裝目錄lib/ext，然后重啟Jmeter即可，可以通過點擊下圖圈出來的按鈕檢驗是否成功安裝：
無論是對服務器資源使用率還是測試數據報表生成，甚至TPS、TRT等的監聽，該插件都提供了組件支持，具體使用方法自行探索。
3、分析和調優
性能測試除了為獲取性能指標外，更多是為了發現性能瓶頸和性能問題，然后對性能問題和瓶頸進行分析和調優，在當今互聯網高速發展的時代，性能調優的模型可以歸納總結如下圖所示。
性能調優就是不斷采集系統中的性能指標以及系統模型中各層的資源消耗，從中發現性能瓶頸和性能問題，然后對瓶頸和問題進行分析診斷來確定性能調優方案，最后通過性能壓測進行驗證調優方案是否有效，如果無效繼續重復這個過程進行性能分析，直到調優方案有效，瓶頸和問題得到解決。這個過程一般是非常漫長，因為很多時候性能調優方案往往不是一次就能有效或者一次就能解決所有的瓶頸和問題，或者解決了當前的瓶頸和問題，但是繼續性能壓測又可能會出現新的瓶頸和問題。
4、輸出測試報告
根據以上幾個步驟，得到測試結果，分析系統存在的瓶頸，然后采用各種方法提出解決方案或優化建議，最后對本次性能測試進行一個完整的總結，這樣，一次性能測試就完成了。在整個過程中，費時較長一般是在測試數據准備和測試執行以及監控調優階段。