测试专题 on 测试开发刚哥

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。

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需要占用大量内存，最好加上额外参数：

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的状态验证，

class OrderStateTester…

public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    MailServiceStub mailer = new MailServiceStub();
    order.setMailer(mailer);
    order.fill(warehouse);
    assertEquals(1, mailer.numberSent());
}

只做了简单的测试，断言发出了1封邮件。没有测试是否发送给了对的收件人，或者邮件正文是否正确。不过不影响跟Mock比较。

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

Suites

Graphs

Timeline

Behaviors

Packages

Java TestNG集成Allure Report

集成

在Maven的pom.xml中添加：

<properties>
    <aspectj.version>1.8.10</aspectj.version>
</properties>
<dependencies>
    <dependency>
        <groupId>io.qameta.allure</groupId>
        <artifactId>allure-testng</artifactId>
        <version>LAST_VERSION</version>
        <scope>test</scope>
    </dependency>
</dependencies>
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.20</version>
            <configuration>
                <argLine>
                    -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
                </argLine>
            </configuration>
            <dependencies>
                <dependency>
                    <groupId>org.aspectj</groupId>
                    <artifactId>aspectjweaver</artifactId>
                    <version>${aspectj.version}</version>
                </dependency>
            </dependencies>
        </plugin>
    </plugins>
</build>

然后执行命令：

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}进行访问。

Regular Expression

正则表达式。

Template( $i$ where i is capturing group number, starts at 1)

用$$引用起来，如果在正则表达式中有多个正则表达式（多个括号括起来的），则可以是 $1$ 、 $2$ 等等， $1$ 指第一个模板， $2$ 指第二个模板，依次类推， $0$ 指全文匹配，$1$$2$指同时取第一个和第二个模板。

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

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

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

线程组编辑区如下：

JUnit5参数化测试的几种方式

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

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

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

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占比的意义更大，因为使用测试环境与否，最终的体现还是落在缺陷上面的，比较容易量化，需求使用测试环境占比不是很确定，需求多少功能在测试环境使用了，相对来说不是很好度量，但也可以作为辅助指标进行观察。

测试环境破局

测试环境关联了很多东西，比如物料、自动化、精准、流水线等，都可以围绕测试环境来做文章。测试环境既是团队重点，也是是我个人的大案例，目前已经解决了部分困难，要想做出一鸣惊人的成绩，还需要站在更高的角度去看待整个事情，这也是一个全新的挑战，需要不断刷新自己，突破。

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执行的过程中完成。

启动脚本示例：

java -javaagent:jacocoagent.jar -jar target/app.jar

默认情况下，JaCoCo会在JVM停掉以后，生成覆盖率数据，一个jacoco.exec文件。

官方手册也有相关说明：

output默认为file：At VM termination execution data is written to the file specified in the destfile attribute。这种方式有2个局限，一是必须停掉应用；二是只能把覆盖率数据生成到本地文件。

output还有另外一个选项，tcpserver：

java -javaagent:jacocoagent.jar=output=tcpserver,address=0.0.0.0,port=2014 -jar target/app.jar

address：服务端地址；

port：服务端端口；

通过这种方式启动后，会同时启动一个TCP服务端，使用lsof -i :2014命令查看端口进程：

然后就能通过TCP通信，来获取覆盖率数据，也就是所谓的”dump“。

代码片段：

