昨天写完了，然后点发表，竟然什么都没了，真是惆怅啊。难道是长时间没响应？之前好象不会把今天重写把。

最近因为在公司因为搞性能测试的没什么人了，我也就逐渐转向性能测试方面的学习了。学习了大概有3个星期了，也用了LR跑了一些场景，不过觉得首先还是要把一些基本概念理解清楚，所以就把一些基本的东西写下来。让自己加深理解。也希望帮助大家了解一些。

 

 

一. 软件性能测试

 

在我们学习性能测试之前，首先要明白什么是性能。汽车有他的性能，比如速度，加速时间，稳定性；电脑硬件有他的性能，比如CPU的频率，处理的速度，游戏的性能。而计算机软件也有他的性能，比如软件运行速度如何，系统稳定性如何等等。性能的好坏不能凭空想象。必须有一些数据来说明来比较。所以我们软件性能测试就是通过得到软件在各种运行情况下的数据来进行分析，来判断软件的性能。一个软件对于不同的人群，他所关注的性能方面是不一样的。比如对于用户来说，他关心的是程序响应的时间，也就是他点一个提交按钮，多长时间可以得到结果。而对于系统管理员他关注的可能是软件在运行时，对系统资源的使用情况，在大量用户使用时的表现如何，能否长时间稳定的工作；而对于开发人员，他们更关心的是系统结构是否合理，SQL执行速度是否够快，有没有内存泄漏等情况。而对于我们测试人员来说，我们需要站在多个 角度来关心性能问题。

 

 

二 性能测试主要术语

 

1：响应时间：

 

响应时间的定义是：对请求作出响应所需要的时间。我们一般把响应时间作为用户角度衡量软件性能的主要指标。

毕竟系统是给用户使用的，用户对系统性能是否满意是用户说了算的。一般情况下响应时间是分为多个步骤的，首先从客户端发出请求，经过网络达到服务器N1，应用服务器处处理S1，访问数据库服务器N2，数据库服务器处理时间为D1，然后返回给应用服务器的网络时间为N3，应用服务器处理时间S2，在传个客户端的网络时间是N4。那么整个响应时间应该为T=N1+S1+N2+D1+N3+S2+N4,当然如果还用到其他服务器，还要加上其他时间。而实际上，除开这T，还有一个客户端的显示时间也要可以算做响应时间。所以时间Tx = T +Ts。但实际上Ts很大程度上是由用户的机器决定的，所以我们一般只关注T，所以通常把T称做响应时间。

一般一个网站，被普遍接受的响应时间是2/5/10，就是说2秒内给用户响应是很满意的，5秒是可以接受，而我一般是等不到10秒就会ALT+F4了！但不同的软件，响应时间的标准要根据实际情况来定。比如一个数据库备分软件，你能要求他5秒内搞定一个1G的数据库吗？

 

2：并发用户数

 

对于一个系统来说，并发用户数是很重要的一个指标。并发用户数也分为两种，分别是业务并发用户数和服并发访问数。在具体谈这之前我们先讨论下并发这个概念，并举个例子帮助大家了解。

学习过操作系统的朋友都知道。并发性，又称共行性，是指能处理多个同时性活动的能力；与之类似的还有一个并行，它是指同时发生的两个并发事件，具有并发的含义。而并发则不一定并行，也亦是说并发事件之间不一定要同一时刻发生。举个列子，我有10辆车，但只有一条路。我10辆车同时提出请求，要走这条路。但同一个时刻，只有一辆车能出发。这个时候我们就称为并发。如果我修了2条路，那么同一时刻有2辆车可以同时出发，我们可以说这2个车是并行的，而所有的车一起看来是并发的。如果我修了10条路，那么10辆车同时出发，那么就可以说他们是并行的。

