測試過程是否滿足以上過程指標及最終的需求指標；
及如何通過結合2者指標評估出被測系統及上線環境的線性對比指標；
最後得到系統的性能、可擴展性、可用性等測試結論。
測試步驟：
1) 基準測試：分步測試。測試結果是一致的且可重現。測試環境一直處在相同的高負載下進行。
2) 容量規劃測試：系統測試。容量規劃在測試需求階段就需要從設計獲取了，詳見附件《性能指標容量規劃.DOC》。如果要確定系統的容量，需要考慮幾個因素。這些用戶中有多少是併發與服務器通信的，其次是，每個用戶的"考慮時間"即請求時間是多少，以及本次請求服務通信總響應的時間是多少，等等。通過用戶考慮時間+服務器響應時間=場景總運行時間，且通過調整各參數及隨機因子（利用"調步"的理念向負載場景中引入更多的隨機性），換算出最大及最優同時併發用戶數。接着引入ramp-up測試及flat測試不斷微調。
3) 峯谷測試：系統測試。峯谷測試通過一系列的快速ramp-up測試，繼之以一段時間的平穩狀態（取決於業務需求），然後急劇降低負載，然後再進行快速的ramp-up；反覆重複這個過程。這樣可以確定以下事項：
第二次高峯是否重現第一次的峯值？
其後的每次高峯是等於還是大於第一次的峯值？
在測試過程中，系統是否顯示了內存或GC（內存釋放）性能降低的有關跡象？
測試運行（不停地重複"峯值/空閒"週期）的時間越長，系統的性能越被瞭解。
4) 滲入測試：系統測試。滲入測試所需時間較長，也叫疲勞測試。滲入測試以2端負載通過低負載/高負載運行較長時間，即運行兩次測試，一次使用較低的用戶負載（要在系統容量之下，以便不會出現執行隊列），一次使用較高的負載（以便出現積極的執行隊列）。
測試所需指標：
1、 獲取各WEB服務的性能指標，包括 WEB SERVER的性能（包括線程數（爲了給執行隊列決定一個理想的線程數，當隊列中所有應用程序都運行在最大負荷的情況下，監視隊列的吞吐量。增加線程數，重複負載測試，直到達到最佳的吞吐量。（在某些情況下，增加線程數將產生足夠多的上下文轉換程序，使得隊列中的吞吐量開始減少。））、最大併發數、最優併發數、TPS）；
---最佳線程數（調整並滿足既定的配置數，詳見2.2硬件環境描述）
---最佳吞吐量 for server (tomcat/sip/oracle)
---響應時間 for case（OSAP/PXYWEB/xxxCOMP/WEB SERVICES）
---最大同時併發用戶數 for osap
---最佳同時併發用戶數 for osap
---最佳用戶數下的TPS for case（OSAP/PXYWEB/xxxCOMP/WEB SERVICES）
2、 能力組件性能
---最大併發用戶數下的CPS for case（xxxCOMP）
---最佳線程數（調整並滿足既定的配置數，詳見2.2硬件環境描述）
---最佳吞吐量 for server (tomcat)
---響應時間 for case（xxxCOMP）
---最大同時併發用戶數 for case（xxxCOMP）
---最佳同時併發用戶數 for case（xxxCOMP）
3、 應用服務（SIPSVR）的性能指標：
---最佳線程數
---最佳吞吐量 for case5
---CPS for case2/case5
4、 後置指標：
---各服務器的CPU佔用百分比（基準測試/容量規劃測試/滲入測試）
---各服務器的Memory平均佔用比例 （基準測試/容量規劃測試/滲入測試）
（例如，如果想知道增加JVM內存是否會影響應用程序的性能，就逐次遞增JVM內存（例如，從1024 MB增至1224 MB，然後是1524 MB，最後是2024 MB），在每個階段收集結果和環境數據，記錄信息，然後到下一階段。）
容量規劃
前提（測試結果有效的先決條件）：
1、 web/sip/oracle/第三方後臺服務器配置滿足建設方案標準配置或以上；
2、 系統正常工作時，用戶訪問系統的基本性能需求如下：
1) 軟終端用戶登錄時間<= 3秒
2) WEB終端用戶頁面初始化操作<= 3秒
3) WEB接入的系統響應時間：在帶寬足夠的情況下，用戶點擊訪問頁面時間不超過3秒，請求提交響應時間最大不超過5秒；
4) 系統一般性操作最長時間<= 2秒
5) 用戶操作界面友好，交互性強，在出現錯誤時，應能顯示錯誤提示信息，並且錯誤信息能夠被用戶取消，並恢復界面正常顯示。
3、 根據項目一期設計，系統建設要求滿足3萬用戶需求，業務話務模型如下：
1) 點擊撥號
按最大CAPS爲60計算，普通用戶的通話時長爲60秒，媒體服務器爲主叫放音時長爲30秒。
2) 網絡傳真
按最大CAPS爲3計算，每個呼叫時長爲120秒，媒體服務器話音提示時長爲15秒。
3) Web會議
按最大CAPS爲0.2計算，每次會議保持時長爲120秒，會議方數爲5方，40%用戶存在數據協同會議需求。
4) 短信
短信按每秒100條計算。
5) 電話總機
按最大CAPS爲0.5計算，每個呼叫時長爲90秒。
4、 九的個數和時間之間的對應關係。
可接受的運行時間百分比 每天的停機時間 每月的停機時間 每年的停機時間
95 72.00 分鐘 36 小時 18.26 天
99 14.40 分鐘 7 小時 3.65 天
99.9 86.40 秒鐘 43 分鐘 8.77 小時
99.99 8.64 秒鐘 4 分鐘 52.60 分鐘
99.999 0.86 秒鐘 26 秒鐘 5.26 分鐘
5、業務比例選取：
“xx”平臺用戶主要針對中小企業用戶，按照約有3萬企業用戶，xx商業客戶分類如下：
客戶類型 客戶員工規模 客戶數量 比率
1-2線客戶 約3-10人 135萬 86%
3-10線客戶 約10-100人 19.5萬 12%
10線以上客戶 約20-500人 2.2萬 2%
按以上比例，3萬用戶中，2.58萬爲1-2線用戶，3600爲3-10線用戶，600爲10線以上用戶。
企業用戶數：25800*2+3600*10+600*10=93600=9.4萬
如果再考慮未來幾年的交易量的增加（每年增長15％），則可以歸納爲：
類型 第一年（萬） 第二年（萬） 第三年（萬） 第四年（萬） 合計（萬）
企業客戶 3.45 3.97 4.56 5.25 17.23
企業
用戶 10.81 12.43 14.30 16.44 53.98
6、壓力分解：
對於一個由很多環節組成的複雜系統來說，如果想要模擬實際環境進行整體的聯合性能測試的話，就需要針對整體壓力進行各個層次的分解。
例如：後臺系統CPS是60次/秒，由於接口網關和後臺主機在此環境中是1對1的關係，所以接口網關的壓力要達到60次/秒。而一個接口網關對應着三個前置機，所以每個前置機要達到20次/秒送達主機的吞吐量，纔可能使整個系統滿負荷運轉。考慮到其它層次類推。由於主機以外還存在其它服務系統，所以在前置機的壓力上面加了一個“X”代表其它服務系統要求的壓力。當某個層次的設備短缺，無法實際上達到其分解下來的壓力時，往往需要使用軟件手段，在上一層次上直接加壓力解決。
性能監控
利用容器的管理界面，分析最大線程數、併發線程數（最優併發用戶數）
每秒鐘運行成功的交易數量（TPS/CPS）
Web 服務/Get 請求/秒（TPS）
後臺服務請求頻率（CPS）
單一客戶端的響應時間(使用時間戳的差值，發出請求的時間和收到迴應的時間)
請求的執行時間(RPT:事務響應時間)
網絡流量佔用率（最佳吞吐量）
各服務器的CPU佔用百分比（SHELL）
內存的佔用率（SHELL）
硬盤使用率
-----------
選取場景---〉單用戶單事務執行當前場景---〉獲取執行時間（請求時間+響應時間+服務時間）---〉獲取CPS---〉以此作爲當次場景的基準值--〉換算到併發請求場景中--〉多用戶併發單事務執行當前場景--〉獲取TPS--〉以當前服務環境爲基準(當前最大線程數)獲取當前TPS、最大併發數、當前最大吞吐量--〉換算出以上最優理論值--〉調整間隔時間--〉引入TCA--〉獲取單用戶多事務TPS--〉換算出以上實際測試指標--〉多用戶多事務滲入測試--〉調整以上指標--〉結論