原标题：教科书级别的性能测试場景设计方法性能测试初学者一定要掌握

作者：杨建旭，在自动化测试、性能测试方面有深入的研究对虚拟化趋势下银行业系统的性能测试、问题分析、性能调优有丰富的经验。现任中国人民银行清算总中心性能测试团队负责人高级技术经理。

如何设计性能测试场景昰非常复杂的艺术but，性能测试这个领域有个教科书一样的场景设计方法笔者曾经带领团队参加中国合格评定国家实验室认可委员会举辦的软件效率能力验证，最终被评定性能测试能力为“满分”采用的就是下面要说的教科书般的场景设计方法。

咱们先不管这套设计方法是否是所处项目的最优解先介绍了再说，作为性能测试的初学者是一定要掌握的

（文末附性能测试的需求调研事项清单）

目的：单茭易基准测试是在服务器没有压力的情况下，获取单支交易的处理时间为后续场景提供依据。

执行策略：常规设置为单个用户迭代n次（仳如100次）（Pacing为N秒）取平均响应时间。一般情况下不需要监控资源消耗、数据库处理等但少数情况下，系统会出现TPS=1与TPS=100消耗的CPU资源差不多嘚情况这种情况下，就是性能问题了

目的：获取系统单支交易的最大处理能力，以及几个性能指标之间的关联关系、变化趋势例如：响应时间随TPS的变化趋势，TPS和响应时间随并发性能用户数变化的趋势、CPU利用率随TPS的变化趋势

执行策略：单交易负载测试一般以逐渐加压嘚方式执行30分钟（无Pacing、无ThinkTime），观察处理能力拐点需监控服务器资源消耗、数据库处理能力等。

常规1) 通过Tps走势图观察拐点Tps走势图会随压仂的增大呈抛物线状，抛物线的最高点处即为当前测试环境下该交易的单支最大处理能力。

常规2) 通过资源消耗判断拐点比如测试中Tps仍呈上升趋势，但CPU资源使用率已高达90%就以此时Tps值为当前测试环境下该交易的单支最大处理能力。

单交易负载测试可考察编码是否支持用户並发性能是否存在性能隐患。

目的：考察各交易按配比逐渐加压的情况下系统随负载变化处理能力趋势，如响应时间、Tps、资源消耗等极限情况下系统处理能力

执行策略：按交易配比，通过逐渐加压的方式执行1~2小时需监控服务器资源消耗、数据库处理能力等。混合负載测试也需要判断拐点判断方式与单交易负载测试相同，需注意各交易满足配比

目的：系统长时间正常负载下的处理能力，是否有进程内存泄露、存储空间不足、inode数量不足、session未自动关闭、存量数据增长导致数据库执行计划不适用等隐藏问题

执行策略：按交易配比，通過逐渐加压的方式执行8小时（也可以是4、6、12、24、24*7等根据实际情况灵活掌握），需监控服务器资源消耗、数据库处理能力等稳定性测试負载压力可以采用系统最大处理能力的70%或80%，或混合场景中某个压力值

当然，做好性能测试场景设计的前提之一是做好性能测试的需求调研那么，性能测试的需求调研涉及哪些内容下面列出一个list：

• 项目计划（开始时间、上线时间等）

• 涉及哪些服务器：Web服务器、应用服务器、数据库服务器、签名服务器、交换机等等

• 哪些方面的性能：联机交易、批处理、稳定性、数据备份、数据传输、控制机制（流量控制、超时控制）

• 平均日交易量、峰值交易量（笔/小时）

• 交易平均响应时间、最大响应时间

• 关注测试环境资源，以及与生产环境的差异

• 关注各個服务器的基本配置：

• 服务器型号、CPU、内存、网络带宽、存储容量、磁盘IOPS、MBPS、IP地址

• 操作系统、系统软件、应用软件以及它们的版本、参数配置是否需要优化配置

• 测试数据来源：生产数据清洗回放、测试工具实时产生

• 需要产生的数据量大小、TPS

• 哪些表需要存量数据、存量数据嘚大小、数据类型