效能測試需求分析 業務PV量，響應時間、QPS、TPS
阿新 • • 發佈：2018-12-30
一、 效能測試需求分析
1.1 效能測試需求內容
效能測試需求應包括以下內容：
a) 測試場景及用例，用例訪問URL；
b) 目標介面方法的入參、出參；
c) 外部依賴的服務細節；
d) 關鍵資料: 資料量、高峰業務PV量
e) 預期效能指標：響應時間、QPS、TPS等
效能測試需求模板表格參考如下：
效能測試(1) ---效能測試需求收集
1.2 預期效能指標1.2.1資料量
測試環境的資料量，應該跟線上環境保持一致，至少要在一個數量級。
舉例有，中文站線上的每秒登入使用者資料量平時為20個，特殊情況下，每秒為10萬，那麼測試環境要保證正常情況下在20個左右，至少是十的數量級，效能測試特殊情況下，要準備十萬級的資料量，模擬最高併發使用者資料量。
1.2.2高峰業務PV量
1) 二八法
若80%的訪問量集中在20%的時間裡，可用此分析方法，其圖形就是一個正態分佈圖，如下。
具體計算公式為：
tps = (24小時的PV值*80%)/（24*3600*20%）
舉例有，假如中文站每日的訪問量為500萬，其中19:00-23：40，訪問量為400萬，其餘時間段的訪問量很平坦，而且其餘時間段的總訪問量為100萬，那麼就可以用二八法，其計算公式為 tps = (500萬*0.8)/(24*3600*0.2)。
2）簡單峰值法
若在每天的某一時段裡有很大的訪問量，其他時間相對較少，可以用簡單峰值法，其實二八法只是簡單峰值法的一個特例。
具體計算公式為：
tps =(24小時的PV值)/（峰值時間段中的小時數*3600）
舉例有，假如中文站每日的訪問量為500萬，其中17:00-24:00這個時間段裡面訪問量為450萬，其他時間段的訪問量很平緩，那麼，我可以用簡單峰值法近似計算，其計算公式為 tps = 500萬/（（24-17）*3600）
3）無峰值法
若24小時裡的訪問量都是平穩波動的，沒有峰值，那麼可以採用無峰值計算方法，圖形如下。
具體計算公式為：
tps= (24小時的PV值)/（24*3600）
舉例有，假如中文站每日的訪問量為500萬，每小時的訪問量都為20萬左右，那麼，可以用無峰值法來近似計算，其計算公式為 tps = 500萬/(24*3600)。
1.2.3吞吐量
指軟體系統在每單位時間內能處理多少事務/請求/單位資料等，
其與tps的近似計算公式為：（單位為秒）
tps = 這段時間內的總樣本數/（最後一個請求完成的時刻-第一個請求發起的時刻）
可以這樣舉例，假如，在17：58的0 秒發起第一個請求，在18:02分0秒完成最後一個請求，在這4分鐘整的期間，共處理的總的樣本數為1000個，那麼，可以這樣近似計算：
tps = 1000/（4*60）
值得注意的是，因為每個請求之間的空閒值也包含在內了，故tps是有誤差的，而且tps是個平均值。
來源： <http://blog.sina.com.cn/s/blog_639aa08501010kkr.html>
需求收集之後，我們已經從效能需求文件中提取出了業務效能測試指標，主要包括PV到TPS的轉換以及響應時間要求，接下來我們需要進行進一步的需求分析過程。
1瞭解系統架構、明確壓力流向
例如統一訂購平臺的系統架構圖：
理解架構圖中各個節點的功能與互動關係，通過系統架構圖我們能看到壓力的入口，即oop應用。請求從oop發起，從udb取到會員資料後，通過dubbo介面，呼叫訂購服務層提供的各種服務，訂購服務層所需資料全部從對應cache中取。因此，主幹壓力流向可得知：
Oop—>udb
Oop—>dubbo—>訂購服務層—>cache
然後結合需求文件，根據具體業務場景，確定各分支壓力流向，比如有的業務場景需要從pc2取得使用者的服務記錄，有的業務場景需要付款則需要去帳戶中心取得帳戶資訊，則新增的壓力流向如下：
Oop—>dubbo—>pc2—>cache
Oop—>dubbo—>帳戶中心
針對每一個測試場景，都要根據系統架構圖進行上述分析，明確了各場景的壓力流向，即明確了效能測試過程中的監控物件。
監控物件確定後，需要進一步分析明確測試重點，如上例，我們關注的重點是網站的oop應用，因為平臺的udb、pc2，crm的服務訂購中心，都有各自做過介面效能測試。或者有的所用應用功能是線上已有的，並沒有修改變動，如帳戶中心。明確測試重點，將有助於我們進行測試環境相關的測試策略的選擇。
2 明確測試環境2.1 伺服器數量確定
根據系統架構圖，我們得到了專案中所涉及的環境。眾所周知，測試環境越接近生產環境，則測試結果越精確。但通常我們會碰到伺服器資源緊張，或者所用應用為外部門的外圍環境，搭建方法複雜。此時我們面臨兩種選擇，要麼使用功能環境，要麼mock掉該環境。建議不要選擇前者，可以多個壓力流向小的應用公用一臺效能伺服器。
2.2 伺服器配置確定
還是一條不變的原則：測試環境軟硬體配置儘量與生產環境保持一致。
機器的效能需求：32位or64位；4核or8核；是否要求同一網段
測試環境軟體架構確定（jdk、apache、jboss版本、jvm引數）：與線上環境一致，重點關注jvm引數配置，確保與線上一致。
效能測試關注的主要硬體配置及OS引數如下表：
主機/ip
硬體配置
作業系統及引數調整
10.20.133.165
統一訂購層應用伺服器
機型
PowerEdge 1950
Linux 2.6.18-92.el5
64位作業系統
CPU
Intel(R) Xeon(R) CPU E5410 @ 2.33GHz * 8
記憶體
10G
網路
1000M
應用伺服器配置檢查中常用的linux指令：
檢視機型: dmidecode --type 1|grep "Product Name"
檢視CPU: cat /proc/cpuinfo
檢視記憶體：free -mt
紅框內即為本機記憶體總量
檢視網絡卡：
1）ifconfig 檢查伺服器連線的哪塊網絡卡（ethx）
上圖紅框內即為當前活動的網絡卡
2）ethtool ethx 檢查網絡卡詳細資訊（ethx為ifconfig檢查出來的網絡卡編號，如上圖就為eth0）
上圖紅框內即為當前網絡卡頻寬（雙工模式）
檢視作業系統：
uanme -a 檢視所有資訊
uname -o, --operating-system GNU/Linux
-r, --kernel-release 2.6.18-128.el5（作業系統核心版本）
-i, --hardware-platform x86_64（硬體版本）
-o, --operating-system x86_64（作業系統版本）
3 關鍵業務資料量分析3.1 資料量需求確認
1) 資料量是指的效能測試需要考慮的資料總量和資料型別。
例如在offer資料量為30w的DB中查詢和在offer資料量為1000w的DB中查詢，效能表現一定是不一樣的。我們需要考慮，現階段的資料量等級和未來發展趨勢下的資料量等級。有的時候資料量也是程式分支邏輯，所以這點就必須詳細考慮了。
2) 儲存分佈指的資料來源的分佈情況，是分散式分佈還是單臺分佈；是search分佈還是DB分佈，等等。例如offer拆分專案的效能測試就需要綜合考慮Oracle單表、Oracle16張表、mysql128張表的使用場景
3) 基本要求：測試資料庫資料量要與線上資料量保持一個數量級。
3.2 造資料方法確定
根據數量級的需要，可以採用不同的方法，大致有以下幾種：
1） 找DBA幫忙導線上/測試庫資料；
2） 用datafactory/sql直接插資料庫；（檢視datafactory文件）
介面如圖，具體使用方法問google
3） 用jmeter/LR/ruby等指令碼走正常業務流造資料。（檢視各指令碼錄製方法）
3.3劃分測試場景、明確測試用例
測試用例的產生需要考慮以下幾方面：
1) 測試頁面和業務邏輯，也就是業務對應的功能點
注意，效能測試的測試用例也需要專一性，也就是對應單個測試功能點。
因為我們監控的是每個事物的響應時間，功能點需要單一。
2) 壓力持續時間
壓力持續時間指的是給伺服器施加多長時間的壓力。
這個時間，我們會結合測試場景，對壓力時間做一定的控制。
ü 如果測試的是高峰場景，時間一般最少為1個小時；
ü 如果測試的是穩定性場景，時間一般最少要求8小時；
3) 併發數
不要混淆併發和TPS的關係。
併發數指的是同時有多少使用者（執行緒）在對伺服器施加壓力，是量化的給伺服器的壓力；而TPS指的是伺服器每秒鐘能夠處理的事物數，是伺服器處理能力的體現。
來源： <http://blog.sina.com.cn/s/blog_639aa08501010kkx.html>
1.1 效能測試需求內容
效能測試需求應包括以下內容：
a) 測試場景及用例，用例訪問URL；
b) 目標介面方法的入參、出參；
c) 外部依賴的服務細節；
d) 關鍵資料: 資料量、高峰業務PV量
e) 預期效能指標：響應時間、QPS、TPS等
效能測試需求模板表格參考如下：
效能測試(1) ---效能測試需求收集
1.2 預期效能指標1.2.1資料量
測試環境的資料量，應該跟線上環境保持一致，至少要在一個數量級。
舉例有，中文站線上的每秒登入使用者資料量平時為20個，特殊情況下，每秒為10萬，那麼測試環境要保證正常情況下在20個左右，至少是十的數量級，效能測試特殊情況下，要準備十萬級的資料量，模擬最高併發使用者資料量。
1.2.2高峰業務PV量
1) 二八法
若80%的訪問量集中在20%的時間裡，可用此分析方法，其圖形就是一個正態分佈圖，如下。
具體計算公式為：
tps = (24小時的PV值*80%)/（24*3600*20%）
舉例有，假如中文站每日的訪問量為500萬，其中19:00-23：40，訪問量為400萬，其餘時間段的訪問量很平坦，而且其餘時間段的總訪問量為100萬，那麼就可以用二八法，其計算公式為 tps = (500萬*0.8)/(24*3600*0.2)。
2）簡單峰值法
若在每天的某一時段裡有很大的訪問量，其他時間相對較少，可以用簡單峰值法，其實二八法只是簡單峰值法的一個特例。
具體計算公式為：
tps =(24小時的PV值)/（峰值時間段中的小時數*3600）
舉例有，假如中文站每日的訪問量為500萬，其中17:00-24:00這個時間段裡面訪問量為450萬，其他時間段的訪問量很平緩，那麼，我可以用簡單峰值法近似計算，其計算公式為 tps = 500萬/（（24-17）*3600）
3）無峰值法
若24小時裡的訪問量都是平穩波動的，沒有峰值，那麼可以採用無峰值計算方法，圖形如下。
具體計算公式為：
tps= (24小時的PV值)/（24*3600）
舉例有，假如中文站每日的訪問量為500萬，每小時的訪問量都為20萬左右，那麼，可以用無峰值法來近似計算，其計算公式為 tps = 500萬/(24*3600)。
1.2.3吞吐量
指軟體系統在每單位時間內能處理多少事務/請求/單位資料等，
其與tps的近似計算公式為：（單位為秒）
tps = 這段時間內的總樣本數/（最後一個請求完成的時刻-第一個請求發起的時刻）
可以這樣舉例，假如，在17：58的0 秒發起第一個請求，在18:02分0秒完成最後一個請求，在這4分鐘整的期間，共處理的總的樣本數為1000個，那麼，可以這樣近似計算：
tps = 1000/（4*60）
值得注意的是，因為每個請求之間的空閒值也包含在內了，故tps是有誤差的，而且tps是個平均值。
來源： <http://blog.sina.com.cn/s/blog_639aa08501010kkr.html>
需求收集之後，我們已經從效能需求文件中提取出了業務效能測試指標，主要包括PV到TPS的轉換以及響應時間要求，接下來我們需要進行進一步的需求分析過程。
1瞭解系統架構、明確壓力流向
例如統一訂購平臺的系統架構圖：
理解架構圖中各個節點的功能與互動關係，通過系統架構圖我們能看到壓力的入口，即oop應用。請求從oop發起，從udb取到會員資料後，通過dubbo介面，呼叫訂購服務層提供的各種服務，訂購服務層所需資料全部從對應cache中取。因此，主幹壓力流向可得知：
Oop—>udb
Oop—>dubbo—>訂購服務層—>cache
然後結合需求文件，根據具體業務場景，確定各分支壓力流向，比如有的業務場景需要從pc2取得使用者的服務記錄，有的業務場景需要付款則需要去帳戶中心取得帳戶資訊，則新增的壓力流向如下：
Oop—>dubbo—>pc2—>cache
Oop—>dubbo—>帳戶中心
針對每一個測試場景，都要根據系統架構圖進行上述分析，明確了各場景的壓力流向，即明確了效能測試過程中的監控物件。
監控物件確定後，需要進一步分析明確測試重點，如上例，我們關注的重點是網站的oop應用，因為平臺的udb、pc2，crm的服務訂購中心，都有各自做過介面效能測試。或者有的所用應用功能是線上已有的，並沒有修改變動，如帳戶中心。明確測試重點，將有助於我們進行測試環境相關的測試策略的選擇。
2 明確測試環境2.1 伺服器數量確定
根據系統架構圖，我們得到了專案中所涉及的環境。眾所周知，測試環境越接近生產環境，則測試結果越精確。但通常我們會碰到伺服器資源緊張，或者所用應用為外部門的外圍環境，搭建方法複雜。此時我們面臨兩種選擇，要麼使用功能環境，要麼mock掉該環境。建議不要選擇前者，可以多個壓力流向小的應用公用一臺效能伺服器。
2.2 伺服器配置確定
還是一條不變的原則：測試環境軟硬體配置儘量與生產環境保持一致。
機器的效能需求：32位or64位；4核or8核；是否要求同一網段
測試環境軟體架構確定（jdk、apache、jboss版本、jvm引數）：與線上環境一致，重點關注jvm引數配置，確保與線上一致。
效能測試關注的主要硬體配置及OS引數如下表：
主機/ip
硬體配置
作業系統及引數調整
10.20.133.165
統一訂購層應用伺服器
機型
PowerEdge 1950
Linux 2.6.18-92.el5
64位作業系統
CPU
Intel(R) Xeon(R) CPU E5410 @ 2.33GHz * 8
記憶體
10G
網路
1000M
應用伺服器配置檢查中常用的linux指令：
檢視機型: dmidecode --type 1|grep "Product Name"
檢視CPU: cat /proc/cpuinfo
檢視記憶體：free -mt
紅框內即為本機記憶體總量
檢視網絡卡：
1）ifconfig 檢查伺服器連線的哪塊網絡卡（ethx）
上圖紅框內即為當前活動的網絡卡
2）ethtool ethx 檢查網絡卡詳細資訊（ethx為ifconfig檢查出來的網絡卡編號，如上圖就為eth0）
上圖紅框內即為當前網絡卡頻寬（雙工模式）
檢視作業系統：
uanme -a 檢視所有資訊
uname -o, --operating-system GNU/Linux
-r, --kernel-release 2.6.18-128.el5（作業系統核心版本）
-i, --hardware-platform x86_64（硬體版本）
-o, --operating-system x86_64（作業系統版本）
3 關鍵業務資料量分析3.1 資料量需求確認
1) 資料量是指的效能測試需要考慮的資料總量和資料型別。
例如在offer資料量為30w的DB中查詢和在offer資料量為1000w的DB中查詢，效能表現一定是不一樣的。我們需要考慮，現階段的資料量等級和未來發展趨勢下的資料量等級。有的時候資料量也是程式分支邏輯，所以這點就必須詳細考慮了。
2) 儲存分佈指的資料來源的分佈情況，是分散式分佈還是單臺分佈；是search分佈還是DB分佈，等等。例如offer拆分專案的效能測試就需要綜合考慮Oracle單表、Oracle16張表、mysql128張表的使用場景
3) 基本要求：測試資料庫資料量要與線上資料量保持一個數量級。
3.2 造資料方法確定
根據數量級的需要，可以採用不同的方法，大致有以下幾種：
1） 找DBA幫忙導線上/測試庫資料；
2） 用datafactory/sql直接插資料庫；（檢視datafactory文件）
介面如圖，具體使用方法問google
3） 用jmeter/LR/ruby等指令碼走正常業務流造資料。（檢視各指令碼錄製方法）
3.3劃分測試場景、明確測試用例
測試用例的產生需要考慮以下幾方面：
1) 測試頁面和業務邏輯，也就是業務對應的功能點
注意，效能測試的測試用例也需要專一性，也就是對應單個測試功能點。
因為我們監控的是每個事物的響應時間，功能點需要單一。
2) 壓力持續時間
壓力持續時間指的是給伺服器施加多長時間的壓力。
這個時間，我們會結合測試場景，對壓力時間做一定的控制。
ü 如果測試的是高峰場景，時間一般最少為1個小時；
ü 如果測試的是穩定性場景，時間一般最少要求8小時；
3) 併發數
不要混淆併發和TPS的關係。
併發數指的是同時有多少使用者（執行緒）在對伺服器施加壓力，是量化的給伺服器的壓力；而TPS指的是伺服器每秒鐘能夠處理的事物數，是伺服器處理能力的體現。
來源： <http://blog.sina.com.cn/s/blog_639aa08501010kkx.html>