@Override
    public void dump(String dumpPath, String ip, int port) throws IOException {
        dumpPath = FileUtil.getAbsolutePath(dumpPath);
        if (!FileUtil.exist(dumpPath)) {
            FileUtil.mkdir(dumpPath);
        }
        FileOutputStream localFile = new FileOutputStream(dumpPath + File.separator + "jacoco.exec");
        ExecutionDataWriter localWriter = new ExecutionDataWriter(localFile);
        SocketAddress socketAddress = new InetSocketAddress(ip, port);
        Socket socket = new Socket();
        try {
            socket.connect(socketAddress, 10000);
            RemoteControlWriter writer = new RemoteControlWriter(socket.getOutputStream());
            RemoteControlReader reader = new RemoteControlReader(socket.getInputStream());
            reader.setSessionInfoVisitor(localWriter);
            reader.setExecutionDataVisitor(localWriter);
            log.info("开始dump:{} {}", ip, port);
            writer.visitDumpCommand(true, false);
            if (!reader.read()) {
                log.error("Socket closed unexpectedly");
                throw new IOException("Socket closed unexpectedly.");
            }
            log.info("dump完成:{} {}", ip, port);
        } catch (Exception e) {
            log.info("dump失败:{}", e.getMessage());
        } finally {
            socket.close();
            localFile.close();
        }
    }

dump经过TCP通信，将远程机器的覆盖率数据取到本地后，生成jacoco.exec文件，然后可以使用jacococli.jar生成HTML报告：

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条件

端到端自动化的开源框架

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模式下运行，可以通过日志观察运行过程。

更新命令：

pip install pytest-playwright playwright -U

编写测试

访问url：

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。

Order

JUnit5默认使用了某种算法来确定test方法的执行顺序。我们可以通过@TestMethodOrder进行自定义，既可以使用内置类，也可以使用实现了MethodOrderer接口的类。

内置类如下：

DisplayName 按DisplayName的字母数字顺序
OrderAnnotation 通过@Order注解指定顺序
Random 随机顺序
Alphanumeric 按test方法名和参数列表的字母数字顺序

示例：

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报告：

java -jar jacoco/jacococli.jar report jacoco.exec --classfiles ./target/classes/ --sourcefiles ./src/main/java/ --html ./report

接下来就来验证动态特性。把report目录和jacoco.exec都删了，因为jacoco每次部署只能分析一次。把服务停掉后，重新启动。这一次不直接分析，而是先用postman调一下接口：

然后再分析一把：

把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这两个操作，包进一个事务里，要么同时执行，要么同时回滚，是不是就解决了？

JMeter英文版界面介绍

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

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

JUnit5编写基本测试

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

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

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 传到安卓机上，对请求抓包，同时监控应用日志。本文就来讲讲具体操作。

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，不但能执行了，还能在线程之间灵活切换。

多进程和多线程都可以用来模拟并发请求。JMeter是用Java语言写的程序，运行在JVM虚拟机之上，进程的开销比线程大很多，JVM为了保证足够性能，控制了进程的数量。如果用多线程，单台电脑能提供了负载有限，那么就只能用多线程。JMeter只支持多线程！

用户即线程

JMeter除了Thread Group，其他地方都是用的另外一个词：User。实际上它们是一个意思，用户就是线程。JMeter的运行原理就是用多个线程来模拟多个用户！以下是简单示例：

从图中可以看出，有两个线程组，Thread Group 1和Thread Group 2，它们分别定义了自己组内的用户要做的事情。不同线程组做的事情是不一样的，但是同一线程组内部做的事情是一模一样的。我们在写JMeter脚本的时候，实际上是在定义每个用户要做哪些事。当运行脚本的时候，JMeter会启动多个线程，都来执行这个脚本，按照我们写的进行执行。

远程运行

一台机器提供了线程数量有限，如果想要施压更大的并发，那么就需要多台机器。JMeter天然支持多台机器并发：

控制机和负载机本质上没有区别，同一台机器既可以做控制机，也可以做负载机，取决于你的负载设计。控制机的作用是管理多台远程负载机，控制远程负载机脚本运行，收集远程负载机测试结果。负载机是实际产生并发的机器，它们向被测应用系统发起负载。

运行逻辑如下：

远程负载机启动Agent客户端，等待控制机连接。
控制机连接上远程负载机。
控制机发送指令到远程负载机启动线程。
远程负载机运行脚本，回传结果数据。
控制机收集结果并显示。

操作步骤如下：

