性能測試（性能分析）

 1、需求分析

1. 測試目的

爲何測？目的在於測試系統相關性能可否知足業務需求。一般分如下兩種狀況：

1）新項目上線

2）老項目優化

若是是老項目優化，可考慮是否存有歷史測試方案，若是有能夠參考，或許能夠省事不少。

2. 測試對象

要測啥？

測試對象能夠歸結爲「業務功能」。測試前，須要瞭解咱們須要測試的業務功能（不深刻細節）有哪些，好比「購買商品」、「寄送快遞」。

有沒有必要測？

需求來源哪裏？，有沒有數據支撐測試這個需求的必要性？

一般，能夠從如下幾個方面考慮：

1）是否核心功能，是否要求嚴格的質量

2）是否經常使用、高頻使用的功能

3）可能佔用系統較多資源的功能

4）使用人數多仍是少

5）在線人數多仍是少

3. 拆分對象

先從業務上來分，實現這個完整的功能包含哪些流程、環節

舉例：購買商品

登陸->搜索商品->提交訂單->支付訂單->退出

4. 指標分析

分析性能需求指標（如「支持300人併發登陸」）是否合理

有必要測試這個需求，考慮需求指標是否合理？有沒有數據支撐？

一般，支撐數據能夠從如下方面考慮：

1）採樣時間段內系統使用人數

2）採樣時間段內系統在線人數

3）採樣時間段內系統(頁面)訪問量

4）採樣時間段內請求數

....

經常使用分析思路：

1）2/8法則

2/8法則：80%的業務量在20%的時間裏完成。這裏，業務量泛指訪問量，請求數，數據量等

2）正態分佈

3）按比例倍增

4）響應時間2-5-8原則

就是說，通常狀況下，當用戶可以在2秒之內獲得響應時，會感受系統的響應很快；當用戶在2-5秒之間獲得響應時，會趕忙系統的響應速度還能夠；當用戶在5-8秒之內獲得響應時，會趕忙系統的速度很慢，可是還能夠接受；而當用戶在超過8秒後仍然沒法獲得響應時，會感受系統糟糕透了，或者認爲系統已經失去響應。

注意：這個要根據實際狀況，有些狀況下時間長點也是能夠接受的，比如12306

舉例：

某公司後臺監控，根據一段時間的採樣數據，分析得出日高峯時段(11:00-14:00)用戶下單請求數平均爲1000，峯值爲1500，根據這個計算併發請求數

時段：3個小時 -> 3 x 60 x 60 = 1080s

業務量：1500

吞吐量：1500 * 80% / (1080 * 20%) = 5.56請求數/s

假設用戶下單遵循正態分佈，那麼併發請求數峯值會確定大於上述估算的吞吐量

注意:

一、2/8原則計算的結果並不是在線併發用戶數，是系統要達到的處理能力（吞吐量）

二、若是要求更高系統性能，根據實際狀況，也能夠考慮1/9原則或其它更嚴格的算法

三、以上估值只是大體的估算，不是精確值

舉例：

想了下，暫時沒想到啥好的例子，大體就說一些涉及到數據量的性能測試，好比報表統計，或者是大數據挖掘，查詢等，怎麼去估算數據量？

數據生命週期：

通常來講，數據都是有必定的生命週期的，時間的選取須要結合數據週期考慮。這裏假設3年後系統性能仍然須要知足業務需求。

數據增加率：

若是是老項目，能夠考慮對應功能主表歷史數據存放狀況

這裏假設按年統計，好比第一年 10000，第二年 15000，第三年 20000，第四年25000，那麼咱們得出，以第一年爲基準，數據增加率分別爲 0.5，1，1.5，每一年在上一年的基礎上，以5000的速度增加

預估3年後，數據增加率爲 3，須要測試數據量爲 （1+3）x 10000 = 40000

注意：

一、實際數據通常是沒上面舉例那麼規律的，只能大體估算數據增加率。

二、一些大數據量的性能測試除了和數據量相關，還涉及到數據分佈等，好比查詢，構造數據時須要結合實際，儘可能貼近實際。

三、不一樣業務模塊，涉及表不同，數據量要求也是不同的，須要有區別的對待。

若是是新項目，那就比較不肯定了，除非能收集相關數據。

