51Testing软件测试论坛

标题: [原创]X银行营销服务系统性能测试小记 [打印本页]

作者: xingcyx 时间: 2005-8-12 09:37
标题: [原创]X银行营销服务系统性能测试小记
[原创]X银行营销服务系统性能测试小记

1、背景
本次性能测试的系统是X银行营销服务系统总行版，该系统使用的数据库服务器、应用服务器均布署在总行机房，各地分行通过WEB方式登录访问本系统。系统上线后的总用户数（包括各分行、支行主管，客户经理等）在5000左右。
该系统采用DB2数据库、WebLogic应用服务器。
本次性能测试进入的条件是系统的代码已经基本完成并经过功能测试。

2、测试计划
在确定了本次性能测试的要点后，我们初步拟定一份性能测试计划，提交给客户，并获得了客户的认可。在本文中不列出项目测试计划中的所有内容，仅就主要问题进行说明。
测试范围：在真实业务局域网测试环境下，对系统实施并发性能测试的同时，监控Web 服务器和数据库服务器的系统资源，以及数据库资源的使用情况。
测试内容：并发性能测试、系统资源监控。
测试方法与工具：采用自动测试与人工测试相结合的测试方法，测试工具使用LoadRunner。
测试资源：测试环境及测试数据准备。

3、测试用例
确定了测试计划，我们针对该系统的特点，从中挑选出三个有代表性的功能点，作为本次性能测试的用例。我们认为作为银行的营销服务系统，最常使用且对于系统的整体性能有着较大影响的是“客户信息查询”和“客户对账单查询”两个模块。因此，我们设计了三个单交易性能测试用例，分别是：“用户签到/签退”、“客户信息查询”、“客户对账单查询”。然而客户却对此提出异议，他们认为我们设计的测试用例数量太少，要求我们的测试用例应包含更多的功能模块。经过会议讨论，最终我们根据客户给出的一份性能测试大纲，针对其中提出的测试内容、测试策略，以及测试目标，将单交易测试用例增加到十四个。
测试用例采用以下格式：
案例名称并发
用户数数据量操作步骤备注
要求清晰地描述出详细的操作步骤。

4、测试数据
针对以上设计的测试用例，需要准备大量的业务数据。本次性能测试的环境即系统上线后真实运行的环境，所有的业务数据均来自X银行的真实核心系统（通过ETL转换），数据量已经能满足测试的需要。
由于测试用例中要求执行并发操作的时候使用不同身份的用户登录系统，因此在测试开始前需要准备一批具有不同身份的用户名（包括各分支行的主管以及客户经理），并且要有相应的操作权限。
对于“积分转移”、“积分兑换”、“礼品兑换”等等交易，则需要提供一批卡上有足够积分的客户理财卡号。
以上测试数据由X银行负责提供，在性能测试执行之前提供给我们。

5、测试脚本
使用性能测试工具LoadRunner录制并调试测试脚本，对相关的输入项进行参数化。

6、测试实施
在LoadRunner中执行测试脚本，实施性能测试。对于每个单交易测试脚本各执行一轮测试，并按一定的用户比例设计出一个混合交易场景，令其自动持续运行五小时左右，观察系统的性能表现。每次执行的结果文件均保存下来，待测试完成后连同性能测试报告一并交付客户确认。在此过程中，需要监视相关的系统资源使用情况，包括：应用服务器和数据库服务器的所有系统资源指标，所有数据库资源指标。

7、测试结果
经过本次性能测试，发现了系统五个主要的性能问题。我们与程序开发人员一同分析问题产生的原因，并给出改进建议，一起记录到测试报告中。其中的一个问题在性能测试报告提交客户之前已经过优化，得到显著改进。

8、测试结论
测试结果显示，系统性能能满足测试目标，交易并发数达到或超过30个，批量交易（查询记录50条以上的交易）并发数也能达到或超过10个，交易平均响应时间在2－12秒内，90％平均响应时间在2－15秒间完成。
混合交易案例持续运行5小时，运行结果正常，系统没有报任何错误，系统稳定，可用率应达到100％。
另外如在ETL批处理期间运行营销服务系统，系统性能明显下降，建议ETL批处理在夜间处理，避免影响系统的正常运行。

