系统性能测试场景规划设计
一个性能测试案例的执行成本远高于功能测试，那么如何设计性能测试场景，以最少的案例拿出能够说明
问题的结论，是所有关注性能问题的工程师的重要目标，同时也是一门工匠的艺术。
1
本文总结了社区线上交流活动“如何规划和设计高质量的系统性能测试场景”的50 余个问题，将之
分门别类的汇总、归纳、浓缩，将50 余个方方面面的知识点在最短的篇幅中展现给大家。浓缩之后的章
节如下：
性能测试策略的设计
性能测试场景的设计
性能测试环境的设计
性能测试工具的选取和设计
2
(一)性能测试策略的设计
如何制定性能测试策略？
性能测试策略需要考虑以下方面
、业务测试范围
哪些测，哪些不测。比如什么业务测、什么操作系统版本、中间件版本测。
、制定优先级规则
由于测试场景、测试案例是没办法穷举的，理论上测试是永远不可能结束的。并且，性能测试本身又牵涉
出容量测试、扩展性测试、高可用测试、压力下的异常测试等等的测试延伸，因此在给定的时间条件下，
必须制定性能测试的优先级规则，根据优先级规则划定测试范围。性能测试的进展受制于功能验证的完成、
环境准备的完成、相关工具的开发、性能问题的定位和调优等，当性能测试的计划需要变更时，可以按照
优先级规则重新选择测试范围。
3 、基本的测试方法
例如：
a)如何产生业务压力
b )如何产生用户并发
c)如何构造场景使应用系统的逻辑处理算法达到生产的计算量级
d )如何制造外围环境对被测目标的响应
3
4 、测试环境设计
设计测试环境的拓扑结构和资源配置，因为测试环境的拓扑、资源不一定和生产环境相同。
需要想清楚为什么这么设计，也就是说在这样的环境下(可能是精简的环境)可以得出可信度高的性能测
试结论。
、概要测试计划
、依赖条件
、风险
等等
其中前 4 条基本决定了项目的工作量。更直接的说，前2 条决定了测试人员可以晚上几点回家。
“测测看”是不是一个有效的测试方法？
性能测试的成本是非常高的，“测测看”往往浪费严重。性能测试必须对测试场景有提前的规划，而这个
规划的前提是对被测系统、产品有充分的了解。业务上面那些交易吞吐量大，从技术上讲哪些服务器、哪
些模块容易出现性能瓶颈，甚至对操作系统、中间件、应用软件的参数都要提前规划好。不然测了很多案
例，发现参数不合理，测试结论完全作废。当然，有时我们并不能很准确的设计每个参数，但至少要有一
个计划，我对那个参数进行调参的测试，以期测出最优的性能表现。
4
然而，“测测看”有它的可取之处，因为真正的性能表现只有测试之后才会知道，笔者比较倾向的一种方
式是，“提前规划场景，每个场景跑完之后分析结果，然后决定下一场跑不跑、跑什么、参数怎么设”。
如何模拟和感知关联系统的压力？
1 )如何模拟核心系统的正常压力
不确定你问的是哪一方面，就我的理解先回答一部分
一个交易或者请求的链路可以很长，那么，可以从这条链路中任意一个节点，采用某种压力工具进行施加
压力。比如：
a)可以模拟end user的页面操作，用Loadrunner、JMeter等性能测试工具录制用户的页面操作，采
用并发用户回放，模拟用户。
b )可以模拟应用服务器直接给数据库服务器施加压力，采用性能测试工具，建立与数据库的连接，直接
把批量的 sql 语句扔过去
c)可以直接采用数据库录制回放，把生产上录制的数据库sql 在测试环境的数据库回放。
发起压力的机器离核心系统越近，越容易控制
2 )如何感知在测试系统接入后对核心系统的压力影响
5
这个由监控来做。平常不测试的时候，核心系统有多少TPS ，多少 CPU 占用、内存占用，多少任务数，
多少网络带宽占用、磁盘IO 、业务响应时间是多少。测试的时候，这些指标增加了多少，这个感知工作由
监控来做。
去掉前端系统，直接压测后端，和真实情况有差异吗？
如果模拟的逼真，是没有任何差异的。那么问题来了，什么是模拟的不逼真？
举例 1 )生产环境某系统每秒处理100 个事务，你如果采用性能测试工具，1 个用户每秒发100 个请求，
可以模拟出系统每秒处理100 个事务。但是，假如生产环境中这100 个事务是由100 个用户发起的，那
么此时就有些差异了。首先，网络通道的连接数可能不一样，用户登录次数可能不一样，session的打开
数量，数据库连接数，数据库启动的服务进程数等等都有可能不一样。
举例 2 )生产环境中每分钟处理60 个业务，这60 个业务是匀速达到的。而你如果在性能测试的时候，在
第一秒钟把60 笔业务都发出去了，后面59 秒闲着。那么这个模拟也是非常不逼真的。
一场性能测试跑多长时间合适？
很多人一跑性能场景就跑1 个小时以上，其实跑多久完全取决于系统特点。有些
扫一扫
4555
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