远程负载机启动jmeter-server.bat。
在控制机bin\JMeter.properties文件中，修改remote_hosts，添加远程负载机的ip和port，多个远程负载机ip 用逗号分隔，如remote_hosts=192.168.0.1:1664,192.168.0.2:1664。1664是默认RMI端口号（Remote Method Invocation，远程方法调用）。
在控制机菜单栏Run执行Remote命令：

小结

本文先从JMeter运行文件讲起，启动后默认有测试计划，建线程组，线程即用户，用多线程来模拟多用户，这就是JMeter运行起来施压的原理。为了解决单台机器负载能力有限的问题，JMeter还提供了远程运行方式，既可以在局域网用多台机器来控制，也可以部署到云服务器上，进行云压测。

JUnit5注解学习指引

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

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

Postman竟然还能录制流量

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

大家好，我是刚哥。

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

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、空指针异常

import org.mybatis.spring.SqlSessionTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class UserService {

    private final SqlSessionTemplate sqlSessionTemplate;
    
    @Autowired
    public UserService(SqlSessionTemplate sqlSessionTemplate) {
        this.sqlSessionTemplate = sqlSessionTemplate;
    }
    
    public void getUserById(String userId) {
        User user = sqlSessionTemplate.selectOne("com.example.mapper.UserMapper.getUserById", userId);
        System.out.println(user.getName()); // 可能导致空指针异常
    }
}

如果取到的 user 对象为空，就会导致空指针异常。

接口设计的可测试性

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，入参引用预设变量。

财务接口：依赖测试物料无法满足，通过Mock来返回模板数据，让接口继续往下走。

基础断言：接口响应状态码200。

业务断言：调用订单列表查询接口，用JSONPath提取响应中的发票类型，断言已经改成了2。

场景用例

数据准备：通过物料工具造订单数据，写入MySQL数据库中。

更新MySQL数据：更新订单的部分字段数据，触发binlake，将数据同步至ES，因为提交开票申请是读取的ES数据；从预设变量获取orderId。

提交开票申请：从ES读取订单数据，提交开票申请；从预设变量获取orderId和userId。

查询申请单号：根据订单号查询申请单号；从预设变量获取orderId和userId。用JSONPath提取申请单号，存入动态变量中。

推送财务：把申请单号推送给财务；从动态变量获取applyId。

覆盖更多代码

①看代码：

在Java工程里面的Controller/Provider找到所有接口，分析可以用来做自动化的接口，设计自动化用例进行覆盖。

②代码覆盖率：

借助于jacoco，在执行自动化用例后，把代码覆盖率跑出来，分析没覆盖的代码，补充更多正常/异常/边界的自动化用例。也就是精准测试。

自动化巡检

每天早上8点，定时任务执行用例集；发送邮件，抄送测试组、开发组、领导，让测试、开发和领导都知道自动化建设情况；如果出现问题，一定要在当天解决，并邮件回复问题原因；确保当天的自动化用例结果都是正确的；第二天接着继续巡检。

流水线

在持续集成中，引入自动化用例环节，把自动化用例跑通作为提测卡点，不通过可以驳回。

产出是什么(Result)

定性来看：

结合测试环境、测试物料、自动化、流水线、精准测试，完成了一个能对环境和业务进行稳定性巡检，能对研发提测进行质量门禁，能对应用进行代码覆盖率分析的接口自动化项目。

定量来看：

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

这个Q主要完成了核心流程和重要接口的自动化用例，还需要持续补充场景用例和异常/边界的自动化用例。

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）；

公式计算错误；

字符串对比不能用==，使用equals；

数组可能越界；

传递引用错误；

类型转换错误；

条件范围选择错误；

重点检查项：

一致性检查：是否需求相关；是否和方案设计一致；代码风格、日志规范、异常处理等是否和统一规范一致；

完整性检查：服务层是否包含了所有业务功能；数据层是否包含所有需要的数据和操作；

