测试回顾版-第二讲：性能测试基础知识大温习

（并发用户数量）与服务器进行交互的在线用户总量（）可以通过对服务器日志的分析得到

（请求响应时间）从client端发出请求到得到响应的整个时间，一般包括网络响应时间和server的响应时间（要区分）

（事物响应时间）完成这个事物所需要的时间（性能测试中重点关注指标）

（吞吐率）单位时间在网络上面传输的数据量（衡量网络性能的主要指标）从server返回到client的数据量

（吞吐量）网络上面传输的数据总量（单位时间内系统处理的客户请求数量）

（TPS）每秒钟系统能够处理事物的数量

（点击率）每秒发送的HTTP请求的数量，点击率越大对server的压力也越大

（资源利用率）对不同资源使用的程度，比如服务器的CPU，内存等

响应时间=网络传输时间+应用延迟时间

应用延迟时间=数据库延迟时间+应用服务器延迟时间

而“系统响应时间”指应用系统从请求发出开始到客户端接收到所有数据所消耗的时间。

这样，“系统响应时间”加上“呈现时间”，才是完整的用户感受到的响应时间。

经验公式：企业内部的文本系统如OA，平均每天访问系统用户数的10%作为平均的并发用户数。

并发用户最大值在这个值基础上面乘2~3

正常的话：吞吐量=（虚拟用户个数*每个虚拟用户发出的请求（单击）数量）/性能测试所用时间

遇到性能瓶颈的时候上面公式不成立

其中每个虚拟用户发出的请求（单击）数量= 时间/思考时间

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

统计出系统平均的吞吐量

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

根据上面公式计算思考时间

1：要保证每次执行的数据库具有相同的数据环境，不然得出的结果不可比

2：J2EE和DONET应用服务器需要先预热，让代码都编译为本地代码

性能测试专注的是服务端和应用之间的通信数据，而不是应用的GUI操作。

场景：主要表现为在control中设计和执行测试用例中的用户场景。（一般是由用户在某个时间段内所有业务使用状况组成）

负载发生器：用来产生压力的真实机器，受control的控制，可以使用户脚本在不同机器上面运行，通常是一个control控制多个load generator一起对被测系统实施加压。

虚拟用户：用Loadrunner生成的用户就是虚拟用户，对应于现实的真实用户。

事务：Loadrunner通过事务来衡量服务器的性能，测试人员将一个或者多个操作定义为一个事务，以衡量这部分用户并发响应时间

思考时间：void lr.think_time ( double time );

集合点：并发点，Loadrunner通过集合点来实现真正意义上的并发。int lr.rendezvous ( String rendezvous_name );

事务响应时间：

虚拟用户脚本生成器是通过proxy方式实现，具体来说，通过一个proxy，该proxy作为客户端和服务端的中间人，接收从客户端发送的数据包，记录并转发给服务端。记录从服务端返回的数据流，记录并返回给客户端。

我们在定义响应时间的时候，是从应用的使用者/客户的角度出发的。从这个角度出发，响应时间被定义成“ 对请求做出响应所需要的时间”。我们以一个web应用为例，假设web应用有一个“提交用户留言”的功能，考察这个功能的响应时间，就应该是“从用户填写完留言，点击提交按钮开始，到页面刷新完成，用户看到完整的返回页面为止”所消耗的所有时间——这个定义非常完整，但若从用户的实际感受来看的话，这里还是有一点模糊的地方。

我们可以把上文提到的交互过程细化一下：

用户点击“提交”按钮-》请求被发送到服务器-》服务器处理-》服务器返回页面-》浏览器接收服务器的返回并render页面

模糊之处在于最后一个环节：“浏览器接收服务器的返回并render页面”，如果我们坚定的认为“只有当页面完整的显示完成，才是响应时间的结束”，这不会是一个问题。但实际上，对大多数用户来说，看到页面上开始显示数据或是图片，用户就会认为“我已经得到了响应”，从这个角度来说，用户感受到的响应时间实际上是“从请求发出开始，到用户看到页面开始呈现出的内容结束”所需要的时间。

那为什么我们不采用“从请求发出开始，到用户看到页面开始呈现出的内容结束” 这样一个定义方式呢？关键在于这里涉及到用户的认知行为，带有主观色彩，不完全是客观的标准，因此不适合作为一个需要被度量的性能指标。另一方面，不同的浏览器有不同的行为（例如parse的方式和render的方式），如果需要把这些浏览器本身的行为都考虑到性能测试中的话，我们很难为所有的系统建立统一的测试模型——实际上，现在的主流性能测试工具（例如JMeter，LoadRunner，Webload等）都完全不考虑客户端的呈现过程。