论文部分内容阅读
摘要:在交易量不断增长的情况下,X银行原有的个人网上银行系统从架构到性能都无法满足当前的需求,在这种情况下,X银行计划对原有的网上银行系统进行优化和升级。
关键词:性能测试;沟通;Load Runner
中图分类号:TP303 文献标识码:A文章编号:1007-9599 (2011) 11-0000-02
Online Banking System Performance Testing Records
Fang Chengyin,Wu Weiwei
(Ministry of Industry and Information Technology Computer and Microelectronics Industry Development Research Center(China Software Testing Center),Beijing100048,China)
Abstract:In trading volume growing conditions,X bank original personal online banking system from architecture and performance can not meet the current needs,in this case,the X bank plans to original online banking system optimization and upgrade.
Keywords:Performance testing;Communication;Load Runner
我曾参与X银行营销服务系统的网上银行性能测试部分,该系统使用的数据库服务器、应用服务器均部署在北京机房,核心系统部署在山东临沂,北京机房与山东临沂由专线连接,见图一。本次的合作方共有三方,开发商、银行核心系统负责方及测试方,见图二。
图一:网络拓扑图
图二:合作三方
此次测试,由于项目经验的不足,与开发商及核心系统间的沟通比较被动,由于沟通不畅造成了大量时间耽误。在这里,深刻体会到沟通的重要性。由于前期沟通机制不够灵活,先前的沟通模式是单向沟通,即测试方向开发商提出需求,开发商再向核心系统负责方提出测试方的需求,核心系统再向开发商返回测试方所需的需求,最后开发商再向测试方反馈由核心系统返回的需求。如图三所示。由于间接沟通太过于浪费时间,后期改变了沟通机制,如图四所示,提高了效率。此次项目主要存在以下问题:
图三:单向间接沟通
图四:直接沟通
一、测试环境不独立,测试行为被动
由于客户无法提供一个单独的性能测试环境,我们的性能测试工作与核心系统负责方的性能测试在同一个环境下进行,而双方测试在同时进行,在我方进行性能测试时间与核心系统测试方冲突时,核心系统擅自切断核心系统与北京服务中心的专线,致使我方测试需等核心系统测试方测试完后恢复网络方可重新测试,测试过程很是被动造成时间上的严重浪费,使项目的成本增加。
二、数据准备不充分,性能测试进展不顺
因为测试数据由核心系统负责方获取,但是在前期的沟通中,未将所需准备的数据写清楚,在进场测试后,因为数据的不够充分,导致测试中断。并且在项目进行中,由于数据的意外删除,导致我方等待核心系统重新提供数据。核心系统负责方在准备数据过程中也显得过于散慢,在沟通过程中未提高客户的积极性。
三、未努力争取利益,给自己造成额外的工作量
核心系统负责方所提交的数据未经验证,测试方与开发商在收到数据后,还得对数据进行验证,对通过验证用户进行审批,才能进行银行的相关操作。由于流程的繁琐,开发商与测试方在准备数据的过程中就消耗了大量的精力与时间浪费,造成项目的时间后延。在后期的工作中,将吸引教训,在前期沟通时,应该与客户明确责任,严格按责任分配完成自己的任务。
单从沟通角度,在后期的工作中,将引以为戒,努力作到以下几点:
(一)态度诚恳,氛围和谐
沟通中营造开放的沟通氛围,要明确沟通的重要性,创造一个相互信任,有利于沟通的小环境。双方作到坦诚相待时,消除彼此间的隔阂,增加沟通双方的信任度,从而达成双方合作。在沟通中创造良好的沟通气氛,保持良好的沟通意向和认知感受性,使沟通双方在沟通中始终保持亲密、信任的人际关系,这样一方面可以维持沟通的进行,另一方面会使沟通朝着正确的方向进行。
(二)充分准备,明确目的
沟通要有认真的准备和有明确的目的性,沟通前要先对沟通的内容有正确、清晰的理解,理解沟通要解决什么问题,达到什么目的。项目组成员要统一思想,协调行动,确保沟通的内容有针对性,语意确切、通俗、具体。
(三)多听少讲,用心感悟
在对方发言时要保持积极的态度,以便在谈话中获取更多的信息,去粗取精,去伪存真,由此及彼,由表及里。在沟通过程中必须谨慎行事,关键性话语不要随意出口,要细心领会对方提出问题的实质,才有可能找出摆脱难题的办法。
四、总结与提高
经验在本次性能测试的过程中,我们遇到一些问题,通过解决这些问题,从中获得了一些性能测试的经验。
收获一:学习Load Runner操作,修改、调试脚本
在以前的性能测试过程中,对验证码等都是要求客户屏蔽或者删除,因此从未进行过关联操作。在这次测试过程中,由于客户提出新的要求,不对验证码进行删除,而测试方在测试过程中只能采取关联,从而使测试能顺利进行。实践的机会可以尽快掌握操作。Load Runner的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯,以此达到模拟实际操作的目的,因此我们只需将要测试的交易或功能点所需要组装的报文传送给后台服务器即可,而不必像功能测试那样,按部就班地重现每一步操作。
在脚本录制过程完后,回放成功后,进入测试阶段却一直不能成功,提示信息为服务器返回错误,最早一直在对关联做检查,当全部的关联都成功后,还是处于不能测试,客户端登录也可以访问成功。在对服务器进行检查后,确认没有问题,却发现在LOADRUNNER设置中语言栏设置为默认英文,最终修改成ZH-CN,测试成功。
收获二:脚本录制有讲究
之前我做性能测试,对于脚本录制脚本都是放在ACTION中,在INIT中没有任何操作,发现在脚本运行过程中,很多操作都是在重复进行,造成系统的无意义繁忙。因此在此次测试中,只将关注点放在ACTION中,其它操作都放在INIT部分及END部分。有效的降低了系统的负载压力。由于Load Runner的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯,因此它会跳过在应用程序前台进行的校验,所以在脚本回放的时候一定要注意在脚本中提前进行这些校验或改由人工控制,以保证发送报文的正确性。
关键词:性能测试;沟通;Load Runner
中图分类号:TP303 文献标识码:A文章编号:1007-9599 (2011) 11-0000-02
Online Banking System Performance Testing Records
Fang Chengyin,Wu Weiwei
(Ministry of Industry and Information Technology Computer and Microelectronics Industry Development Research Center(China Software Testing Center),Beijing100048,China)
Abstract:In trading volume growing conditions,X bank original personal online banking system from architecture and performance can not meet the current needs,in this case,the X bank plans to original online banking system optimization and upgrade.
Keywords:Performance testing;Communication;Load Runner
我曾参与X银行营销服务系统的网上银行性能测试部分,该系统使用的数据库服务器、应用服务器均部署在北京机房,核心系统部署在山东临沂,北京机房与山东临沂由专线连接,见图一。本次的合作方共有三方,开发商、银行核心系统负责方及测试方,见图二。
图一:网络拓扑图
图二:合作三方
此次测试,由于项目经验的不足,与开发商及核心系统间的沟通比较被动,由于沟通不畅造成了大量时间耽误。在这里,深刻体会到沟通的重要性。由于前期沟通机制不够灵活,先前的沟通模式是单向沟通,即测试方向开发商提出需求,开发商再向核心系统负责方提出测试方的需求,核心系统再向开发商返回测试方所需的需求,最后开发商再向测试方反馈由核心系统返回的需求。如图三所示。由于间接沟通太过于浪费时间,后期改变了沟通机制,如图四所示,提高了效率。此次项目主要存在以下问题:
图三:单向间接沟通
图四:直接沟通
一、测试环境不独立,测试行为被动
由于客户无法提供一个单独的性能测试环境,我们的性能测试工作与核心系统负责方的性能测试在同一个环境下进行,而双方测试在同时进行,在我方进行性能测试时间与核心系统测试方冲突时,核心系统擅自切断核心系统与北京服务中心的专线,致使我方测试需等核心系统测试方测试完后恢复网络方可重新测试,测试过程很是被动造成时间上的严重浪费,使项目的成本增加。
二、数据准备不充分,性能测试进展不顺
因为测试数据由核心系统负责方获取,但是在前期的沟通中,未将所需准备的数据写清楚,在进场测试后,因为数据的不够充分,导致测试中断。并且在项目进行中,由于数据的意外删除,导致我方等待核心系统重新提供数据。核心系统负责方在准备数据过程中也显得过于散慢,在沟通过程中未提高客户的积极性。
三、未努力争取利益,给自己造成额外的工作量
核心系统负责方所提交的数据未经验证,测试方与开发商在收到数据后,还得对数据进行验证,对通过验证用户进行审批,才能进行银行的相关操作。由于流程的繁琐,开发商与测试方在准备数据的过程中就消耗了大量的精力与时间浪费,造成项目的时间后延。在后期的工作中,将吸引教训,在前期沟通时,应该与客户明确责任,严格按责任分配完成自己的任务。
单从沟通角度,在后期的工作中,将引以为戒,努力作到以下几点:
(一)态度诚恳,氛围和谐
沟通中营造开放的沟通氛围,要明确沟通的重要性,创造一个相互信任,有利于沟通的小环境。双方作到坦诚相待时,消除彼此间的隔阂,增加沟通双方的信任度,从而达成双方合作。在沟通中创造良好的沟通气氛,保持良好的沟通意向和认知感受性,使沟通双方在沟通中始终保持亲密、信任的人际关系,这样一方面可以维持沟通的进行,另一方面会使沟通朝着正确的方向进行。
(二)充分准备,明确目的
沟通要有认真的准备和有明确的目的性,沟通前要先对沟通的内容有正确、清晰的理解,理解沟通要解决什么问题,达到什么目的。项目组成员要统一思想,协调行动,确保沟通的内容有针对性,语意确切、通俗、具体。
(三)多听少讲,用心感悟
在对方发言时要保持积极的态度,以便在谈话中获取更多的信息,去粗取精,去伪存真,由此及彼,由表及里。在沟通过程中必须谨慎行事,关键性话语不要随意出口,要细心领会对方提出问题的实质,才有可能找出摆脱难题的办法。
四、总结与提高
经验在本次性能测试的过程中,我们遇到一些问题,通过解决这些问题,从中获得了一些性能测试的经验。
收获一:学习Load Runner操作,修改、调试脚本
在以前的性能测试过程中,对验证码等都是要求客户屏蔽或者删除,因此从未进行过关联操作。在这次测试过程中,由于客户提出新的要求,不对验证码进行删除,而测试方在测试过程中只能采取关联,从而使测试能顺利进行。实践的机会可以尽快掌握操作。Load Runner的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯,以此达到模拟实际操作的目的,因此我们只需将要测试的交易或功能点所需要组装的报文传送给后台服务器即可,而不必像功能测试那样,按部就班地重现每一步操作。
在脚本录制过程完后,回放成功后,进入测试阶段却一直不能成功,提示信息为服务器返回错误,最早一直在对关联做检查,当全部的关联都成功后,还是处于不能测试,客户端登录也可以访问成功。在对服务器进行检查后,确认没有问题,却发现在LOADRUNNER设置中语言栏设置为默认英文,最终修改成ZH-CN,测试成功。
收获二:脚本录制有讲究
之前我做性能测试,对于脚本录制脚本都是放在ACTION中,在INIT中没有任何操作,发现在脚本运行过程中,很多操作都是在重复进行,造成系统的无意义繁忙。因此在此次测试中,只将关注点放在ACTION中,其它操作都放在INIT部分及END部分。有效的降低了系统的负载压力。由于Load Runner的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯,因此它会跳过在应用程序前台进行的校验,所以在脚本回放的时候一定要注意在脚本中提前进行这些校验或改由人工控制,以保证发送报文的正确性。