测试 on 测试开发刚哥

单篇长文 TestNG 从入门到精通

Wed, 21 Jan 2026 00:00:00 +0000

简介

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 配置实践

Tue, 20 Jan 2026 00:00:00 +0000

为什么要用 JUnit5？

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

Sun, 18 Jan 2026 00:00:00 +0000

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

locustfile 中的 User 类和 HttpUser 类

Sat, 17 Jan 2026 00:00:00 +0000

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 入门

Fri, 16 Jan 2026 00:00:00 +0000

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

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

Thu, 15 Jan 2026 00:00:00 +0000

什么是 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

Wed, 14 Jan 2026 00:00:00 +0000

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 请求

Tue, 13 Jan 2026 00:00:00 +0000

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

JMeter 响应断言够用了

Mon, 12 Jan 2026 00:00:00 +0000

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

JMeter 定时器设置延迟与同步

Sun, 11 Jan 2026 00:00:00 +0000

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

JMeter 逻辑控制器完整介绍

Sat, 10 Jan 2026 00:00:00 +0000

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

JMeter36 个内置函数及 11 个新增函数介绍

Fri, 09 Jan 2026 00:00:00 +0000

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

Java 单元测试 Mock 框架 Mockito 入门介绍

Thu, 08 Jan 2026 00:00:00 +0000

鸡尾酒

Mockito 是 Java 的单元测试 Mock 框架。它的 logo 是一杯古巴最著名的鸡尾酒 Mojito，Ｍojito 鸡尾酒，源自古巴的哈瓦那，带有浓厚的加勒比海风情。并不浓烈，但是喝一杯下去，脸上会泛起红晕，象少女的羞涩。味道很清新，有一点青涩、有点甜蜜。

Stub & Mock

Stub 和 Mock 是 Test Double 类型中的 2 种。Test Double 一共有 5 种类型，Dummy，Stub，Spy，Mock，Fake。

Test Double 是测试复制品，用来统称模拟真实对象的假对象。因使用场景有略微不同，而有这 5 种类型。

Dummy，通常只用来填充参数列表。有可能是 null 对象引用，或 Object 类实例等。
Fake，是简化版的实现，比如基于内存实现的数据库，不会真的去做数据库操作，用简单的 HashMap 来存放数据。
Stub，Stub 用来替代 SUT(System Under Test)依赖的组件，但是只模拟一个外部依赖，不做断言。
Spy，介于 Stub 和 Mock 之间。如果真实对象没有被打桩，当调用 Spy 对象时，真实对象也会被调用。
Mock，可以理解为 Stub+Verification，既模拟外部依赖，也会定义预期结果。

看一个实例，发送邮件，

public interface MailService {
    public void send(Message msg);
}

先写个 Stub，

public class MailServiceStub implements MailService {
    private List<Message> messages = new ArrayList<Message>();

    public void send(Message msg) {
        messages.add(msg);
    }

    public int numberSent() {
        return messages.size();
    }
}

实现 Stub 的状态验证，

JMeter 四种参数化方式

Thu, 08 Jan 2026 00:00:00 +0000

JMeter 参数化是指把固定的数据动态化，这样更贴合实际的模拟用户请求，比如模拟多个不同账号。JMeter 一共有四种参数化方式，分别是：

Allure 测试报告完整学习笔记

Wed, 07 Jan 2026 00:00:00 +0000

简介

假如你想让测试报告变得漂亮一点，那你一定会在搜索引擎中找到 Allure 测试报告的。Allure 官方给出了个在线网站，访问以下链接就能一睹为快：

https://demo.qameta.io/allure/

可以在左下角切换为中文报告：

如此好看的测试报告，哪个老板不喜欢呢？

安装 Allure

1.在 GitHub releases：

https://github.com/allure-framework/allure2/releases

或者 Maven Central：

https://repo.maven.apache.org/maven2/io/qameta/allure/allure-commandline/

下载安装包并解压。

2.找到 bin 目录，Windows 使用allure.bat，Unix 使用allure：

3.为了后续方便使用，可以把 bin 完整路径添加到系统环境变量 PATH中，然后在命令行直接输入allure命令。

官方也给出了通过 Linux 的 ppa、Mac 的 brew、Windows 的 scoop 的安装方式，不过对于咱们老百姓来说，不如手动下载包来安装实在。

安装后就可以检查是否安装成功了：

$ allure --version
2.17.2

因为 Allure 是用 Java 写的，所以如果无法运行，那么要检查下有没有安装 Java。

Allure 测试报告的结构

Overview

JMeter 关联陌生又熟悉

Wed, 07 Jan 2026 00:00:00 +0000

JMeter 关联是什么

JMeter 关联，这几个字看着可能会有点陌生，实际上却是工作中经常会做的一件事情，尤其是接口自动化，它指的是把一个接口的响应作为另一个接口的参数，从而把接口关联起来。

JMeter 关联是通过后置处理器来实现的，本文将介绍两个主流提取器：正则表达式提取器和 JSON JMESPath 提取器。

正则表达式提取器

Name

最好有业务含义的名称。

Comments

可以为空的注释。

Apply to

匹配范围。

Main sample and sub-samples

匹配当前父取样器及其子取样器。

Main sample only

仅匹配当前父取样器。

Sub-samples only

仅匹配子取样器。

JMeter Variable Name to use

匹配 JMeter 变量。

Field to check

匹配响应的字段，共七个选项。

Body：主体，最常用。

Body(unescaped) ：替换了所有的 html 转义符的响应主体内容，注意 html 转义符处理时不考虑上下文，因此可能有不正确的转换，不太建议使用。

Body as a Document：从不同类型的文件中提取文本，注意这个选项比较影响性能。

Response Headers：响应 Headers。

Request Headers：请求 Headers。

URL：请求 URL。

Response Code：响应代码，比如 200、404 返回码。

Response Message：响应信息，比如“成功”、“OK”字样。

Name of created variable

创建的变量名，比如变量名为 token，通过${token}进行访问。

JUnit5 依赖注入与测试接口

Wed, 07 Jan 2026 00:00:00 +0000

依赖注入

以前的 JUnit 的类构造方法和测试方法都是不能有参数的，JUnit Jupiter 有一个颠覆性的改进，就是允许它们有入参，这样就能做依赖注入了。

ParameterResolver 是一个接口类，类构造方法和测试方法在运行时，必须由被注册的 ParameterResolver 进行解析。JUnit Jupiter 有三个自动注册的内置解析器：

TestInfoParameterResolver 参数类型为 TestInfo
RepetitionInfoParameterResolver 参数类型为 RepetitionInfo
TestReporterParameterResolver 参数类型为 TestReporter

TestInfo

TestInfo 包含 the display name, the test class, the test method, and associated tags 等信息。

示例：

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Tag;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInfo;

@DisplayName("TestInfo Demo")
class TestInfoDemo {

    TestInfoDemo(TestInfo testInfo) {
        assertEquals("TestInfo Demo", testInfo.getDisplayName());
    }

    @BeforeEach
    void init(TestInfo testInfo) {
        String displayName = testInfo.getDisplayName();
        assertTrue(displayName.equals("TEST 1") || displayName.equals("test2()"));
    }

