性能測試：利用工具模擬大量用戶操作，驗證系統(tǒng)承受的負載情況。
性能測試的目的：找到潛在的性能問題或瓶頸，分析并解決；找出性能變化趨勢，為后續(xù)擴展系統(tǒng)提供參考。

• 測試監(jiān)控：基準測試、配置測試、負載測試、穩(wěn)定性測試，對硬件和中間件進行監(jiān)控。

1、學(xué)習(xí)業(yè)務(wù)：

通過查看文檔、手工操作系統(tǒng)對系統(tǒng)功能進行學(xué)習(xí)。

2、需求分析：

分析系統(tǒng)非功能需求（關(guān)注業(yè)務(wù)量、業(yè)務(wù)分布、用戶規(guī)模、性能指標等信息），確定性能測試范圍，了解性能指標。

一、系統(tǒng)非功能需求采集

（1）系統(tǒng)架構(gòu)：物理架構(gòu)（硬件及部署策略）和邏輯架構(gòu)（系統(tǒng)的功能與服務(wù)），包括中間件產(chǎn)品與配置、數(shù)據(jù)庫配置等，供我們搭建測試環(huán)境時進行參考。

（2）業(yè)務(wù)流程：業(yè)務(wù)量和業(yè)務(wù)分布。采集業(yè)務(wù)（分析出哪些業(yè)務(wù)納入性能測試范圍）并量化業(yè)務(wù)、業(yè)務(wù)擴展趨勢（年增長率或者未來的業(yè)務(wù)量）、業(yè)務(wù)發(fā)生時段（業(yè)務(wù)高峰的發(fā)生時間和高峰業(yè)務(wù)量）、業(yè)務(wù)分布（各項業(yè)務(wù)之間的比例）。

（3）用戶信息：在線用戶數(shù)、活動用戶數(shù)、業(yè)務(wù)分布。有些系統(tǒng)用戶量特別大，會對系統(tǒng)造成性能瓶頸，可以通過分析活動用戶數(shù)和業(yè)務(wù)分布來分析負載情況。

（4）系統(tǒng)是否與第三方系統(tǒng)有關(guān)，是否需要做擋板（Mock程序）。

（5）系統(tǒng)是否有歸檔機制：如果數(shù)據(jù)庫有歸檔機制？？？，可以把一些無用或者過時的信息移到歸檔庫，這樣就減少當前數(shù)據(jù)庫的數(shù)據(jù)，有利于提高系統(tǒng)性能。

（6）性能指標：吞吐率、響應(yīng)時間、事務(wù)成功率，CPU、內(nèi)存、磁盤、帶寬使用閥值。

二、系統(tǒng)非功能需求分析

確定性能測試范圍

1. 是否核心業(yè)務(wù)，是否要求嚴格的質(zhì)量
2. 是否高頻次的業(yè)務(wù)
3. 是否占用系統(tǒng)較多資源、或性能影響大的業(yè)務(wù)
4. 使用人數(shù)多還是少
5. 在線人數(shù)多還是少
6. 確定此功能的可測性、可驗證性：功能是否可驗證（是否牽連到第三方程序，是否需要做擋板Mock程序）。

明確性能指標
業(yè)務(wù)性能指標
1. 吞吐量（PV）、吞吐率（TPS等）
2. 響應(yīng)時間（RT）/ 應(yīng)用響應(yīng)時間（ART）：3秒以內(nèi)
3. 事務(wù)成功率：99%以上
4. 穩(wěn)定波動正常范圍

響應(yīng)時間2-5-8原則
當用戶在2秒以內(nèi)得到響應(yīng)時，會感覺系統(tǒng)的響應(yīng)很快；
當用戶在2-5秒之間得到響應(yīng)時，會感覺系統(tǒng)的響應(yīng)速度還可以；
當用戶在5-8秒以內(nèi)得到響應(yīng)時，會感覺系統(tǒng)的速度很慢，但是還可以接受；
而當用戶在超過8秒后仍然無法得到響應(yīng)時，會感覺系統(tǒng)糟糕透了，或者認為系統(tǒng)已經(jīng)失去響應(yīng)。

硬件性能指標
CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)帶寬等。

系統(tǒng)硬件指標閥值