[ Last edited by xingcyx on 2005-8-12 at 10:27 ]

[ 本帖最后由 xingcyx 于 2006-1-20 17:14 编辑 ]

作者: xingcyx 时间: 2005-8-12 09:38
9、经验
在本次性能测试的过程中，我们遇到一些问题，通过解决这些问题，从中获得了一些经验。现总结如下：
 问题一
在我们对系统进行测试的过程中，某些操作是相关联的。例如我们测试“查看客户资产历史”这个交易的系统响应时间，这时需要先列出客户的基本信息，选中一个客户，点击打开另一个页面，才能查看到该客户的资产历史信息，同时，在测试脚本中需要对所选择的客户编号做一个参数化，但由于LoadRunner不提供像WinRunner或QTP一样识别页面对象的功能，如果在Vugen中直接抓取页面上显示的客户编号去参数化，实现起来将十分烦琐。考虑到在以上那两步操作中，第一步“列出客户基本信息”只是辅助的操作，而第二步操作“查看客户资产历史”才是我们要测试的功能点，因此我们忽略了这二者之间的关联性，仅对第二步操作中的客户编号进行参数化。（只要服务器端对此不加验证，甚至我们将第一步操作都忽略掉，也是可行的）。
结论：LoadRunner的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，以此达到模拟实际操作的目的，因此我们只需将要测试的交易或功能点所需要组装的报文传送给后台服务器即可（因为我们关注的只是系统的性能，不是功能），而不必像功能测试那样，按部就班地重现每一步操作。
 问题二
在测试过程中，我们发现有一个查询交易的系统响应速度特别慢，无论是在Controller中使用单个虚拟用户执行脚本，还是在Vuser中直接运行，情况均是如此，然而当我们用手工进行同样操作的时候，响应时间却明显地小于工具统计出来的时间，也就是说，在LoadRunner中模拟操作的结果与真实操作的结果明显不一致。经过反复尝试与观察，我们才终于找到问题的原因所在：该查询交易是通过客户的证件号码查询客户信息，当用户输入客户的证件号码时，如果没有选择证件类型，系统会自动将证件类型设置为默认值“身份证”。按“证件类型+证件号码”为组合索引查询客户信息表，查询速度极快，而在我们录制脚本时，忽视了“证件类型”这项输入，只有“证件号码”，因此查询的效率大为降低。解决办法：只需在测试脚本中，对CertType（“证件类型”）一项赋值为“A”（“身份证”），此时在LoadRunner中重新运行该脚本，响应速度提高，统计结果与实际完全一致！
结论：LoadRunner的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，以此达到模拟实际操作的目的，因此我们在测试脚本中组装发送到服务器端的报文时，注意一定要和实际操作时的发送报文完全一致，这样才能保证测试的结果与真实情况相吻合。这就要求在测试正式开始执行时，要对测试脚本进行反复的调试，通常的做法是：在Vugen中执行一遍脚本，统计执行某个事务的时间，再用手工实际做一遍同样的操作，大体上比较一下，确保与实际估算的时间没有太大出入后，再逐渐增加并发用户数，正式开始性能测试。
 问题三