操作系统中的CPU就好象这条路，如果只有一个CPU核心，那么同时只能处理一个进程，其他进程就必须等待，这些进程可能同时提出CPU请求，那么他门是并发的。如果有多个CPU，就可以同时处理多个进程。同时处理的进程是并行的。我们从宏观角度看不出两者的区别，但微观上，并行是永远同时进行的，而并发则不是。

理解了并发大概的意思，在来谈我们前面说的2种并发用户的概念。

业务并发数是指从业务的角度来看，就是一端时间内有多少个用户在使用我们的系统。但这些用户的操作可能不同，比如有的再浏览，有的在提交请求，有的在发呆。要注意的是这个时候所以用户都算如业务并发用户数。而不是仅仅只看在象服务器请求的用户。这个地方的并发和前面概念有点不一样。就好比理发店有一个师傅，同一时间只能给一个人理发，这个时候来了5个用户，我们就可以说这5是业务并发用户数。我们并不需要了解这些用户到底是不是都是来理发的，或许只是来和老板聊天的。而另一个概念是服务器承受的并发访问数。联系到我们系统就是在同一个时间点，向服务器发起的请求数。也就是前面那部分在提交请求的用户数。还是看上面理发店的例子。来的5个用户，有3个是需要理发的。他们同时象师傅提出理发的请求，这就是对服务器而言的并发用户数了。

而对于我们测试，关注比较多的就是业务并发数。而服务器并发是用来了解在最大压力情况下服务器对于资源竞争引起的问题。所以我们必须分清测试时要测那一种并发的情况。而我们通常直接把业务并发数称为并发用户数。

 

 

3： 其他相关用户数

 

了解了并发用户数的概念，在看下其他一些相关的用户概念。

• 系统用户数：是我们经常听到的，他是指一个系统可以支持多少个用户。也就是可能使用系统的最大用户数。这是一个静态的概念。并不代表系统可以同时应付这么多用户，只是说可以支持这么多拥护。
• 同时在线人数：我门经常听到一个网站会说我们有多少多少用户同时在线。这就是一个动态的概念。他们只是连接到了系统，但不一定都对系统产生了很大的压力。而一个系统最多能容纳多少用户同时在线，就是系统能支持的同时在线人数。也可以理解为前面的业务并发用户数，但是系统最大支持的业务并发数。超过这个数的用户连接系统可能就会遇到习性能障碍。

 

具体场景的并发用户数：

前面已经说到了并发用户数，就是在一段时间类连接到系统的用户数。但前面的的定义并不严格。因为不同用户处于的场景不同，那么对服务器的压力也不同。比如100%的用户都在发呆和100%用户都在请求资源的压力肯定不同，那我们就不能说系统是否支持100个并发用户。  所以谈到并发数，我们必须结合实际的场景。所以千万不要脱离场景去谈并发。就好象在美国买IBM你说会说IBM很便宜，但你不知道在中国很贵。你必须结合你的场景–美国来说IMB很便宜。

PS：这个问题是我在使用LR中一直很困惑的。因为当时就想，我让100个用户不断进入系统，如果最后一个进来是，前面的10个已经完成了任务，退出了，那就不能说支持100并发啊。这就是忽略的场景。因为那10个用户推出的这个业务，不属于这个场景了。这个时候在按100来谈并发就没有了意义。但也不是说我们只能针对单一的场景来谈并发，在综合场景测试中就会象前面说的，一些用户在发呆，一些用户在请求。那么这个时候我们就要说在综合场景下的并发是多少。总之并发数不能脱离场景。

看到书上还有写计算并发用户的一些公式，自己暂时不想去研究，也不知道作用如何。大家可以自己去看。有一个经验公司就是把每天系统访问数的10%作为平均并发用户数（这里应该是指综合场景），最大并发一般为平均值的2-3倍。

 

4：吞吐量

 

吞吐量是指单位时间内系统处理客户请求的数量，他直接体现了软件系统的性能承载能力。

