性能測試到底該怎麽做？
高性能、高並發、高可用。
聽起來非常高大上，但是性能到底如何呢？又該如何評定呢？
這次我們談壹談性能測試，看壹看到底什麽樣才叫做高性能。
本文主要從以下幾個方面進行討論。
（1）性能測試是什麽？
（2）為什麽需要性能測試？
（3）性能測試如何做？
（4）有哪些性能測試的工具
老馬曾經說過，妳想理解壹件事物，首先必須先定義它。
這裏直接引用壹下百科中的定義：
性能測試的定義也不難理解，往往定義本身闡述了性能測試的作用。
如果妳是壹名開發、測試，平時接手過不少需求，可能性能測試接觸的也不多。
每壹個需求，都有對應的功能性需求和肺功能性需求。
功能性需求是產品需求文檔中最直接的，需要實現的功能目標。簡稱，能用就行。
非功能性需求則要寬泛的多，架構設計是否合理？是否便於後期拓展？是否便於監控？代碼實現是否優雅？文檔註釋是否完整？
就像妳寫了壹只鳥，鳥頭做螺旋槳非能飛起來，但是在架構設計上可能是不合理的。
飛起來
壹個查詢功能，用戶點擊查詢，10S 種才返回數據，功能上是滿足的，但是性能上是不能接受的。
線上的交易功能平時各方面都很棒，節假日高峰期直接系統就癱瘓了。
那如何避免這些問題出現在生產上呢？
這就需要上線之前，首先做好對應的性能測試，避免再生產上出現問題，帶來嚴重的生產事故。
性能要高，性能要硬，性能測試，又高又硬！
又高又硬
做壹件事情之前，我們首先要確定好自己的目標。
性能測試，到底要測試什麽？
有些類似於開發過程中的需求分析，常見的測試指標如下。
響應時間是指某個請求或操作從發出到接收到反饋所消耗的時間，包括應用服務器（客戶端）處理時間、網絡傳輸時間以及數據庫服務器處理時間。
作為用戶而言，在頁面點擊查詢，等待了多久才能獲取結果，這個就是響應時間。
用戶不關心妳後端經過了多少個服務，慢就是原罪。
對於微服務系統，鏈路監控就顯得比較重要。可以幫助我們快速定位到底慢在哪裏。
TPS（Transaction Per Second）是指單位時間（每秒）系統處理的事務量。
我看網上還有很多類似的概念：點擊量/點擊率、吞吐量/吞吐率、PV/UV，這裏不做贅述。
個人看來本質上 TPS/QPS 就是去壓測妳應用的極限，當訪問量較大的時候，程序能否活下來？
這裏主要涉及到兩個概念：高性能和高可用。
我們後面會簡單討論下這兩點。
明確了測試指標之後，就需要進行測試的準備。
環境準備：比如妳想壓測數據庫，那就需要準備對應配置的數據庫資源。
腳本的準備：數據初始化腳本，調用腳本等。
這個可以類比開發過程中的代碼開發。
ps: 性能壓測壹般不是很常用，所以環境準備流程會比較長，這壹點需要註意。
當進行測試之後，測試的結果壹定要給出壹份報告出來。
是否通過壓測要求？
最高的 QPS 是多少？
這樣開發可以根據這份報告進行相應的優化。
提升性能的內容寫壹本書也不為過，這裏簡單羅列壹些最常用的幾點：
（1）慢 SQL
壹般程序如果響應時間較長，可以首先看壹下慢 SQL。
看下是否需要增加索引，或者進行 SQL 優化。
（2）緩存
針對查詢，性能提升最顯著的就是引入緩存。
當然，引入緩存會使架構變得復雜，這壹點要結合自己的實際業務。
（3）硬件升級
如果程序優化的空間比較小，可以考慮升級壹下硬件資源。
比如服務器配置翻倍，數據庫配置翻倍。
什麽？妳說公司沒錢升級？
沒錢升級做什麽壓測？
這個時候測試報告的作用就顯露了，直接用數據說話。
直接說 QPS 達不到生產要求，程序優化的空間很小，推薦硬件升級配置，升級到多少。
做人，要以德服人。
做測試，要用數據說話。
以德服人
測試最常用的工具當屬 jmeter。
除此之外，還有壹些其他的工具：
LoadRunner、QALoad、SilkPerformer和Rational Performance Tester。
下面對幾個工具做下簡單介紹
Apache JMeter 可以用於測試靜態和動態資源(Web動態應用程序)的性能。
它可以用於模擬服務器、服務器組、網絡或對象上的負載，以測試其強度或分析不同負載類型下的總體性能。
將負載測試集成到開發工具中:IDE、jUnit、nUnit、Jenkins、Selenium和Microsoft Visual Studio。
從12.55版本開始，您可以運行您的JMeter腳本，並在任何性能測試中集成JMeter和附加的腳本類型。
ps: 這個設計理念就非常好，可以和成熟的工具進行整合。站在巨人的肩膀上。
QALoad是客戶/服務器系統、企業資源配置（ERP）和電子商務應用的自動化負載測試工具。
QALoad可以模擬成百上千的用戶並發執行關鍵業務而完成對應用程序的測試，並針對所發現問題對系統性能進行優化，確保應用的成功部署。
ps: 這個工具本人沒有接觸過。
SilkPerformerV可以讓妳在使用前，就能夠預測企業電子商務環境的行為—不受電子商務應用規模和復雜性影響。
可視化的用戶化、負載條件下可視化的內容校驗、實時的性能監視和強大的管理報告可以幫助您迅速將問題隔離，這樣，通過最小化測試周期、優化性能以及確保可伸縮性，加快了投入市場的時間，並保證了系統的可靠性。
作為 DevOps 方法的壹部分，IBM Rational Performance Tester 幫助軟件測試團隊更早、更頻繁地進行測試。
它驗證 Web 和服務器應用程序的可擴展性，確定系統性能瓶頸的存在和原因，並減少負載測試。
您的軟件測試團隊可以快速執行性能測試，分析負載對應用程序的影響。
ps: 這壹款工具有 IBM 提供，質量值得信賴。
這麽多工具可供使用，相信讀到這裏的小夥伴已經找到了自己心儀的測試工具。
別急，下面專門為做 java 開發的小夥伴們推薦壹款性能測試工具。
男人有男人的浪漫，開發者當然也要有開發者的浪漫。
男人的浪.jpg
作為壹名開發者，老馬平時單元測試使用 junit 最多。
所以壹直希望找到壹款基於 junit 的性能壓測工具，後來也確實找到了。
@JunitPerfConfig 指定測試時的屬性配置。(必填項)
使用如下：
@JunitPerfRequire 指定測試時需要達到的要求。(選填項)
使用如下：
對應的測試報告生成方式也是多樣的，也允許用戶自定義。
基於控臺日誌：
或者基於 HTML:
junitperf
本文對性能測試做了最基本的介紹，讓小夥伴們對性能壓測有壹個最基本的理解。
測試和開發壹樣，都是壹件費時費力，而且需要認真做才能做好的事情，其中的學問不是壹篇就能說清的。
性能測試工具也比較多，本文重點介紹了專門為 java 開發者打造的 junitperf 工具。
下壹節我們將從源碼角度，講解壹下 junitperf 的實現原理。
我是老馬，期待與妳的下次重逢。
開源地址：/houbb/junitperf