第二条路线上主要运行的是查询指令信息。
查询指令产生时，通过http协议访问weblogic上的web服务器和应用服务器上的相应组件，以JDBC接口访问后台的DB2数据库，并把数据库返回的结果发送至终端界面。
在本条流程线上的加压主要验证weblogic处理能力，数据库中索引是否创建合理。
两条流程线相对独立，但又是互相依赖的。由于是对同一个数据库系统进行读操作和写操作，查询流程的结果依赖于交易流程数据的产生，交易流程的产生的数据又通过查询流程得到验证。在进行压力测试时，两者的协同会对数据库形成压力的冲击。
鉴于以上分析，结合用户性能指标，我们决定把本次性能测试分解为如下几个子测试来进行。A: 并发登陆测试：750个终端一分钟内并发登陆系统，并且响应时间在30秒之内。
B: 业务负载测试
此下又有三个子测试。
- 交易流程测试：多个终端发起交易请求，逐渐加压，以达到300笔/秒的压力为限。
- 查询流程测试：多个终端进行查询，逐渐加压，以达到400笔/秒的压力为限。查询成功与否以所请求的web页面完全展现为标准。（查询响应能力其实和数据库中的数据量有关系，后来和用户进一步确认，基础数据为30万条）
- 综合测试：
在上面两种测试都通过的情况下，进行综合测试。
2)性能测试的执行过程，性能测试依照下面的步骤来进行：
本次压力测试采用MI公司的loadrunner工具，脚本编辑和编译工作在VU Generator(脚本作坊)中进行。
理想的脚本是对现实世界的业务行为进行了完全无误的模拟，这其实是不可能的。我们的目标是使模拟的误差在我们认可的范围之内，并能有方法加以控制。
针对并发登陆测试和交易流程测试，由于两者运行机理相同，都是终端调用socket client，和交易前置的socket server建立连接，将请求消息发送至交易前置机。我们考虑采用将此部分java socket程序编入测试脚本程序，生成登陆和交易业务脚本，通过loadrunner来执行。这样做的好处是绕过终端IE界面复杂的处理逻辑，直接施压在前置机上（这种方式同时也带来了偏差，在执行测试场景时通过其它方法得到了一定的弥补）。
脚本除了要实现与前置机的socket连接，业务发送等功能，还要建立用户信息数据池，设置检测点、异常退出点，为脚本执行后的结果统计和分析提供正确的依据。
交易业务脚本内容略。部分如下：
public class Actions {/*登陆变量初始化*/ProtocolManager protocol;//ProtocolManager为实现socket连接的类 ServiceName service; //ServiceName对服务端的信息进行了封装，包括IP地址和端口号。LoginMessage login；//LoginMessage为登陆时需要向服务器发送的消息，待服务器确认并返回回应消息时，登陆成功。protocol = new ProtocolManager(); //创建ProtocolManager类的protocol对象service = ServiceName.getInstance();//获得ServiceName的实例login=new LoginMessage();//创建LoginMessage类的login对象service.setIP("200.31.10.18");//设置服务端的IP地址service.setPort(17777);//设置服务端的端口号/*设置登陆消息*/ login.serUserName(lr.eval.string(“{loginName}”));//从数据池里读出用户名，设置在login成员变量里login.setPasswd(“1234”);//数据库中添加的用户密码都为1234/*发送登陆消息*/protocol.login(login);//发送登陆消息lr_start_transaction("trade");//交易开始点TradeMessage trademessage;//生成交易消息/*设置交易消息*/………………………….
………………………….
/*发送交易消息*/………………………….
………………………….
if(sendfail)lr_end_transaction("trade", LR_FAIL);//如果发送交易消息失败，交易结束，返回。/*循环回收主机返回的处理信息*/…………………………
…………………………
if(recievefail)lr_end_transaction("trade", LR_FAIL);//如果不能接收到主机处理回应消息，交易结束，返回。if(recievesuccess)lr_end_transaction("trade", LR_PASS);//如果接收到主机成功处理的回应消息，交易结束，返回。…………………………..
}在上面的例子中，我们主要对每笔交易进行了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进行设置完成。
测试场景的创建之后，我们的测试任务更加具体化和清晰化。
- 第三步：运行测试场景，同步监测被测系统性能行为
文章来源于领测软件测试网 https://www.ltesting.net/
