SOAP Over JMS 服务调用的各个属性说明：
QueueConnectionFactory:连接工厂的默认 JNDI 实体
JNDI name Request queue:JNDI 请求队列名字
JNDI name Receive queue:JNDI 接收队列名字
Timeout:请求超时设置
Communication style:通讯形式（包括仅仅请求和请求应答）
Content:请求信封
JMS Properties:JMS 的一些属性设置（对于 IBM WAS 必须要有 targetService 属性）
Initial Context Factory:JNDI 的初始会话工厂
Provider URL:服务提供地址
下面是一次完整的 JMS 请求与 JMS 响应 SOAP 数据：
JMS Request <soapenv:Envelope> <soapenv:Body> <tns0:getAuEmpPositionId> <ev_id>6098</ev_id> </tns0:getAuEmpPositionId> </soapenv:Body> </soapenv:Envelope> JMS Response <soapenv:Envelope> <soapenv:Header/> <soapenv:Body> <p150:getAuEmpPositionIdResponse> <getAuEmpPositionIdReturn xsi:nil="true"/> </p150:getAuEmpPositionIdResponse> </soapenv:Body> </soapenv:Envelope> |
设计高效的测试用例集
压力测试或者系统测试不同于功能测试，测试的重点不在系统产品是不是满足设计需求。它所看重的是系统在大的用户量和负载情况下的可靠性以及系统响应 , 它目标是测试系统的执行效率，特别是在较短时间内系统负载快速增长时系统的相应速度。在实际的测试过程中，大量用户同时访问的系统节点也可能成为产品潜在的效率瓶颈。因此 , 压力测试和系统测试也往往是在功能测试之后进行。
对于普通的软件系统 , 产品的瓶颈可能会在数据库服务器上，Web 服务器上，而对于 SOAP 服务系统测试，Web Services 服务器和 JMS 服务器是客户端请求的主要节点 , 同时，主要业务逻辑的处理也都分布在这些节点上，它们很有可能成为系统访问的瓶颈，如果这些节点出现问题，那么对整个系统的效率会有致命的影响，也是压力测试和系统测试要优先考虑的。
改进测试策略、测试方法、测试过程，使用高效的测试用例集，从而保证产品质量。这个是主要目的，也是最直接的目的。一个高效的测试用例集应包含以及适应如下要素：
在什么时候确定要执行系统测试
如何去检测并解决系统性能和负载问题
收集监视服务器性能数据（I/O,CPU,MEM）
尽量减少因为个人配置和某些测试用例而造成系统出现错误和瓶颈
所有测试工作都得到有效协调并目标一致
当已经确定了所需的 JMeter Samplers，并且在此基础上设计出一个通用的测试计划，那么就可以构建我们的测试脚本了。本文的测试用例以及最终的测试计划也是建立在这些要素之上。
测试计划（Test Plan）描述了测试运行过程中 JMeter 的执行顺序、过程以及步骤，一个完整的测试计划包括一个或者多个线程组 (Thread Groups)、循环控制器（Loop Controllers）、监听器 (Listener)、逻辑控制器（Logic Controller）、定时器（Timer）、断言（Assertions）、配置信息（Config Elements）等。
在测试计划中添加一个用户定义变量配置元素（User Defined Variables）, 可以在里面定义服务器地址，日志路径，超时限制等变量，提供脚本重用。同时添加两个用户组，一个是 SOAP Over HTTP Group，一个是 SOAP Over JMS Group。在每个用户组下面分别添加一个总的循环控制器（Loop Controller），用以控制脚本循环次数。在总循环控制器下面添加随机选择器（Random Selector）用以随机选择运行测试脚本。下图是我们整个的 Test Plan。
图 4. 设计完成之后的 SOAP 测试计划