分析業(yè)務(wù)量
測試數(shù)據(jù)的多少對測試結(jié)果會有影響。特別是數(shù)據(jù)成千萬上億條之后，性能影響明顯，所以需要做足一定數(shù)量的歷史數(shù)據(jù)。除此之外，還得關(guān)注業(yè)務(wù)的增長。如果系統(tǒng)需要滿足未來三年的業(yè)務(wù)增長需求，那么在測試時就需要生成三年的存量業(yè)務(wù)數(shù)據(jù)。對于關(guān)系型數(shù)據(jù)庫來說，數(shù)據(jù)最大時對性能的影響還是比較明顯的。

估算TPS與并發(fā)數(shù)
一般我們會從運維那里得到整個系統(tǒng)在一天內(nèi)按小時進行統(tǒng)計的PV趨勢圖。根據(jù)訪問高峰業(yè)務(wù)量，估算出TPS與并發(fā)用戶數(shù)等性能測試執(zhí)行依據(jù)。一般采用二八原則，即80%的業(yè)務(wù)在20%的時間內(nèi)完成。二八原則計算的結(jié)果是吞吐量（即TPS），而并發(fā)數(shù) = TPS *（ThinkTime+RunTime）。

如果你的系統(tǒng)性能要求更高，也可以選擇一九原則或更嚴格的算法，二八原則比較通用，一般系統(tǒng)性能比較接近這個算法而已，大家應(yīng)該活用。

分析系統(tǒng)協(xié)議
一般性能測試腳本可以通過錄制或者手動開發(fā)，而錄制方式對協(xié)議的依賴性相當強。一般我們先分析系統(tǒng)協(xié)議（向開發(fā)團隊咨詢，或者截包分析），再評估用什么工具完成。HTTP可以用JMeter或者LoadRunner，Java接口可以用JMeter的JavaRequest元件與JUnit元件測試。

三、性能測試從哪里獲取需求？

一般需求文檔中會有一部分章節(jié)用于描述系統(tǒng)非功能性需求，但是多數(shù)需求文檔對于性能需求的說明都比較籠統(tǒng)抽象。在需求不明確的情況下，通常需要性能測試工程師主動向需求提供方（BA團隊、產(chǎn)品團隊等）去征詢。

對于升級、優(yōu)化類的老系統(tǒng)，可考慮是否存有歷史測試方案參考，或許可以省事很多?；蛘呶覀兎治鲈拖到y(tǒng)業(yè)務(wù)數(shù)據(jù)即可，最直接的辦法就是分析原型系統(tǒng)的數(shù)據(jù)、統(tǒng)計業(yè)務(wù)量、業(yè)務(wù)分布等信息。

3、工作評估：

工作量分解，評估工作量，計劃資源投入（即需要多少人力，多少工作日來完成性能測試工作）。

4、設(shè)計模型：

圈定測試范圍后，把業(yè)務(wù)模型映射成測試模型。

業(yè)務(wù)模型：業(yè)務(wù)流程，系統(tǒng)在某個時間段內(nèi)運行的業(yè)務(wù)種類及其業(yè)務(wù)占比，即哪個業(yè)務(wù)在什么時段在運行，業(yè)務(wù)量是多少？

測試模型：從業(yè)務(wù)模型中分析整理出來的需要進行測試的業(yè)務(wù)。對業(yè)務(wù)進行拆分對象，實現(xiàn)這個完整的功能包含哪些流程、環(huán)節(jié)。比如“購買商品”，具體的流程環(huán)節(jié)包括“登錄->搜索商品->提交訂單->支付訂單->退出”。接著，明確業(yè)務(wù)占比，重要程度，目的在于：
（1）明確重點測試對象，安排測試優(yōu)先級
（2）建模，混合場景中，虛擬用戶資源分配，針對不同業(yè)務(wù)功能施加不同的負載。
（3）明確下“需求分析-指標分析”中相關(guān)業(yè)務(wù)功能所需基礎(chǔ)數(shù)據(jù)及數(shù)據(jù)量問題，因為那塊需求分析時可能只是大致估算下，評估指標是否合理，需要認真再分析下。

有些因為特殊原因無法測試（比如第三方非開源加密程序，測試程序無法模擬）的業(yè)務(wù)，測試模型中將會去掉這部分業(yè)務(wù)，或者設(shè)計替代等價方案，比如第三方程序可以使用擋板程序?qū)崿F(xiàn)。