在我们的每个测试脚本中的init部分，都录制了登录系统的操作，并且对登录的用户名进行了参数化，使用各种不同身份的用户（分行主管、支行主管、客户经理等）进行相同的操作。在并发测试过程中发现对某些查询交易测试的结果波动较大，系统响应时间从零点几秒到几十秒不等。经检查后发现原因在于：使用不同身份的用户登录系统后，在输入查询条件后，点击查询按钮后会将根据该用户的身份，将其所属的分行机构号、支行机构号、客户经理编号等一并提交，因此在脚本中，就必须根据不同的用户身份，分别将其对应的分支行机构号等也运用参数提交，否则在执行脚本时就会出现查询不到记录或查询速度变慢等各种问题。解决方法有三个：1、修改脚本，使其能够依据用户的身份分别传送相应参数，2、针对不同类型的用户使用不同的脚本分别测试。3、输入参数使用统一的用户类型。在实际中，我们为了简化脚本的复杂度，节省对脚本编程的时间，采取的是第三种方法。
结论：由于LoadRunner的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，因此它会跳过在应用程序前台进行的校验，所以在脚本回放的时候一定要注意在脚本中提前进行这些校验或改由人工控制，以保证发送报文的正确性（如操作权限的控制等）。
 问题四
测试多用户并发登录系统的时候，从虚拟用户图和事务图上发现，总有一部分用户在登录的时候要等待很长时间，用户登录的最小时间与最大时间相差非常大。于是我们在让脚本自动运行的同时，手工再登录一个用户，发现无论如何都不会发生等待的情况，多次试验的结果均是如此，也就是说LoadRunner测试的结果与实际结果再次发生了偏差！经过反复的调试，以及与程序开发人员沟通，我们终于发现问题的原因所在：在用户登录系统的时候，系统会自动记录登录用户的信息，并产生一个登录ID，以此ID做为主键，向数据库插入记录。因此当大量用户在极短的时间内同时登录时，就有可能出现生成相同的登录ID的情况，此时便会造成数据库中的主键冲突，导致用户等待很长时间或登录失败。而我们手工测试时却无法做到在很短的时间内同时登录，因此很难用手工重现此种情况。通过LoadRunner的模拟表现出来的状况，正是我们测试出程序存在的性能问题，并非与实际结果的偏差。
还有一个例子，在第二轮性能测试中，同样发生了类似的情况。在本系统中，如果同一个用户登录后，未正常退出超过5次，系统将会把该用户锁住，使其无法再次登录，而我们用于参数化的用户名个数有限，因此当脚本使用大量用户同时登录时，很容易造成同样的用户登录系统而未签退的情况发生（脚本正在执行，还未能退出），此时将会造成许多用户操作的失败。
结论：使用LoadRunner可以模拟出大量用户同时对系统操作的情况，而这些情况通过手工往往是很难重现出来的。例如大量用户在同时对系统做某些操作时，很容易造成数据库的死锁、锁等待、主键冲突、数据混乱等等问题，因此在做性能测试的同时，也常常可以连带测试出系统的一些隐蔽的“缺陷”。在本次性能测试中，这种例子是很多的。对待此类“缺陷”，应具体情况具体分析。有些确实是程序的BUG，需要修正，而有些可能只是很极端的情况，只有在做压力测试时才有可能发生，可不必深究。
 问题五
