jmeter英语怎么念

本文分上下两个部分，上半部分主要介绍： 一、什么是性能测试 二、术语 三、性能测试类型下半部分主要介绍： 四、性能测试流程 五、性能测试执行（三分钟教会你用Jmeter进行性能压测） 六、结果查看及分析    通篇的风格以寓教于乐为主，介绍知识为辅。希望大家能在快乐中学习，在开心中成长。时间仓促，错误纰漏在所难免，还请“大神”不惜指正！一、什么是性能测试     性能测试 是通过对系统进行性能需求分析，在合理评估的性能测试环境上，通过测试工具模拟正常、峰值、以及异常负载条件对系统各项性能指标进行测试，旨在发现性能缺陷、进行能力验证、验证规划能力和性能调优，并针对测试结果进行分析总结定位的测试过程。（* 引自专家测试团队《性能测试白皮书》） ************解释************    通俗点说，就是使用用各种“酒具”（jmeter、LoadRunner、Power平台）配合着各种“红、白、啤酒”（入参数据+并发数）来让你达到“正常嗨（正常）、非常嗨（峰值）、嗨过头（异常负载）”的状态，并在这期间通过“心电图”（JMC-- Java Mission Control）或者把你放到“提前定制化的座椅”（RSMS、Dolphin）来持续对你进行观察、监控，从而记录下你在不同剂量下的反应。并根据观察结果来分析“红酒您能喝几瓶”、“白酒能喝几瓶”、“啤酒能喝几瓶”（能力验证）；强化了身体素质（系统性能优化）之后又能喝几瓶；甚至是规划一下“有蒙古大汉自远方来不亦喝乎”时，你能不能喝翻他（容量规划）等等……，这些过程，就是“性能测试”！ 二、术语     在继续介绍性能测试之前，我们有必要先解释一下经常用的一些术语。否则我瞎逼逼半天，您一脸懵逼，大家就真的在尬聊了…… 1.并发用户数     同一时刻操作某个页面或某个功能的用户数，描述系统能够承受的并发性能。它是一个时间段内发生的事情，它意在表达“并发”的可能性，是压力的一种度量。计算公式：C=nl/t  n :  业务在线的总用户数量  l :  业务产生的平均时间长度  t :  考察的时间段总长度 ************解释************  我们假想出一个很长很长的水泥管道，管道入口处站了1000个高矮胖瘦一致的人，其中有400人想要通过这个管道。每个人走过这个管道平均需要1个小时，前面的人没走完时入口不放行下一组进入，且入口处每天只有8小时可以放行让人进入。那么，这时“预期”的并发用户数就是400*1/8=50，也就是说，只有管道宽的可以装下50人并排走，才能在一天之内让400人都通过。     为什么说是“预期”呢？那是因为可能您胆子小，假想的时候没敢想太大，就只想出了一个允许2人通行的小水管。那8小时肯定走不完所有人啊，所以你需要继续想、使劲努力YY出一个巨大的管子（性能优化）！当然，不排除您跟我一样天赋异禀，一开始就构想出能同时并排200人的巨管。这意味着，就并发用户数这一项，您的系统性能指标完爆当前既定业务量。    2.响应时间    用户发起请求到响应返回的时间，描述交易执行快慢程度。（计算规则：响应时间=网络传输时间+系统响应时间） 90%Percent：每个事务90%用户的响应时间在该值以下 Minimum：每个事务所有用户中最小的响应时间 Average：每个事务所有用户的响应时间算数平均值 Maximum：每个事务所有用户中最大的响应时间 ************解释************     还是继续走管道……我们给每个人发一个秒表，人们并排进入管道的同时每个人按下秒表。每个人行走的速度不同，虽然是并排进入，但并不是一同出来。每一个人走出管道的同时，再次按下秒表……这时，秒表记录的时间就是这个人（请求）开始到结束的响应时间。 90%Percent：我们把同时走管道的一波人看做一个队伍，队伍中90%的人是在这个时间以内就走出了管道； Minimum：走的最快的那个人所用的时间； Average：所有人花费时间的平均值（在这个例子中为1小时）； Maximum：走的最慢的那个人所用的时间。     3.TPS  指每秒处理的事务数，TPS=总事务数/总的时间，描述了服务器的处理能力。  ************解释************     一句话，就是每秒钟通过管道的人。这里肯定有人觉得这个概念看着眼熟，很像最开始的并发用户数，对么？仔细看一下他们的区别：并发用户数是指同时进入管道的“肩并肩”的人，吞吐量是指每秒钟那些肩并肩进入管道的人中，平均多少人走了出来。所以，在这里“TPS = 并发数/平均响应时间”      4.二八法则    【80%的业务请求在20%的业务时间里面产生。】    如：信用卡客服系统中"客户信息查询功能”年使用量为4800万次，系统服务时间为7*24小时。每秒请求数：    48000000*80%/365*24*3600*20%=38400000/6307200=6次/秒  ************解释************  这个有毛用呢？试想一下，如果我们要压这个信用卡客服系统，是不是真的需要7*24小时不停压一年凑够4800万个请求呢？用脚趾头也能想明白，肯定不用啊！那如何在减少工作量的情况下尽可能的模拟真实场景呢？这个时候二八法则就出场了！（别问我为什么不是三七、四六、五五法则，你当是在分赃吗？）5. 2-5-8原则     WEB系统性能测试中的2-5-8原则描述如下： 用户在2秒以内得到响应时，系统的响应很快，用户对系统的体验较优； 用户在2-5秒之间得到响应时，系统的响应速度还可以，用户对系统的体验一般； 用户在5-8秒以内得到响应时，系统的响应速度较慢但还在接受范围，用户对系统的体验较慢； 用户在超过8秒后仍然无法得到响应时，通常会认为系统已经失去响应，选择离开或者发起第二次请求，用户对系统的体验很糟糕。 ************翻译************ 这个没啥好解释的，就是个“业界”非标准化的一个标准……所以，以后在项目中没有明确要求某功能or页面的响应时间时，就拿这个当标准来考量吧！另外需要补充的一点是，我们用jmeter一般是压接口，我们得出的响应时间一般会小于直接压页面，为什么呢？这里影响响应时间的除了网络传输时间+系统响应时间，还有个前端页面渲染的时间。所以如果我们想web用户体验较好（3秒内），压接口的响应时间最好就要低于3秒，这给页面渲染留出一定的冗余时间。三、性能测试类型     终于要开始介绍性能测试的干货（Fuck foods）了。1、基准测试 测试系统是否存在线程安全性问题，并得到一定测试条件下的系统的性能基线数据。目的是得到系统的性能基线数据，并对响应时间、TPS和其他与时间相关的需求进行评估。 ************翻译************ 俗话说的好，“凡事都有个第一次，再丑的媳妇也要见公婆”。这个类型就是针对之前没有做过性能测试，或者是根据新需求而刚刚开发完成的新系统来说的。这时，您就需要来一份“基准测试”啦！先给自己留个底儿，有了性能基线，我们才能继续后面的“调优”不是？ 对比测试 对比不同测试条件下的性能差距，常用于系统优化，技术选型，通过相同的用例对比性能数据。测试方式和负载测试类似。 ************翻译************ 多说无益，我们“举几个比方，打几个栗子”： 我们对系统的某功能进行了优化，需要验证该功能在优化前后的性能对比数据时，可以进行对比测试； 老板让我说出两种系统架构或者实现方法下，哪一种更好，可以进行对比测试； 老板让我说出这两款设备，哪一款更优秀，可以进行对比测试。 说白了，就是各种比较，没有对比就没有伤害；不对比你怎么能知道你有多胖呢，对不对？！（观众：扔砖头！！！）2、容量规划 测试系统在软硬件上的扩展能力，常用于测试软件扩容，硬件扩容。容量规划也是对比测试的一种。 ************翻译************ 就如定义中所说，容量规划也是对比测试的一种。这个类型主要使用场景有： 软件扩容：我们用多线程来代替原有的单线程处理请求； 硬件扩容：我们增加了两台redis，加大了weblogic server的内存或者直接增加了4台服务器。 在这里也要额外说一点：我们扩容，特别是硬件扩容，是不能按照倍数来放大扩容效果的。例如，我们2台server时TPS为100，我们增加到4台同样配置的server时，TPS并不是增加到200了。有可能是160、170、180……这其中并没有一个线性的关系，这点很重要需要知悉。所以，很多时候项目组找到我们做性能测试，说我们生产环境与测试环境配置相同，只是数量不同，是否能直接换算性能指标呢？答案是否定的！我们只能说，你在测试环境中如果满足了预期性能指标，那生产环境理论上是没有问题的，no more！3、稳定性测试 采用系统稳定运行情况下能够支持的最大并发用户数，或者日常运行用户数，持续运行一段时间。目标是检测系统能否持续稳定工作。 ************解释************ 其实，我们在用Jmeter压测的时候，至少都要持续10~15min以上，为什么呢？我们要让TPS稳定下来，这时采集的数据才有效；当然，并不是说15分钟就一定够了，某些情况下需要更长时间的压测才能发现性能问题。 稳定性测试多用于对“系统稳定性”有“强需求”的系统，比如金融类的银行、证券等等。如系统要求3*24小时运行，测试当系统在一定的压力情况下（如CPU资源使用率维持在50%左右），选取复合场景的案例，持续运行3x24小时，观测系统的稳定性状态数据。 还有一种是：测试人员发现，系统在短时间（1个小时、8个小时甚至1天）内都是正常的，但一超过一定时间后就会CPU利用率徒增，或者内存持续增高（疑似内存泄露），这也需要来一场轰轰烈烈的稳定性测试……4、负载测试 负载测试是通过逐渐增加用户量来观察在不同的负载下系统的指标，以检验系统的行为和特性，以发现系统可能存在的性能问题，并可以检测系统的伸缩性。 也可以确定在什么负载条件下系统性能处于失效状态，目标是获得系统能提供的最大服务级别。 ************解释************ 负载测试是大家平时做性能测试使用最多的一种类型，甚至有些时候大家嘴里所说的性能测试，就是指的负载测试。说的直白点，就是你写好脚本跑个100并发，发现对于系统来说“洒洒水啦”，监控显示内存和CPU指标都懒得波动一下。那我们加到400试试，加到500呢，1000……？所以，这就是一个“试”的过程，直到系统“失效”！这里的“失效”不一定是指系统宕机，监控显示CPU、Memory利用率超过80%了也叫失效，系统响应时间超过预期的3秒了也叫失效，就看哪个条件先被打破了……