《应用程序性能测试的艺术 第2版》第五章 性能测试结果解读 摘录

 对测试结果的分析有两种：实时分析和事后分析。 

 在做性能测试的时候，我们期望能获得以下这些信息以做实时分析：

• 以表格或者图形方式展示性能测试中每个用例的响应时间。数据应该包含整个用例的执行时长和用例中为了分析而独立标记的区域时长。比如可能会有完成登录所花的时长，或者完成一次搜索所消耗的时长。
• 必须能够监控为每个脚本所分配的虚拟用户增长情况以及整个测试所用的虚拟用户数。从这些信息中，你可以看出应用对于不断增长的负载和吞吐是如何反应的。
• 必须能够监控到所有施压机的状态，从而可以确保它们没有过载。
• 必须能够监控到性能测试计划中包含任何服务器的KPI数据，比如应用服务器以及网络KPI.
• 必须能够看到性能测试配置的一些阈值，当一些超过阈值的指标出现时需要及时收到告警。
• 必须能够看到整个测试执行过程中的所有错误，这些错误发生的次数，影响到哪些虚拟用户，发生错误的原因以及解决这些错误的可能建议。

而为了保证以后还能进行事后分析，一定要把所有相关数据都做好特定的标记保存起来，在测试结束后的任意时间都可方便快速的获取。之后可以拿这些结果做比较。

结果分析：

性能测试输出数据的类型：平均值（算术平均值）和中位数（一组数取中间值，奇数直接中间那个，偶数中间两个平均值），标准差和正态分布。百分位数（按大小排列后，落在一定百分比范围内的边界数值），响应时间分布（柱状图）。

响应时间的衡量：（通常性能测试工具会提供图形和表格来展示响应时间与虚拟用户数，用例之间的关联）

如果应用在指定时间内没有返回结果，性能测试工具通常会记录下一次超时错误。如果出现大量超时，很可能应用的某些节点出现了过载现象，也可能是性能测试配置中的超时时间设置过短引起的。

任何纯客户端的时间消耗都可以看作思考时间，思考时间代表了真实终端用户在使用应用时出现的正常延迟和思考。响应时间是不包括这些思考时间的，因为我们关注的是服务器在收到请求之后需要多长时间才能返回响应。

另外不恰当的测试数据会对性能测试结果产生影响。

吞吐率和容量：

吞吐率关注一个特定的用例执行速度有多快，容量的关注点在于一段时间内能够处理多少的用例。如果吞吐率出现了明显下降的情况，很可能意味着出现了某些问题。可能是由于1个或多个虚拟用户执行发生了错误。吞吐率下降是揭示Web或者应用服务器层出现容量瓶劲的有效指示。

Web服务器不总是导致问题的源头，我遇到过很多案例，虚拟用户的请求发生超时，实际的问题却是数据库层有一些查询语句执行的时间非常长，查询响应没有能够及时回传到应用或者Web服务器层。这也就是为什么需要在被测系统的各个层次都部署KPI监控的原因。

监控关键性能指标：远程监控和监控代理

远程监控是被测服务器通过网络将数据传送给你的性能测试工具监控模块。好处是不需要在被测服务器上安装任何软件，这就绕过了由于内部安全规则导致不能在服务器上安装非标准软件的限制。采用远程监控可实现从一个地点监控多台服务器。

如果在项目中无法使用远程监控，性能测试方案可能会提供一种代理模块，通过在被测服务器上安装这种代理软件，可以对被测服务器进行监控。

性能测试中理想的可扩展性和响应时间模型：随着虚拟用户负载和吞吐率逐步增加，平均响应时间也有平缓且可以接受的增长。糟糕的的可扩展性和响应时间模型：随着虚拟用户负载的增长，响应时间也是同步增长，而响应时间不会保持平稳，甚至开始剧烈波动，产生很大的标准差。

寻找性能拐点：当达到某一特定吞吐率或并发虚拟用户数的时候，性能测试图表中的用例响应时间会出现明显的上升趋势。这意味着应用整体的部署架构达到了服务能力的上限，已经开始影响应用的响应时间。

根源分析：发现问题之后，需要找到问题的根源。这时候，服务器和网络的KPI就派上用场了。这些指标的配置应该按服务器部署架构分层定义，深入观察应用服务器的内部细节。

建立基线：一次成功的性能测试的最后产出应该是一份性能基线数据。这些数据可以在应用发布后持续监控的时候用来做对比。现在你有了这些指标数据，就可以在生产环境监控的时候，用它们来针对用户服务，网络以及服务器设置一些服务等级协议（SLA)。