原文地址：http://blog.sina.com.cn/s/blog_639aa08501010kkr.html
1.1 性能測試需求內容
性能測試需求應包括以下內容：
a) 測試場景及用例，用例訪問URL；
b) 目標接口方法的入參、出參；
c) 外部依賴的服務細節；
d) 關鍵數據: 數據量、高峰業務PV量
e) 預期性能指標：響應時間、QPS、TPS等
性能測試需求模板表格參考如下：
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是個平均值。
一、 性能測試需求分析
需求收集之后，我們已經從性能需求文檔中提取出了業務性能測試指標，主要包括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指的是服務器每秒鍾能夠處理的事物數，是服務器處理能力的體現。