测试专题

Tasks和Events是Locust性能测试工具的核心技术，有了它们，Locust才能称得上是一个性能工具。

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 locustfile是什么？ locustfile是Locust性能测试工具的用户脚本，描述了单个用户的行为。 locustfile是个普通的Python模块，如果写作locustfile.py，那么路径切换到文件所在目录，直接执行命令就能运行： $ locust 如果换个名字，那么只能通过-f参数指定文件名运行： $ locust -f locust_files/my_locust_file.py 与一般Python模块不同的是：locustfile必须至少定义一个类，且继承自User类。 User类 User类表示性能测试的模拟用户，Locust会在运行时创建User类的实例。 wait_time属性 设置等待时间，默认值不等待，立即执行。 Locust支持4种方式设置wait_time属性。 为了便于理解实际意义，我把源码贴在了下面。 constant函数，常量，任务执行完毕等待X秒开始下一任务。 def constant(wait_time): """ Returns a function that just returns the number specified by the wait_time argument Example:: class MyUser(User): wait_time = constant(3) """ return lambda instance: wait_time between函数，区间随机值，任务执行完毕等待X-Y秒（中间随机取值）开始下一任务。 def between(min_wait, max_wait): """ Returns a function that will return a random number between min_wait and max_wait. Example:: class MyUser(User): # wait between 3.0 and 10.5 seconds after each task wait_time = between(3.0, 10.5) """ return lambda instance: min_wait + random.random() * (max_wait - min_wait) constant_pacing函数，自适应，若任务耗时超过该时间，则任务结束后立即执行下一任务；若任务耗时不超过该时间，则等待达到该时间后执行下一任务。 def constant_pacing(wait_time): """ Returns a function that will track the run time of the tasks, and for each time it's called it will return a wait time that will try to make the total time between task execution equal to the time specified by the wait_time argument. In the following example the task will always be executed once every second, no matter the task execution time:: class MyUser(User): wait_time = constant_pacing(1) @task def my_task(self): time.sleep(random.random()) If a task execution exceeds the specified wait_time, the wait will be 0 before starting the next task. """ def wait_time_func(self): if not hasattr(self, "_cp_last_run"): self._cp_last_wait_time = wait_time self._cp_last_run = time() return wait_time else: run_time = time() - self._cp_last_run - self._cp_last_wait_time self._cp_last_wait_time = max(0, wait_time - run_time) self._cp_last_run = time() return self._cp_last_wait_time return wait_time_func 自定义wait_time方法，比如每次等待时间1秒2秒3秒递增： class MyUser(User): last_wait_time = 0 def wait_time(self): self.last_wait_time += 1 return self.last_wait_time ... ...

