【银行测试】银行系统项目-性能测试压测，场景设计分析...
目录：导读
前言
1、性能测试的四个方面
完整的性能测试可以分为四个方面：
1）测试策略制定；
2）性能脚本编写；
3）被测系统监控
4）性能瓶颈调优。
2、测试需求分析
1）业务场景分析
测试银行核心系统时将柜员签到、签退、业务操作、批量等众多交易放在同一场景中执行，这样的场景在现实中是否存在？
测试POS、ATM等渠道时将查询、动账类交易各按50%的比例分配，这样的比例是否正确？
所有的性能测试都是以复现实际业务场景为目标。因此业务场景分析和选取务必严谨。业务场景应该从时间和空间两个角度考虑：
时间角度：
分别以一年、一月、一天的角度观察，被测系统是否存在业务高峰时段。各高峰时段的重点交易是什么，交易比例如何。
空间角度：
根据各分行业务特点不同，被测系统是否存在不同的高峰场景和交易，操作交易的柜员数量及一般操作时间是多少。
业务场景分析阶段应向业务、研发、运维等多部门了解被测系统需求，但就数据准确度而言，应多参考生产日志。
对升级改造类系统，场景分析的数据可从老系统的生产日志中获取；对新开发的系统，分析数据可从业务上有关联的其他系统中获取，同时参考业务部门意见。
典型业务场景可以不止一个，但一定要明确各场景中的交易和比例，不要模拟一个不存在的大混合！
2）负载目标计算
与项目管理中的SMART原则类似，业务场景需转换成可量化、可衡量、可实现的负载目标才能进行性能测试，而负载目标要根据不同场景分别计算。
根据上阶段收集到“原始”数据，本阶段可计算或指定出各种间接和直接的负载目标值，一般负载目标多从两种角度考虑：
前端角度：
在线用户数量：间接负载目标值，可理解为所有能操作被测交易的用户（柜员）数量。
平均操作时间（思考时间）：间接负载目标值，与在线用户数量一同计算业务并发数量。
业务并发数量：典型场景中集中操作（不是绝对并发）交易的用户（柜员）数量。
后端角度：
每秒交易数量（TPS）：根据日志计算出的被测系统应承受的每秒交易数量。
交易响应时间（TRT）：与TPS对应，负载场景下交易应达到的响应时间。
吞度量（Throughout）：LoadRunner中吞度量是以每秒收到的字节数计算，其实TPS也是吞吐量的一种，根据不同被测系统计算对应的吞吐量。
系统并发数量：区别于业务并发数量，系统并发数量更趋近于绝对并发。对长连接系统来说系统并发就等于允许的连接数，对短连接系统来说更多取决于架构。
被测系统CPU、Mem、Disk等指标值：多为指定值，如CPU利用率不高于80%等。
前端负载目标需要通过大量、广泛的业务和日志统计才能得出，如需记录下高峰时段操作交易的用户数量、估算用户状态比例、统计操作习惯等，由于考虑到人的因素，因此前端负载很难计算精确。
前端负载目标适合交易关联不大、操作用户分散、无具体业务量要求的系统，如内控管理、培训考核、网银主页等（以B/S架构为主）。
后端负载目标则比较容易计算，如当前某省对公汇兑类交易日均8万笔，则TPS=80000/（66060）=3.7笔/秒（对公按6小时计算）；
核心系统联机交易平均响应时间在3秒以下等。后端负载目标适合交易关联度大、操作用户相对集中、有具体业务量要求的系统，以银行核心业务系统为主。
负责目标需要针对不同类型的被测系统计算合理的目标值，同时还需考虑2/8原则，未来业务量、用户量扩展等因素，这里不做赘述。
3、测试环境设计
1）硬件环境设计
大部分性能测试的硬件环境与生产相去甚远，受品牌、型号、部署方式（集群个数减少，软负载均衡代替硬负载均衡）等多种因素限制，无法直接将测试环境下的性能结果向生产环境做比例放大。
因此硬件环境设计主要关注应用架构与生产环境一致（如应用、数据库服务器必须为集群方式），尽量减少性能测试中的硬件资源瓶颈（如数据库存储必须为SAN，发压与被测系统间网络带宽必须为1000M）。
2）软件环境设计
软件测试环境可从两个方面考虑：
基础配置：
确认操作系统、中间件、数据库和被测系统的版本与补丁与生产环境一致，但操作系统、中间件、数据库的内部参数应根据测试硬件环境做适当调整，可参考生产中的设置比例。
数据库分区、索引等必须与生产或预计投产时一致。
外联系统：
尽量减少外联系统，因为外联系统越多，测试链条越长，环境越难维护，问题越难定位。可适当在被测系统中做挡板程序，模拟与外联系统的应答，但必须保证被测系统中的逻辑分支没有被屏蔽。
3）铺底数据策略
性能铺底数据量的大小和分布情况会对测试结果产生极大影响，是场景设计阶段的重中之重！测试前对铺底数据的构造可从以下四个方面考虑：
表分区情况：
确认测试环境与生产环境（或预计投产后）的表分区和索引分区规划一致，结合表清理策略确认典型场景中各分区、各表中的数据存量大小和分布情况。
表清理策略：
确认生产环境（或预计投产后）的数据库表（尤其业务热表）清理和备份策略，与表分区情况配合，预铺数据并确保测试数据库表中数据存量与生产保持同一量级。
表维护策略：
确认当前生产数据库表（尤其热表）和索引统计值更新、rebuild和reorg等操作的频度，在数据预铺中适当更新统计值，切勿在测试环境中频繁执行统计值更新等操作，造成虚假的性能表现。
如下图，更新统计值后表和索引的相关信息会统计正确，性能将得到一定程度的提升。
合理的业务数据：
确认铺底数据中的柜员、行部、角色、权限、待处理任务等业务数据是否符合实际情况，切勿为图省事而创建超级行部、全能柜员和过量的待处理任务。
4、测试场景设计
1）发压数据策略
测试发压数据应在数据铺底时一同考虑，但发压数据需要和压力工具配合使用，可从以下四个方面考虑：
表分区情况：
确认发压数据覆盖各表分区，且在分区中也需尽量离散，不要集中操作（主要是查询）同一范围内的数据。
表维护策略：
通常生产环境中数据库表在日终结束后执行统计值更新，对应第二天营业时的数据状态，除柜员签到外，其余典型场景均发生在更靠后的营业时段。
因此不要在刚刚执行完统计值更新的环境中执行正式的性能测试，建议再执行一段时间的数据预铺，模拟行部营业一段时间后的业务，这时再执行正式的性能测试，并记录结果。
被测交易分支：
在能力允许的情况下应尽量多的阅读被测交易源码，或向开发人员了解程序逻辑和交易分支，确认发压数据可覆盖程序中所有重点路径。避免造成该复现的问题没有复现，该出现的瓶颈没有出现。
合理的业务数据：
与发压工具配合，确认在测试过程中没有同一柜员并发操作交易，没有超出合理范围的待处理任务，以日峰TPS为负载目标时不要同时执行疲劳测试，这样会导致交易量远远大于实际。
2）测试并发设计
并发设计与负载目标紧密关联，同样可分为前端、后端两种方式：
前端角度：
使用工具模拟的并发数量代表业务并发用户数量，一个并发进程或线程即模拟一个操作交易的柜员，脚本中设置thinktime模拟平均操作时间，维持典型场景中各交易的用户比例，并做等比例递增，关注此时被测系统的处理能力。
但需注意的是，受thinktime和响应时间等影响，业务并发数量≠系统并发数量，所以不能在结论中说“被测系统只能承受XX并发”。
且业务并发数量与在线用户数量的换算不可能完全精确，所以也不能用类似10个业务并发即代表100个在线用户的粗略换算为结论。
后端角度：
使用工具模拟的并发数量不代表用户数量，也不完全等价于系统并发数量，它仅通过并发的形式对被测系统产生压力。
由于后端角度更关注TPS，因此并发递增时各交易之间的并发比例可能会变化，响应时间变慢的交易会增加更多并发以维持预期TPS。
后端角度重点关注并发增加时的TPS和响应时间变化趋势，确定被测系统的处理能力。
5、测试策略维护
测试策略应在测试执行前确定，执行过程中不做大的变更，但仍需根据测试结果不断反思和维护策略，确保性能测试能够真实复现生产场景。
| 下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结（尾部小惊喜）
不要被现实的限制所束缚，勇敢地冲破自我设限。相信自己的能力，敢于追求梦想，只有拼尽全力奋斗，才能创造属于自己的辉煌人生。
莫让失败打败你，每一次跌倒都是站起的力量。坚持努力，积极进取，相信自己的潜能，勇往直前，终将成就不凡的人生传奇。
勇敢追求自己的梦想，奋斗不息，没有什么能够阻止你前进的脚步。坚定信念，毫不气馁，只有拼尽全力，才能创造出辉煌的人生篇章。