效能測試顧名思義指的是應用軟體中各項指標的負載情況。
根據百度百科的釋義，效能測試是透過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。
效能測試在軟體的質量保證中起著重要的作用，它包括的測試內容豐富多樣。中國軟體評測中心將效能測試概括為三個方面：應用在客戶端效能的測試、應用在網路上效能的測試和應用在伺服器端效能的測試。通常情況下，三方面有效、合理的結合，可以達到對系統性能全面的分析和瓶頸的預測。
簡而言之，效能測試目標就是為了識別並消除應用程式中的效能瓶頸。
今天，我們就以博睿資料的個別產品為例，講講效能測試的那些事兒。
效能測試的基本常識
首先，要想全面的認識效能測試，就要對效能測試的基本常識、術語以及效能測試的基本方法論有基本的認識。
效能測試的概念前文已經陳述，在這裡我們就不再贅述。
我們來看下什麼是軟體效能。
軟體測試是軟體的一種非功能特性，它關注的不是軟體是否能夠完成特定的功能，而是在完成該功能時展示出來的及時性。
一般而言，效能測試主要包含以下5個術語：
² 響應時間：對請求做出響應需要的時間。
² 併發使用者數：在同一時間段內訪問系統的使用者數量。
² 吞吐量：單位時間內系統處理的客戶請求的數量。
² 效能計數器：描述伺服器或作業系統效能的一些資料指標。
² 思考時間：休眠時間。
按照型別來劃分，效能測試又分為六大型別：
l 負載測試：負載測試用於測試應用程式在正常和峰值情況下的效能。在負載測試中，我們對應用程式效能好壞的判定依據主要源於該應用程式對使用者請求的響應情況，以及它在不同負載變化下（可接受的程度內）一致響應的能力來檢測的。
負載測試中的核心關注點：
在應用程式出現異常情況前，該應用程式所能容納的最大負載量是多少？
在系統變慢或出現崩潰之前，資料庫所能處理的資料量有多少？
是否有任何與網路相關的問題需要解決？
l 驗收效能測試：透過模擬生產執行的業務壓力量和使用場景組合，測試系統性能是否滿足生產效能要求。
l 壓力測試：壓力測試旨在尋找破壞系統的方法。該測試同時還能為我們找到系統可以承受的最大負載範圍。
通常，壓力測試採用增量方法，透過逐步增加負載來觀察系統各項效能指標的變化情況。
首先，我們可以從應用程式已經測試過的負載開始（例如當前使用者數 100 個）；然後慢慢地增加更多的負載來給系統增加壓力（例如從 100 個使用者數逐步增加到 10000）。
當我們發現伺服器沒有響應請求的那個點開始，這個點就被認為是斷點（在一些效能測試報告圖表中，往往也視為效能拐點）。
在壓力測試過程中，我們需要關注的問題有：
系統在崩潰前能承受的最大負載是多少？
在實施壓力測試過程中，系統是如何崩潰的？系統能否在崩潰後自行恢復？
被測系統/應用程式在處理異常負載時，有哪幾種中斷方式？
l 配置測試：透過對被測系統軟硬體環境的調整，瞭解各種不同環境對系統性能的影響程度，從而找到系統各項資源的最優分配原則。
l 可靠性/可恢復測試：可靠性測試或恢復測試用於驗證應用程式在出現故障或異常行為後，是否能夠恢復到正常狀態，以及恢復階段需要經過多長時間。
例如在某線交易站點出現故障，致使使用者不能在一天的某個點（高峰時間）買賣股票，但在一兩個小時後使用者能夠進行線上股票交易，我們就可以說該應用程式是可靠的，即有能力從異常行為中自行恢復。
l 併發測試：模擬使用者的併發訪問，測試多使用者併發訪問同一個應用、同一個模組或者資料記錄時，是否存在死鎖或者其他效能問題。
瞭解了這些基本資訊後，一個很重要的問題是如何測試效能？
博睿資料為大家整理了7個方法論：
ü SEI負載測試計劃過程：關注負載測試計劃的方法，包括6個關注區域：目標、使用者、用例、生成環境、測試環境、測試場景。
ü RBI方法：是Empirix公司提出的一種用於快速識別系統性能瓶頸的方法。
RBI方法基於以下事實：
1、發現的80%系統的效能瓶頸都由吞吐量制約；
2、併發使用者數和吞吐量瓶頸之間存在一定的關聯；
3、採用吞吐量測試可以更快速的定位問題。
需要注意的是RBI的分析方法是自上而下的：即首先確定是由併發還是吞吐量引發的效能表現限制；然後從網路、資料庫、應用伺服器和程式碼4個環節確定系統性能具體瓶頸。
ü 效能下降曲線分析：描述的是效能隨使用者數增加而出現下降趨勢的曲線。
效能下降曲線可以分為以下幾個部分：
單使用者區域——對系統的單使用者響應時間；對建立效能的參考值有幫助；
效能平坦區域——在不進行更多效能調優的情況下所能期望達到的最佳效能；該區域可被用作基線。
壓力區域——應用輕微下降的區域；典型的、最大的建議使用者負載，是壓力區域的開始。
拐點——效能開始急劇下降的點。
ü LoarRunner效能測試過程：計劃測試、測試設計、建立VU指令碼、建立測試場景、執行測試場景、分析結果。
ü Segue提供的效能測試過程：是Segue公司Silk Performer提供的效能測試過程；適合效能調優和最佳化。
ü 敏捷效能測試：是隨著敏捷技術發展而來的一種行的效能測試方法。
敏捷效能測試包括如下特點：
在每個迭代目標中包含明確的效能目標；
建立不同層次的效能測試——端到端、基於介面、面向具體函式；
完全或接近完全自動化的效能測試——LoadRunner、JMeter、JUnit；
使用測試驅動的方法保證效能與最佳化效能。
ü PTGM模型：應用於非敏捷過程的效能測試模型；分測試前期準備、測試工具引入、測試計劃、測試設計與開發、測試執行與管理、測試分析6個步驟。
此外，在應用領域方面，效能測試又可細分為5個領域：
u 能力驗證——在給定條件下，系統能否具有預期的能力表現。
u 規劃能力——應該如何使系統具有我們要求的效能能力；如：應該如何調整，使系統能夠滿足增長的使用者數的需要。
u 效能調優——主要應用於對系統性能進行調優。
u 發現缺陷——主要時透過效能測試的手段發現系統種存在的缺陷。
u 效能基準比較——通常應用在敏捷開發過程，是在不設定明確目標的情況下，透過比較得到每次迭代中的效能表現的變化，根據這些變化決定迭代是否達到了預期的目標。
效能測試怎麼做？
那麼，瞭解了效能測試的基本常識後，我們接下來就要了解效能測試要怎麼做？
一般而言，效能測試的流程分為需求分析——測試準備——執行測試——結果分析與調優——報告與總結五個階段。
接下來，我們具體來看下。
(1) 需求分析：
首先需要明確性能需求分析是整個效能測試工作開展的基礎，如果連效能的需求都沒弄清楚，後面的效能測試執行其實是沒有任何意義的，而且效能需求分析做的好不好直接影響到效能測試的結果。
需求分析需要明確倒底要不要做效能測試？效能測試的目的是什麼？明確被測系統是什麼？被測試系統的相關技術資訊如：架構、平臺、協議等？明確被測系統的基本業務、關鍵業務，使用者行為？明確性能測試點是什麼？哪些需要測，為什麼？哪些不需要測，又是為什麼？
一般而言，需求分析可以從系統資訊調研、業務資訊調研、效能需求評估、效能測試點、效能指標等五方面入手。
以博睿資料的SDK 產品為例。
我們在分析需求時首先會從其架構入手分析，然後從業務層面進行分析，例如新增、活躍使用者數，第一次使用和啟動app（config請求）、啟動以後每一分鐘上報一次資料（upload請求）、controller接收請求，簡單解析封裝，傳送到kafka、ETL從kafka上獲取controller儲存的資料，進行解析（解析成不同表資料，封裝）、ETL解析資料後，將封裝好的資料，再次上傳到kafka、druid從kafka獲取資料入到庫中、web頁面從druid中查詢資料展示等等業務資訊情況，最終從效能測試和效能指標入手，確定性能需求。
(2) 效能測試準備：
效能測試準備階段又分為6個階段：
環境準備：
a）系統執行環境：這個通常指的是我們的測試環境，有些時候需求比較多，做效能測試擔心把環境搞跨了影響其它的功能測試，可能需要重新搭建一套專門用來做效能測試的環境。
b）執行機環境：這個就是用來生成負載的執行機，我們每次做效能測試都需要提前準備好執行機環境，建議執行機使用liunx系統，不要使用windows系統。
（3）場景設計：
根據效能需求分析來設計符合使用者使用習慣的場景，場景設計的好不好直接影響到效能測試的效果。
（4）工具準備：
a）負載工具：根據需求分析和系統特點選擇合適的負載工具，比如LR、Jmeter或galting等。
b）監控工具：準備效能測試時的伺服器資源、JVM、資料庫監控工具，以便進行後續的效能測試分析與調優、redis狀態監控、kafka消費情況監控。
測試指令碼：
如果效能測試工具不能滿足被測系統的要求或只能滿足部分要求時，需要我們自己開發指令碼配合工具進行效能測試。
（5）測試資料：
a）用例資料。
b）負載測試資料。
其他：如果需要其它關聯絡統或專業人士，如DBA配合的，也需要提前進行溝通。
（6）效能結果分析：
效能結果分析則主要從兩個層面出發：即效能指標與負載的簡單關係和結果分析。
其中，效能指標與負載的簡單關係又可分為響應時間、吞吐量、資源利用率三個層面。
首先來看響應時間。
響應時間對應的負載的關係從函式的角度理解，可以簡單理解為負載隨著響應時間的增加而增加的正向關係。
也就是說，響應時間突然增加，意味著系統的一種或多種資源利用可能達到的極限。通常可以利用拐點來進行效能測試分析與定位。
再來看下吞吐量。
吞吐量逐漸達到飽和意味著系統的一種或多種資源利用達到的極限。
最後說到資源利用率。
與負載對應關係可以理解為伺服器某薦資源使用逐漸達到飽和。
結果分析需具體問題具體分析，一般是多項指標結合分析，透過單個指標一般得不出結論。
結果可以從以下幾個方面分析：
v 執行發壓機器效能是否正常。
v 被壓測程式所在機器，資源是否正常。
v 依賴元件是否正常。
v 依賴元件所在機器資源是否正常。
v 宿主機機器資源是否正常。
最後需要注意的是，完整的效能測試報告以簡潔為主，不需要任何推導，開發團隊需要更多關於分析、比較結果的資訊，以及如何獲得結果的細節。
總結
不難發現要成功完成一個性能測試專案，我們需要確保效能測試計劃階段各方面的準確性。
即計劃、基於測試需求分析的用例開發、場景設計、測試執行和結果分析，這些關鍵點都必須按照正確的方式進行，加上合理的風險預估及緩解策略。
