51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 4042|回复: 6

[原创] 使用LoadRunner调用WebSphere接口进行某保险小核心性能测试实例(二)测试准备

[复制链接]

该用户从未签到

发表于 2014-7-4 16:29:33 | 显示全部楼层 |阅读模式
经过前期调研后,开始进行测试准备工作。本次将测试方案放在测试准备活动当中,一般情况应该作为测试调研之后的产出物,包括计划和方案。全部测试准备工作分为三个部分,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,响应时间都要数字化。并且一定要三方确认。
感觉这次写的比较乱,请大家批评指正,我会针对内容进行更新修改。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复

使用道具 举报

  • TA的每日心情
    无聊
    昨天 09:12
  • 签到天数: 918 天

    连续签到: 3 天

    [LV.10]测试总司令

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



        不错的原创,大家有什么建议可以提出来~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2014-7-4 16:50:40 | 显示全部楼层
    感觉业务中多模块直接的数据传输是问题,先要明确有哪些情况,才能知道用哪些方法解决。总体感觉业务比较复杂,完全弄清楚,整理出一套完整的LR脚本实在不容易。我觉得LZ肯定特别有成就感。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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


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

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

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

    使用道具 举报

    该用户从未签到

     楼主| 发表于 2014-7-4 17:05:57 | 显示全部楼层
    回复 2# lsekfe



        感谢支持!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2014-7-4 17:25:34 | 显示全部楼层
    本帖最后由 fiskeryang 于 2014-7-5 00:15 编辑

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

    使用道具 举报

  • TA的每日心情
    奋斗
    2015-4-16 14:55
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    发表于 2014-7-11 10:08:08 | 显示全部楼层
    支持,之前也做过保险的性能测试
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-3-28 21:49 , Processed in 0.079611 second(s), 29 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表