4.2.2　响应时间测量

通常情况下性能测试中您首先关注的指标就是应用程序或服务器每个事务的响应时间。自动化性能测试工具中的响应时间指的是客户端向服务器发起请求到客户端接收到响应所花费的时间。如果应用程序在指定的时间内没有响应，性能测试工具将记录超时错误。假如出现这种情况，最大的可能就是应用程序中某部分应用已经过载。我们需要检查服务器和网络KPI以帮助我们确定可能出现负载过重的地方。

提示

负载过重并不一定完全是应用程序的问题。有时我们也可以通过增加脚本中的超时时间或者性能测试配置参数避免负载过重情况的出现。

所有消耗在客户端的时间都被当作思考时间，这个思考时间代表的是最终用户和应用程序之间交互的正常延时与停顿。性能测试工具一般都工作在中间层，也就是说性能测试工具一般工作在表现层之下，因此它不像单击一个组合框并选择某一项操作这样的事件，除非这些动作会在网络上产生通信。类似这样的用户操作在事务脚本中会以一段不活动的时间或者“休眠”的形式体现，它表示一段简单的延迟，用于模拟用户查看屏幕出现的内容的时间，以及像刚才所提到的单个或一组操作。假如你需要单独获取这些操作的时间，那么你需要在性能测试中将功能测试工具和性能测试工具结合使用（详见第5章）。

通常衡量响应时间的时候不应该包含思考时间，因为你关注的重点在于从客户端发出请求到服务器完全返回响应所花费的时间。一些测试工具细分了响应时间，它能够分别指出服务器开始做出响应的时间以及服务器完全返回响应所花费的时间。

接着看一些例子，下面三张图列出了性能测试中可以获取到的几种典型的响应时间。这些信息可以在测试运行过程中实时获取，也可以在测试完成之后从测试结果中获取。

图4-3简单地描述了随着性能测试时间（X轴）而增长事务响应时间（Y轴）的变化。除了响应时间外，该图没有提供性能测试过程中每个事务行为的情况。假如应用程序存在基本问题，则无论多少用户处在活动状态，响应时间总是表现很差。

图　4-3　整个性能测试过程中的响应时间

图4-4与图4-3描述的是同一个性能测试的结果，不同的是图4-4在每个响应时间点上增加了此时运行的并发用户数。通过这幅图您可以了解到用户数量的增长对应用程序响应时间的影响。你通常会认为随着活动用户数的增长，响应时间也会相应增加，但是通常来说响应时间的增长与负载的增长并不一定同步。

图　4-4　测试过程中响应时间与并发虚拟用户的关联

图4-5基于之前的两个图而创建，并且添加了事务中的“检查点”的响应时间。正如第2章中所提及的那样，添加“检查点”有利于提高响应时间分析的粒度，并且可以将性能较差的响应时间与特定事务的行为进行关联。这幅图显示了大约在1500秒的时候，事务响应时间出现的峰值与“检查点”的响应时间峰值一致，但跟活动的用户数却没有直接关系。

图　4-5　事务和检查点响应时间与当前用户的关联

事实上，响应时间在1500秒时出现峰值，是由于在登录验证的事务中输入了一组无效数据引起的。这很清晰地表明了无效数据的输入会对性能测试结果造成影响。

图4-6以表格形式展现了图4-5中的响应时间。在该图中，我们看到完整事务以及每个“事务（Checkpoint）”的算术平均数和标准方差值。

图　4-6　响应时间表

性能测试工具应该提供一个清晰的起始点用于结果分析。例如，图4-7列举了性能测试过程中所有事务中10个最差的性能“检查点”。这种排序的图表有利于在众多“检查点”和事务中突出显示问题所在。

图　4-7　10个最差的性能检查点