性能测试中的常见

PV = Page View  pv 是指页面被浏览的次数；

QPS = req/sec = 请求数/秒;

TPS：Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标;

MTBF: mean time between failure 即错误发生的平均时间间隔;

HPS: Hit Per Second点击率可以看做是TPS的一种特定情况。点击率更能体现用户端对服务器的压力。 注意点击一次鼠标包含很多请求，因为点击一次鼠标我们会向服务器请求文字，图片等等内容

请求响应时间：从客户端发出请求到得到响应的整个过程的时间，单位通常为“秒”或“毫秒”，响应时间=网络响应时间 + 服务器端响应时间 ;
事务响应时间：完成该事务所用的时间。其包含一个或多个“请求响应时间“，比如你进行一次登录操作，此次登录包含多个请求，如想数据库请求用户名和密码、请求登录界面的图片等等。

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

-----------------------------------------用户相关---------------------------------------------------------------------------------------------------

并发用户数：是指现实系统中操作业务的用户，并发用户数一定会对服务器产生压力的，在性能测试工具中，一般称为虚拟用户数(Virutal User)。

注册用户数：并发用户数和注册用户数一般指的是数据库中存在的用户数；在线用户数的概念不同，注册用户数一般指的是数据库中存在的用户数。

在线用户数：只是 ”挂” 在系统上，不做任何操作对服务器不产生压力；

----------------------------------------测试类型-----------------------------------------------------------------------------------------------------

稳定性测试（reliability testing）

稳定性测试，也叫可靠性测试（reliability testing），是指连续运行被测系统，检查系统运行时的稳定程度。我们通常用mtbf（mean time between failure,即错误发生的平均时间间隔）来衡量系统的稳定性，mtbf越大，系统的稳定性越强。稳定性测试的方法也很简单，即采用24*7（24小时*7天）的方式让系统不间断运行，至于具体运行多少天，是一周还是一个月，视项目的实际情况而定。

稳定性测试的方法也很简单，即采用24*7（24小时*7天）的方式让系统不间断运行，至于具体运行多少天，是一周还是一个月，视项目的实际情况而定。

负载测试（load testing）
通常是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。

可以看出负载测试和稳定性测试比较相似，都是让被测系统连续运行，区别就在于负载测试需要给被测系统施加其刚好能承受的压力；

比如我们还是测试163邮箱系统的登录模块，我们先用1个用户登录，再用两个用户并发登录，再用5个，10个…在这个过程中，我们每次都需要观察并记录服务器的资源消耗情况（可以通过任务管理器中的性能监视器或者控制面板中的性能监视器），当发现服务器的资源消耗快要达到临界值时（比如cpu的利用率90%以上，内存的占有率达到80%以上），停止增加用户，假如现在的并发用户数为20，我们就用这20个用户同时多次重复登录，直到系统出现故障为止。
负载测试为我们测试系统在临界状态下运行是否稳定提供了一种办法。

压力测试（stress testing）
压力测试，是性能测试的一种，通常是指持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。
比如我们不断增加并发的登录用户数，20，30，50…比如，当增加到70个用户并发登录时，系统崩溃了，最大登录并发数为70个左右。

-------------------------------------------------------------------------------------------------------------------------------------------------------------

Vu和TPS换算

Ø  简单例子：在术语中解释了TPS是每秒事务数，但是事务时要靠虚拟用户做出来的，假如1个虚拟用户在1秒 内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务 响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生 1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。

Ø  复杂公式：

试想一下复杂场景，多个脚本，每个脚本里面定义了多个事务（例如一个脚本里面有100个请求，我们把这100个连续请求叫做Action,只有第10个请求，第20个请求分别定义了事务10和事务20）具体公式如下：

符号代表意义：

Vui表示的是第i个脚本使用的并发用户数

Rtj表示的是第i个脚本第j个事务花费的时间，此时间会影响整个Action时间

Rti表示的是第i个脚本一次完成所有操作的时间，即Action时间

n 表示的是第n个脚本

m 表示的是每个脚本中m个事务 

那么第j个事务的TPS = Vui/Rti

总的TPS= 

相关案例

通过大量性能测试我们发现不需要用上万的用户并发去进行测试，只要系统处理业务时间足够快，几百个用户甚至几十个用户就可以达到目的。另外咨询很多专家做过的性能测试项目，基本都没有超过5000用户并发。因此对于大型系统、业务量非常高、硬件配置足够多的情况下，5000用户并发就足够了；对于中小型系统，1000用户并发就足够了。(5000 用户并发 提交事务数 T 事务包含请求数为 Q; 那么 QPS=?)

----------------------------------------------------------------------------------------