正确性检查：计算逻辑等业务逻辑是否正确；变量是否被正确定义和使用；代码是否符合制定的标准；

可修改性检查：代码涉及到常量是否易于修改，比如使用配置，定义为常量类等；建议业务方法只有一个出口和一个入口（异常处理除外）；重要公共方法是否有交叉注释说明；重要的对外方法修改后影响多个下游接口；

可预测性检查：变量初始化；方法稳定性；代码是否存在死循环；代码无穷递归检查；

健壮性检查：代码是否采取措施避免运行时错误（如数组边界溢出、被零除、值越界、堆栈溢出等）

高可用性检查：是否有预案（降级开发、限流配置、兜底策略）；补偿方案是否合理；

结构性检查：程序的每个功能是否都作为一个可辨识的代码块存在；

可理解性检查：是否使用到不明确或不必要的复杂代码；代码中的算法是否符合开发文档中描述的数学模型；每个变量都定义了合法的取值范围；

可验证性检查：代码功能是否便于测试；单元测试覆盖度是否足够；

可追溯性检查：代码是否包括一个修订历史记录，记录中对代码的修改和原因都有记录；

编码规范：

《阿里巴巴Java开发手册》

最新版本：黄山版（2022.2.3发布）

https://github.com/alibaba/p3c

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。

打开模拟器。

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写测试

示例代码：

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

import example.util.Calculator;

import org.junit.jupiter.api.Test;

class MyFirstJUnitJupiterTests {

    private final Calculator calculator = new Calculator();

    @Test
    void addition() {
        assertEquals(2, calculator.add(1, 1));
    }

}

注意这个导包的路径org.junit.jupiter.api，Jupiter就是JUnit5的新特性。

JMeter全部组件概览

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

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

从零开始学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需要手动设置代理，开发团队的解释是因为浏览器版本和配置经常会变化，所以他们建议在网上根据环境搜索方法手动设置。

下载证书

访问http://mitm.it/，如果代理配置没有生效，打开后会是这个界面：

正常的话，会出现证书下载页面：

根据平台选择相应证书安装就OK了。

使用

mitmproxy更其他抓包工具用法类似。

官方用视频演示了mitmproxy如何使用：

https://docs.mitmproxy.org/stable/mitmproxytutorial-userinterface/

并且介绍了5种运行模式：

https://docs.mitmproxy.org/stable/concepts-modes/

读者可以自行阅读下。

mitmproxy工作原理

客户端（本机）连接代理服务器（http://127.0.0.1:8080），代理服务器连接服务器。
客户端给代理服务器发请求，代理服务器把请求发送到服务器。

所有请求经过mitmproxy，就可以实现请求拦截。

对于HTTP来说，直接借助mitmproxy传递请求就可以。而对于HTTPS来说，有个SSL/TLS安全认证，必须安装证书，服务器才会认为mitmproxy的请求是可信任的，请求才会成功传递。

HTTPS的代理过程就要复杂很多，客户端先跟mitmproxy建立连接（1~~2步），然后进行安全认证（3~~6步），最后传递请求（7~8步）。

反向代理

假设在本机使用FastAPI启动了个Mock服务，地址为http://127.0.0.1:5000，通过Postman调接口，怎么使用mitmproxy来拦截请求呢？这就需要用到反向代理。

首先以反向代理模式运行mitmproxy，服务器端口为5000，监听端口为8000：

mitmproxy --mode reverse:http://127.0.0.1:5000 --listen-host 127.0.0.1 --listen-port 8000

然后把请求http://127.0.0.1:5000/login里面的5000端口改成8000，访问：

http://127.0.0.1:8000/login

就能在mitmproxy看到抓到请求了：

这样就能在本地使用Mock服务来调试拦截请求的Python代码了。

Python API

Python API是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); // 这是远程调用，逻辑是用户小组的服务实现的。
    }

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

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

RPC和HTTP用法区别