    @Test
    @DisplayName("TEST 1")
    @Tag("my-tag")
    void test1(TestInfo testInfo) {
        assertEquals("TEST 1", testInfo.getDisplayName());
        assertTrue(testInfo.getTags().contains("my-tag"));
    }

    @Test
    void test2() {
    }

}

RepetitionInfo

pytest 用例查找原理

Wed, 07 Jan 2026 00:00:00 +0000

当执行 pytest 命令时，pytest 会从 project 中查找 test 来执行。本文先从几个路径相关的概念讲起，这样便于理解 pytest 在遍历路径时的走向。

JMeter100 个线程竟然只模拟出 1 个并发

Tue, 06 Jan 2026 00:00:00 +0000

线程组编辑区如下：

JUnit5 参数化测试的几种方式

Tue, 06 Jan 2026 00:00:00 +0000

参数化测试一直是津津乐道的话题，我们都知道 JMeter 有四种参数化方式：用户自定义变量、用户参数、CSV 文件、函数助手，那么 JUnit5 有哪些参数化测试的方式呢？

pytest 断言技巧

Tue, 06 Jan 2026 00:00:00 +0000

pytest 的断言把 Python 语言简洁的优点发挥的淋漓尽致，因为它用的就是 Python 的标准断言assert。

老板给我安排了个测试环境治理的活

Tue, 06 Jan 2026 00:00:00 +0000

测试环境困局

测试环境治理专项是在我入职 2 个月接手的活，用“烂摊子”来形容一点也不为过。年久失修，需求基本没有在测试环境使用，想用也有很多问题。人员缺乏信心，之前负责测试环境的同学抱怨极多，外部推不动，内部又没有技术能力支撑，负能量已经蔓延到整个团队。当然，我也是其中一员，这事确实难搞。在技术部测试环境平台化的大方向下，需要每个组出一个接口人来牵头，考虑到我以前写过测试平台，乱七八糟的事都整过，老板就指定了我。

What，测试环境是什么？

测试环境是一套能够支撑业务系统运行的环境，是相对于预发环境和生产环境来说完全隔离的环境。测试环境=应用+数据+配置+依赖服务。应用包含系统应用和中间件等，数据就是测试物料，配置针对测试环境应该有单独的一套，依赖服务要跟外部联调好以后整个环境才是可用的。测试环境治理就是通过内部搭建和外部联调，保障业务系统能够在完全隔离的环境中运行。

Why，为什么要做测试环境？

测试环境是为了隔离。如果只有一套生产环境，那么开发、测试、上线等活动，可能会对线上系统稳定性造成影响，可能会污染线上用户数据，可能引起客户投诉甚至资产损失，所以需要有一套完全隔离的测试环境。

Who，谁来负责测试环境？

每个测试人员都需要具备测试环境搭建能力。当然可以推动运维或研发来搭建测试环境，但是测试人员需要具备搭建能力，能够自主编译，构建，部署，遇到问题能够根据日志做初步定位，将问题抛出推动研发或外部依赖方解决。

When，什么时间做测试环境？

测试环境治理需要前置到研发自测阶段。在实践过程中，测试同学暴露出来最多的问题是，没有时间投入到测试环境搭建中，一方面是缺乏动力，不肯迈出艰难的第一步，另一方面也是跟项目节奏有关，研发就算用测试环境自测，也会在预发联调好以后再提测，到测试手上时，已经有可用的预发环境了，就不会再去用测试环境。“项目时间紧，测试环境不好用，直接用预发测吧”，顺理成章的就成为了很合理的借口。所以需要从提测，前置到，研发自测，做测试环境治理：

Where，从哪里入手测试环境？

测试环境治理需要从上往下才能推动，先有文化，才有行动。假如只有某个部门想做测试环境治理，外部依赖基本上是推不动的，一个人呐喊得再愤怒其他人也可能无动于衷。所以得先把测试环境治理这件事，跟老板沟通，从高层入手，把它定义为一项政治任务，从上往下层层递进。

How，怎么做测试环境？

工欲善其事，必先利其器，公司的基建比较完善，给测试人员搭建测试环境降低了很大难度。设想一下，假如只能折腾 Docker 和 K8S，那可能需要专门的运维才能搞得定环境，对测试来说门槛就会比较高了，除了少数技术能力强的，其他同学基本没有什么可操作性。测试环境平台化就是武器。公司有个部署平台叫做 JDOS，日常运维都是在这上面操作，没有运维人员，环境全靠开发人员和测试人员自己整。JDOS 已经是页面化操作了，但它对测试环境没有特殊的应用场景，是个大而全的平台，所以二级部门开了一个测试环境平台，Env，“一款全流程自动化测试环境搭建的利器”。

Env 的核心思想是1+N。1代表稳定分组（分组≈Pod），搭建稳定分组需要经过创建系统，创建应用，创建集群，申请机器，代码编译构建，部署镜像，修改配置等操作，需要选取 master 稳定版本，这样才能对外提供稳定服务。N是克隆1产生的多个分组，相互隔离，能让开发同学复用测试搭建好的环境，完成冒烟自测等过程；也能在多业务联调测试时，通过平台快速搭建一套全链路测试环境。

Env 提供了环境监控的功能。对于搭建好的稳定环境，它可以每天监控机器是否可用，服务是否正常，镜像是否老旧，等等等，让你及时维护环境，保障稳定性。

Env 提供了一键搭建的功能。新克隆的环境，只要点一下“一键搭建”，就会基于稳定分组，自动化搭建一套新环境，大大节约了时间成本。

Env 提供了拓扑画图的功能。将多个应用拖到一张拓扑图里面，根据依赖关系连线，能够直观了解到应用之间的依赖关系。基于拓扑来克隆新环境，也能批量克隆多个应用。假如多项目需求并行迭代，想要多套联调的测试环境，就可以克隆多套新环境。

Env 还解决了一个资源浪费的问题，以前搭建测试环境比较随意，申请资源也很容易，其实会导致很多机器用过后，一直空置在那里。Env 收拢了申请资源入口，基于 Env 来创建稳定分组，只能有 1 个，想要更多必须走审批。而对于克隆的新环境，也会有期限，14 天以后会自动释放，想要延期也必须走审批。

我所负责的第一件事，就是用 Env 来搭建一张拓扑图，把组内所有应用都从 JDOS 迁移到 Env 上，维持稳定环境对外提供支撑对接，克隆环境对内支持多项目并行。

搭建测试环境只是起步，测试环境治理的目标是需求能够使用测试环境。对于外部依赖少的业务模块来说，这相对容易。对于外部依赖很多的业务模块来说，这就很难了。那么该如何推动这件事呢？

第 1 个策略是共建，让研发和测试一起来搭建和维护测试环境。

第 2 个策略是做功能验证，梳理出链路用例，跟踪验证结果，识别卡点问题：

对于卡点问题的处理，把干系人单独拉群对，响应超过 3 天就往上抛，一定会遇到推不动的问题，那么办法只能找自己的上游负责人，层层向上反馈，让上面的负责人去找对方负责人，然后推动对方的下游同学来协助解决。卡点问题记录后需要做问题分类，做好统计，这既是工作量的体现，也是每周进度汇报的依据：

