测试所需指标：
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线以上用户。
6、在线使用概况
峰值乘数用于计算与平均负载有关的系统的最大容量。 如果每秒钟的平均请求数量是 50 ，如果您的峰值乘数是 3 的话那么预期峰值将会是每秒钟 150 次请求。 为了对实施进行容量规划，您应当为系统的峰值容量做规划。
描述 值
会话的平均时间 7 分钟(420 秒)
峰值乘数 3x 平均值
每个用户每次访问的请求数 10
7、事务比例选取
对于行业应用，测试数据的准备中最重要的就是事务的选取，以上从业务比例中抽取每个客户类型的事务比例：
比例的分布：
操作 分布权重 发送比例 标准化 每个操作的请求数 每个会话的请求数
定购(ws)/请求使用 0.10 10*0.1=1 2 1 Ws:canuse
登录 0.10 10*0.1=1 1 2 Login->logout
发送传真 0.20 10*0.2=2 1 3 Osap->pxy->comp->sip
已发/接收传真 0.03 10*0.03=0.3 2 2 Osap->pxy->comp->
发送短信 0.20 10*0.2=2 1 3 Osap->pxy->comp->
已发/接收短信 0.05 10*0.05=0.5 2 2 Osap->pxy->comp->
点击拨号 0.20 10*0.2=2 1 3 Osap->pxy->comp->ctd
发起会议 0.09 10*0.09=0.9 1 3 Osap->pxy->comp->ipunity
定制语音流程 0.03 10*0.03=0.3 1 3 Osap->pxy->comp->->sip
总计 1 10
其中 分布权重 一栏给出某类操作占总请求数的百分比。
其中 标准化 一栏表示分布权重乘以前表给出的每用户每次访问请求数得到的结果。 注意这一栏合计达10。
其中 每个操作的请求数 一栏给出了执行某一操作所用的用户请求数量。 由于回帖或服务器重定向等原因，有些操作会产生多个请求。
其中 每个会话的请求数 一栏给出了用户在每次会话中发起的对某一操作的请求数量。
8、测试强度估算：
测试强度估算时采用如下假设前提：
*全年的业务量集中在10个月完成，每个月20个工作日，每个工作日8个小时；
*采用80—20原理，每个工作日中80%的业务在20%的时间内完成，即每天80%的业务在1.6小时内完成；
测试压力的估算结果：
按照3万用户每用户每次访问的10请求数，每7分钟一次会话计算，可处理业务约30万笔，每小时处理超过100次请求。其中，假设早上9点及下午15点为高峰期，按照2个小时段的业务处理量估计如下：
10%的业务处理每笔订购业务需对应用服务器提交1（标准化）*10=10次请求；
10%的业务处理每笔登录业务需对应用服务器提交1（标准化）*10=10次请求；
20%的业务处理每笔传真业务需对应用服务器提交2（标准化）*10=20次请求；
20%的业务处理每笔短信业务需对应用服务器提交2（标准化）*10=20次请求；
20%的业务处理每笔呼叫业务需对应用服务器提交2（标准化）*10=20次请求；
9%的业务处理每笔呼叫业务需对应用服务器提交9（标准化）*10=9次请求；
其余11%的业务每笔业务向应用服务器提交1.1（标准化）*10=11次请求。
根据以往统计结果，每年的业务增量为15%，考虑到今后三年业务发展的需要，测试需按现有业务量的2倍进行。
每年总的请求数量为：
（30*10%*10*2+30*10%*10*2+30*20%*20*2+30*20%*20*2+30*20%*20*2+30*9%*9*2+30*11%
*11*2）*2=60+60+240+240+240+48.6+72.6=961.2万次/年。
每天的请求数量为：961.2/200=4.806万次/天。
每秒的请求数量为：（48060*80%）/（8*20%*3600）=38448/5760=6.675次/秒。
正常情况下，应用服务器处理请求的能力至少应达到：6.675次/秒。
某种程度上，可认为请求数量约等于交易数量：
如果再考虑未来几年的交易量的增加（每年增长15％），则可以归纳为：
第一年（万） 第二年（万） 第三年（万） 第四年（万） 合计（万）
30 34.5 39.675 45.627 149.802
