使用LoadRunner调用WebSphere接口进行某保险小核心性能测试实例（二）测试准备

low1210

经过前期调研后，开始进行测试准备工作。本次将测试方案放在测试准备活动当中，一般情况应该作为测试调研之后的产出物，包括计划和方案。全部测试准备工作分为三个部分，1.方案、案例的准备；2.环境准备；3.脚本准备。下面将针对这三个部分，分别描述。
方案、案例准备：
测试方案中重点体现测试的目标，范围，测试模型，测试策略以及对环境的定义，还包括测试准则，过程输出定义等。测试准则，过程输出定义，测试背景等一般的套话就不描述了。
测试目标：
        获取典型交易响应时间、交易成功率、资源消耗等指标；
        网络直销系统业务处理能力是否满足性能需求，符合上线条件；
        换取系统最大、最优性能拐点；
        定位性能瓶颈，为项目组性能调优提高参考；
        极限压力下的性能表现；
        验证系统能否稳定运行；
测试范围：
        基准测试；
        单交易负载测试；
        混合场景容量；
        稳定性测试；
测试模型:
选取的原则为:1.交易量大；2交易路径复杂；3业务重要,数据量大。选具体业务交易的时候，由于是新系统，业务人员参与不够。通过保险方IT人员确认，选取了一支查询交易，两支业务必须接口。异步选取两支交易，具体如下图：
信息处理方式        交易名称        占比        接入方式
同步        询价        40%        前脸
同步        核保        30%        前脸
同步        承保        30%        前脸
批量        **承保        50%       
批量        **承保数据同步        50%       
其中，核保交易为承保交易的前提交易，根据保险产品的不同，核保交易处理的数据量不同，会影响响应时间，因此核保根据产品划分为小数据量，中数据量，大数据量来进行测试。**承保为**承保数据同步的前提交易，交易数据量为3W笔。完成时间为12小时内。
测试策略：
由于是针对WebSphere发布的web service接口进行测试，使用web service协议调用发布接口，进行测试。针对接口的测试比较方便，只要实现接口的调用，剩下的就是数据的组织了。
案例部分就是描述了一下场景如何生成，比如基准测试为单交易迭代100次，这里就不赘述了。针对测试范围的几个场景，都是常用的，如果需要请留言告知，我在把案例po上来。
环境准备：
硬件环境包括：app服务器，数据库服务器，压力发起机等
IP                类型        数量         型号        资 源
                AP        2        Hp        2*8C32G
        DB        1        IBM 750        20*power 7
压力发起机为单台PC
软件环境包括：程序，操作系统，数据库，性能测试工具，监控工具
操作系统        AIX、RedHat linux6.3
数据库        Oracle 11g 11.2.0.3.0
中间件        WebSphere 7.0
测试工具        LoadRunner11
监控工具        Nmon
数据库使用Oracle自带的awr监控，中间件使用WebSphere自带的控制台监控
一般硬件系统安装，中间件配置，程序发布等工作，有开发和配置管理员完成。测试人员搞定压力机环境以及监控软件安装。
脚本准备：
本次测试系统通过WebSphere发布的web service服务，因此脚本协议采用web service协议。首先web service服务，会为每个服务生成一个标准的WSDL，获取接口对应wsdl，直接使用loadrunner提供的WebSphere协议的脚本导入即可。

黑线连接为点击此处弹出框体，中间的输入框为WSDL的url，具体的情况大家可以百度一下，有很详细的使用指南。
成功后工具会自动将要传输的xml格式的报文解析出来，直接在工具中将你需要输入的字段值输入即可。
根据以上的说明，很轻松将询价交易的脚本调试成功。当进行核保与承保生产的时候产生了问题，在xml文件的body中使用 cdata这种格式，里面嵌套的是另一个整套格式xml文件，导致每次发送出去后，都会报解析流错误。后于开发沟通，此部分内容是以对象的形式传过去的，接口服务不做解析直接发送给相应服务进行处理。最终确定使用工具无法实现，最终请开发帮忙编写了一个调用web service服务接口的程序，进行报文的收发，使用JAVA VUSER调用该程序，完成了脚本。过程说起来简单当时可以愁白了少年头。
其实调用web serivice接口服务的代码，是可以使用JDK的方法自动生成的，有兴趣的小伙伴可以百度谷歌一下，当然调用对象的方法来实现报文的传输，就需要你在工具的IDE里面自己编写了。
文字表述苍白的很，小伙伴们有啥问题尽情的提，后续可以的话我将脚本内容，po上来供大家玩玩。
测试数据的准备，根据业务的前后关系，核保交易为承保提供数据，批量数据由前脸方提供。
测试的准备工作这个阶段基本完成了，这个阶段的准出为，测试环境准备完毕，脚本调试完成，测试数据准备完成。
本阶段在方案评审时，由于没有业务人员的参与，最后口头确定的是跑出了个指标看看，等于说所见即所得。直接导致后续工作的扯皮，业务人员不认，开发人员不改。所以在方案阶段我们的性能指标一定要尽量明确，比如TPS，响应时间都要数字化。并且一定要三方确认。
感觉这次写的比较乱，请大家批评指正，我会针对内容进行更新修改。

lsekfe

经过前期调研后，开始进行测试准备工作。本次将测试方案放在测试准备活动当中，一般情况应该作为测试调研之 ...
low1210 发表于 2014-7-4 16:29

    不错的原创，大家有什么建议可以提出来~

gaha

感觉业务中多模块直接的数据传输是问题，先要明确有哪些情况，才能知道用哪些方法解决。总体感觉业务比较复杂，完全弄清楚，整理出一套完整的LR脚本实在不容易。我觉得LZ肯定特别有成就感。

low1210

感觉业务中多模块直接的数据传输是问题，先要明确有哪些情况，才能知道用哪些方法解决。总体感觉业务比较复 ...
gaha 发表于 2014-7-4 16:50

模块间的传输没有考虑，直接在外面调用的接口。

第一次做保险业务，确实对保险业务特点不是很熟悉。

个人觉得保险系统的性能测试要关注不同业务产品，因为不同产品数据量有很大的差异，直接导致系统资源损耗不同。以本次测试为例，简单业务产品只包括一个保单（单个主险），而复杂的可能有很多保单（一主险多副险多责任），响应时间会有很大差异。

low1210

回复 2# lsekfe



    感谢支持！

fiskeryang

我们的web服务测试也类似  
传输的参数和返回的值大多是对象类型  经过序列化和压缩之后的生成字符串
只能在.net 里吧这些处理好 再使用loadrunner来调用
大量的接口和复杂数据对象  生成测试数据工作量都不小

zhjl5661990

支持，之前也做过保险的性能测试