效能測試需求應包括以下內容：
a) 測試場景及用例，用例訪問url；
b) 目標介面方法的入參、出參；
c) 外部依賴的服務細節；
d) 關鍵資料: 資料量、高峰業務pv量
e) 預期效能指標：響應時間、qps、tps等
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是個平均值。
需求收集之後，我們已經從效能需求文件中提取出了業務效能測試指標，主要包括pv到tps的轉換以及響應時間要求，接下來我們需要進行進一步的需求分析過程。
例如統一訂購平台的系統架構圖：
理解架構圖中各個節點的功能與互動關係，通過系統架構圖我們能看到壓力的入口，即oop應用。請求從oop發起，從udb取到會員資料後，通過dubbo介面，呼叫訂購服務層提供的各種服務，訂購服務層所需資料全部從對應cache中取。因此，主幹壓力流向可得知：
oop—>udb
oop—>dubbo—>訂購服務層—>cache
然後結合需求文件，根據具體業務場景，確定各分支壓力流向，比如有的業務場景需要從pc2取得使用者的服務記錄，有的業務場景需要付款則需要去帳戶中心取得帳戶資訊，則新增的壓力流向如下：
oop—>dubbo—>pc2—>cache
oop—>dubbo—>帳戶中心
針對每乙個測試場景，都要根據系統架構圖進行上述分析，明確了各場景的壓力流向，即明確了效能測試過程中的監控物件。
監控物件確定後，需要進一步分析明確測試重點，如上例，我們關注的重點是**的oop應用，因為平台的udb、pc2，crm的服務訂購中心，都有各自做過介面效能測試。或者有的所用應用功能是線上已有的，並沒有修改變動，如帳戶中心。明確測試重點，將有助於我們進行測試環境相關的測試策略的選擇。
2.1 伺服器數量確定
根據系統架構圖，我們得到了專案中所涉及的環境。眾所周知，測試環境越接近生產環境，則測試結果越精確。但通常我們會碰到伺服器資源緊張，或者所用應用為外部門的外圍環境，搭建方法複雜。此時我們面臨兩種選擇，要麼使用功能環境，要麼mock掉該環境。建議不要選擇前者，可以多個壓力流向小的應用公用一台效能伺服器。
2.2 伺服器配置確定
還是一條不變的原則：測試環境軟硬體配置盡量與生產環境保持一致。
機器的效能需求：32位or64位；4核or8核；是否要求同一網段
效能測試關注的主要硬體配置及os引數如下表：
主機/ip
硬體配置
作業系統及引數調整
10.20.133.165
統一訂購層應用伺服器
機型poweredge 1950
linux 2.6.18-92.el5
64位作業系統
cpuintel(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.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指的是伺服器每秒鐘能夠處理的事物數，是伺服器處理能力的體現。
效能需求分析
通過技術的手段模擬大量使用者同時訪問被測應用，觀察 記錄和分析系統的各項效能指標的過程。評估系統的效能瓶頸，系統的最大使用者負載能力 1 能夠有效評估系統的效能指標，用於系統的效能評估2 能夠識別系統的效能瓶頸，協助效能調優3 能夠指導突發流量承載方案的制定4 能夠用於系統運維成本的預算 測試 根據...
效能測試 效能需求分析
乙個真實的需求 測試某系統切換成https協議之後效能的下降情況 需求分析 1 對比 http https 2 求出http協議下的效能 3 求出https協議下的效能 4 求出兩者的差異 5 確定效能指標 tps 6 測試報告裡體現 tps的變化 測試策略 1 基準測試 1.1http作為基準 1...
政務專案 效能需求分析
在進行效能測試之前，我們需要先對效能需求進行分析，得出我們測試的依據，同時也是錄製指令碼的方向。先來看一下合同上的效能需求，分時效性需求和併發性需求 a.時效性需求 在系統基礎軟體效能及相應的系統管理保障基礎上，保證90 的使用者一次性成功的登入系統，而且用時不超過2秒，80 的資料提交不超過3秒，...