参考：https://www.testwo.com/article/725

性能测试的五大测试内容：

1、压力测试：强调极端暴力。
2、稳定性测试：在一定压力下，长时间运行的情况，运行几小时至数天时间。
3、基准测试：在特定条件下的性能测试，正常使用情况下测试。
4、负载测试：不同负载下的表现，发现性能的瓶颈。
5、容量测试：最优容量，数据库的数据量大小，保证满足几年的容量需求。

性能测试外部指标：

1、吞吐量：每秒钟系统能够处理的请求数、任务数。
2、响应时间：服务处理一个请求或一个任务的耗时。
3、错误率：一批请求中结果出错的请求所占比例。

性能测试内部指标：

1、CPU、
2、内存、
3、服务器负载、
4、网络、
5、磁盘IO等

常见性能瓶颈：

1、吞吐量到上限时系统负载未到阈值：一般是被测服务分配的系统资源过少导致的。测试过程中如果发现此类情况，可以从ulimit、系统开启的线程数、分配的内存等维度定位问题原因

2、CPU的us和sy不高，但wa很高：如果被测服务是磁盘IO密集型型服务，wa高属于正常现象。但如果不是此类服务，最可能导致wa高的原因有两个，一是服务对磁盘读写的业务逻辑有问题，读写频率过高，写入数据量过大，如不合理的数据载入策略、log过多等，都有可能导致这种问题。二是服务器内存不足，服务在swap分区不停的换入换出。

3、同一请求的响应时间忽大忽小：在正常吞吐量下发生此问题，可能的原因有两方面，一是服务对资源的加锁逻辑有问题，导致处理某些请求过程中花了大量的时间等待资源解锁；二是Linux本身分配给服务的资源有限，某些请求需要等待其他请求释放资源后才能继续执行。

4、内存持续上涨：在吞吐量固定的前提下，如果内存持续上涨，那么很有可能是被测服务存在明显的内存泄漏，需要使用valgrind等内存检查工具进行定位。

测试报告输出：

1、测试结论：包括被测服务最大QPS、响应时间等指标是否达到期望，部署建议等。
2、测试环境描述：包括性能需求、测试用服务器配置、测试数据来源、测试方法等
3、监控指标统计：响应时间统计、QPS、服务器指标统计、进程指标统计。建议最好用图表来表示统计数据。

软件性能的关注点：

1、用户角度：
用户操作响应时间
及时正向友善的错误提示

2、运维角度：
响应时间
服务器资源使用情况是否合理
应用服务器和数据库资源使用是否合理
系统能否实现扩展
系统最多支持多少用户访问、系统最大业务处理量是多少
系统性能可能存在的瓶颈在哪里
更换那些设备可以提高性能
系统能否支持7×24小时的业务访问

3、开发设计人员角度：
架构设计是否合理
数据库设计是否合理
代码是否存在性能方面的问题
系统中是否有不合理的内存使用方式
系统中是否存在不合理的线程同步方式
系统中是否存在不合理的资源竞争

4、性能测试工程师的角度：
以上所有的性能点

软件性能的几个主要术语：

1、响应时间：对请求作出响应所需要的时间

网络传输时间：N1+N2+N3+N4
应用服务器处理时间：A1+A3
数据库服务器处理时间：A2
响应时间=N1+N2+N3+N4+A1+A3+A2

2、并发用户数的计算公式

系统用户数：系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是5000个，那么这个数量，就是系统用户数。

同时在线用户数：在一定的时间范围内，最大的同时在线用户数量。
同时在线用户数=每秒请求数RPS（吞吐量）+并发连接数+平均用户思考时间

平均并发用户数的计算：C=nL / T

其中C是平均的并发用户数，n是平均每天访问用户数（login session），L是一天内用户从登录到退出的平均时间（login session的平均时间），T是考察时间长度（一天内多长时间有用户使用系统）

并发用户数峰值计算：C^约等于C + 3*根号C

其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。

3、吞吐量的计算公式：
指单位时间内系统处理用户的请求数
从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量
从网络角度看，吞吐量可以用：字节/秒来衡量
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力
以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，
可以采用以下公式计算：F=VU * R /

其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间

4、性能计数器：
是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。

资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。

5、思考时间的计算公式：

Think Time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，而在做新能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作。

在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数，而其中的R又可以用时间T和用户思考时间TS来计算：R = T / TS

下面给出一个计算思考时间的一般步骤：

A、首先计算出系统的并发用户数

C=nL / T F=R×C

B、统计出系统平均的吞吐量

F=VU * R / T R×C = VU * R / T

C、统计出平均每个用户发出的请求数量

R=uCT/VU