此问题发生在第二轮测试（即回归测试）中。在第一轮测试中发现的性能问题，经程序员修正后，我们对系统进行了第二轮性能测试，以验证其性能改进的效果。在前一轮测试中，我们发现通过选择客户级别为“未评级”时，查询的速度极慢，经过改进后，速度应有较大提高。然而在回归测试中，却依然很慢。经过对测试脚本和程序的仔细检查，才发现原来在程序中已将“未评级”这个选项去除，而我们的测试脚本的参数文件中仍然保留有该选项，因此测试的结果与前次没有区别。在参数文件中将该选项去掉后，测试结果正常，查询效率有所提高。
结论：使用录制好的测试脚本进行回归测试之前，一定要先仔细检查、了解程序的改动，对原先的测试脚本做必要的修改后，才可以重新测试，否则只是在做无用功。
10、教训
在本次测试过程中，由于经验不足，我们也得到了一些教训。前事不忘，后事之师，现总结出来与大家分享。
 与客户的沟通做得不够，客户要求我们做的性能测试用例数量太多，我们未能据理力争，最后导致工作量过大。
 按照原定的项目计划，我们要在系统的功能测试即将结束前进驻项目组，准备并进行性能测试。然而由于客户在功能测试的后期仍然不断的提出新需求，导致开发人员疲于奔命，系统的性能难以稳定下来，性能测试的前期准备工作也受到很大影响，不能正常开展，浪费了很多人力物力。
 由于客户无法提供一个单独的性能测试环境，我们的性能测试工作与业务组的功能测试在同一个环境下进行，而系统的功能测试迟迟未能完成，加上ETL（数据转换）小组对数据库资源的占用，因此我们的性能测试只能在夜间才能进行。导致时间上的浪费，使项目的成本增加。
 没有将性能测试中发现的缺陷记录到缺陷管理工具中加以跟踪，而仅仅体现在最后的测试报告上，个人认为这是比较不规范的做法。
 性能测试前的数据准备不够充分。客户提供测试的系统用户、身份数量有限，导致许多案例的测试只能使用少量数据进行参数化，由此带来许多本可以避免的问题。
 测试计划及测试报告的书写格式缺乏规范，尤其测试计划书未能包含本应包含的所有内容。
 在我们将LoadRunner的测试结果文件全部提交给客户的前提下，客户仍然要求我们在测试报告中将每一次测试的数据均以表格的形式填至测试报告中，此项工作的工作量十分巨大，个人认为这样做并无必要。
以上是在本次性能测试及回归测试过程中总结出来的一些经验教训，在此做一个小小的总结，以便下次工作中改进。

作者: xingcyx 时间: 2005-8-12 09:38
不好意思，在本论坛发贴有10000个字符的限制，所以我不得不将文章拆成两篇贴子来发。

作者: luming 时间: 2005-8-12 10:24
good，谢谢，很有启发意义。这样实际测试的文章希望能多看到一些。

[ Last edited by luming on 2005-8-12 at 10:57 ]

作者: Fantasy 时间: 2005-8-12 10:48
标题: thank~~！
学到了很多~~~

作者: yuhuawang 时间: 2005-8-12 10:50
好贴，强烈支持，希望还能看到贴近测试实际工作的纪实性贴子。

作者: 小屋_vivian 时间: 2005-8-18 16:57
写的好!!!很实际,♂需要的就是这个

作者: 大妮 时间: 2005-8-21 20:51
这个。。。是属于验收测试的范围吗？

还有，此次测试是真实用户环境
在这次测试前，有进行过模拟用户环境测试吗？

作者: xingcyx 时间: 2005-8-22 09:09
可以算是吧。
是系统上线前，客户要求我们去做的性能测试。
在这之前没有进行过模拟用户环境测试。

作者: 大妮 时间: 2005-8-23 20:01
谢楼主解答 ^_^

作者: lindahere 时间: 2005-8-24 23:09
热烈欢迎这样的帖子!
在论坛里很难看到啊.....
受益匪浅!

作者: lindahere 时间: 2005-8-24 23:10
热烈欢迎这样的帖子!
在论坛里很难看到啊.....
受益匪浅!

作者: liuxueying 时间: 2005-10-27 14:53
写得很好！

作者: jxaa133720 时间: 2005-10-30 11:49
不错！值得肯定！
加油啊，把你的经验都可以拿过来啊

作者: guojin 时间: 2005-11-22 11:22
强烈支持这样的帖子，谢谢楼主！！！！

作者: 槛外人 时间: 2005-11-25 11:46
标题: 楼主,麻烦你排排版
这样看不清楚，不过基本过程跟我上次做的那个差不多的。

作者: myang 时间: 2005-12-5 13:32
标题: 不错的帖子
不错的帖子

作者: shengyan 时间: 2006-2-7 17:32
楼主好样的！

作者: sn51 时间: 2006-3-30 13:07
这种实际性测试的例子很受欢迎，学到了不少知识，也是我在性能测试时碰到的，真好！

作者: zibeike 时间: 2006-3-31 16:51
好帖，学习中。。。

作者: davinci_chenbz 时间: 2006-4-25 15:37
标题: 强人！
介绍的清楚明白，这才是真正的高手，表达清楚、细致很期待新的帖子！