第 3 个策略就是制定 kpi，强制大家使用测试环境完成绩效。

How much，测试环境做到什么程度？

测试环境的 kpi 能反应出测试环境应该做到什么程度，可以使用需求使用测试环境占比和测试环境 bug 占比。需求使用测试环境占比的计算公式是打标了测试环境的提测卡片数/总的提测卡片数，测试在点击开始测试时，选择是否使用测试环境进行打标。测试环境 bug 占比的计算公式是测试环境bug/(测试环境bug+预发环境bug+生产环境bug)，在提交缺陷时选择环境类型进行打标。测试环境 bug 占比的意义更大，因为使用测试环境与否，最终的体现还是落在缺陷上面的，比较容易量化，需求使用测试环境占比不是很确定，需求多少功能在测试环境使用了，相对来说不是很好度量，但也可以作为辅助指标进行观察。

HttpRunner3 的$符号是如何解析的

Mon, 05 Jan 2026 00:00:00 +0000

变量解析

$符号在很多测试框架中都会拿来用做变量解析，大名鼎鼎的 JMeter 就有这个用法。HttpRunner3 也支持$符号，比如：

Step(
    RunRequest("登录")
        .post("/login")
        .with_headers(**{"Content-Type": "application/json"})
        .with_json({"username": "dongfanger", "password": "123456"})
        .extract()
        .with_jmespath("body.token", "token")
        .validate()
        .assert_equal("status_code", 200)
),
Step(
    RunRequest("搜索商品")
        .get("searchSku?skuName=电子书")
        .with_headers(**{"token": "$token"})
        .extract()
        .with_jmespath("body.skuId", "skuId")
        .with_jmespath("body.price", "skuPrice")
        .validate()
        .assert_equal("status_code", 200)
),

从登录提取的变量token，在搜索商品中使用$token来引用。

parser.py

HttpRunner 对$符号的解析是在 parser.py 文件中实现的：

这些方法可以分为四类：

url

build_url()
变量

extract_variables() get_mapping_variable() parse_variables_mapping() regex_findall_variables() parse_data() parse_string()
函数

get_mapping_function() parse_function_params() regex_findall_functions() parse_string_value() parse_data() parse_string()
参数化（"${parameterize(account.csv)}"）

parse_parameters()

本文专门针对变量这一块源码来进行剖析。

全局变量池

HttpRunner3 在运行时的所有变量都是存储在__session_variables这个字典中的：

在脚本开始时会把 config 的预设变量加载进来，然后会在执行 Step 测试步骤时，把各个步骤的变量也放到全局变量池里面。

解析过程

在 runner.py 的第 350 行代码能看到解析变量的调用：

JaCoCo 增量覆盖率的基本实现原理

Mon, 05 Jan 2026 00:00:00 +0000

什么是增量覆盖率

如图所示，在 master 分支提交了 HelloController，然后从 master 拉了个新分支 test；提交了第 1 次代码，增加了 WorldController；提交了第 2 次代码，增加了 DonController。增量的获取方式有两种：

版本对比：在分支上，第 2 次提交和第 1 次提交版本对比的增量代码，就是 DonController；第 2 次提交和刚从 master 拉取分支时版本对比的增量代码，除了 DonController 还有 WorldController；
分支对比：把 test 分支和 master 分支进行对比，增量代码就是 DonController 和 WorldController；

增量，就是通过版本对比或分支对比，多出来的新增加的那部分代码。覆盖率是指程序运行以后，有多少代码被执行到了，除以总的代码数算出来的，即覆盖率=执行代码行数/总代码行数。增量覆盖率是针对增量代码来计算的，也就是增量覆盖率=执行代码行数/增量代码行数。

基本实现原理

使用 JaCoCo 的 On-the-fly 模式，以 tcpserver 方式启动，将远程机器的覆盖率数据通过 TCP 通信 dump 到本地 jacoco.exec 文件，二次开发 JaCoCo 源码，实现增量覆盖率分析和输出 HTML 报告。

JaCoCo 默认覆盖率

JaCoCo 是一个开源的覆盖率工具，它的 On-the-fly 模式，无须侵入应用启动脚本，只需在 JVM 中通过-javaagent 参数指定 jar 文件启动的代理程序，代理程序在 ClassLoader 装载一个 class 前判断是否需要注入 class 文件，将统计代码插入 class，覆盖率分析就可以在 JVM 执行的过程中完成。

JMeter 测试计划配置项解析

Mon, 05 Jan 2026 00:00:00 +0000

测试计划（Test Plan），是 JMeter 目录树的初始根节点，它的编辑区如下：

JUnit5 的条件测试、嵌套测试、重复测试

Mon, 05 Jan 2026 00:00:00 +0000

条件测试

JUnit5 支持条件注解，根据布尔值判断是否执行测试。

自定义条件

@EnabledIf和@DisabledIf注解用来设置自定义条件，示例：

@Test
@EnabledIf("customCondition")
void enabled() {
    // ...
}

@Test
@DisabledIf("customCondition")
void disabled() {
    // ...
}

boolean customCondition() {
    return true;
}

其中 customCondition()方法用来返回布尔值，它可以接受一个 ExtensionContext 类型的参数。如果定义在测试类外部，那么需要是 static 方法。

内置条件

JUnit5 的org.junit.jupiter.api.condition包中内置了一些条件注解。

操作系统条件

@EnabledOnOs和DisabledOnOs，示例：

@Test
@EnabledOnOs(MAC)
void onlyOnMacOs() {
    // ...
}

@TestOnMac
void testOnMac() {
    // ...
}

@Test
@EnabledOnOs({ LINUX, MAC })
void onLinuxOrMac() {
    // ...
}

@Test
@DisabledOnOs(WINDOWS)
void notOnWindows() {
    // ...
}

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Test
@EnabledOnOs(MAC)
@interface TestOnMac {
}

JRE 条件

pytest 参数化进阶

Mon, 05 Jan 2026 00:00:00 +0000

用过 unittest 的朋友，肯定知道可以借助 DDT 实现参数化。用过 JMeter 的朋友，肯定知道 JMeter 自带了 4 种参数化方式（见参考资料）。pytest 同样支持参数化，而且很简单很实用。

端到端自动化的开源框架

Mon, 05 Jan 2026 00:00:00 +0000

什么是 Playwright？

Playwright 是一个开源框架，用于对 Web 应用进行端到端测试。

什么是端到端测试？

这里的“端”，不是指 A 模块或 B 模块，而是可以理解为从前端到后端。举个例子，对于登录功能来说，如果只测前端，那么测试范围就是前端页面，可能会对后端接口进行 mock。如果只测后端，那么测试范围就是后端接口等。而端到端呢，就是前端输入用户名密码，点击登录，与后端交互，查询数据库，鉴权，后端返回登录成功，前端进行页面跳转。端到端测试，可以理解为全流程测试，也可以理解为模拟用户场景测试。

Playwright 框架特点

官方网站首页：https://playwright.dev/python/

总结下重点，一是跨浏览器、跨平台、跨语言；二是自动等待；三是多用户场景测试；四是只需要一次登录；五是可以录制脚本。