2、系統分析

結合需求分析中第3點，分析系統架構。從功能實現上來看，怎麼實現這個完整功能的。一般這些業務功能操做都對應着一個或多個請求(可能能是不一樣類型的請求，好比http, mysql等)，咱們要作的是找出這些：

1）請求順序、請求之間相互調用關係

2）數據流向，數據是怎麼走的，通過哪些組件、服務器等

3）預測可能存在性能瓶頸的環節（組件、服務器等）

4）明確應用類型 IO型，仍是CPU消耗性、內存消耗型-> 弄清楚重點監控對象

5）關注應用是否採用多進程、多線程架構-> 多線程容易形成線程死鎖、數據庫死鎖，數據不一致等

6）是否使用集羣/是否使用負載均衡

瞭解測試環境部署和生產環境部署差別，是否按1:1的比例部署

一般建議測試時先不考慮集羣，採用單機測試，測試經過後再考慮使用集羣，這樣有個比較，比較能說明問題

參考閱讀「淺談web網站架構演變過程 」：http://blog.csdn.net/qiaqia609/article/details/50809383

3、業務分析

1）明確要測試的功能業務中，功能業務佔比，重要程度。

目的在於

<1>明確重點測試對象，安排測試優先級

<2>建模，混合場景中，虛擬用戶資源分配，針對不一樣業務功能施加不一樣的負載。

2）明確下「需求分析-指標分析」中相關業務功能所需基礎數據及數據量問題，由於那塊需求分析時可能只是大體估算下，評估指標是否合理，須要認真再分析下

4、用例設計

1）用例設計

一般是基於場景的測試用例設計

<1> 單業務功能場景

運行測試期間，全部虛擬用戶只執行同一種業務功能某個環節、操做

<2> 混合業務功能場景

運行測試期間，部分虛擬用戶執行某種業務的某個環節操做，部分虛擬用戶執行該業務功能的其它環節

或者

運行測試期間，部分虛擬用戶執行某種業務功能，部分虛擬用戶執行其它業務功能

注：這裏用例沒說到多少用戶去跑，跑多久等，這裏只是把他看成相同場景用例下的的一組組測試數據了。

2）事務定義

根據用例合理的定義事務，方便分析耗時（特別是混合業務功能場景測試），進而方便分析瓶頸。

好比，購買商品，咱們能夠把下訂單定義爲一個事務，把支付也定義爲一個事務。

3）場景監控對象

針對每條用例，結合「系統分析」第4）點，明確可能的壓力點（好比數據庫、WEB服務器），須要監控的對象，好比tps，耗時，CPU，內存，I/O等

5、測試策略

1）先進行混合業務功能場景的測試，在考慮進行測試單業務功能場景的測試

2）負載測試 -> 壓力測試-> 穩定性測試-> 強度測試

注：若是測試穩定性，時間建議至少8小時；

3）逐步加壓

好比開始前5分鐘，20個用戶，而後每隔5分鐘，增長20個用戶。

好處：不只比較真實的模擬現實環境，並且在性能指標比較模糊，且不知道服務器處理能力的狀況下，能夠幫咱們肯定一個大體基準，由於一般狀況下，隨着用戶數的不斷增長，服務器壓力也會隨着增長，若是服務器不夠強大，那麼就會出現不能及時處理請求、處理請求失敗的狀況下，對應的運行結果圖形中，運行曲線也會出現對應的形態，好比從本來程一條穩定直線的狀況，到忽然極限降低、開始上下波動等，經過分析咱們就能得出服務器大體處理能力，供後續測試參考。

4）單點併發

好比使用集合點，單獨針對某個環節的併發測試，一般是針對某個環節的性能調優時使用。

常識：

a) 負載測試

保證系統能正常運行(一般是知足某些系統性能指標)的前提下，讓被測對象承擔不一樣的工做量，以評估被測對象的最大處理能力及存在缺陷而進行的測試

b) 壓力測試

不保證系統可否正常運行的前提下，讓被測對象承擔不一樣工做量，以評估被測對象能提供的最大處理能力及存在缺陷而進行的測試

c) 穩定性測試