性能測試場景：參照用戶使用習(xí)慣設(shè)計負載場景，比如哪些業(yè)務(wù)的測試腳本一起運行，哪些業(yè)務(wù)有先后順序，運行多少并發(fā)用戶等。比如WMS系統(tǒng)（倉庫管理系統(tǒng)），WMS中都會有盤點功能，此功能就不應(yīng)該與日常功能混合在一起，因為盤點通常都是一個月一次。所以組織測試場景時盡量要與實際業(yè)務(wù)情況一致。

5、編寫計劃

在文檔中明確列出測試范圍、人力投入、持續(xù)時間、工作內(nèi)容、風險評估、風險應(yīng)對策略等。

• 系統(tǒng)概述：簡述系統(tǒng)使命、系統(tǒng)功能，用于給非專業(yè)人士了解系統(tǒng)是做什么的。
• 測試環(huán)境：生產(chǎn)環(huán)境、測試環(huán)境（服務(wù)器+負載機）的硬件架構(gòu)和詳細配置信息。
• 需求分析：需要測試的業(yè)務(wù)模型及其信息采集，性能指標的采集和確定。
• 測試策略：測試目的、測試執(zhí)行的可行性分析、具體的測試手段及測試監(jiān)控策略。
• 測試場景：如何組合業(yè)務(wù)場景進行性能測試。
• 測試準備：包括：測試工具的準備（負載工具、監(jiān)控工具、文檔管理工具）；測試腳本及測試程序準備；測試數(shù)據(jù)準備；測試環(huán)境準備。
• 時間計劃：進行需求分析、測試策略后，就可以相對合理的估算測試資源及耗時。
• 測試組織架構(gòu)：測試相關(guān)干系人，明確不同干系人的工作職責。
• 交付物清單：性能測試計劃、性能測試腳本、性能缺陷報告、性能測試階段性報告、性能測試報告（包括且不僅限于事務(wù)成功率、TPS、硬件性能指標等）。
• 系統(tǒng)風險：風險預(yù)測及風險評估（包括且不僅限于人員風險、軟件風險、進度風險、變更風險、系統(tǒng)風險、數(shù)據(jù)風險、環(huán)境風險），并提出應(yīng)對策略。

6、開發(fā)腳本

錄制腳本或手動開發(fā)，添加固定計時器模擬ThinkTime，增加同步定時器模擬集合點，增加IF條件控制器判斷邏輯，添加后置處理器獲取參數(shù)。腳本注意做斷言？？？，驗證事務(wù)是否成功。
開發(fā)擋板程序，開發(fā)測試工具等。

事務(wù)定義
合理的定義事務(wù)，能夠方便分析耗時（特別是混合業(yè)務(wù)功能場景測試），進而方便分析瓶頸。比如，購買商品，我們可以把下訂單定義為一個事務(wù)，把支付也定義為一個事務(wù)。

7、測試環(huán)境準備

測試環(huán)境包括服務(wù)器和負載機。找出這些：

• 請求順序、請求之間相互調(diào)用關(guān)系。
• 數(shù)據(jù)流向，數(shù)據(jù)是怎么走的，經(jīng)過哪些組件、服務(wù)器等。
• 預(yù)測可能存在性能瓶頸的環(huán)節(jié)（組件、服務(wù)器等）。
• 明確應(yīng)用類型IO型，還是CPU消耗性、內(nèi)存消耗型->弄清楚重點監(jiān)控對象。
• 關(guān)注應(yīng)用是否采用多進程、多線程架構(gòu)->多線程容易造成線程死鎖、數(shù)據(jù)庫死鎖，數(shù)據(jù)不一致等。
• 是否使用集群/是否使用負載均衡。

生產(chǎn)環(huán)境和測試環(huán)境的硬件架構(gòu)和配置需要進行估算，否則結(jié)果會有很大的偏差。了解測試環(huán)境部署和生產(chǎn)環(huán)境部署差異，是否按1:1的比例部署。通常建議測試時先不考慮集群，采用單機測試，測試通過后再考慮使用集群，這樣有個比較，比較能說明問題。

8、測試數(shù)據(jù)準備：

準備被測系統(tǒng)的主數(shù)據(jù)（保證系統(tǒng)能夠正常運行的數(shù)據(jù)，比如論壇版塊、角色、用戶等數(shù)據(jù)）與業(yè)務(wù)數(shù)據(jù)（運行業(yè)務(wù)產(chǎn)生的數(shù)據(jù)，比如訂單；訂單出庫需要庫存數(shù)據(jù)，庫存數(shù)據(jù)也是業(yè)務(wù)數(shù)據(jù)）。