快速入门

在官网的顶部菜单可以切换不同编程语言的教程：

本文及后续文章均选择 Python。

安装

安装 Python 的 Playwright，这里结合了 pytest：

pip install pytest-playwright

成功后安装浏览器：

playwright install

这里也可以不安装浏览器，而是在脚本里面指定现有浏览器路径。

示例

test_example.py

import re
from playwright.sync_api import Page, expect

def test_has_title(page: Page):
    page.goto("https://playwright.dev/")

    # Expect a title "to contain" a substring.
    expect(page).to_have_title(re.compile("Playwright"))

def test_get_started_link(page: Page):
    page.goto("https://playwright.dev/")

    # Click the get started link.
    page.get_by_role("link", name="Get started").click()

    # Expects page to have a heading with the name of Installation.
    expect(page.get_by_role("heading", name="Installation")).to_be_visible()

执行 pytest 后默认会选择 chrome 在 headless 模式下运行，可以通过日志观察运行过程。

HttpRunner3 的变量是如何传递的

Sun, 04 Jan 2026 00:00:00 +0000

HttpRunner3 的变量可以在测试类的用例配置中通过variables添加，也可以在测试步骤中使用extract()、with_jmespath()提取出来放到变量x，再用$x传递给下一个接口使用，比如登录到下单流程的部分测试脚本如下：

JMeter 元件作用域实践指南

Sun, 04 Jan 2026 00:00:00 +0000

从一个问题说起

对于以下测试脚本：

为了能调用进入房间接口，需要从考场接口获取考场 token。为了调用考场接口，需要从登陆接口获取登陆 token。元件说明如下：

学生登录，提取登录${token}传入下个接口参数。
添加 HTTP Header Manager：
考场 token，提取考场${exam_token}传入下个接口参数。
添加 HTTP Header Manager：
进入房间

貌似挺合理，HTTP Header Manager 会给下方的接口添加请求头，运行结果真的如我们所料么？

运行顺序

在回答这个问题之前，有必要搞懂 JMeter 元件的运行顺序，它是由 2 个维度来决定的：从上往下和元件类型。

从上往下，即目录树从上往下。元件类型，分为 3 类：

线程组、逻辑控制器。
取样器。
配置元件、前置处理器、定时器、后置处理器、断言、监听器。

它们的运行顺序如下：

配置元件（如果存在）
前置处理器（如果存在）
定时器（如果存在）
取样器（如果存在）
后置处理器（如果存在且取样器的结果不为空）
断言（如果存在且取样器的结果不为空）
监听器（如果存在且取样器的结果不为空）

换句话说，假设我们新建了 1 个线程，想用这个线程去发请求。

第一步，初始化配置，比如参数化、设置 Header、Cookie 等，用到配置元件。

第二步，可能需要给线程加点参数，比如用户参数，用到前置处理器。

第三步，在发送请求前可能会等待一段时间，用到定时器。

第四步，发送请求，用到取样器。

第五步，可能需要提取响应数据，比如正则表达式提取器、JMESPath 提取器，用到后置处理器。

第六步，验证结果符合预期，用到断言。

第七步，查看请求响应数据和测试结果，用到监听器。

实践指南

对于以下所列元件：

JMeter 会按以下步骤运行：

线程组（如果有多个线程组可以在测试计划设置是顺序执行还是同时执行）
简单控制器（父节点）
HTTP Cookie 管理器（配置元件）
用户参数（前置处理器）
Synchronizing Timer（定时器）
HTTP 请求 1（取样器）
正则表达式提取器（后置处理器）
响应断言（断言）
HTTP Cookie 管理器（配置元件）
用户参数（前置处理器）
Synchronizing Timer（定时器）
HTTP 请求 2（取样器）
正则表达式提取器（后置处理器）
响应断言（断言）
HTTP 请求 3（取样器）
察看结果树（严格来讲是与第 6 步并行，也就是取样器之后）

作用域

其中有个观察作用域实际效果的关键元件：HTTP 请求 2，它的前后并没有元件，但是也被作用上了。在 JMeter 中，同一层级的元件具有相同的作用域！

JUnit5 的 Tag、Filter、Order、Lifecycle

Sun, 04 Jan 2026 00:00:00 +0000

Tag

JUnit5 可以使用@Tag注解给测试类和测试方法打 tag，这些 tag 能用来在执行时进行过滤，它跟 group 有点类似。

tag 应该遵循以下规则：

不能为 null 或者为空。
不能包含空格。
不能包含 ISO 控制字符。
不能包含保留字符：, ( ) & | !

示例代码：

import org.junit.jupiter.api.Tag;
import org.junit.jupiter.api.Test;

@Tag("fast")
@Tag("model")
class TaggingDemo {

    @Test
    @Tag("taxes")
    void testingTaxCalculation() {
    }

}

Filter

打好了 tag 后，在执行时可以进行过滤，比如 Maven 配置：

<!-- ... -->
<build>
    <plugins>
        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.22.2</version>
            <configuration>
                <groups>acceptance | !feature-a</groups>
                <excludedGroups>integration, regression</excludedGroups>
            </configuration>
        </plugin>
    </plugins>
</build>
<!-- ... -->

groups 用来指定包含哪些 tag，excludedGroups 用来指定排除哪些 tag。

pytest 内置和自定义 marker

Sun, 04 Jan 2026 00:00:00 +0000

可以通过命令行查看所有 marker，包括内置和自定义的

send_keys 报错 element_not_interactable

Sun, 04 Jan 2026 00:00:00 +0000

这两天要在阿里云日志中操作 UI，以输入关键字搜索日志。

SpringBoot 接入 JaCoCo 实践教程

Sun, 04 Jan 2026 00:00:00 +0000

静态接入和动态接入

SpingBoot 可以通过 2 种方式接入 JaCoCo：Maven 和 Agent。Maven 方式是静态接入，在编译时计算代码覆盖率。Agent 方式是动态接入，服务启起来以后，能实时根据代码命中情况计算代码覆盖率。

教程代码已上传开源项目：https://github.com/dongfanger/mini

Maven

pom.xml 添加依赖：

<dependency>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.7</version>
</dependency>

添加配置：

<build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <version>${project.parent.version}</version>
            </plugin>
            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>0.8.7</version>
                <executions>
                    <execution>
                        <id>default-prepare-agent</id>
                        <goals>
                            <goal>prepare-agent</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>default-report</id>
                        <goals>
                            <goal>report</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

点击 maven 的 install：

target/site/jacoco目录下就生成了覆盖率报告：

Agent

下载 jacoco 文件后解压，提取 2 个文件：

使用命令启动 SpringBoot，启动参数添加-javaagent：

java -javaagent:jacoco/jacocoagent.jar -jar target/mini-0.0.1-SNAPSHOT.jar

此时会生成 1 个jacoco.exec文件，这个文件就是覆盖率数据文件，采用以下命令根据数据文件生成 HTML 报告：

把 RPC 包进事务的暗坑

Sun, 04 Jan 2026 00:00:00 +0000

