性能測試顧名思義指的是應用軟件中各項指標的負載情況。

根據(jù)百度百科的釋義，性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。

性能測試在軟件的質量保證中起著重要的作用，它包括的測試內容豐富多樣。中國軟件評測中心將性能測試概括為三個方面：應用在客戶端性能的測試、應用在網(wǎng)絡上性能的測試和應用在服務器端性能的測試。通常情況下，三方面有效、合理的結合，可以達到對系統(tǒng)性能全面的分析和瓶頸的預測。

簡而言之，性能測試目標就是為了識別并消除應用程序中的性能瓶頸。

今天，我們就以博睿數(shù)據(jù)的個別產(chǎn)品為例，講講性能測試的那些事兒。

性能測試的基本常識

首先，要想全面的認識性能測試，就要對性能測試的基本常識、術語以及性能測試的基本方法論有基本的認識。

性能測試的概念前文已經(jīng)陳述，在這里我們就不再贅述。

我們來看下什么是軟件性能。

軟件測試是軟件的一種非功能特性，它關注的不是軟件是否能夠完成特定的功能，而是在完成該功能時展示出來的及時性。

一般而言，性能測試主要包含以下5個術語：

2 響應時間：對請求做出響應需要的時間。

2 并發(fā)用戶數(shù)：在同一時間段內訪問系統(tǒng)的用戶數(shù)量。

2 吞吐量：單位時間內系統(tǒng)處理的客戶請求的數(shù)量。

2 性能計數(shù)器：描述服務器或操作系統(tǒng)性能的一些數(shù)據(jù)指標。

2 思考時間：休眠時間。

按照類型來劃分，性能測試又分為六大類型：

l 負載測試：負載測試用于測試應用程序在正常和峰值情況下的性能。在負載測試中，我們對應用程序性能好壞的判定依據(jù)主要源于該應用程序對用戶請求的響應情況，以及它在不同負載變化下（可接受的程度內）一致響應的能力來檢測的。

負載測試中的核心關注點：

在應用程序出現(xiàn)異常情況前，該應用程序所能容納的最大負載量是多少？

在系統(tǒng)變慢或出現(xiàn)崩潰之前，數(shù)據(jù)庫所能處理的數(shù)據(jù)量有多少？

是否有任何與網(wǎng)絡相關的問題需要解決？

l 驗收性能測試：通過模擬生產(chǎn)運行的業(yè)務壓力量和使用場景組合，測試系統(tǒng)性能是否滿足生產(chǎn)性能要求。

l 壓力測試：壓力測試旨在尋找破壞系統(tǒng)的方法。該測試同時還能為我們找到系統(tǒng)可以承受的最大負載范圍。

通常，壓力測試采用增量方法，通過逐步增加負載來觀察系統(tǒng)各項性能指標的變化情況。

首先，我們可以從應用程序已經(jīng)測試過的負載開始（例如當前用戶數(shù) 100 個）；然后慢慢地增加更多的負載來給系統(tǒng)增加壓力（例如從 100個用戶數(shù)逐步增加到 10000）。

當我們發(fā)現(xiàn)服務器沒有響應請求的那個點開始，這個點就被認為是斷點（在一些性能測試報告圖表中，往往也視為性能拐點）。

在壓力測試過程中，我們需要關注的問題有：

系統(tǒng)在崩潰前能承受的最大負載是多少？

在實施壓力測試過程中，系統(tǒng)是如何崩潰的？系統(tǒng)能否在崩潰后自行恢復？

被測系統(tǒng)/應用程序在處理異常負載時，有哪幾種中斷方式？

l 配置測試：通過對被測系統(tǒng)軟硬件環(huán)境的調整，了解各種不同環(huán)境對系統(tǒng)性能的影響程度，從而找到系統(tǒng)各項資源的最優(yōu)分配原則。

l 可靠性/可恢復測試：可靠性測試或恢復測試用于驗證應用程序在出現(xiàn)故障或異常行為后，是否能夠恢復到正常狀態(tài)，以及恢復階段需要經(jīng)過多長時間。

例如在某線交易站點出現(xiàn)故障，致使用戶不能在一天的某個點（高峰時間）買賣股票，但在一兩個小時后用戶能夠進行在線股票交易，我們就可以說該應用程序是可靠的，即有能力從異常行為中自行恢復。

l 并發(fā)測試：模擬用戶的并發(fā)訪問，測試多用戶并發(fā)訪問同一個應用、同一個模塊或者數(shù)據(jù)記錄時，是否存在死鎖或者其他性能問題。