我們知道數(shù)據(jù)量變會引起性能的變化。在制作測試數(shù)據(jù)時，一要注意量，需要準備足夠的存量/歷史業(yè)務(wù)數(shù)據(jù)，二要注意數(shù)據(jù)的分布。比如我們計算出需要并發(fā)100個虛擬用戶，我們至少需要準備100個以上賬號，并對賬號賦予相應(yīng)的權(quán)限（瀏覽、發(fā)帖、刪除、查詢）。

那么準備多少數(shù)據(jù)夠用呢？
往往性能測試需求會要求我們對系統(tǒng)進行定容定量，所以測試過程會經(jīng)歷如圖的曲線變化；我們需要跨過③到達④這個階段，所以至少需要準備在④這個點所需要的用戶賬號。

RT&TPS和Thread的趨勢圖

另外，為了更形象的模擬用戶使用情況，我們會希望使用盡可能多的模擬用戶（即并發(fā)用戶數(shù)），通過ThinkTime來調(diào)節(jié)這些模擬用戶產(chǎn)生的負載（因為，并發(fā)用戶數(shù)=TPS*(ThinkTime+RunTime)。ThinkTime時間越長，所需要的并發(fā)數(shù)越大，請求數(shù)量越多，TPS也會相應(yīng)增加）大小，用戶越多越好。

數(shù)據(jù)制作方法
可以使用工具、SQL或者存儲過程？？？來完成。建議使用SQL，同時還能夠熟悉數(shù)據(jù)庫的物理設(shè)計（索引、字段、范式、反范式等）和ER關(guān)系？？？

9、測試執(zhí)行

測試執(zhí)行是性能測試的關(guān)鍵，同樣的腳本不同執(zhí)行人員得出的結(jié)果可能差異較大。這些差異主要體現(xiàn)在場景設(shè)計與測試執(zhí)行上。

場景設(shè)計
前面已經(jīng)確定了測試模型。場景設(shè)計是根據(jù)測試模型與目標，組織虛擬用戶、組合業(yè)務(wù)種類到一個測試單元。組織測試場景時盡量要與實際業(yè)務(wù)情況一致。

基準測試
采用單業(yè)務(wù)場景、單用戶的方式執(zhí)行腳本。用于驗證測試環(huán)境、測試腳本，以及為后續(xù)的測試執(zhí)行提供性能基準。比如一個登錄系統(tǒng)，如果系統(tǒng)登錄時間為8秒，那么這個系統(tǒng)也就沒必要再進行性能測試，因為它連一般性能都達不到要求。

配置測試
配置測試場景一般為混合場景（多個業(yè)務(wù)同時執(zhí)行），用于幫助分析系統(tǒng)軟、硬件配置是否滿足性能需求指標，優(yōu)化配置使各項資源達到最優(yōu)分配原則。測試過程是一個實驗過程，先是找出不合理配置，然后進行修改，最后進行驗證；周而復(fù)始到配置滿足需求。

負載測試
負載測試的目的是分析性能變化趨勢，找出性能拐點分析性能問題與風險，對系統(tǒng)進行定容定量；為系統(tǒng)優(yōu)化、性能調(diào)整提供數(shù)據(jù)支撐。負載測試分為單場景與混合場景；單場景有利于分析性能問題，因為排除了其他業(yè)務(wù)干擾；混合場景更貼近用戶實際使用習(xí)慣，是一個綜合的性能評估。建議先做單場景測試再做混合場景測試。

負載測試的性能變化曲線圖見前面的 “RT&TPS和Thread的趨勢圖”，①可以理解為單業(yè)務(wù)、單用戶時的系統(tǒng)性能，②通常是我們估算的滿足性能需求的點，③是性能拐點，之后性能變差，在這個點系統(tǒng)吞吐量達到最大，④這個點已經(jīng)過載，吞吐量開始減小。負載測試一般需要找到②③④這三個點，通常會因為一些配置、程序問題而受到干擾，所以執(zhí)行測試也是一個耗時的工作。