# 方式：把判断放进 SQL，一条语句的原子性
rows = db.execute("""
    UPDATE pay_record SET status = 'PAID'
    WHERE order_no = ? AND status = 'INIT'
""", order_no)

if rows == 0:
    return "已处理"          # 别人改过了，我不是第一个

grant_coupon(order_no)       # 只有改成功的那个才发券
return "success"

grant_coupon 失败会发生什么？

券永久丢失，该发没发，资损。

第一次请求：

UPDATE status: INIT → PAID   ✅ 已提交，改不回去了
grant_coupon(order_no)        ❌ 抛异常 / 超时 / 下游挂了

第二次请求：

rows = db.execute("UPDATE ... WHERE status = 'INIT'")  # status已是PAID
# rows == 0
return "已处理"   # ← 被自己的幂等逻辑拦住，不会执行grant_coupon

包进一个事务能解决吗

把 update 和 grant_coupon 这两个操作，包进一个事务里，要么同时执行，要么同时回滚，是不是就解决了？

HttpRunner3 的用例是怎么运行起来的

Sat, 03 Jan 2026 00:00:00 +0000

在 PyCharm 中打开examples/httpbin/basic_test.py：

JMeter 英文版界面介绍

Sat, 03 Jan 2026 00:00:00 +0000

JMeter 的界面虽然不华丽，但是使用起来还是很便利。本文将基于英文版界面对整个可视区域进行介绍，如果想看中文版，请在菜单栏点击 Choose Language 切换：

JUnit5 编写基本测试

Sat, 03 Jan 2026 00:00:00 +0000

JUnit5 的测试不是通过名称，而是通过注解来标识的。

pytest 精通 fixture

Sat, 03 Jan 2026 00:00:00 +0000

fixture 是什么

看看源码

def fixture(
    callable_or_scope=None,
    *args,
    scope="function",
    params=None,
    autouse=False,
    ids=None,
    name=None
):
    """Decorator to mark a fixture factory function.

    This decorator can be used, with or without parameters, to define a
    fixture function.

    The name of the fixture function can later be referenced to cause its
    invocation ahead of running tests: test
    modules or classes can use the ``pytest.mark.usefixtures(fixturename)``
    marker.

    Test functions can directly use fixture names as input
    arguments in which case the fixture instance returned from the fixture
    function will be injected.

    Fixtures can provide their values to test functions using ``return`` or ``yield``
    statements. When using ``yield`` the code block after the ``yield`` statement is executed
    as teardown code regardless of the test outcome, and must yield exactly once.

    :arg scope: the scope for which this fixture is shared, one of
                ``"function"`` (default), ``"class"``, ``"module"``,
                ``"package"`` or ``"session"`` (``"package"`` is considered **experimental**
                at this time).

                This parameter may also be a callable which receives ``(fixture_name, config)``
                as parameters, and must return a ``str`` with one of the values mentioned above.

                See :ref:`dynamic scope` in the docs for more information.

    :arg params: an optional list of parameters which will cause multiple
                invocations of the fixture function and all of the tests
                using it.
                The current parameter is available in ``request.param``.

    :arg autouse: if True, the fixture func is activated for all tests that
                can see it.  If False (the default) then an explicit
                reference is needed to activate the fixture.

    :arg ids: list of string ids each corresponding to the params
                so that they are part of the test id. If no ids are provided
                they will be generated automatically from the params.

    :arg name: the name of the fixture. This defaults to the name of the
                decorated function. If a fixture is used in the same module in
                which it is defined, the function name of the fixture will be
                shadowed by the function arg that requests the fixture; one way
                to resolve this is to name the decorated function
                ``fixture_<fixturename>`` and then use
                ``@pytest.fixture(name='<fixturename>')``.
    """
    if params is not None:
        params = list(params)

    fixture_function, arguments = _parse_fixture_args(
        callable_or_scope,
        *args,
        scope=scope,
        params=params,
        autouse=autouse,
        ids=ids,
        name=name,
    )
    scope = arguments.get("scope")
    params = arguments.get("params")
    autouse = arguments.get("autouse")
    ids = arguments.get("ids")
    name = arguments.get("name")

    if fixture_function and params is None and autouse is False:
        # direct decoration
        return FixtureFunctionMarker(scope, params, autouse, name=name)(
            fixture_function
        )

    return FixtureFunctionMarker(scope, params, autouse, ids=ids, name=name)

总结一下

webdriver 使用已打开过的 chrome

Sat, 03 Jan 2026 00:00:00 +0000

基本功能：

代码覆盖率从 0 到 100 的入门实践

Sat, 03 Jan 2026 00:00:00 +0000

JaCoCo 全称是Java Code Coverage，Java 代码覆盖率，广泛运用于各种测试平台对 Java 代码的全量覆盖率和增量覆盖率进行统计，分析代码行差异，度量单元测试效果。Jacoco 也是精准测试的技术实现手段之一。

基于 HAR 包的流量录制回放

Sat, 03 Jan 2026 00:00:00 +0000

什么是 HAR 包？

HAR（HTTP Archive format），是一种JSON格式的存档格式文件，通用扩展名为 .har。

HAR 包是 JSON 格式的，打开后，重点关注entries里面的request和response，包含了请求和响应信息。

流量录制

怎么获取 HAR 包呢？可以网上搜索方法，浏览器 F12、抓包工具（Charles、Proxyman 等）都可以将 HTTP 请求导出为 HAR 包。

生产级别的流量录制很复杂，想要了解的话可以参考阿里开源项目：https://github.com/alibaba/jvm-sandbox-repeater

回放对比

本文重点介绍在导出 HAR 包后，怎么通过 Python 来实现回放对比。

使用介绍

一、将 HAR 包转换为 pytest 用例

har_file 为 har 包路径，profile 配置开启回放，调用 Har.har2case()方法将 HAR 包转换为 pytest 用例。

转换后会生成：

demo_test.py 与 HAR 同名的 pytest 用例文件
demo-replay-diff 对比结果目录，暂时为空
sqlite.db 存储 HAR 包响应数据，标记为 expect

二、执行 pytest 用例

from tep.libraries.Diff import Diff
from tep.libraries.Sqlite import Sqlite