了解了這些基本信息后，一個很重要的問題是如何測試性能？

博睿數(shù)據(jù)為大家整理了7個方法論：

ü SEI負載測試計劃過程：關注負載測試計劃的方法，包括6個關注區(qū)域：目標、用戶、用例、生成環(huán)境、測試環(huán)境、測試場景。

ü RBI方法：是Empirix公司提出的一種用于快速識別系統(tǒng)性能瓶頸的方法。

RBI方法基于以下事實：

1、發(fā)現(xiàn)的80%系統(tǒng)的性能瓶頸都由吞吐量制約；

2、并發(fā)用戶數(shù)和吞吐量瓶頸之間存在一定的關聯(lián)；

3、采用吞吐量測試可以更快速的定位問題。

需要注意的是RBI的分析方法是自上而下的：即首先確定是由并發(fā)還是吞吐量引發(fā)的性能表現(xiàn)限制；然后從網(wǎng)絡、數(shù)據(jù)庫、應用服務器和代碼4個環(huán)節(jié)確定系統(tǒng)性能具體瓶頸。

ü 性能下降曲線分析：描述的是性能隨用戶數(shù)增加而出現(xiàn)下降趨勢的曲線。

性能下降曲線可以分為以下幾個部分：

單用戶區(qū)域——對系統(tǒng)的單用戶響應時間；對建立性能的參考值有幫助；

性能平坦區(qū)域——在不進行更多性能調優(yōu)的情況下所能期望達到的最佳性能；該區(qū)域可被用作基線。

壓力區(qū)域——應用輕微下降的區(qū)域；典型的、最大的建議用戶負載，是壓力區(qū)域的開始。

拐點——性能開始急劇下降的點。

ü LoarRunner性能測試過程：計劃測試、測試設計、創(chuàng)建VU腳本、創(chuàng)建測試場景、運行測試場景、分析結果。

ü Segue提供的性能測試過程：是Segue公司Silk Performer提供的性能測試過程；適合性能調優(yōu)和優(yōu)化。

ü 敏捷性能測試：是隨著敏捷技術發(fā)展而來的一種行的性能測試方法。

敏捷性能測試包括如下特點：

在每個迭代目標中包含明確的性能目標；

建立不同層次的性能測試——端到端、基于接口、面向具體函數(shù)；

完全或接近完全自動化的性能測試——LoadRunner、JMeter、JUnit；

使用測試驅動的方法保證性能與優(yōu)化性能。

ü PTGM模型：應用于非敏捷過程的性能測試模型；分測試前期準備、測試工具引入、測試計劃、測試設計與開發(fā)、測試執(zhí)行與管理、測試分析6個步驟。

此外，在應用領域方面，性能測試又可細分為5個領域：

u 能力驗證——在給定條件下，系統(tǒng)能否具有預期的能力表現(xiàn)。

u 規(guī)劃能力——應該如何使系統(tǒng)具有我們要求的性能能力；如：應該如何調整，使系統(tǒng)能夠滿足增長的用戶數(shù)的需要。

u 性能調優(yōu)——主要應用于對系統(tǒng)性能進行調優(yōu)。

u 發(fā)現(xiàn)缺陷——主要時通過性能測試的手段發(fā)現(xiàn)系統(tǒng)種存在的缺陷。

u 性能基準比較——通常應用在敏捷開發(fā)過程，是在不設定明確目標的情況下，通過比較得到每次迭代中的性能表現(xiàn)的變化，根據(jù)這些變化決定迭代是否達到了預期的目標。

性能測試怎么做？

那么，了解了性能測試的基本常識后，我們接下來就要了解性能測試要怎么做？

一般而言，性能測試的流程分為需求分析——測試準備——執(zhí)行測試——結果分析與調優(yōu)——報告與總結五個階段。

接下來，我們具體來看下。

(1) 需求分析：

首先需要明確性能需求分析是整個性能測試工作開展的基礎，如果連性能的需求都沒弄清楚，后面的性能測試執(zhí)行其實是沒有任何意義的，而且性能需求分析做的好不好直接影響到性能測試的結果。

需求分析需要明確倒底要不要做性能測試？性能測試的目的是什么？明確被測系統(tǒng)是什么？被測試系統(tǒng)的相關技術信息如：架構、平臺、協(xié)議等？明確被測系統(tǒng)的基本業(yè)務、關鍵業(yè)務，用戶行為？明確性能測試點是什么？哪些需要測，為什么？哪些不需要測，又是為什么？