一般来说可以从业务角度的‘页面数/秒’，‘请求数/秒’来衡量，也可以通过‘字节数/秒’等多个方面来衡量。我们可以通过前面的响应时间和并发数来确定一个交互系统的性能。而对于非交互系统，吞吐量更能反映性能。而对于交互系统，吞吐量反映了服务器承受的压力，他能够说明系统级别的负载能力而且在性能调优过程中也有重要作用。比如通过‘字节数/秒’反映网络，服务器架构的制约，用‘单击数/秒’表示主要受服务器和应用代码的限制。

通过吞吐量，并发数和响应时间，我们可以大概了解一个系统的性能。当并发数增大时，吞吐量会增大，响应时间有所增加。但并发数继续增加时，响应时间增大的幅度变大，而吞吐量逐渐平缓稳定。当并发数继续增大，响应时间会明显快速增大，而吞吐量可能因为服务器压力过大，反而出现下降。所以一定要结合起来一起看。

 

 

5：性能计数器和资源利用率

 

性能计数器是服务器或操作系统性能的一些数据指标。比如WINDWOS中的进程时间，使用内存数等计数器。

资源利用率是系统各个资源的使用情况。比如WINDOWS的资源管理器，Linux下top命令，以及sysstat工具都可以用来监视系统资源。通过这些资源，结合前面的响应时间，吞吐量，并发来进一步分析系统性能。

 

 

6：思考时间

 

从业务角度来说，就是在操作过程中停顿的时间，不如用户想自己密码的时间。使用思考时间，是为了更好的模拟真实的应用环境。具体设置多少时间也有一个公式来计算，但我并不太清楚。只是在LR录制脚本时，尽量安装正常的操作时间来操作，LR会自动把你未操作的时间设为思考时间。

 

 

三：性能测试的方法

 

 

1：性能测试(Performance Testing)

 

通过模拟系统生产运行的压力量和使用场景组合，测试系统是否满足性能要求。也就是说在指定的环境下运行，来验证系统能力。这种测试首先需要对测试的场景的业务比较熟悉，在就是要有一个明确的目标，比如能否达到100用户并发时响应时间不超过5秒。最后就是这种测试的环境是确定的。

 

 

2：负载测试（Load Testing）

 

负载测试是在被测系统上不断增加压力，直到性能指标。比如响应时间超过指标或资源饱和。这种方法被称为Scalability Testing可量性测试。主要目的是找到系统处理能力的极限。一般会给定一些条件，比如响应时间不超过10秒，CPU利用率底于65%。同样这个测试也需要一个给定的环境，也要考虑执行时的场景。而且在性能调优时也用这种方法来查看前后的差异。

 

 

3：压力测试(Stress Testing)

 

是指系统在一定饱和状态下，如CPU，内存在饱和状态下处理的能力。主要观察的是系统在压力情况下的性能表现，重点观察是否会出现错误,响应时间如何。通常这些测试的描述会为，当CPU使用率在75%以上，内存使用70%以上，等作为测试依据。这种测试一般用于系统稳定性测试。

 

 

4：配置测试（Configuration Testing）

 

通过对系统软硬件的调整，了解不同环境对性能的影响，找到最优的分配方式。一般是在对系统性能有一定了解的基础上，多用于性能调优。

 

 

5：并发测试（Concurrency Test）

 

这就是前面说的用户同时对一个资源或模块数据发出请求的情况。通过这种测试手段可以发现系统中一些性能问题，比如资源竞争，死锁，内存泄露等问题。他可以在各个测试阶段使用。

 

 

6：可靠性测试（Reliability Testing）

 

通过给系统加载一定压力的情况下，让系统长时间运行，测试他在这种条件下能否稳定运行。主要是验证系统能否长期稳定运行。测试过程中，需要关注系统的资源情况。

 

 

7：失效恢复测试（Failover Testing）

 

这个主要是测试系统在部分发生故障时，用户能否继续使用，多少用户会受到影响。一般测试时要指出系统发生鼓掌时能支持多少用户访问，采取什么应急措施。