银行系统性能测试策略探讨
一、性能测试的四个方面
在一般的性能测试讨论中大家通常只围绕三个方面进行提问和总结：测试脚本如何编写，被测系统如何监控，性能瓶颈如何调优。大部分刚刚接触性能测试的人会纠结于脚本的编写，如何设置参数化、如何设置关联、何时插入检查点，各种论坛和讨论群里不断有人提出也不断有人解答。经过一段时间的经验积累后就会遇到如何监控被测系统，如何确定瓶颈并调优等问题，各种操作系统、中间件、数据库的监控和调整方法也被口耳相传。但我认为在性能测试的讨论中我们却忽略了另一个重要的方面：如何制定性能测试策略。
我认为完整的性能测试可以分为四个方面：1、测试策略制定；2、性能脚本编写；3、被测系统监控4、性能瓶颈调优。从流程来看这四个方面有先后顺序的关系，从领域来看这四个方面都有可深入研究的内容。
1、测试策略决定了性能测试如何开展，负载目标是否正确，场景模拟是否合理，好比战场上的指挥部，从全局设计战争的方向。
2、测试脚本编写决定了性能测试能否顺利执行，压力发起是否正确，好比战场上直面敌人的作战单位，需要真刀真枪的去拼杀。
3、测试监控决定了关注范围是否合理，能否发现瓶颈所在，好比潜入敌后的地下组织，要设置在关键的脉络上实时收集情况。
4、性能调优并不是所有项目都需要的，但一旦发现问题，调优就决定了测试能否完美收官，如战场上的特种兵，用专业的技能解决各种难题，非一时所能练成，所以我们大部分人都执著于此。
本文以笔者实际项目经验为基础，尝试探讨并总结银行系统性能测试策略制定过程中必经的步骤和所需考虑的内容。
二、测试需求分析
1、业务场景分析
测试银行核心系统时将柜员签到、签退、业务操作、批量等众多交易放在同一场景中执行，这样的场景在现实中是否存在？测试POS、ATM等渠道时将查询、动账类交易各按50%的比例分配，这样的比例是否正确？所有的性能测试都是以复现实际业务场景为目标。因此业务场景分析和选取务必严谨。业务场景应该从时间和空间两个角度考虑：
1.1 时间角度
分别以一年、一月、一天的角度观察，被测系统是否存在业务高峰时段。各高峰时段的重点交易是什么，交易比例如何。
1.2 空间角度
根据各分行业务特点不同，被测系统是否存在不同的高峰场景和交易，操作交易的柜员数量及一般操作时间是多少。
业务场景分析阶段应向业务、研发、运维等多部门了解被测系统需求，但就数据准确度而言，应多参考生产日志。对升级改造类系统，场景分析的数据可从老系统的生产日志中获取；对新开发的系统，分析数据可从业务上有关联的其他系统中获取，同时参考业务部门意见。典型业务场景可以不止一个，但一定要明确各场景中的交易和比例，不要模拟一个不存在的大混合！
2、负载目标计算
与项目管理中的SMART原则类似，业务场景需转换成可量化、可衡量、可实现的负载目标才能进行性能测试，而负载目标要根据不同场景分别计算。根据上阶段收集到“原始”数据，本阶段可计算或指定出各种间接和直接的负载目标值，一般负载目标多从两种角度考虑：
2.1 前端角度
在线用户数量：间接负载目标值，可理解为所有能操作被测交易的用户（柜员）数量。
平均操作时间（思考时间）：间接负载目标值，与在线用户数量一同计算业务并发数量。
业务并发数量：典型场景中集中操作（不是绝对并发）交易的用户（柜员）数量。
2.2 后端角度
每秒交易数量（TPS）：根据日志计算出的被测系统应承受的每秒交易数量。
交易响应时间（TRT）：与TPS对应，负载场景下交易应达到的响应时间。
吞度量（Throughout）：LoadRunner中吞度量是以每秒收到的字节数计算，其实TPS也是吞吐量的一种，根据不同被测系统计算对应的吞吐量。
系统并发数量：区别于业务并发数量，系统并发数量更趋近于绝对并发。对长连接系统来说系统并发就等于允许的连接数，对短连接系统来说更多取决于架构。
被测系统CPU、Mem、Disk等指标值：多为指定值，如CPU利用率不高于80%等。
前端负载目标需要通过大量、广泛的业务和日志统计才能得出，如需记录下高峰时段操作交易的用户数量、估算用户状态比例、统计操作习惯等，由于考虑到人的因素，因此前端负载很难计算精确。前端负载目标适合交易关联不大、操作用户分散、无具体业务量要求的系统，如内控管理、培训考核、网银主页等（以B/S架构为主）。
后端负载目标则比较容易计算，如当前某省对公汇兑类交易日均8万笔，则TPS=80000/（6*60*60）=3.7笔/秒（对公按6小时计算）；核心系统联机交易平均响应时间在3秒以下等。后端负载目标适合交易关联度大、操作用户相对集中、有具体业务量要求的系统，以银行核心业务系统为主。
负责目标需要针对不同类型的被测系统计算合理的目标值，同时还需考虑2/8原则，未来业务量、用户量扩展等因素，这里不做赘述。
三、测试环境设计
1、硬件环境设计
大部分性能测试的硬件环境与生产相去甚远，受品牌、型号、部署方式（集群个数减少，软负载均衡代替硬负载均衡）等多种因素限制，无法直接将测试环境下的性能结果向生产环境做比例放大，因此硬件环境设计主要关注应用架构与生产环境一致（如应用、数据库服务器必须为集群方式），尽量减少性能测试中的硬件资源瓶颈（如数据库存储必须为SAN，发压与被测系统间网络带宽必须为1000M）。
2、软件环境设计
软件测试环境可从两个方面考虑：
2.1 基础配置
确认操作系统、中间件、数据库和被测系统的版本与补丁与生产环境一致，但操作系统、中间件、数据库的内部参数应根据测试硬件环境做适当调整，可参考生产中的设置比例。
数据库分区、索引等必须与生产或预计投产时一致。
2.2 外联系统
尽量减少外联系统，因为外联系统越多，测试链条越长，环境越难维护，问题越难定位。可适当在被测系统中做挡板程序，模拟与外联系统的应答，但必须保证被测系统中的逻辑分支没有被屏蔽。
3、铺底数据策略
性能铺底数据量的大小和分布情况会对测试结果产生极大影响，是场景设计阶段的重中之重！测试前对铺底数据的构造可从以下四个方面考虑：
3.1 表分区情况
确认测试环境与生产环境（或预计投产后）的表分区和索引分区规划一致，结合表清理策略确认典型场景中各分区、各表中的数据存量大小和分布情况。
3.2 表清理策略
确认生产环境（或预计投产后）的数据库表（尤其业务热表）清理和备份策略，与表分区情况配合，预铺数据并确保测试数据库表中数据存量与生产保持同一量级。
3.3 表维护策略
确认当前生产数据库表（尤其热表）和索引统计值更新、rebuild和reorg等操作的频度，在数据预铺中适当更新统计值，切勿在测试环境中频繁执行统计值更新等操作，造成虚假的性能表现。
如下图，更新统计值后表和索引的相关信息会统计正确，性能将得到一定程度的提升。
3.4 合理的业务数据
确认铺底数据中的柜员、行部、角色、权限、待处理任务等业务数据是否符合实际情况，切勿为图省事而创建超级行部、全能柜员和过量的待处理任务。
四、测试场景设计
1、发压数据策略
测试发压数据应在数据铺底时一同考虑，但发压数据需要和压力工具配合使用，可从以下四个方面考虑：
1.1 表分区情况
确认发压数据覆盖各表分区，且在分区中也需尽量离散，不要集中操作（主要是查询）同一范围内的数据。
1.2 表维护策略
通常生产环境中数据库表在日终结束后执行统计值更新，对应第二天营业时的数据状态，除柜员签到外，其余典型场景均发生在更靠后的营业时段，因此不要在刚刚执行完统计值更新的环境中执行正式的性能测试，建议再执行一段时间的数据预铺，模拟行部营业一段时间后的业务，这时再执行正式的性能测试，并记录结果。
1.3 被测交易分支
在能力允许的情况下应尽量多的阅读被测交易源码，或向开发人员了解程序逻辑和交易分支，确认发压数据可覆盖程序中所有重点路径。避免造成该复现的问题没有复现，该出现的瓶颈没有出现。
1.4 合理的业务数据
与发压工具配合，确认在测试过程中没有同一柜员并发操作交易，没有超出合理范围的待处理任务，以日峰TPS为负载目标时不要同时执行疲劳测试，这样会导致交易量远远大于实际。
2、测试并发设计
并发设计与负载目标紧密关联，同样可分为前端、后端两种方式：
2.1 前端角度
使用工具模拟的并发数量代表业务并发用户数量，一个并发进程或线程即模拟一个操作交易的柜员，脚本中设置thinktime模拟平均操作时间，维持典型场景中各交易的用户比例，并做等比例递增，关注此时被测系统的处理能力。但需注意的是，受thinktime和响应时间等影响，业务并发数量≠系统并发数量，所以不能在结论中说“被测系统只能承受XX并发”。且业务并发数量与在线用户数量的换算不可能完全精确，所以也不能用类似10个业务并发即代表100个在线用户的粗略换算为结论。
2.2 后端角度
使用工具模拟的并发数量不代表用户数量，也不完全等价于系统并发数量，它仅通过并发的形式对被测系统产生压力。由于后端角度更关注TPS，因此并发递增时各交易之间的并发比例可能会变化，响应时间变慢的交易会增加更多并发以维持预期TPS。
后端角度重点关注并发增加时的TPS和响应时间变化趋势，确定被测系统的处理能力。
五、测试策略维护
测试策略应在测试执行前确定，执行过程中不做大的变更，但仍需根据测试结果不断反思和维护策略，确保性能测试能够真实复现生产场景。
六、总结
工欲善其事必先利其器，在性能测试中我们的武器不仅仅是发压和调优工具，还有测试的思想！性能测试不是一个流水化作业的过程，它必须深入被测领域，对业务和技术进行全面了解才能正确执行。本文探讨并总结了银行系统性能测试策略的制定，由于经验有限，难免会有偏颇和遗漏，请批判阅读，同时对其他领域的策略制定也是抛砖引玉。
版权声明：本文出自 dionysus 的51Testing软件测试博客：http://www.51testing.com/?5939