性能测试的一些思路

测试目标：
测试过程是否满足以上过程指标及最终的需求指标；
及如何通过结合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--〉换算出以上实际测试指标--〉多用户多事务渗入测试--〉调整以上指标--〉结论