說明：該篇博客是博主一字一碼編寫的，實屬不易，請尊重原創，謝謝大家！
1.什麼是性能測試
性能測試是通過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。——來自百度百科
總結： 性能測試是一個非常廣泛的概念，包括很多方面的測試，可以將性能測試稱之爲非功能性測試
2.性能測試的目的
目的是驗證軟件系統是否能夠達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，優化軟件，最後起到優化系統的目的。
包括以下幾個方面
1.評估系統的能力，測試中得到的負荷和響應時間數據可以被用於驗證所計劃的模型的能力，並幫助作出決策。
2.識別體系中的弱點：受控的負荷可以被增加到一個極端的水平，並突破它，從而修復體系的瓶頸或薄弱的地方。
3.系統調優：重複運行測試，驗證調整系統的活動得到了預期的結果，從而改進性能。檢測軟件中的問題：長時間的測試執行可導致程序發生由於內存泄露引起的失敗，揭示程序中的隱含的問題或衝突。
4.驗證穩定性（resilience）可靠性（reliability）：在一個生產負荷下執行測試一定的時間是評估系統穩定性和可靠性是否滿足要求的唯一方法。
總結： 通俗來說就是發現軟件的性能瓶頸
3.性能測試的類型
性能測試類型包括負載測試、壓力測試、併發測試、容量測試、可靠性測試、異常測試。
- 負載測試：通過逐步加壓的方法，達到既定的性能閾值的目標；閾值的設定應該是小於等於某個值，如CPU使用率小於等於80%。
- 壓力測試：通過逐步加壓的方法，使系統的某些資源達到飽甚至失效的狀態，通俗來說就是在什麼條件下能將系統壓到崩潰。
- 併發測試：在同一時間內，多個虛擬用戶同時訪問同一模塊、同一功能，通常的測試方法是設置集合點。
- 容量測試：通常是指數據庫層面，目標是獲取數控的最佳容量的能力，又稱之爲容量預估；具體的測試方法爲在一定的併發用戶，不同的基礎數據量下觀察數據庫的處理能力，即獲取數據庫的各項性能指標。
- 可靠性測試：又稱之爲穩定性測試或疲勞測試。指系統在高壓的情況下，長時間的運行系統是否穩定；比如當CPU使用率在80%以上，持續一週7*24小時，查看系統是否穩定。
- 異常測試：又稱之爲失敗測試。指系統架構方面的測試，比如在負載均衡的情況下，測試down機或節點掛掉的情況下系統的反映情況。 比如nginx下掛了三個tomcat，掛掉其中一個tomcat後，即nginx下只有兩個tomcat，此時系統正常的反映是掛掉的tomcat不會影響我係統的正常運行，也就是說nginx會檢測到掛掉的tomcat而不會將用戶請求轉發到down掉的這臺tomcat上
4.需要掌握的技能
- 開發語言：推薦Java編程語言，因爲該語言在互聯網領域使用非常廣泛，很多公司的軟件都是使用Java語言開發的，所以當你對Java語言深入瞭解後和開發進行交流溝通無障礙以及做性能測試的時候比其他人做的更深入
- 操作系統：現在大多數公司都使用Linux做爲服務器，版本包括centos和ubuntu，絕大多數都是用centos系統；目前來說還是有少部分公司在使用windows server IIS來做服務器，基於市場的需求所以必須首先要會使用linux操作系統，然後要會使用linux的監控命令（通過監控命令獲取服務器的數據信息和狀態，那麼在做性能測試瓶頸時就知道服務器處於什麼狀態時異常的）
- 數據庫：現在使用比較多的是SQL關係型數據庫SQLServer、Mysql、對於金融行業如銀行使用Oracle、DB2的比較多；NoSQL非關係型數據庫用的則是Redis和MongoDB，做讀寫分離或者數據緩存以及ES數據庫；那麼作爲性能測試肯定要會增刪改查的操作，並且對數據庫進行監控，同樣根據數據庫返回的狀態信息，定位瓶頸後就可以進行調優了。
- 測試工具：第一種嘛就是自己通過Go、Java等語言進行開發一個性能測試工具（）；第二種則是市場應用比較多的工具則如Jmeter和LoadRunner，這裏推薦使用Jmeter，原因是開源免費簡單輕巧並且是純Java語言開發的，而LoadRunner是收費且因功能強大所以比較笨重；因爲是工具都不存在難度，用的多的熟練度就深了。
- 網絡知識：網絡對性能測試的影響非常大，如客戶端向服務器發送請求數據，這個請求數據或者叫報文數據它是有一個大小的，當對後端接口調用傳輸的數據很大，而網絡帶寬不咋地這樣就會導致該接口性能非常低，比如說網絡帶寬爲10M，一次調用接口傳輸的數據大小爲1M(舉例)，秒內併發最多能承受10個請求，所以在做性能測試時一定要對網絡知識有一定的瞭解，不然連請求都沒有發送到服務器怎麼進行併發測試；其次對網絡協議分層還是要進行了解，如OSI的七層模型以及TCP/IP四層模型。
- 業務知識：對於業務知識這一塊是很重要的，當你進入一個公司或者企業，首選要對公司開發的產品進行熟悉，如該產品屬於什麼行業的，軟件是幹啥的，瞭解整個軟件的業務流程，這樣才能知道軟件哪一塊或者時候哪一個接口適用於做性能測試，那肯定是用戶進行訪問的接口了，最簡單的例子就是註冊和登錄這兩個接口，你肯定要清楚哪個接口是用戶經常使用的，很明顯就是登錄接口，所以說了解公司產品業務是相當重要的。
5.性能測試的流程
- 需求分析
熟悉項目，瞭解項目的業務流程以及重點功能 - 性能指標制定
設定服務器到達的性能指標，如Response time、Throughput、Resource utilization、Hits per second、Concurrent users等，也就是說什麼樣的指標標準能夠滿足現階段的業務需求 - 腳本開發
使用一些性能測試工具，如jmter、loadrunner等；也可以自己開發一個性能測試工具 - 場景設計
設計性能測試場景必須符合用戶在軟件上的使用流程，用戶經常使用的功能模塊所對應的接口就需要做多併發的測試 - 監控部署
一個軟件的構成除了應用程序還需要將其部署到的服務器上以及數據存儲的數據庫，這些組成的東西都需要將它們進行監控，只有這樣才能看到各個部分實際的運行狀態以便我們進行更好的數據分析從而發現性能瓶頸才能進行調優 - 測試執行
當以上的步驟流程都完成了開始進行測試跑腳本 - 性能分析
性能分析基於監控部署，只有當監控部署進行到無死角的監控，得到的監控數據越全面，那麼性能分析得到結果才最準確 - 性能調優
只有將監控部署以及性能分析做到位最全面做準確後，才能進行性能調優，可以發現以上關鍵幾步都是相互關聯的；如果沒有監控部署而是通過工具自帶的測試報告數據也就是工具去收集了服務器或應用程序的一些狀態數據，而這些數據是不全面的，並不能完全勝任監控部署的角色，所以需要單獨去進行監控部署;當性能調優後遇到一些問題後，再去進行測試執行；實際上測試執行—性能分析—性能調優這關鍵的三步是一個迭代的過程 - 生成測試報告
當性能測試指標達到性能指標制定的標準後，也就是達標後，這時候生成就可以生成測試報告給上級領導看，程序滿足制定的性能指標，可以進行上線了
6.性能測試的指標
- 事務
從客戶端發起的一個或多個請求（這些請求組成一個完整的操作），到客戶端接收到從服務器返回的響應；如客戶在web端點擊登錄按鈕調用api接口方法，在api中去檢驗請求傳遞的登錄數據是否合法然後去數據庫中驗證數據是否存在且準確，最後再通過api接口方法返回響應數據到web客戶端提示用戶登錄成功或登錄失敗，這就是一個完整的事務；登錄屬於一個請求，多個請求比如銀行轉賬等 - TPS（Transactions Per Second）
每秒鐘系統能夠處理的事務數
注意：事務數並不等於請求數，如服務器一秒鐘處理5個事務，並不等於服務器一秒鐘處理5個請求也可能是10個請求，TPS和事務的關聯關係就在此。
舉例：事務靠虛擬用戶產生，假如1個虛擬用戶在1秒內完成1筆事務，那麼TPS就是1，要想達到1000TPS至少需要1000個用戶；如果某筆業務響應時間爲1ms，那麼1個用戶在1秒內能完成1000筆事務，TPS就是1000.因此1個用戶可以產生1000TPS，1000個用戶也可以產生1000TPS，主要看響應時間的快慢。 - 請求響應時間
從客戶端發起的一個請求開始，到客戶端接收到從服務器返回的響應。整個過程所消耗的時間。 - 事務響應時間
事務可能是由一個或多個請求組成的，事務響應時間主要是針對於用戶的角度而言，如轉賬。 - 併發的定義
沒有嚴格意義上的併發。併發總有先後，無論差距是1ms或者是μs(微秒)，總有一個時間差。所以併發講的是一個時間範圍內，比如1秒內的併發。
舉例：多用戶在系統上進行同一操作，比如雙11的時候，大家都針對同一種商品進行秒殺
多用戶在系統上進行不同操作，比如雙11的時候，大家針對不同的商品進行秒殺，或者說是大家有進行其他不同的操作，比如瀏覽其他商品。 - 併發用戶數
同一單位時間內對系統發起請求的用戶數量
舉例：現在服務器都是多核CPU，這樣做的目的是提高服務器處理多線程能力，也就是處理用戶數的能力；一般情況下都是1秒內，如1秒內服務器能夠承擔多少併發用戶數，一定要對時間敏感。 - 吞吐量（Throughput）
一次性能測試過程中網絡上傳輸的數據量總和
說明：以上傳輸數據量的總和是可以自己手工計算的，如一個http請求（get、post等），你知道它的請求參數，請求頭的大小是多少，就可以進行一個粗略的計算；之所以要使用監控軟件進行監控是防止有些請求中攜帶的參數是我們不知道的（也佔了網絡流量）。
舉例：如公司帶寬下載速度是10M/S（拋開其他的網絡消耗），當下載的文件大小爲1M，最大的下載用戶併發爲10個，再多就會排隊等待了，就好比百度網盤一樣，實際是將每個用戶進行網絡帶寬限制了，也就是成本控制，畢竟網絡開銷費用不便宜，所以用戶要想提高下載速度就需要花錢了；實際在工作的時候，一般人往往會忽略網絡帶寬帶來的性能瓶頸，如代碼、服務器、數據庫都沒有問題，併發數上不來，那麼就需要監控一下網絡資源消耗情況 - 吞吐率
單位時間內網絡上傳輸的數據量；吞吐率 = 吞吐量 / 傳輸時間
壓力10分鐘總的吞吐量爲10M，一分鐘的吞吐量 = 10 / 10 = 1M = 1024KB，一秒中的吞吐率爲 = 1/60 M - 點擊率
每秒鐘用戶向服務器提交的請求數。這個指標是web應用程序特有的一個指標，可以想象爲每秒鐘用戶總共在頁面上進行多少次點擊動作，但是需要注意的是一次鼠標單擊的操作後，客戶端有可能向服務器發送了多次請求。（現在在手機在也是可以通過手指不斷點擊的） - 資源使用率
對不同的系統資源的使用情況，如CPU、內存、IO等
7.性能測試需求分析
說明：這是性能測試的第一步，也是至關重要的一步；需求分析以及需求評審環節是非常重要的；開發之所以寫代碼寫出了BUG，那是因爲開發在寫代碼過程中存在想不到的地方，測試之所以沒有測出所有的BUG，那也是因爲在測試過程中，有些情況或者是場景沒有想到；所以說需求分析、評審很重要，同樣測試人員寫的用例也是需要進行評審的，大家一起研究探討分析就會讓用例覆蓋率更全面，多個人多個思想多個想法嘛
-
目的
- ⇒ 明確測試指標
- √ 有哪些指標需要進行重點關注，如TPS等
- √ 測試人員必須清楚指標的含義
- ⇒ 明確測試場景
- √ 如對某個業務進行性能測試，但是這個業務模塊需要準備大量的測試數據，即會產生時間成本，那麼就需要考慮該模塊是否需要測試出性能瓶頸，所以需要明確哪些場景（業務模塊）是需要着重測試的。
- √ 如之前併發的例子，多用戶對同一系統下的同一功能模塊進行操作以及多用戶對同一系統下的不同功能模塊進行操作，這也是一種業務測試場景（1、用戶登錄——瀏覽不同商品——對同一商品進行秒殺；2、用戶登錄——瀏覽不同商品——對不同商品進行秒殺；除了這兩種還有很多很多的場景，如登錄後瀏覽購買或登錄後結算掉上次添加到購物車的商品等等等等’）。
- ⇒ 明確測試指標
-
新系統
- ⇒ 同行業對比
- √ 公司以前就沒有做過此類軟件，沒有任何經驗，首先是想市場上有麼有該類軟件，如果有就去收集一下該軟件的業務場景之類的，可以去成爲該軟件的用戶去體驗一下軟件。
- ⇒ 業務預期
- √ 預期在產品發佈後的多少天內有多少用戶，如果是大公司的產品，那麼用戶數會呈現階梯式的增長，根據在這個期間系統用戶的增長，那麼性能就需要扛住用戶併發數，通過市場部門反饋用戶的未來三個月的增長數來制定性能測試指標。
- ⇒ 同行業對比
-
老系統
- ⇒ 對比以往用戶使用行爲以及用戶量
- √ 根據之前老系統在過去一段時間的用戶增長，如過去半年內用戶增長是屬於平穩期還是上升期，如果是平穩期就直接來制定指標，如果是上升趨勢，那麼就預估之後系統的用戶增長，根據預估的系統用戶增長來制定性能測試指標。
- ⇒ 對比以往用戶使用行爲以及用戶量