測試系統的長期穩定運行的能力。同疲勞強度測試的區別是，穩定性測試的壓力強度較小，通常趨向於客戶現場平常狀態下的壓力強度，固然在經過時間不能保證穩定性的狀態下，須要加大壓力強度來測試，此時的壓力強度則會高於正常值。

d) 強度測試

一般模擬系統在較差、異常資源配置下運行，如人爲下降系統工做環境所須要的資源,如網絡帶寬,系統內存,數據鎖等等,以評估被測對象在資源不足的狀況下的工做狀態

注：疲勞強度測試是一類特殊的強度測試，主要測試系統長時間運行後的性能表現，例如7x24小時的壓力測試。

6、工具選取

1）協議分析

通常性能測試工具都是基於協議開發的，因此先要明確應用使用的協議

2）工具選取

1）類型

開源工具、收費工具、自研工具

2）分析工具

<1> 理解工具實現原理

<2> 採用用異步仍是同步

常識：

1．同步請求：發出一個調用請求，在沒有獲得結果以前，該調用就不返回。

2.異步請求：發出一個調用請求，在沒有獲得請求結果以前，該調用可當即返回。該調用請求的處理者在處理完成後經過狀態、通知和回調等來通知調用者。

<3> 使用長鏈接仍是短鏈接

7、 軟件配置

1）操做系統

內核版本、32 or 64位?

2）應用版本

應用版本要和線上保持一致，特別是中間件、組件等的版本，由於不一樣版本，其性能可能不同

3）參數配置

<1> 負載均衡、反向代理參數配置

<2> Web服務器參數配置

<3> 數據庫服務器參數配置

8、網絡分析

1）網絡路由

一般爲了排除網絡型瓶頸，一般建議在局域網下進行測試。

一般，這裏個人分析思路是這樣的：

<1> 檢查hosts文件的配置

從終端壓測機(負載生成機)開始，到請求目的服務器器，機器的hosts文件配置

一般，hosts文件位於以下：

Windows：C:\Windows\System32\drivers\etc\hosts

Unix/Linux：/etc/hosts

小常識：

一、一般域名訪問站點，首先要經過DNS域名服務器把網絡域名（形如www.xxx.com）解析成XXX.XXX.XXX.XXX的IP地址，而後繼續後續訪問。

二、hosts存放了域名和ip地址的映射關係，以下

 

使用hosts能夠加快域名解析，在進行DNS請求之前，系統會先檢查本身的hosts文件中是否有這個地址映射關係，若是有則把域名解析爲映射的IP地址，不請求網絡上的DNS服務器，若是沒有再向已知的DNS 服務器提出域名解析。也就是說hosts的請求級別比DNS高，可加快域名解析。

<2> 檢查DNS配置

不一樣DNS，其速度和準確率是不同的，好比114.114.114.114速度遠比8.8.8.8快，若是有用到DNS（特別是壓測機），須要考慮下是否適當

<3> 確保路由正確設置

2）網絡帶寬

若是沒條件在局域網下測試，可能須要估算所需大體帶寬。

若是測試時是基於UI層操做的操做，那麼得估算頁面平均大小，這個能夠經過瀏覽器自帶工具查看打開單個頁面服務器返回的請求數據大小。若是是測試時是基於接口層的請求測試，能夠經過工具查看服務器響應數據大小。

而後根據採集的頁面PV峯值、請求數峯值進行計算。

假設在 PV峯值、請求數峯值 = 1000，峯值時段：8:00 - 12:00，平均頁面、請求大小 200k

帶寬 = 1000 x 80% / (20% x 4 x 3600s) x 200KB x /1024 x 8bit ,單位MBps

注意： 這裏涉及到瀏覽器緩存等因素，估值可能不許，大體估算。

9、硬件配置

1) CPU

型號，頻率，核數

2) 內存

3) 磁盤

不一樣磁盤類型，讀寫速率不同

4) 網卡

不一樣網卡，其傳輸速率也不同

注意：硬件配置最好和生產環境的配置保持一致

10、性能監控

略

注意：

1） 這裏監控不只僅是服務器自身性能指標監控，如cpu，還包括事務耗時監控等

2） 須要記錄測試前各個性能指標數據，方便後續測試對比

11、 實施測試

略

12、 結果分析

若是是性能調優，還需同上一個版本的性能測試結果對比

略