D、根据公式计算出思考时间

TS=T/R

性能测试术语

(1) 负载:模拟业务操作对服务器造成压力的过程,比如模拟100个用户进行发帖。

(2)性能测试( Performance Testing):模拟用户负载来测试系统在负载情况下,系统的响应时间、吞吐量等指标是否满足性能要求

(3)负载测试( Load Testing):在一定软硬件坏境下,通过不断加大负载(不同虚拟用户数)来确定在满足性能指标情况下能够承受的最大用户数。简单说,可以帮我们对系统进行定容定量,找出系统性能的拐点，给予生产环境规划建议。这里的性能指标包括TPS(每秒事务数)、RT(事务平均响应时间)、 CPU Using(CPU利用率)、 Mem Using(内存使用情况)等软硬件指标。从操作层面上来说,负载测试也是一种性能测试手段,比如下面的配置测试就需要变换不同的负载来进行测试。

(4)配置测试( Configuration Testing):为了合理地调配资源,提高系统运行效率,通过测试手段来获取、验证、调整配置信息的过程。通过这个过程我们可以收集到不同配置反映出来的不同性能,从而为设备选择、设备配置提供参考。

(5)压力/强度测试( Stress Testing):在一定软硬件环境下,通过高负载的手段来使服务器资源(强调服务器资源,硬件资源)处于极限状态,测试系统在极限状态下长时间运行是否稳定,确定是否稳定的指示包括TPS、RT、 CPU USing、 Mem Using等。

(6)稳定性测试( Endurance Testing)在一定软硬件环境下,长时间运行一定负载,确定系统在满足性能指标的前提下是否运行稳定。与上面的压力/强度测试区别在于负载并不强调是在极限状态下(很多测试人员会持保守观念,在测试时会验证极限状态下的稳定性),着重的是满足性能要求的情况下,系统的稳定性、比如响应时间是否稳定、TPS是否稳定。一般我们会在满足性能要求的负载情况下加大1.5到2倍的负载量进行测试。

(7)TPS:每秒完成的事务数,通常指每秒成功的事务数，性能测试中重要的综合性性能指标。一个事务是一个业务度量单位,有时一个事务会包括多个子操作，但为了方便统计,我们会把这多个子操作计为一个事务。比如一笔电子支付操作，在后台系统中可能会经历会员系统、账务系统、支付系统、会计系统、银行网关等,但对于用户来说只想知道整笔支付花费了多长时间。

(8)RT/ART( Response Time/average Response Time);:响应时间/平均响应时间，指一个事务花费多长时间完成(多长时间响应客户请求)，为了使这个响应时间更具代表性,会统计更多的响应时间然后取平均值,即得到了事务平均响应时间(ART)，为了方便大家通常会直接用RT来代替ART,ART与RT是代表同一个意思。

(9)PV( Page View):每秒用户访问页面的次数,此参数用来分析平均每秒有多少用户访问页面。

(10) Vuser虚拟用户( Virtual user):模拟真实业务逻辑步骤的虚拟用户,虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。Vuser脚本用于描述 Vuser在场景中执行的操作

(11) Concurrency并发,并发分为狭义和广义两类。狭义的并发,即所有的用户在同一时刻做同一件事情或操作,这种操作一般针对同一类型的业务,或者所有用户进行完全一样的操作,目的是测试数据库和程序对并发操作的处理。广义的并发,即多个用户对系统发出了请求或者进行了操作,但是这些请求或操作可以是不同的。对整个系统而言,仍然有很多用户同时进行操作。狭义并发强调对系统的请求操作是完全相同的,多适用于性能测试、负载测试、压力测试、稳定性测试场景;广义并发不限制对系统的请求操作,多适用于混合场景、稳定性测试场景。

(12)场景( Scenario):性能测试过程中为了模拟真实用户的业务处理过程,在 Load Runner中构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等的一系列动作的集合,称之为性能测试场景。场景中包含了待执行脚本、脚本组、并发用户数、负载生成器测试目标、测试执行时的配置条件等。

(13)思考时间( Think Time):模拟正式用户在实际操作时的停顿间隔时间。从业务的角度来讲,思考时间指的是用户在进行操作时,每个请求之间的间隔时间。在测试脚本中,思考时间体现为脚本中两个请求语句之间的间隔时间。

(14)标准差(sd. Deviation):该标准差根据数理统计的概念得来,标准差越小,说明波动越小,系统越稳定,反之,标准差越大,说明波动越大,系统越不稳定。包括响应时间标准差、TPS标准差、 Running Vuser标准差、Load标准差、CPU资源利用率标准差、WebResources标准差等。举例响应时间标准差。