一、性能测试的四个方面

　　在一般的性能测试讨论中大家通常只围绕三个方面进行提问和总结：测试脚本如何编写，被测系统如何监控，性能瓶颈如何调优。大部分刚刚接触性能测试的人会纠结于脚本的编写，如何设置参数化、如何设置关联、何时插入检查点，各种论坛和讨论群里不断有人提出也不断有人解答。经过一段时间的经验积累后就会遇到如何监控被测系统，如何确定瓶颈并调优等问题，各种操作系统、中间件、数据库的监控和调整方法也被口耳相传。但我认为在性能测试的讨论中我们却忽略了另一个重要的方面：如何制定性能测试策略。

　　我认为完整的性能测试可以分为四个方面：1、测试策略制定；2、性能脚本编写；3、被测系统监控4、性能瓶颈调优。从流程来看这四个方面有先后顺序的关系，从领域来看这四个方面都有可深入研究的内容。

　　1、测试策略决定了性能测试如何开展，负载目标是否正确，场景模拟是否合理，好比战场上的指挥部，从全局设计战争的方向。

　　2、测试脚本编写决定了性能测试能否顺利执行，压力发起是否正确，好比战场上直面敌人的作战单位，需要真刀真枪的去拼杀。

　　3、测试监控决定了关注范围是否合理，能否发现瓶颈所在，好比潜入敌后的地下组织，要设置在关键的脉络上实时收集情况。

　　4、性能调优并不是所有项目都需要的，但一旦发现问题，调优就决定了测试能否完美收官，如战场上的特种兵，用专业的技能解决各种难题，非一时所能练成，所以我们大部分人都执著于此。

　　本文以笔者实际项目经验为基础，尝试探讨并总结银行系统性能测试策略制定过程中必经的步骤和所需考虑的内容。

　　二、测试需求分析

　　1、业务场景分析

　　测试银行核心系统时将柜员签到、签退、业务操作、批量等众多交易放在同一场景中执行，这样的场景在现实中是否存在？测试POS、ATM等渠道时将查询、动账类交易各按50%的比例分配，这样的比例是否正确？所有的性能测试都是以复现实际业务场景为目标。因此业务场景分析和选取务必严谨。业务场景应该从时间和空间两个角度考虑：

　　1.1 时间角度

　　分别以一年、一月、一天的角度观察，被测系统是否存在业务高峰时段。各高峰时段的重点交易是什么，交易比例如何。

　　1.2 空间角度

　　根据各分行业务特点不同，被测系统是否存在不同的高峰场景和交易，操作交易的柜员数量及一般操作时间是多少。

　　业务场景分析阶段应向业务、研发、运维等多部门了解被测系统需求，但就数据准确度而言，应多参考生产日志。对升级改造类系统，场景分析的数据可从老系统的生产日志中获取；对新开发的系统，分析数据可从业务上有关联的其他系统中获取，同时参考业务部门意见。典型业务场景可以不止一个，但一定要明确各场景中的交易和比例，不要模拟一个不存在的大混合！