系统性能测试场景规划设计.docx

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