业务模型分析
业务模型分析主要是为了得到更加真实模拟线上运行场景，保证测试的覆盖率。通过根据系统情况分为有业务数据参考(生产运行日志)和无业务数据参考两种情况。
有业务数据参考
搜集生产上不同高峰时间段的业务种类和业务量，每个时间段的业务种类和业务量是否有很大的差异，如有的话，必须有多个业务模型，差异不大的，可以只用一个业务模型。搜集生产上高峰时间段资源消耗和资源异常的时间点，从中捕获资源消耗高和异常的原因，可能是由于某种”不起眼”的业务导致。搜集生产问题，进行分析，如果是由于某种业务导致而且以前性能测试的时候忽略此笔业务，那么这笔业务的风险是非常大的，需要后续性能测试将此业务加入到业务模型中。系统可按照表格的方式进行分析提取业务模型，如下所示:
任务时间分布表：
接口执行统计表：
无业务数据参考
通过与业务人员或者开发人员沟通，引导业务人员根据业务使用情况，进行业务模型的大概预估。具体方法如下确认被测业务。
业务选取规则如下:
- 使用比较频繁的业务(业务人员根据使用情况提供)。
- 使用不是特别频繁但是交易涉及数据量比较大的业务(业务人员根据使用情况配合开发人员提供)。
- 交易逻辑复杂比较高的业务(开发人员根据代码逻辑提供)。
确认各业务占比:
- 业务人员根据使用情况进行各选取业务比例预估。
- 如果没有业务使用的话，可以参考同行(非功能测试人员根据相关进行建议并让业务确认)。
性能指标分析
在系统性能方面，用户一般的关注点在于如下三点：系统是否满足上线性能要求，系统极限承载能力，系统稳定性能力。因此针对上述三个关注点，需要搜集和监控系统的一些性能指标，性能指标一般分为两大类：资源指标和系统指标，如下图所示，资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关。
系统用户数
与系统用户数量相关的指标包括注册用户数、在线用户数、平均并发用户数和最大并发用户数等。
- 注册用户数:注册用户数指系统中全部注册用户的数量。这个指标不代表系统的处理能力，只代表系统存储能力，一般不作为性能指标定义。
- 在线用户数:在线用户数指在一段时间段内登录了系统，并在系统中进行操作的用户数量。用户登陆后，服务器需要维持与客户端的连接，初始化用户数据，在服务器端为用户访问分配资源，所以服务器能够承载的登录用户的数量是有限的，在需求分析时可以定义在线用户作为一个性能指标。
- 平均并发用户数:指在系统正常访问量情况下的并发用户数量。衡量系统在正常业务量情况下的处理能力，在需求分析时可以定义该指标作为一个性能指标。
最大并发用户数:指在峰值访问情况下的并发用户数，是系统性能的重要指标。在进行系统性能需求分析时，如果系统存在大量用户并发访问的可能性，则需要定义上述指标。
并发用户数
定义并发用户数指标时，要根据系统业务特点，分析有可能产生大量用户并发访问的功能点，以此功能为重点，分析平均并发用户数和最大并发用户数的要求。计算并发用户数的方法一般分为两类，一类为有业务数据参考，一类为无业务数据参考；
有业务数据参考:
方法一
- 平均并发用户数：C=nL/T
- 最大并发用户数：Ñ≈C+C根号3
其中:C代表平均并发用户数，Ñ代表最大并发用户数，n是访问系统用户数量(一般平均每天的用户访问量)，L是用户访问系统平均 时间(单位分钟)，T是用户使用系统时间段(单位分钟)。
方法二
- 并发用户数:系统最大在线用户数的8%到12%。
无业务数据参考：
方法一
- 公式为 C = (Think Time + RT)*TPS
其中:RT代表系统响应时间，Think Time代表用户思考时间。
吞吐量、TPS
吞吐量：
吞吐量是指单位时间内系统能够完成的工作量，它衡量的是软件系统服务器的处理能力，就是在一秒中统计所完成的工作量。一个系统的吞度量（承压能力）与请求对CPU的消耗、外部系统接口、IO等等紧密关联。单个请求对CPU消耗越高，外部系统接口和IO速度越慢，系统吞吐能力越低，反之越高。
- 业务角度:吞吐量可以用,请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量，如RPS、TPS。
- 网络角度:吞吐量可以用,字节/秒来衡量。
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力，以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈。以请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU * R / T（其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间）。
TPS（每秒事务数）:
TPS是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。事务是用户某一步或几步操作的集合，这些操作共同构成一个有意义的业务场景。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，TPS的预估方法如下（最大TPS计算一般是TPS*2~5）：
普通计算方法：
- 计算公式：TPS=C/ (Think Time + RT)
二八原则计算方法：
- 计算公式: TPS = 总请求数 80% / (总时间20%)
无论TPS、QPS、HPS，此指标是衡量系统处理能力非常重要的指标，越大越好，具体数值还是要根据系统自身业务情况确定。
- 金融行业：1000 TPS~50000 TPS，不包括互联网化的活动。
- 保险行业：100 TPS~100000 TPS，不包括互联网化的活动。
- 制造行业：10 TPS~5000 TPS。
- 互联网电子商务：10000 TPS~1000000 TPS。
- 互联网中型网站：1000 TPS~50000 TPS。
- 互联网小型网站：500 TPS~10000 TPS。
响应时间
响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。在性能测试中一般以压力发起端到被压测服务器返回处理结果的时间为计量，单位一般为毫秒。
平均响应时间指系统稳定运行时间段内，同一接口多次请求的平均响应时间。通常性能指标中的响应时间都是指平均响应时间。
如下图所示，以一个简单的客户端-服务器-数据库的应用架构来看，响应时间可以被分解为网络传输时间（N1+N2+N3+N4）和应用延迟时间（A1+A2+A3），而应用延迟时间又可以分解为数据库延迟时间（A2）和应用服务器延迟时间（A1+A3）。对响应时间进行分解使得我们能够更有效率得定位性能瓶颈。
不同行业不同业务可接受的响应时间是不一样的，需要根据自身情况设定合适的符合用户使用要求的响应时间。
一般情况，对于在线实时交易：
- 互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。
- 金融企业：1秒以下为佳，部分复杂业务3秒以下。
- 保险企业：3秒以下为佳。
- 制造业：5秒以下为佳。
事务成功率
成功率指系统在负载情况下，失败成功的概率。可以根据交易数或请求数直接计算得出。对于稳定性较好的系统，其错误大概率由超时引起，即为超时率。计算公式为：成功率＝（失败成功数/交易总数）×100%。不同的系统对成功率的要求不同，但通常会要求成功率不低于99.4%，即错误率不超过千分之六。
CPU指标
中央处理器是一块超大规模的集成电路，是一台计算机的运算核心（Core）和控制核心（ Control Unit）。它的功能主要是解释计算机指令以及处理计算机软件中的数据。CPU Load：系统正在干活的多少的度量，队列长度。系统平均负载。CPU指标主要指的CPU使用率、利用率，包括用户态（user）、系统态（sys）、等待态（wait）、空闲态（idle）。CPU使用率、利用率要低于业界警戒值范围之内，即小于或者等于75%、CPU sys%小于或者等于30%，CPU wait%小于或者等于5%。单核CPU也需遵循上述指标要求。CPU Load要小于CPU核数。
内存指标
内存是计算机中重要的部件之一，它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。现代的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%，太多的交换将会引起系统性能低下。
磁盘指标
磁盘吞吐量是指在无磁盘故障的情况下单位时间内通过磁盘的数据量。磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的重要依据，一般情况下，磁盘繁忙率要低于70%。
网络I/O
网络吞吐量是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的70%。
数据库指标
常用的数据库例如ＭySQL指标主要包括SQL、吞吐量、缓存命中率、连接数等，具体如下：
SQL耗时越小越好，一般情况下微秒级别。命中率越高越好，一般情况下不能低于95%。锁等待次数越低越好，等待时间越短越好。
中间件的指标
常用的中间件例如Tomcat、Weblogic等指标主要包括JVM、ThreadPool、JDBC，具体如下：
当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线程数最小值设置50和最大值设置200比较合适。当前运行的JDBC连接数不能超过设定的最大值。一般情况下系统性能较好的情况下，JDBC最小值设置50和最大值设置200比较合适。GC频率不能频繁（一般平均半个小时以上一次为正常），特别是FULL GC更不能频繁，一般情况下系统性能较好的情况下，JVM最小堆大小和最大堆大小分别设置1024 M比较合适。
稳定性指标
系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。对于7×24运行的系统，至少应该能够保证系统稳定运行24小时以上。 如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险。在稳定性压测时一般要求TPS曲线稳定，没有大幅波动，同时各项资源指标没有泄露或者异常情况。
可扩展性指标
指应用软件或操作系统以集群方式部署，增加的硬件资源与增加的处理能力之间的关系。计算公式为：（增加性能/原始性能）/（增加资源/原始资源）×100%。 扩展能力应通过多轮测试获得扩展指标的变化趋势。 一般扩展能力非常好的应用系统，扩展指标应是线性或接近线性的，现在很多大规模的分布式系统的扩展能力非常好。理想的扩展能力是资源增加几倍，性能就提升几倍，实际一般要求扩展能力至少在70%以上。
可靠性指标
双机热备：
对于将双机热备作为可靠性保障手段的系统，可衡量的指标如下：
- 节点切换是否成功及其消耗时间。
- 双机切换是否有业务中断。
- 节点回切是否成功及其耗时
- 双机回切是否有业务中断。
- 节点回切过程中的数据丢失量。在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。
集群：
对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：
- 集群中某个节点出现故障时，系统是否有业务中断情况出现。
- 在集群中新增一个节点时，是否需要重启系统。
- 当故障节点恢复后，加入集群，是否需要重启系统。
- 当故障节点恢复后，加入集群，系统是否有业务中断情况出现。
- 节点切换需要多长时间。在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。
备份和恢复：
本指标为了验证系统的备份、恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复，包括以下测试内容：
- 备份是否成功及其消耗时间。
- 备份是否使用脚本自动化完成。
- 恢复是否成功及其消耗时间。
- 恢复是否使用脚本自动化完成指标体系的运用原则。
- 指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也不一样，考察的指标项也有很大差别。
- 部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。
- 对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。
- 如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。
- 测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等）。