HTTP接口在调用时，输入URL，Method，Headers，Body等等等就可以发送请求了。

RPC接口的调用大同小异，输入：

JSF地址：方法引用路径，比如com.dongfanger.api.service.ShopProvider。

方法名：方法名称，比如queryShopList。

别名：既可以是分组别名，也可以直连IP地址。

方法入参：JSON串。

等等等，就可以发起请求了。

从用法能看出来，RPC和HTTP接口的结构体是差不多的，但是RPC不需要Method和Headers，精简了许多。

接口自动化

首先需要考虑的是目录结构设计，HTTP可以模块菜单创建用例目录，比如：

一级目录：管理端

二级目录：发票管理

三级目录：发票查询

而RPC是无页面的，一般存在很多业务线，所以可以按照功能域和业务线来组织目录，比如：

一级目录：发票

二级目录：提交申请

三级目录：分销

其次就得考虑技术实现了，公司基建比较完善，无论是HTTP还是JSF接口，都能在接口测试平台上编写自动化用例。虽然是Web平台写用例，但是得益于测试平台的优秀设计和使用体验，用起来很方便，效率也很高。交互方式跟JMeter大同小异，只是在细节上做了很多打磨。

然后就是参数构造了，建议是用流量回放的方式来做，省去手工编写参数的崩溃感。流量用例创建好以后，需要做一些参数化处理和接口关联。这样才能够把多个接口串起来。

对于测试数据，通过预设变量来统一管理，自动化用例也尽可能设计成闭环，增加，修改，查询，删除，用例跑完后产生的数据也跟着清理掉。

最后就是断言了。没有断言的自动化用例，不叫做自动化用例。断言一定要加上，否则定时任务跑出结果后，无法判断到底有没有问题。而断言内容不能只是简单的code200，需要加上业务校验。

中台RPC接口自动化最难处理的是接口依赖问题，链路特别长，依赖特别多。我一般通过Mock来解决这个问题，公司的测试平台也提供了这个功能。

需要注意的是，核心用例定时运行监控起来，而一次性用例要及时维护或清理，防止变成僵尸用例。

最后，我准备基于Vue+FastAPI开发一套新的pytest脚本管理平台，集成流量录制创建用例和Mock等功能，并借鉴公司测试平台的设计，感兴趣的同学可以添加微信cekaigang加群讨论哟。

测试专题 on 测试开发刚哥

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

locustfile中的User类和HttpUser类

locustfile是什么？

User类

wait_time属性

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

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

什么是TP99？

为什么TP99更需要关注？

你的下一个压测工具可以是nGrinder

nGrinder小众而实用

设计理念

nGrinder架构

nGrinder技术栈

快速入门

安装

JMeter扩展Java请求

JMeter响应断言够用了

JMeter定时器设置延迟与同步

JMeter逻辑控制器完整介绍

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

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

鸡尾酒

Stub & Mock

JMeter四种参数化方式

Allure测试报告完整学习笔记

目录

简介

安装Allure

Allure测试报告的结构

Overview

Categories

Suites

Graphs

Timeline

Behaviors

Packages

Java TestNG集成Allure Report

集成

JMeter关联陌生又熟悉

JMeter关联是什么

正则表达式提取器

Name

Comments

Apply to

Field to check

Name of created variable

Regular Expression

Template($i$ where i is capturing group number, starts at 1)

JUnit5依赖注入与测试接口

依赖注入

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

JUnit5参数化测试的几种方式

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

测试环境困局

What，测试环境是什么？

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

Who，谁来负责测试环境？

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

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

How，怎么做测试环境？

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

测试环境破局

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

什么是增量覆盖率

基本实现原理

JaCoCo默认覆盖率

JMeter测试计划配置项解析

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

条件测试

自定义条件

内置条件

端到端自动化的开源框架

什么是Playwright？

什么是端到端测试？

Playwright框架特点

快速入门

安装

示例

Template( $i$ where i is capturing group number, starts at 1)