Locust是一款Python技术栈的开源的性能测试工具。Locust直译为蝗虫，寓意着它能产生蝗虫般成千上万的并发用户：

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 什么是TP99？ TP是Top Percentile的首字母缩写，TP99是指“前百分之九十九”，用来表示满足百分之九十九的网络请求所需的最低耗时。 该怎么理解？举个简单例子，下图是100次请求的响应时间走势图： 第23次请求的响应时间为600ms，其他请求的响应全部为1ms，这个走势图也就是常说的“尖刺”。我们来计算一下： ①平均响应时间 平均响应时间 = 所有请求响应时间之和 / 请求次数，等于6.99ms ②TP99 TP99 = 把响应时间从小到大排列，取第99%那个位置的值，等于1ms 为什么TP99更需要关注？ 平均响应时间受极端值的影响较大，因为出现1个尖刺，平均响应时间几乎是TP99的7倍！ TP99更能反映大多数请求的情况，通过TP99为1ms可以知道，应用系统对于大多数请求，都能在1ms内响应，整体性能达标。而对于尖刺，我们可以通过走势图的MAX来发现，单独进行分析。 在JMeter的Aggregate Report中，有3个字段：90% Line、95% Line、99%Line 其实就是指TP90、TP95、TP99。此外，在实际工作中，我们还会关注TP999，三个九，也就是99.9%。关注TP多少，取决于我们对性能的要求怎么样，我们希望应用系统满足多少请求。如果对性能要求不高，关注TP90就够了，允许10%请求出现波动。如果对性能要求很高，则需要关注TP999，99.9%请求都能够快速响应。

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 nGrinder小众而实用 nGrinder在GitHub的star有1.6k，相比于JMeter6.4k来说，要少很多。在测试资料中，关于压测工具也是以JMeter居多，几乎没有专门针对nGrinder的学习资料。nGrinder既然这么小众，那为什么还要学它呢？因为听说咱们公司的压测平台，底层就是用的nGrinder，对于企业级应用来说，nGrinder还是很实用的，正如它的介绍：“Enterprise level performance testing solution based on The Grinder”。 nGrinder有以下特点： 我们编写压测脚本用到的就是第一个特点提到的Groovy脚本，跟Java语法类似，可以无成本切换。 设计理念 nGrinder架构 nGrinder系统架构如下： nGrinder的底层是Grinder，基于Grinder的console和agent，nGrinder封装成了controller和agent： controller 提供了Web页面创建测试脚本和配置运行策略，这是nGrinder比较突出的特色了。 agent 虚拟用户生成器，创建压测负载。 当用户创建test后，会先创建一个console，AgentControllerServer会根据console分配相应的agent，AgentControllerServer管理着agent pool，负责agent的创建和释放。然后console将test脚本和资源多个已分配的agent，并控制整个test flow直到测试结束。测试结束后，agent会回收至AgentControllerServer以便其他test使用，console也会回收至ConsoleManager。 nGrinder和Ginder最大的不同之处在于，nGrinder在controller中保留了多个console实例和agent。每个console都是跟其他console隔离的，能并发运行。 不像其他压测工具在测试时，会保留agent以确保用户执行test时agent是可用的，也就是“预占”agent。nGrinder只有在真正测试执行时，动态分配agent，这个方案是nGrinder最独特的架构设计。它保证了多个压测任务能并发执行，并发上限只取决于空闲的agent数量。 nGrinder3.1版本以前是单机架构的，如下图所示： 1、nGrinder使用SVNkit，即svn server，来管理脚本文件。svn仓库存放在${NGRINDER_HOME}目录。 2、nGrinder使用EhCache缓存，提升DB和SVN查询性能。 3、nGrinder使用Spring Security保证安全，并使用Atlassian支持扩展。 nGrinder3.1版本之后，支持集群： 1、集群中所有console共享同样的DB和文件系统，并指向NFS共享的同一个${NGRINDER_HOME}。 2、每个controller有它自己的${NGRINDER_EX_HOME}，存放特殊配置和日志。 3、所有controller相互复制EhCache，让某些数据在集群中都是可见的。 nGrinder技术栈 Client层 Bootstrap、Bootstrap-slider、Jquery、Jquery Validate、Datatables、Select2、JqPlot、CodeMirror。 Controller层 FreeMarker、Spring Security、Spring MVC、GSon、SVNKit Dav。 Service层 The Grinder、Atlassian Plugin Framework、Spring、EhCache。 Data层 Spring Data、H2、Cubrid、Liquibase、SVNKit。 快速入门 安装 在GitHub Release下载war包： https://github.com/naver/ngrinder/releases 执行命令： java -jar ngrinder-controller-{version}.war 访问http://localhost:8080/即可。 但是由于nGrinder需要占用大量内存，最好加上额外参数： ...

本文将通过WebRTC本地音视频流压测脚本，来说明JMeter如何扩展Java请求。

JMeter断言用来对服务器的响应数据进行验证，其中的响应断言基本能完成大多数的验证工作，但是JMeter还是提供了适用于多个不同场景的断言元件，一共16个，如下图所示：

JMeter定时器一般用来设置延迟与同步。它的作用域和优先级如下：

JMeter逻辑控制器可以对元件的执行逻辑进行控制，就像编程一样，实现业务需求。

JMeter内置了36个函数，这些函数可以通过函数助手进行编辑和测试。了解这些函数，不仅能提高JMeter的使用熟练度，也有助于知晓测试工具或测试框架通用的函数有哪些，在自主设计时，作为参考借鉴。