一、 性能測試需求分析

需求收集之后，我們已經(jīng)從性能需求文檔中提取出了業(yè)務性能測試指標，主要包括PV到TPS的轉換以及響應時間要求，接下來我們需要進行進一步的需求分析過程。

1了解系統(tǒng)架構、明確壓力流向

例如統(tǒng)一訂購平臺的系統(tǒng)架構圖：

理解架構圖中各個節(jié)點的功能與交互關系，通過系統(tǒng)架構圖我們能看到壓力的入口，即oop應用。請求從oop發(fā)起，從udb取到會員數(shù)據(jù)后，通過dubbo接口，調用訂購服務層提供的各種服務，訂購服務層所需數(shù)據(jù)全部從對應cache中取。因此，主干壓力流向可得知：

Oop—>udb

Oop—>dubbo—>訂購服務層—>cache

然后結合需求文檔，根據(jù)具體業(yè)務場景，確定各分支壓力流向，比如有的業(yè)務場景需要從pc2取得用戶的服務記錄，有的業(yè)務場景需要付款則需要去帳戶中心取得帳戶信息，則新增的壓力流向如下：

Oop—>dubbo—>pc2—>cache

Oop—>dubbo—>帳戶中心

針對每一個測試場景，都要根據(jù)系統(tǒng)架構圖進行上述分析，明確了各場景的壓力流向，即明確了性能測試過程中的監(jiān)控對象。

監(jiān)控對象確定后，需要進一步分析明確測試重點，如上例，我們關注的重點是網(wǎng)站的oop應用，因為平臺的udb、pc2，crm的服務訂購中心，都有各自做過接口性能測試。或者有的所用應用功能是線上已有的，并沒有修改變動，如帳戶中心。明確測試重點，將有助于我們進行測試環(huán)境相關的測試策略的選擇。

2 明確測試環(huán)境

2.1 服務器數(shù)量確定

根據(jù)系統(tǒng)架構圖，我們得到了項目中所涉及的環(huán)境。眾所周知，測試環(huán)境越接近生產環(huán)境，則測試結果越精確。但通常我們會碰到服務器資源緊張，或者所用應用為外部門的外圍環(huán)境，搭建方法復雜。此時我們面臨兩種選擇，要么使用功能環(huán)境，要么mock掉該環(huán)境。建議不要選擇前者，可以多個壓力流向小的應用公用一臺性能服務器。

2.2 服務器配置確定

還是一條不變的原則：測試環(huán)境軟硬件配置盡量與生產環(huán)境保持一致。

機器的性能需求：32位or64位；4核or8核；是否要求同一網(wǎng)段

測試環(huán)境軟件架構確定(jdk、apache、jboss版本、jvm參數(shù))：與線上環(huán)境一致，重點關注jvm參數(shù)配置，確保與線上一致。

性能測試關注的主要硬件配置及OS參數(shù)如下表：

主機/ip

硬件配置

操作系統(tǒng)及參數(shù)調整

10.20.133.165

統(tǒng)一訂購層應用服務器

機型

PowerEdge 1950

Linux? 2.6.18-92.el5

64位操作系統(tǒng)

CPU

Intel(R) Xeon(R)

CPU? E5410? @ 2.33GHz *

8

內存

10G

網(wǎng)絡

1000M

應用服務器配置檢查中常用的linux指令：

查看機型: dmidecode --type 1|grep "Product Name"

查看CPU: cat /proc/cpuinfo

查看內存：free -mt

紅框內即為本機內存總量

查看網(wǎng)卡：

1)ifconfig 檢查服務器連接的哪塊網(wǎng)卡(ethx)

上圖紅框內即為當前活動的網(wǎng)卡

2)ethtool ethx 檢查網(wǎng)卡詳細信息(ethx為ifconfig檢查出來的網(wǎng)卡編號，如上圖就為eth0)

上圖紅框內即為當前網(wǎng)卡帶寬(雙工模式)

查看操作系統(tǒng)：

uanme -a 查看所有信息

uname -o,

--operating-system

GNU/Linux

-r,

--kernel-release

2.6.18-128.el5(操作系統(tǒng)內核版本)

-i, --hardware-platform

x86_64(硬件版本)

-o,

--operating-system

x86_64(操作系統(tǒng)版本)

3

關鍵業(yè)務數(shù)據(jù)量分析

3.1 數(shù)據(jù)量需求確認

1) 數(shù)據(jù)量是指的性能測試需要考慮的數(shù)據(jù)總量和數(shù)據(jù)類型。

例如在offer數(shù)據(jù)量為30w的DB中查詢和在offer數(shù)據(jù)量為1000w的DB中查詢，性能表現(xiàn)一定是不一樣的。我們需要考慮，現(xiàn)階段的數(shù)據(jù)量等級和未來發(fā)展趨勢下的數(shù)據(jù)量等級。有的時候數(shù)據(jù)量也是程序分支邏輯，所以這點就必須詳細考慮了。

2)

存儲分布指的數(shù)據(jù)源的分布情況，是分布式分布還是單臺分布；是search分布還是DB分布，等等。例如offer拆分項目的性能測試就需要綜合考慮Oracle單表、Oracle16張表、mysql128張表的使用場景

3)

基本要求：測試數(shù)據(jù)庫數(shù)據(jù)量要與線上數(shù)據(jù)量保持一個數(shù)量級。

3.2 造數(shù)據(jù)方法確定

根據(jù)數(shù)量級的需要，可以采用不同的方法，大致有以下幾種：

1) 找DBA幫忙導線上/測試庫數(shù)據(jù)；

2) 用datafactory/sql直接插數(shù)據(jù)庫；(查看datafactory文檔)

界面如圖，具體使用方法問google

3) 用jmeter/LR/ruby等腳本走正常業(yè)務流造數(shù)據(jù)。(查看各腳本錄制方法)

3.3劃分測試場景、明確測試用例

測試用例的產生需要考慮以下幾方面：

1)

測試頁面和業(yè)務邏輯，也就是業(yè)務對應的功能點

注意，性能測試的測試用例也需要專一性，也就是對應單個測試功能點。

因為我們監(jiān)控的是每個事物的響應時間，功能點需要單一。

2)

壓力持續(xù)時間

壓力持續(xù)時間指的是給服務器施加多長時間的壓力。

這個時間，我們會結合測試場景，對壓力時間做一定的控制。

ü

如果測試的是高峰場景，時間一般最少為1個小時；

ü

如果測試的是穩(wěn)定性場景，時間一般最少要求8小時；

3)

并發(fā)數(shù)

不要混淆并發(fā)和TPS的關系。

并發(fā)數(shù)指的是同時有多少用戶(線程)在對服務器施加壓力，是量化的給服務器的壓力；而TPS指的是服務器每秒鐘能夠處理的事物數(shù)，是服務器處理能力的體現(xiàn)。

總結

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

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