def test(HTTPRequestKeyword, BodyKeyword):
    var = {'caseId': '023f387db398504889e0afb8dd1bc99d', 'requestOrder': 1, 'diffDir': '/Users/wanggang424/Desktop/PycharmProjects/tep/tests/demo/case/har/demo-replay-diff'}
    
    url = "https://postman-echo.com/get?foo1=HDnY8&foo2=34.5"
    headers = {'Host': 'postman-echo.com', 'User-Agent': 'HttpRunnerPlus', 'Accept-Encoding': 'gzip'}
    ro = HTTPRequestKeyword("get", url=url, headers=headers)
    # user_defined_var = ro.response.jsonpath("$.jsonpath")
    assert ro.response.status_code < 400
    Sqlite.record_actual((ro.response.text, var["caseId"], var["requestOrder"], "GET", "https://postman-echo.com/get?foo1=HDnY8&foo2=34.5"), var)
    
    url = "https://postman-echo.com/post"
    headers = {'Host': 'postman-echo.com', 'User-Agent': 'Go-http-client/1.1', 'Content-Length': '28', 'Content-Type': 'application/json; charset=UTF-8', 'Cookie': 'sails.sid=s%3Az_LpglkKxTvJ_eHVUH6V67drKp0AGWW-.PidabaXOnatLRP47hVyqqepl6BdrpEQzRlJQXtbIiwk', 'Accept-Encoding': 'gzip', 'sails.sid': 's%3Az_LpglkKxTvJ_eHVUH6V67drKp0AGWW-.PidabaXOnatLRP47hVyqqepl6BdrpEQzRlJQXtbIiwk'}
    body = r"""{"foo1":"HDnY8","foo2":12.3}"""
    ro = BodyKeyword(body)
    # ro = BodyKeyword(body, {"$.jsonpath": "value"})
    body = ro.data
    ro = HTTPRequestKeyword("post", url=url, headers=headers, json=body)
    # user_defined_var = ro.response.jsonpath("$.jsonpath")
    assert ro.response.status_code < 400
    Sqlite.record_actual((ro.response.text, var["caseId"], var["requestOrder"], "POST", "https://postman-echo.com/post"), var)
    
    url = "https://postman-echo.com/post"
    headers = {'Host': 'postman-echo.com', 'User-Agent': 'Go-http-client/1.1', 'Content-Length': '20', 'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8', 'Cookie': 'sails.sid=s%3AS5e7w0zQ0xAsCwh9L8T6R7QLYCO7_gtD.r8%2B2w9IWqEIfuVkrZjnxzm2xADIk34zKAWXRPapr%2FAw', 'Accept-Encoding': 'gzip', 'sails.sid': 's%3AS5e7w0zQ0xAsCwh9L8T6R7QLYCO7_gtD.r8%2B2w9IWqEIfuVkrZjnxzm2xADIk34zKAWXRPapr%2FAw'}
    ro = HTTPRequestKeyword("post", url=url, headers=headers, data=body)
    # user_defined_var = ro.response.jsonpath("$.jsonpath")
    assert ro.response.status_code < 400
    Sqlite.record_actual((ro.response.text, var["caseId"], var["requestOrder"], "POST", "https://postman-echo.com/post"), var)

    Diff.make(var["caseId"], var["diffDir"])

执行时会记录实际请求响应，存入 sqlite 数据库，标记为 actual。

幂等测试

Sat, 03 Jan 2026 00:00:00 +0000

连续调用两次，第一次提交成功，第二次会被驳回——串行重复，系统是防住了的。

Android 测试三件套：传文件、抓包、看日志

Fri, 02 Jan 2026 00:00:00 +0000

在对安卓进行测试时，我们需要把 apk 传到安卓机上，对请求抓包，同时监控应用日志。本文就来讲讲具体操作。

HttpRunner3 的 HTTP 请求是怎么发出去的

Fri, 02 Jan 2026 00:00:00 +0000

在 HttpRunner3 的示例代码中，发送 HTTP 请求的代码是这样写的：

JMeter 是如何运行施压的

Fri, 02 Jan 2026 00:00:00 +0000

运行文件

JMeter 下载地址为：

https://jmeter.apache.org/download_jmeter.cgi

最新版本为 5.4.1，依赖于 Java8+，下载后无需安装，解压即用。解压后的目录和文件如下：

bin 二进制文件目录，包括配置文件、启动文件、启动 jar 包、示例脚本。比如 Windows 和 Linux 系统的两个启动脚本：

docs API 离线帮助文档。
extras 辅助功能，可用于 Ant、Jenkins 集成。
lib lib 根目录下存放 JMeter 基础 jar 包，lib/ext 目录下存放第三方或自定义扩展 jar 包。
licenses 证书文本文件。
printable_docs 离线帮助文档。
LICENSE 证书说明。
NOTICE 版权声明。
README 简介。

测试计划

JMeter 以图形界面方式启动后，首先映入眼帘的是左侧的 TestPlan，测试计划：

JMeter 的 UI 界面只能同时编辑一个测试计划，如果想再编辑另外一个测试计划，必须再打开一个 JMeter 界面。这是因为测试计划对应的是.jmx 文件！不同的.jmx 文件只能在不同的界面中编辑。

JMeter 界面是通过组件拖拽的方式来编写脚本的，脚本的根目录是测试计划。根节点只能有一个，作为根节点，测试计划很适合来做全局配置，比如在 User Defined Variables 处添加键值对格式的全局变量。

测试计划是默认节点，JMeter 还有另外一个不可缺少的次节点：Thread Group，线程组。

多线程

性能测试工具的目的是用少量电脑产生成百上千个并发请求。多进程和多线程正好能用来实现这个需求，书上有句关于进程和线程的至理名言：“进程是操作系统分配资源的最小单位，线程是程序执行的最小单位”。该如何理解呢？前一句的意思是说，每个应用程序都有对应的进程，按照进程来分配资源，可以使得资源利用最大化，避免浪费。后一句的理解得从一个故事讲起，很久以前，进程拿着资源找 CPU 执行。CPU 一看进程太大，说我处理不了。进程只能拆成多个线程给 CPU，不但能执行了，还能在线程之间灵活切换。

JUnit5 注解学习指引

Fri, 02 Jan 2026 00:00:00 +0000

注解（Annotations）是 JUnit 的标志性技术，本文就来对它的 20 个注解，以及元注解和组合注解进行学习。

Postman 竟然还能录制流量

Fri, 02 Jan 2026 00:00:00 +0000

大家好，我是刚哥。

pytest132 个命令行参数用法

Fri, 02 Jan 2026 00:00:00 +0000

在 Shell 执行pytest -h可以看到 pytest 的命令行参数有这 10 大类，共 132 个

代码评审，揭示黑盒背后的真相

Fri, 02 Jan 2026 00:00:00 +0000

一、引言

黑盒测试犹如案发现场，只能根据表象推断事件经过。

代码评审即深入调查，挖掘蛛丝马迹的线索，揭示背后的真相。

“They think I am hiding in the shadows, but I am the shadows.”

二、黑盒测试与白盒测试的区别

黑盒测试存在一些局限性：

可能无法发现与系统实现相关的问题
可能无法覆盖所有的测试场景
测试效率较低，比如准备物料、模拟场景
强依赖需求文档，如果文档不全，测试会漏

对于测试人员来说，可以在代码评审阶段，通过白盒测试改进测试的质量和效率。

三、代码评审的定义和意义

代码评审，Code Review（CR），是一种通过检查代码来提高代码质量的过程。

对于测试人员来说，参与代码评审，可以尽量提前发现问题，减少修复代价，提高效能。

四、代码评审的形式

多人讨论

组织会议，研发牵头讲解代码，架构和测试参与，讨论交流。这是最普遍的一种形式。

Code Diff

查看 Code Diff，可以借助 Gitlab 或 IDEA，比较分支差异或版本差异。

对比时机：

提测前和测试中，自行走查代码
发现缺陷，定位代码原因
修复缺陷后，评估影响范围
上线前，是否夹带代码

精准测试

评估测试用例的代码覆盖率，查漏补缺，Jacoco 的 on-the-fly 模式支持动态收集代码覆盖率数据。

五、代码评审的方法