作者: ljitry 时间: 2006-5-1 14:02
可不可以告诉我你在从拿到需求到测试结束，一系列环节所花的时间。还有我是用QTP的，没用过LR，你能说说如果用在这个项目上，哪一个工具好一点，说一下你的理由。谢谢！（MSN：ljitry@hotmail。com）

作者: xingcyx 时间: 2006-5-8 15:00
回复 ljitry：
1、这个项目的完成距离现在已经挺久了，你问的环节时间已经没法给你一个准确答复了。不好意思！
2、QTP和LR是两种不同类型的工具。QTP是用于功能测试的自动化测试工具，而LR是用于性能测试，并且它们都同样是MI公司的产品，没法做比较。

作者: jordi 时间: 2006-5-15 19:50
真是非常之好的文章！把解决问题的过程描述的这么清楚，棒！

作者: robust 时间: 2006-6-8 09:41

原帖由 xingcyx 于 2005-8-12 09:38 发表
由于LoadRunner不提供像WinRunner或QTP一样识别页面对象的功能，如果在Vugen中直接抓取页面上显示的客户编号去参数化，实现起来将十分烦琐。 ...

LR里实现这个功能并不烦琐，就是colleration关联功能，有好几个函数支持这个功能的。以楼主这样的使用经验应该是可以做到的。楼主还是不错的。

作者: xingcyx 时间: 2006-6-9 13:54

原帖由 robust 于 2006-6-8 09:41 发表

LR里实现这个功能并不烦琐，就是colleration关联功能，有好几个函数支持这个功能的。以楼主这样的使用经验应该是可以做到的。楼主还是不错的。

你可能没有理解我的意思。这个跟关联没有关系，是参数化的问题。
直接从系统的界面上取值来做参数化，好象确实是很困难的，反正我没有试过。

作者: shengyan 时间: 2006-6-26 10:29
又看了一遍,收获又多了一点,

作者: xingcyx 时间: 2006-6-30 19:53
呵呵，多谢各位的谬赞！
最近在另一家大银行做一个系统的性能测试，有幸得与MI公司的某LR专家共事了一段时间，又向他学了不少东西。
改天有时间我再总结一下，跟大家分享。

作者: jackei 时间: 2006-7-14 09:53
精彩 ^_^

作者: ljitry 时间: 2006-8-9 10:37
谢谢答复！收获不少！！！！

作者: jackly 时间: 2006-8-28 11:03
标题: 好帖!启发很大!
谢谢!我们需要的就是这么有实际的操作经验,在我们的测试过程中,我们也发现了这个问题,一直都得不到解释和理解,谢谢你的启示!

支持!严重支持!

作者: elisly 时间: 2006-10-13 11:09
感谢楼主的帖给予我的极大启示，我在做性能测试的过程中也遇到类似的问题。

作者: zhonglei20 时间: 2006-10-30 17:29
字體太小　看的好痛苦

作者: xingcyx 时间: 2006-11-3 22:06
不好意思，格式比较乱，是这个坛子的原因。

作者: seasons 时间: 2006-11-8 16:38
标题: 回复 #2 xingcyx 的帖子
然而由于客户在功能测试的后期仍然不断的提出新需求，导致开发人员疲于奔命，系统的性能难以稳定下来，性能测试的前期准备工作也受到很大影响，不能正常开展，浪费了很多人力物力。

深有感触，功能版本都不稳定，对性能测试的影响极大

作者: zblovelb 时间: 2006-11-9 12:23
确实好贴呀

作者: 论坛守护神 时间: 2006-11-16 11:15
支持一个，好帖子

作者: 村上舞!舞!舞 时间: 2006-11-19 23:25
不知xingcyx楼主能否将联系方式告知一下，在厦门吗？
Liuc@xindeco.com.cn

作者: xingcyx 时间: 2006-11-20 16:12
咦？楼上的怎么知道我在厦门？