一般而言，需求分析可以從系統(tǒng)信息調研、業(yè)務信息調研、性能需求評估、性能測試點、性能指標等五方面入手。

以博睿數(shù)據(jù)的SDK 產(chǎn)品為例。

我們在分析需求時首先會從其架構入手分析，然后從業(yè)務層面進行分析，例如新增、活躍用戶數(shù)，第一次使用和啟動app（config請求）、啟動以后每一分鐘上報一次數(shù)據(jù)（upload請求）、controller接收請求，簡單解析封裝，發(fā)送到kafka、ETL從kafka上獲取controller存儲的數(shù)據(jù)，進行解析（解析成不同表數(shù)據(jù)，封裝）、ETL解析數(shù)據(jù)后，將封裝好的數(shù)據(jù)，再次上傳到kafka、druid從kafka獲取數(shù)據(jù)入到庫中、web頁面從druid中查詢數(shù)據(jù)展示等等業(yè)務信息情況，最終從性能測試和性能指標入手，確定性能需求。

(2) 性能測試準備：

性能測試準備階段又分為6個階段：

環(huán)境準備：

a）系統(tǒng)運行環(huán)境：這個通常指的是我們的測試環(huán)境，有些時候需求比較多，做性能測試擔心把環(huán)境搞跨了影響其它的功能測試，可能需要重新搭建一套專門用來做性能測試的環(huán)境。

b）執(zhí)行機環(huán)境：這個就是用來生成負載的執(zhí)行機，我們每次做性能測試都需要提前準備好執(zhí)行機環(huán)境，建議執(zhí)行機使用liunx系統(tǒng)，不要使用windows系統(tǒng)。

（3）場景設計：

根據(jù)性能需求分析來設計符合用戶使用習慣的場景，場景設計的好不好直接影響到性能測試的效果。

（4）工具準備：

a）負載工具：根據(jù)需求分析和系統(tǒng)特點選擇合適的負載工具，比如LR、Jmeter或galting等。

b）監(jiān)控工具：準備性能測試時的服務器資源、JVM、數(shù)據(jù)庫監(jiān)控工具，以便進行后續(xù)的性能測試分析與調優(yōu)、redis狀態(tài)監(jiān)控、kafka消費情況監(jiān)控。

測試腳本：

如果性能測試工具不能滿足被測系統(tǒng)的要求或只能滿足部分要求時，需要我們自己開發(fā)腳本配合工具進行性能測試。

（5）測試數(shù)據(jù)：

a）用例數(shù)據(jù)。

b）負載測試數(shù)據(jù)。

其他：如果需要其它關聯(lián)系統(tǒng)或專業(yè)人士，如DBA配合的，也需要提前進行溝通。

（6）性能結果分析：

性能結果分析則主要從兩個層面出發(fā)：即性能指標與負載的簡單關系和結果分析。

其中，性能指標與負載的簡單關系又可分為響應時間、吞吐量、資源利用率三個層面。

首先來看響應時間。

響應時間對應的負載的關系從函數(shù)的角度理解，可以簡單理解為負載隨著響應時間的增加而增加的正向關系。

也就是說，響應時間突然增加，意味著系統(tǒng)的一種或多種資源利用可能達到的極限。通常可以利用拐點來進行性能測試分析與定位。

再來看下吞吐量。

吞吐量逐漸達到飽和意味著系統(tǒng)的一種或多種資源利用達到的極限。

最后說到資源利用率。

與負載對應關系可以理解為服務器某薦資源使用逐漸達到飽和。

結果分析需具體問題具體分析，一般是多項指標結合分析，通過單個指標一般得不出結論。

結果可以從以下幾個方面分析：

v 執(zhí)行發(fā)壓機器性能是否正常。

v 被壓測程序所在機器，資源是否正常。

v 依賴組件是否正常。

v 依賴組件所在機器資源是否正常。

v 宿主機機器資源是否正常。

最后需要注意的是，完整的性能測試報告以簡潔為主，不需要任何推導，開發(fā)團隊需要更多關于分析、比較結果的信息，以及如何獲得結果的細節(jié)。

總結

不難發(fā)現(xiàn)要成功完成一個性能測試項目，我們需要確保性能測試計劃階段各方面的準確性。

即計劃、基于測試需求分析的用例開發(fā)、場景設計、測試執(zhí)行和結果分析，這些關鍵點都必須按照正確的方式進行，加上合理的風險預估及緩解策略。