一、 性能測試需求分析

需求收集之后，我們已經從性能需求文檔中提取出了業務性能測試指標，主要包括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指的是服務器每秒鐘能夠處理的事物數，是服務器處理能力的體現。

總結

以上是生活随笔為你收集整理的性能测试服务器数量与线上数量不同,性能需求分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。