作者: 村上舞!舞!舞 时间: 2006-11-26 22:09
标题: 呵呵！！
呵呵！！xingcyx老兄，我还在胡乱猜测您是哪家公司的呢。。。呵呵，无意中看到的您的贴中好像有提到你在厦门。所以才想要问一下您的联系方式的。呵呵。。不好意思啊，最近项目在外所以上网时间很少。可不可以把你的QQ号或MSN告知一下？

作者: xingcyx 时间: 2006-11-27 17:06
MSN：xingcyx@hotmail.com

作者: dandan 时间: 2006-11-27 17:21
very good,thanks very much......

作者: songfun 时间: 2006-11-27 17:45
排版啊看的累啊

作者: xingcyx 时间: 2006-11-28 14:55
排版不是我的错，当时我试了几遍贴出来都是这个效果，我也没办法，呵呵。
不容易看明白的东西才是好东西嘛，呵呵，说笑。

另：没想到这个贴都发了一年多了，还有人看啊sdlkfj6

作者: ly_xixihaha 时间: 2006-12-13 09:39
好帖，学习中.......
不过楼主可以发个附件上来

作者: 青青 时间: 2006-12-22 09:56
很好啊!
希望早点看到LZ分享与LR工作人员共事的经验之谈.

作者: xingcyx 时间: 2006-12-22 15:01

原帖由青青于 2006-12-22 09:56 发表
很好啊!
希望早点看到LZ分享与LR工作人员共事的经验之谈.

哈哈，晕。。还惦记着哪？
一直偷懒呢。

作者: suifengpiao 时间: 2006-12-28 14:15
好帖子，论坛这种帖子太少了

作者: kklizi 时间: 2006-12-28 17:40
写的好哇有看的了不过要是能排下版就更好了 HOHO

作者: sunxy5291 时间: 2007-1-22 13:57
感觉不错怎么我今天才看到，你们都厉害啊

作者: h220000 时间: 2007-3-1 11:05
顶啦，这种好帖太少了

作者: imqjzf 时间: 2007-9-20 15:33
写的真好。

作者: 54111 时间: 2008-1-10 16:37

原帖由 xingcyx 于 2006-11-28 14:55 发表
排版不是我的错，当时我试了几遍贴出来都是这个效果，我也没办法，呵呵。
不容易看明白的东西才是好东西嘛，呵呵，说笑。

另：没想到这个贴都发了一年多了，还有人看啊sdlkfj6

可以很负责任的说，现在还有人在看

作者: 开着拖拉机上班 时间: 2008-1-10 16:57
娘唉！！
你就不能排排版啊！
看的我眼睛疼！

作者: 紫色梦幻 时间: 2008-1-11 17:11
首先谢谢楼主的分享,资料对我现在进行的测试有所启发!

作者: wan_xie2007 时间: 2008-1-14 15:55
标题: 总结的很好
向楼主学习
我也加楼主
交流一下

作者: 423799223 时间: 2008-1-29 16:18
这才是实战的总结
支持楼主

作者: meiliqingdao 时间: 2008-3-13 11:14
好东西是不错，就是看着累，扯着胳膊连着腿的！总之还是万分感谢！

作者: 茶思 时间: 2008-3-19 22:22
学到了很多，表述很清晰，谢谢

作者: ZH_0211 时间: 2008-3-26 10:08
学习了，感谢楼主的倾情奉献经验

作者: bigstone81 时间: 2008-3-26 16:27
为什么性能测试和功能测试不能同步进行？
万一你功能ok了，但是性能达不到，用户要求yi一定要达到这个指标
但是在你现有的实现方式已经无法达到（当然这个可能是se,或者开发造成），项目经理和开发人员不得重构系统，换种实现方式，那岂不是.....

作者: cathyhmn 时间: 2015-4-22 11:10
非常感谢，现在急需这些东西

作者: 军哥帅过王力宏 时间: 2016-6-27 10:36
谢谢楼主无私的分享，很有用。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)