银行系统性能测试策略探讨
上一篇 / 下一篇 2012-06-22 19:53:52 / 个人分类:性能测试
在一般的性能测试讨论中大家通常只围绕三个方面进行提问和总结:测试脚本如何编写,被测系统如何监控,性能瓶颈如何调优。大部分刚刚接触性能测试的人会纠结于脚本的编写,如何设置参数化、如何设置关联、何时插入检查点,各种论坛和讨论群里不断有人提出也不断有人解答。经过一段时间的经验积累后就会遇到如何监控被测系统,如何确定瓶颈并调优等问题,各种操作系统、中间件、数据库的监控和调整方法也被口耳相传。但我认为在性能测试的讨论中我们却忽略了另一个重要的方面:如何制定性能测试策略。
A_ v9W!H_3J051Testing软件测试网.W&^*C+O%bi我认为完整的性能测试可以分为四个方面:1、测试策略制定;2、性能脚本编写;3、被测系统监控4、性能瓶颈调优。从流程来看这四个方面有先后顺序的关系,从领域来看这四个方面都有可深入研究的内容。51Testing软件测试网\+W&c"^;xF6d e}$V
51Testing软件测试网.l7?Q&F7F g'l.F1、测试策略决定了性能测试如何开展,负载目标是否正确,场景模拟是否合理,好比战场上的指挥部,从全局设计战争的方向。
5}M)S&}3VA051Testing软件测试网P(A'tO?f2、测试脚本编写决定了性能测试能否顺利执行,压力发起是否正确,好比战场上直面敌人的作战单位,需要真刀真枪的去拼杀。
jX8X-z8Eb0H&h}*J7P XQ7a_P0 3、测试监控决定了关注范围是否合理,能否发现瓶颈所在,好比潜入敌后的地下组织,要设置在关键的脉络上实时收集情况。
e#WW {lV:\7n0,j3V7sB8Y0 4、性能调优并不是所有项目都需要的,但一旦发现问题,调优就决定了测试能否完美收官,如战场上的特种兵,用专业的技能解决各种难题,非一时所能练成,所以我们大部分人都执著于此。51Testing软件测试网"pd0R(p!Y
~xtlv{F0 本文以笔者实际项目经验为基础,尝试探讨并总结银行系统性能测试策略制定过程中必经的步骤和所需考虑的内容。
g^Z+V:mC1I051Testing软件测试网Aq:fS:K二、 测试需求分析 1. 业务场景分析
2F`j5Sd.B5Vq051Testing软件测试网wP8_0PkT2Yw测试银行核心系统时将柜员签到、签退、业务操作、批量等众多交易放在同一场景中执行,这样的场景在现实中是否存在?测试POS、ATM等渠道时将查询、动账类交易各按50%的比例分配,这样的比例是否正确?所有的性能测试都是以复现实际业务场景为目标。因此业务场景分析和选取务必严谨。业务场景应该从时间和空间两个角度考虑:51Testing软件测试网]J'\1^&j~ rC
@~E+La)@0 1.1 时间角度51Testing软件测试网N]*{&v^0i5a'_g6}
z4O0^jZ;U@0`0 分别以一年、一月、一天的角度观察,被测系统是否存在业务高峰时段。各高峰时段的重点交易是什么,交易比例如何。51Testing软件测试网*ay0RT8[w \
p3?(K rHF!D&w0 1.2空间角度
o-[ Cx_g3@`:n UuN0@u8Z.g]4g5X Y0 根据各分行业务特点不同,被测系统是否存在不同的高峰场景和交易,操作交易的柜员数量及一般操作时间是多少。
#IQZ0L"P051Testing软件测试网 Ff1\e X5x4jY!u业务场景分析阶段应向业务、研发、运维等多部门了解被测系统需求,但就数据准确度而言,应多参考生产日志。对升级改造类系统,场景分析的数据可从老系统的生产日志中获取;对新开发的系统,分析数据可从业务上有关联的其他系统中获取,同时参考业务部门意见。典型业务场景可以不止一个,但一定要明确各场景中的交易和比例,不要模拟一个不存在的大混合!
/J(S+R$Tt0j'UM}0(Q}"b _U*E6})[ w-^#}G0 2. 负载目标计算51Testing软件测试网D$bw j9^,rA nk
51Testing软件测试网;Z D]X)z1k)r/Z+J.|$x#t w与项目管理中的SMART原则类似,业务场景需转换成可量化、可衡量、可实现的负载目标才能进行性能测试,而负载目标要根据不同场景分别计算。根据上阶段收集到“原始”数据,本阶段可计算或指定出各种间接和直接的负载目标值,一般负载目标多从两种角度考虑:51Testing软件测试网,@.v2m!D!eSl0U.s8[y
2x {+vhO2M0 2.1前端角度51Testing软件测试网#Nn.^3m*qjz
51Testing软件测试网U!_e3i$bZ3OsH^在线用户数量:间接负载目标值,可理解为所有能操作被测交易的用户(柜员)数量。51Testing软件测试网{q zo"v S
r o?S~(?0 平均操作时间(思考时间):间接负载目标值,与在线用户数量一同计算业务并发数量。
b/zv(m}:j)vL0ImW i&t8Gz0 业务并发数量:典型场景中集中操作(不是绝对并发)交易的用户(柜员)数量。
GnY0x-j ~1F}0iG9rm+B5ZZ0 2.2后端角度
H @ @*~E j M051Testing软件测试网 m!NU;a&~Mb每秒交易数量(TPS):根据日志计算出的被测系统应承受的每秒交易数量。51Testing软件测试网|7n[ `lF
5ZLlE'p0?Bq0 交易响应时间(TRT):与TPS对应,负载场景下交易应达到的响应时间。51Testing软件测试网RzCaLG2R'O
5n+n/\"{ ap0 吞度量(Throughout):LoadRunner中吞度量是以每秒收到的字节数计算,其实TPS也是吞吐量的一种,根据不同被测系统计算对应的吞吐量。
,E:e;vX4ly051Testing软件测试网oO6t4}1UN D QsI系统并发数量:区别于业务并发数量,系统并发数量更趋近于绝对并发。对长连接系统来说系统并发就等于允许的连接数,对短连接系统来说更多取决于架构。51Testing软件测试网%W0y z/J2FptJ7V%|'Z
~;{4zIEPO0F0 被测系统CPU、Mem、Disk等指标值:多为指定值,如CPU利用率不高于80%等。51Testing软件测试网(A3E:I9{]TxNm%D
51Testing软件测试网dSa.r4m}"b4JG前端负载目标需要通过大量、广泛的业务和日志统计才能得出,如需记录下高峰时段操作交易的用户数量、估算用户状态比例、统计操作习惯等,由于考虑到人的因素,因此前端负载很难计算精确。前端负载目标适合交易关联不大、操作用户分散、无具体业务量要求的系统,如内控管理、培训考核、网银主页等(以B/S架构为主)。51Testing软件测试网0^Q#D&a,A`
51Testing软件测试网;p0@km8u9S:R后端负载目标则比较容易计算,如当前某省对公汇兑类交易日均8万笔,则TPS=80000/(6*60*60)=3.7笔/秒(对公按6小时计算);核心系统联机交易平均响应时间在3秒以下等。后端负载目标适合交易关联度大、操作用户相对集中、有具体业务量要求的系统,以银行核心业务系统为主。
/Y _I3D9Q:q5]1c0.U3eR2@!dB%Y hAx0 负责目标需要针对不同类型的被测系统计算合理的目标值,同时还需考虑2/8原则,未来业务量、用户量扩展等因素,这里不做赘述。51Testing软件测试网[Z$YKW7a c#p
e\ d Y5V.^|K0 三、 测试环境设计 1. 硬件环境设计
8S0\S+lZ7g"l6E+a0y+xI`(b$Y#U^0 大部分性能测试的硬件环境与生产相去甚远,受品牌、型号、部署方式(集群个数减少,软负载均衡代替硬负载均衡)等多种因素限制,无法直接将测试环境下的性能结果向生产环境做比例放大,因此硬件环境设计主要关注应用架构与生产环境一致(如应用、数据库服务器必须为集群方式),尽量减少性能测试中的硬件资源瓶颈(如数据库存储必须为SAN,发压与被测系统间网络带宽必须为1000M)。51Testing软件测试网6nq1U4mV&a:f
51Testing软件测试网~|-An\ x oy0A6o2. 软件环境设计51Testing软件测试网9l%OT&s_t}$P1LF
51Testing软件测试网Dbr(H#l4knm%g]8qL软件测试环境可从两个方面考虑:51Testing软件测试网4r1`5HBtb ^
ve G8Wy0 2.1基础配置
9S9x8F"@s4o051Testing软件测试网1g4e0wHk/ax4H,q确认操作系统、中间件、数据库和被测系统的版本与补丁与生产环境一致,但操作系统、中间件、数据库的内部参数应根据测试硬件环境做适当调整,可参考生产中的设置比例。51Testing软件测试网9f7o2XU@$^'GkR
7Jm&l7^2B JF/y0 数据库分区、索引等必须与生产或预计投产时一致。
'E9D/j@.~?7w0q$H)Z;yR!]hY9X0 2.2外联系统