面向业务，面向业务，面向业务。重要的事情说三遍。

刚开始做代码评审，很容易把注意力集中在找代码规范问题上面，比如命名不规范、注释不清楚、代码实现冗长等。这些问题不是测试人员关注的重点，需要由研发团队或代码扫描工具来解决。

在做 Code Diff 时，也没必要把每个文件、每行代码的意思搞懂，比如研发对代码结构做了调整，在 diff 时要梳理清楚的话，ROI 会非常低，因为既消耗时间，又发现不了问题。

那该怎么做代码评审呢？ 关注业务：

跟需求文档比较，哪些需求是遗漏的，哪些代码是补充的，哪些代码是夹带的
关注核心业务代码逻辑，使用条件覆盖、路径覆盖等方法设计测试用例
优化测试用例，针对代码实现考虑异常、边界、幂等、并发等场景

代码评审要求测试人员具备代码能力，理解编程语言，掌握软件设计，熟悉代码结构和架构，多与开发同学交流，共同优化代码质量。

六、代码评审的实际案例

1、空指针异常

接口设计的可测试性

Fri, 02 Jan 2026 00:00:00 +0000

错误码不分层的接口，你只能靠 msg 断言，改个文案用例就跑失败。返回快照的字段返回了实时，数据就无法核对上。

理想中的接口自动化项目

Fri, 02 Jan 2026 00:00:00 +0000

如何评价接口自动化项目

我理想中的接口自动化项目，是有一套脚本，能够 100%覆盖核心业务场景，能够回归线上频繁出现的问题，能够支持手工无法验证的场景，能够抛出偶现问题，能够包含容易遗漏的边界场景、异常场景，每天都能定时运行，出具报告，给予反馈。

用实际的指标量化下：

功能测试自动化率 = 自动化测试用例数/总测试用例数
自动化发现 bug 占比 = 自动化发现的 bug/总 bug 数
自动化发现 bug 有效性 = 自动化发现的有效 bug/自动化提交的 bug 总数
自动化执行成功率 = 自动化执行成功的次数/自动化执行总次数
周活跃自动化用例占比 = (∑每周执行过的自动化测试用例)/(∑周维度自动化测试用例)
应用维度自动化代码覆盖率 = 自动化用例覆盖代码行数/应用维度代码总行数

现状是什么(Situation)

我负责的业务是发票中台，数据流简化后如下图所示：

发票中台对调用方提供 RPC 服务，底层有读写 MySQL、同步 ES、消息队列、异步任务等服务，上游是用户和订单，需要账号、增票资质、订单等物料；下游是财务，推送申请单给财务开具发票等。

发票的接口自动化在多年前是写了的，用 Java+TestNG+RPC 本地化了一套框架来实现，因为人员离职和业务变更，这套自动化到我手上的时候，已经不能用了，本地化的接口自动化项目也无法做数据度量，只有接口测试平台写的自动化用例才会被统计到。

任务是什么(Task)

我给自己定的绩效是在 Q2 完成 95 条自动化用例，按照一个标准化的自动化项目来实现发票的接口自动化，结合测试环境、测试物料、流水线、精准分析，打造一个个人的稳定的沉淀物，无论是晋升还是求职，都能拿来讲点故事。

行动是什么(Action)

编写自动化用例的方式

1、最理想的方式，是能够录制线上流量直接转换为自动化用例，修修改改即可。虽然我们有流量录制回放平台，但是它跟接口自动化平台并没有打通，很可惜不能采取这种方式。

2、参考线上流量日志，抓取接口、入参，人工转化为自动化用例。

3、参考接口的代码设计，比如 controller/provider/sdk 都定义了应用接口，能知道哪些覆盖到了，哪些还需要补充。

4、根据入参模板自行构造参数。参数个数太多的话造起来很麻烦。

我主要采用第 2 种和第 3 种方式结合来编写自动化用例。

典型自动化用例

前置步骤：初始化数据，将订单发票类型更新为 3。

预设变量：提供参数化数据。

执行步骤：调用修改订单发票类型接口，将发票类型 3 改为 2，入参引用预设变量。

CodeReview 技巧和规范

Thu, 01 Jan 2026 00:00:00 +0000

What-什么是 CodeReview？

CodeReview，即代码评审，是白盒测试中，静态测试的一种方法，通过阅读代码，提出代码层面的缺陷。

Why-为什么做 CodeReview？

测试左移：在测试前就发现代码缺陷。

明确测试范围：根据需求文档和代码，对齐测试范围，防止研发夹带本次需求范围外的代码上线。

提升代码能力：学习研发优秀的编程技术。

深入原理：了解系统内部结构及实现。

发现隐藏缺陷：能发现某些极端场景下的问题或概率性问题。

减少测试研发周期占比：节省用例执行个数，尤其多个同类异常梳理，不用执行类似用例，CodeReview 一行代码即可。

Who-谁适合做 CodeReview？

CodeReview 需要三大门槛：

①熟悉编程语言，Java/Python/Go 等。

②熟悉编程规范，《阿里巴巴 XXX 编码规范》、《华为 XXX 编码规范》、《京东 XXX 编码规范》。

③了解需求、架构和设计，需求文档/架构图/设计文档。

达到门槛才适合做 CodeReview。

When-什么时候做 CodeReview？

提测前，通过 Code Diff Review，自己走读代码或者参与研发代码评审会议均可，

发现功能缺陷时，通过走查代码定位代码原因，并分析是否有关联缺陷。

修复缺陷时，阅读研发 commit 记录，检查是否引入新缺陷。

上线前，通过 merge 范围检查是否有夹带代码，为了测试改动的临时代码是否恢复。

Where-在哪里做 CodeReview？

线上仓库（如 Gitlab），适合于修改点单一，不需要查看上下文信息就能找到缺陷。直接在网页端评审代码且发表 comment。

本地仓库（如 IDEA），适合于修改点较多，需要查看上下文信息（变量或方法跳转到定义或使用之处）。在本地找到缺陷后在线上发表 comment。

How-CodeReview 如何上手？

准备：了解需求、架构和设计；学习编程语言；学习代码规范；

实践：坚持 CodeReview，记录缺陷，定期总结。如果看代码找缺陷比较困难，可以先从发现功能缺陷后，定位代码原因入手。

常见 CR 缺陷：

除数为 0、整数溢出、精度损失；

可能死循环；

在 finally 程序块中关闭或者释放资源；

异常未处理或提示不明确（没有 catch 异常，集合等没有判空和长度为 0）；

公式计算错误；

HttpRunner3 源码剖析init文件干了些啥

Thu, 01 Jan 2026 00:00:00 +0000

大家好，我是刚哥。

Java 新一代单元测试框架 JUnit5 速览

Thu, 01 Jan 2026 00:00:00 +0000

为什么学 JUnit5

Java 技术栈的单元测试框架有两个：JUnit 和 TestNG，有种说法是 TestNG 比 JUnit 更强大，学 TestNG 就够了，但是当我打开 GitHub 看到 star 的时候，犹豫了：

JUnit

TestNG