穩(wěn)定性測試
穩(wěn)定性測試在正常性能閥值下盡量加大負載，長時間運行，確定系統(tǒng)的軟、硬件環(huán)境是否運行穩(wěn)定。什么是閥值呢？比如響應(yīng)時間要求3s以內(nèi)，3秒就是閥值；比如CPU利用率70%以下，70%就是閥值。假設(shè)滿足性能要求的負載是B，那么穩(wěn)定性測試時負載一般是1.5B~2B。執(zhí)行時采用混合場景，按慣例執(zhí)行時間不低于8小時。時間上越長越好，有些隱藏較深的諸如內(nèi)存溢出的問題是需要長時間運行才能反映出來的。

測試監(jiān)控
測試監(jiān)控

測試執(zhí)行
一般第三方性能測試會有一個測試準入條件（Checklist）。如果是項目組內(nèi)的就沒有這么嚴格了，但基本內(nèi)容不變。
（1）檢查網(wǎng)絡(luò)環(huán)境
確保環(huán)境獨立，不會對生產(chǎn)系統(tǒng)、外部系統(tǒng)等的使用造成影響。
確保環(huán)境可靠，不會因為生產(chǎn)系統(tǒng)、外部系統(tǒng)而影響測試結(jié)果。
為了方便分析問題，排除網(wǎng)絡(luò)IO的影響，測試在局域網(wǎng)中進行。
（2）檢查測試數(shù)據(jù)
確?；A(chǔ)數(shù)據(jù)完整，能夠支持性能測試腳本對業(yè)務(wù)功能的覆蓋。
確保基礎(chǔ)數(shù)據(jù)量，能夠支持性能測試腳本的參數(shù)化要求。
確保存量數(shù)據(jù)量，能夠盡量真實反映系統(tǒng)數(shù)據(jù)環(huán)境。
確保存量數(shù)據(jù)分布，能夠?qū)Y(jié)果施加有意義的影響。
（3）檢查監(jiān)控設(shè)備
監(jiān)控工具是否已經(jīng)準備完畢可用。
（4）腳本檢查
確認腳本能夠模擬業(yè)務(wù)場景。
確認腳本無性能風險不影響測試結(jié)果。
注：具體的測試執(zhí)行詳細見 場景設(shè)計與測試執(zhí)行

10、缺陷管理

對性能測試過程中發(fā)現(xiàn)的缺陷進行管理。

11、性能分析和性能調(diào)優(yōu)

性能測試工程師與開發(fā)人員一起來解決性能問題。

13、測試報告

如何由測試環(huán)境推算生產(chǎn)環(huán)境配置
對于報告人來說，報告的是工作，是對整個測試過程的報告。對于決策層（報告相關(guān)干系人）來說關(guān)心的是結(jié)果，決策層迫切的想知道Yes or No，系統(tǒng)能不能上線，如果不能上線，有什么問題，怎么能夠盡快解決？這兩方面的需求決定了測試報告需要包含以下內(nèi)容。

• 性能測試背景：測試原因，性能測試開展的必要性。
• 性能測試目標：對系統(tǒng)進行定容定量、響應(yīng)時間、配置、穩(wěn)定性等測試，風險評估。
• 性能測試范圍：參考測試計劃中的測試范圍。
• 名詞術(shù)語： 涉及專業(yè)名詞的解釋，參考測試計劃。
• 測試環(huán)境：報告結(jié)果基于的測試環(huán)境，不同的環(huán)境結(jié)果可能大相徑庭。
• 測試數(shù)據(jù)：報告測試數(shù)據(jù)量，參考測試計劃。
• 測試進度：報告測試過程，什么時候做什么工作，比如哪一天執(zhí)行了哪些測試腳本。
• 測試結(jié)果：基準測試、配置測試、負載測試、穩(wěn)定性測試等，全面多方位的報告測試結(jié)果，TPS、ART、事務(wù)成功率、硬件資源使用率（CPU、內(nèi)存、網(wǎng)絡(luò)、IO等）。
• 測試結(jié)論：分析給出測試結(jié)論，系統(tǒng)能否滿足性能要求？存在什么問題？有哪些缺陷？解決了哪些問題？還有哪些問題沒有解決？列出仍沒有解決的系統(tǒng)缺陷。
• 系統(tǒng)風險：報告系統(tǒng)可能存在的風險，幫助決策層應(yīng)對風險。

測試報告要非專業(yè)人士也能看懂，做好指標對比、用圖表表達性能變化趨勢。

14、評審