性能测试原理及性能测试实例分析(3)

　　…………………………..}

　　在上面的例子中，我们主要对每笔交易进行了transaction化。在交易开始时设置开始检测点，交易结束时设置结束检测点，并给loadrunner报出交易状态。实际的脚本中在回收交易响应消息时还进行了拆包，在应用层上对交易状态进行识别，并非例子中只在socket层加以判断。

　　针对查询流程测试，由于loadrunner工具支持基于http的web访问录制功能，我们将考虑采用以录制脚本为主，手工编写脚本为辅的方法，生成查询业务脚本，通过loadrunner来执行。由于查询脚本基本由录制生成http请求和应答，不同的压力测试工具录制会有差别，这里就不再写出查询脚本样例。

　　A:并发登陆测试场景

　　并发登陆750用户/分钟，登陆响应时间在30秒之内。仔细考虑一下，这里的并发登陆750用户/分钟指的是系统能够在1分钟内接受750个用户的登陆请求，而处理的效果如何则在交易终端体现，即登陆响应时间。基于这样的理解，我们把用户性能指标转化为如下的测试场景：

　　从第一秒钟开始，用loadrunner每秒钟登陆13个用户，并保持socket连接，直到1分钟结束，从终端向系统一共发送750个左右的用户登陆请求，系统在一分钟内建立了750个连接。在终端观察并统计登陆响应时间。如果系统不能响应持续增加的登陆请求或平均登陆响应时间大于30秒，并发登陆测试场景都不能算通过。为了帮助用户更加深入了解系统的能力，我们对系统的瞬时并发能力进行测试，即测试系统所能承受的最大的瞬时并发用户登陆连接请求个数。这个场景通过loadrunner在登陆前设置同步点来实现，这个结果将结合上一个结果一同反映系统的登陆处理能力。

　　B:交易流程测试和查询流程测试：

　　在这里我们只对系统的业务负载能力做测试(并发处理能力在登陆测试中已经得到考证)。测试场景如下：

　　在loadrunner中，建立goal-orented的测试场景，以400笔/秒为目标，将调度权交给loadrunner来试图达到这个指标。

　　C: 综合测试：

　　交易流程测试和查询流程测试同时进行。

　　以上的测试场景要求均可在loadrunner中的Controller进行设置完成。

　　测试场景的创建之后，我们的测试任务更加具体化和清晰化。

　　在loadrunner中的controller中开启unix系统资源计数器，weblogic计数器，DB2计数器，检测系统资源消耗情况，并最终和测试结果数据合并，成为分析图表。

　　测试结果可在测试执行完毕后，通过loadrunner工具中的Analysis(分析器)获得。

　　A: 并发登陆测试

依照设计好的测试场景，用loadrunner工具在一分钟内渐增向系统发送登陆请求。分别进行三次，结果如下

　　表格 2登陆测试结果数据表

　　注：这里的登陆成功用户指的是系统接受了登陆请求，并建立了连接。平均响应时间在登陆脚本里设置检测点，由loadrunner工具自动获得。

　　考察系统的瞬时并发处理能力：在完成上一步测试的前提下，逐步增加瞬时并发登陆用户数，直到系统极限。

测试执行结果如下：

　　B: 负载测试

　　交易流程测试：

　　测试结果如下：

　　对于通过网络接口发送的批量业务请求，均在性能指标所指定的时间范围内得到请求成功的反馈消息，说明主机已经处理成功。

　　在通过网络接口发送业务请求的同时，开启IE，通过实际终端界面进行登陆和交易，系统响应时间延长，界面显示和刷新明显变慢，到业务量高峰时期，界面已经不能显示任何信息，处于不可工作的状态。

　　需求说明的是系统正常工作时，每个界面终端不仅应该能够展示己方的交易信息，还要展示其他交易单位的交易信息和系统信息。因此当交易量大的时候，界面需要展示的信息量是巨大的，这本身对终端界面是一个性能考验。

　　查询流程测试：

　　本流程测试在交易流程测试之后进行,以利用其生成的数据。

　　测试结果基本满足性能指标。

　　综合测试

　　由于交易流程测试的未通过，本测试已经不能执行。

　　A:并发测试结果分析

　　根据上述的并发测试响应时间表，我们可以得出以下的结论：

　　被测系统在一分钟内并不能接受750个用户的登陆请求，其可接受的登陆请求用户数大概为490个左右。在这样的条件下，登陆响应时间在用户要求范围之内。

　　被测系统的瞬时并发处理能力约为122个用户。

　　B: 交易流程测试结果分析及性能评价

　　根据交易流程测试结果可知，通过脚本程序进行业务行为，发送业务请求消息到回收主机处理回应消息，这段时间系统是顺畅的，反应也是迅速的，但是在终端界面却不能即时展现消息。这说明信息的回馈通路在终端界面出现了性能瓶颈。当界面需要在短时间内展示大量交易信息时，已经不能承受负荷。这与终端采用java applet技术有关。

　　C: 查询流程测试结果分析

　　查询流程基本符合性能指标。

　　需要说明的是，实际中，以上每个场景的测试都执行了多次，中间件参数进行了多次的调优。从以上测试的结果分析也可以看出，我们的性能测试瓶颈不是出现在中间件产品上，而是在自身开发的程序上。

原文转自：http://www.ltesting.net