相差了足足有3K之多。带着这个困惑，我在网上查阅了一番资料，原来JUnit5 相较于 JUnit4 有了重大升级，已经包含了 TestNG 的所有功能。为了坚定我学 JUnit 的想法，我咨询了身边做 Java 开发的朋友，开发写 UT 都是用的 JUnit。这两个理由足以让我开始对 JUnit5 的学习。

JUnit5 是什么

跟之前的 JUnit 有所不同，JUnit5 由三个子项目的模块组成：

JUnit5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

JUnit Platform 在 JVM 上启动测试框架的基础，不仅支持 Junit 自制的测试引擎，其他测试引擎也都可以接入。提供了从命令行启动平台的 Console Launcher，和支持 JUnit4 环境的 JUnit4 based Runner。IDE 一般都集成了 JUnit Platform，比如 IntelliJ IDEA。
JUnit Jupiter JUnit5 新特性，结合了新的 programming model 和 extension model，以便于在 JUnit5 中编写测试和扩展。提供了在平台上运行基于 Jupiter 测试的 TestEngine。
JUnit Vintage 提供了在平台上运行基于 JUnit3 和 JUnit4 测试的 TestEngine，照顾老的项目。

JUnit5 新特性

使用 JUnit Jupiter 写测试

示例代码：

java+appium+安卓模拟器实现 app 自动化 Demo

Thu, 01 Jan 2026 00:00:00 +0000

环境搭建

据说，很多人都被繁琐的环境搭建给吓到了。

是的，确实，繁琐。

node.js

下载地址：

https://nodejs.org/en/download/

cmd 输入 node -v，出现下图说明成功：

JDK

下载地址：

https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

百度一下“配置 Java”，配置环境变量。

cmd 输入 java -version，出现下图说明成功：

Android SDK

下载地址：

https://www.androiddevtools.cn/

百度一下"配置 Android SDK 环境变量"。

cmd 输入 adb，出现下图说明成功：

Appium Desktop

下载地址：

https://github.com/appium/appium-desktop/releases

或

https://testerhome.com/topics/680

Maven

下载地址：

http://maven.apache.org/download.cgi

百度一下“ maven 环境配置”。

cmd 输入 mvn -version，出现下图说明成功：

IntelliJ IDEA

下载地址：

http://www.jetbrains.com/idea/

安卓模拟器

下载地址：

https://www.yeshen.com/

把 Android SDK 目录下 \platform-tool 的 adb.exe 拷贝。

打开 Nox\bin 目录，粘贴替换 adb.exe。

JMeter 全部组件概览

Thu, 01 Jan 2026 00:00:00 +0000

JMeter 是性能测试工具，在使用 JMeter 变多以后，越来越觉得之所以它能成为当今时代最主流测试工具，是因为它太成熟了，举个小例子，编写 GET 请求的时候，需要把查询参数，也就是?号后面的请求参数添加进去，JMeter 竟然有个 Add from Clipboard 功能，在浏览器复制以后，点这个按钮就填充好了:

pytest 快速入门

Thu, 01 Jan 2026 00:00:00 +0000

安装 Python 和编辑器 PyCharm

Python 安装包下载地址是： https://www.python.org/downloads/ PyCharm 安装包下载地址是： https://www.jetbrains.com/pycharm/download/ 下载后按常规软件安装。

pytest

pytest 是 Python 内置包，无需单独安装，但是需要设置。

创建 1 个 Project 和 1 个 test.py 来试试，左上角点击 File | New Project | create，创建项目。在项目中右键选择 New | File 创建 test.py

在 test.py 文件中添加代码

def test():
    pass

这个时候 def 的左边会出现一个绿色的箭头，点击之后就可以使用 pytest 运行，注意一定要是 pytest for… 才可以，如果只是 Run test.py，是不走 pytest 执行的（右上角 Edit Configurations 删掉来解决）

从零开始学 mitmproxy 抓包工具

Thu, 01 Jan 2026 00:00:00 +0000

Man In The Middle

mitm 是 Man In The Middle 的首字母缩写，意思是位于中间的人，表明 mitmproxy 是一个代理，可以拦截请求，实现网络抓包。知名的网络抓包工具有 Fiddler、Charles、HttpWatch、WireShark、BurpSuite 和 Postman 等，mitmproxy 相对来说，没有这么高的知名度，它相比于以上工具的独特优势是，它提供了 Python API，可以编写 Python 代码对网络请求进行流量录制，从而收集接口信息以及转化为接口自动化用例等。mitmproxy 官方文档不但有 mitmproxy 工具使用介绍，还有代理实现原理，对我们学习掌握网络知识有很大帮助。

安装与使用

pip 安装

pip install mitmproxy

mitmproxy 是 Python 开发的，用 pip 就能安装成功。官方给出了二进制安装包等方法，我觉得作为一款用 Python 开发的工具，用 pip 直接安装是更 Pythonic 的。

命令启动

可以通过 3 种命令启动 mitmproxy：

mitmproxy 控制台
mitmweb 网页
mitmdump 命令行

它们的内容都是一样的，只是 UI 不一样而已。

手动设置代理

打开以后 mitmproxy 默认会监听http://localhost:8080，需要设置下代理，把代理服务器设置为这个地址。

Windows 可以这样设置：

实际上，Charles 等网络抓包工具会自动配置代理，而 mitmproxy 需要手动设置代理，开发团队的解释是因为浏览器版本和配置经常会变化，所以他们建议在网上根据环境搜索方法手动设置。

一个请求的一生

Thu, 01 Jan 2026 00:00:00 +0000

点进 Service，全是接口。点进 ServiceImpl，前半段在校验业务规则，后半段调了个 stockService.deduct()，又得跳到另一个 Service。

中台 RPC 接口自动化怎么做

Thu, 01 Jan 2026 00:00:00 +0000

RPC 接口

我所在的部门是技术中台，主要负责 toB 业务，上游是业务条线，包括 PC、APP、小程序等终端，这些端的后台是 HTTP 接口层，而在 HTTP 接口层之下，就是技术中台的 RPC 接口层。

HTTP 是一种超文本传输协议，基于 TCP/IP 来传输文本、图片、音频、视频等数据。数据包的传输能力不是 HTTP 提供的，而是 TCP/IP 干的。HTTP 的本质是客户端和服务端约定好的一种通信格式，是一种全世界认可的通用范本。

RPC 是一种远程调用，也就是进程间通信，既可以用 HTTP 协议，也可以用自定义协议。RPC 的好处是没有 HTTP 那么多约束，简化了写法，可以根据公司自定义规范，内部统一即可。 所以在公司内部特别流行，比如阿里的 Dubbo 接口就是一种 RPC 接口，我们公司用的 JSF 接口，自研的服务框架，简称杰夫。

举个例子，本地调用，是调用的本地方法：

 public User getUserById(Long id) {
       return userDao.getUserById(id); // 这叫本地调用
    }

而 RPC 远程调用，调用的是另外一个服务的方法：

 public User getUserById(Long id) {
       return userConsumer.getUserById(id); // 这是远程调用，逻辑是用户小组的服务实现的。
    }

本地调用和远程调用的比较如下图所示：

左边的本地调用，只在应用内部调用。右边的远程调用，会跨应用在应用之间调用。