单篇长文 TestNG 从入门到精通

本书作者:测试开发刚哥,文章版权归个人所有,未经授权请勿转载。 简介 TestNG 是 Test Next Generation 的缩写,它的灵感来自于 JUnit 和 NUnit,在它们基础上增加了很多很牛的功能,比如说: 注解。 多线程,比如所有方法都在各自线程中,一个测试类一个线程等。 验证代码是否多线程安全。 灵活的测试配置。 支持数据驱动(@DataProvider)。 支持参数化。 强大的执行机制(不需要 TestSuite)。 能跟各种工具结合(比如 IDEA、Maven 等)。 内嵌 BeanShell。 提供运行时和日志的 JDK 函数(不需要添加 dependencies)。 提供应用服务器测试依赖的方法。 一句话总结就是,TestNG 强大到能覆盖所有测试类型:单元测试、功能测试、端到端测试、集成测试等等等。 一个简单的示例如下: package example1; import org.testng.annotations.*; public class SimpleTest { @BeforeClass public void setUp() { // code that will be invoked when this test is instantiated } @Test(groups = { "fast" }) public void aFastTest() { System.out.println("Fast test"); } @Test(groups = { "slow" }) public void aSlowTest() { System.out.println("Slow test"); } } setUp()会在测试类创建后,测试方法执行前运行。 测试方法名字可以任意的,TestNG 通过@Test 注解来标识。 可以把测试方法按 group 分组。 然后使用 xml 来配置运行策略: ...

Allure+Maven+JUnit5 配置实践

为什么要用 JUnit5?

Locust 性能测试工具核心技术@task 和@events

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

locustfile 中的 User 类和 HttpUser 类

本书作者:测试开发刚哥,文章版权归个人所有,未经授权请勿转载。 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 ... ...

Python 技术栈性能测试工具 Locust 入门

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

性能测试指标 TP99,比平均响应时间更需要关注

本书作者:测试开发刚哥,文章版权归个人所有,未经授权请勿转载。 什么是 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 小众而实用 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。 ...

JMeter 扩展 Java 请求

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

JMeter 响应断言够用了

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

JMeter 定时器设置延迟与同步

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