Java测试开发培训代码包：先跑通冒烟再改可回归工程

简介：这份霍格沃兹测试学院中高级测试开发培训的练习代码仓库，面向已具备 Java 基础、希望向中高级测试开发进阶的工程师，围绕测试框架搭建与工程化实践展开，可用于课程同步练习与项目复盘。压缩包共 2000 个文件、约 3.83MB，以 json 测试数据与配置、java 与 class 源码及编译产物、xml 与 yaml 测试套件与构建配置、txt 与 html 报告文档为主，另附少量图片与表格素材，覆盖一套 Java 测试工程从用例编写到报告输出的完整构成。内容聚焦 JUnit/TestNG 单元测试与断言设计、Mockito 依赖模拟的集成测试、Jenkins 持续集成配置、Selenium WebDriver 自动化脚本、RestAssured 接口测试、JMeter 性能测试以及 JaCoCo 覆盖率统计等环节，并涉及 Git 版本管理与可维护测试架构的设计思路，目录按课程章节组织，便于分模块推进。已有 682 人学习，适合希望系统梳理 Java 测试开发知识体系、积累可复用框架与排错经验的读者对照实践。

1. 中高级测试开发培训代码包先别全跑：用 Java 工程视角找骨架

拿到一套中高级测试开发培训代码，第一反应不该是把全部用例跑一遍。尤其是 Java 技术栈的测试开发培训代码包，里面常混着示例、练习、半成品框架和演示配置，直接全量执行很容易被环境、账号和残留数据淹没。血泪经验是先把构建入口、测试分层、配置读取和报告产物找出来，判断哪些是骨架、哪些是演示。它适合正在从功能测试转测试开发、需要补 Java 工程化能力的人，也适合团队拿它改造成接口或 UI 自动化脚手架。下面按能复现的顺序拆：先编译，再分层，最后排坑和做冒烟门禁。

2. 把 Java 测试代码包跑起来：目录识别、依赖入口与第一轮编译

拿到代码包后，先做“只读检查”，不要急着改包名、升依赖、删示例。培训代码常把接口、UI、工具类、练习答案放在同一棵源码树里，哪些是核心骨架、哪些是课堂演示，单看类名很容易误判。我的习惯是先看构建文件、测试资源、运行入口和产物目录，再决定先跑哪一条用例。第一轮目标不是覆盖率，而是确认 Java 编译链、测试框架和报告插件能形成闭环。

2.1 识别工程类型与依赖入口

先确认工程是 Maven 还是 Gradle，再看测试框架是一套还是两套混用。培训代码里常见 JUnit5、TestNG 同时出现，有的模块用 JUnit4 风格，有的用注解驱动；如果直接复制依赖，很容易出现注解不生效、断言包冲突、用例扫不到。构建文件里的parent、properties、dependencyManagement和测试插件要一起看，尤其是编译级别、资源过滤和报告插件。第一轮不要擅自把大版本升级到本机最新，先跟随仓库声明跑通，再谈改造。

# 只读查看工程骨架，不改任何文件 find . -maxdepth 3 -type f \( -name "pom.xml" -o -name "build.gradle" -o -name "testng.xml" -o -name "junit-platform.properties" \) -print # 查看测试代码常见分层目录，判断先跑哪一类用例 find . -maxdepth 4 -type d \( -name "api" -o -name "page" -o -name "cases" -o -name "utils" -o -name "config" \) -print

这段命令的逻辑是先找构建和运行入口，再找测试分层目录，避免一上来就翻几十个类文件。-maxdepth控制搜索层级，防止进入依赖缓存和构建产物；-type f只找文件，-type d只找目录；-o表示多个条件并列，-print输出结果。不同系统下find参数基本一致，如果工程在 Windows 上解压，建议在 Git Bash 或 WSL 里执行，减少路径分隔符干扰。

构建文件看完，再扫一眼测试资源目录。配置文件名往往能暴露环境设计：local、test、pre这类命名说明代码包已经预留了环境切换；如果所有地址都写死在用例里，后面就要先做配置层改造。依赖入口重点看测试作用域的库是否齐全，例如参数化、断言、HTTP 客户端、浏览器驱动、报告插件是否都在test作用域内。缺依赖时不要凭记忆乱加，先在依赖树里找同类库，避免版本交叉。

2.2 最小可运行配置与第一条用例

第一轮编译只追一个结果：一条最小用例能稳定执行，并且失败信息可读。先确认本机 Java 版本和构建文件声明一致，再看测试插件是否配置了 includes。很多“用例扫不到”的问题不是代码错，而是类名不符合默认规则，或者测试类被放进了不被扫描的目录。最小用例不要依赖数据库、浏览器和外部账号，先用纯 Java 断言验证框架链路。

import org.junit.jupiter.api.DisplayName; import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertAll; import static org.junit.jupiter.api.Assertions.assertEquals; class SmokeTest { @Test @DisplayName("最小冒烟：确认测试框架和断言链可用") void framework_should_be_ready() { int expected = 2; int actual = 1 + 1; assertAll("基础断言链路", () -> assertEquals(expected, actual, "加法结果应符合预期"), () -> assertEquals("demo", "demo".trim(), "字符串处理应符合预期") ); } }

这段代码的逻辑是用一条不依赖外部环境的用例验证 JUnit5 注解、断言和测试发现是否正常。@DisplayName让报告里出现可读名称；assertAll会聚合多个断言，避免第一个失败后看不到后续问题；assertEquals的第三个参数是失败消息，排查时比默认堆栈更直接。依赖跟随仓库声明，不在这里硬写版本；如果仓库用 TestNG，就换成对应的@Test和断言入口，不要两套混着跑。

执行时先只跑这一条，不要全量：

# 只执行 SmokeTest，确认编译、测试发现和报告产物 mvn -q -Dtest=SmokeTest test

-q降低构建日志噪声，-Dtest=SmokeTest限定测试类，test触发测试生命周期。执行后先看控制台是否出现测试统计，再看target/surefire-reports下是否生成报告文件；如果连测试类都没被发现，优先检查类名、包路径和测试插件配置。Gradle 工程对应使用gradle test --tests SmokeTest，参数含义类似。> 注意：第一条用例通过不代表业务用例可跑，只代表 Java 编译链和测试框架链路通了。

2.3 依赖冲突与 JDK 匹配的排查顺序

测试代码包最容易翻车的地方不是业务断言，而是运行时版本不匹配。典型现象是UnsupportedClassVersionError、NoSuchMethodError、ClassNotFoundException，分别指向编译版本、依赖版本和类路径问题。排查顺序建议固定：先看构建实际使用的 Java 版本，再看依赖树里是否有重复测试框架或 HTTP 客户端，最后看测试作用域是否漏配。不要一上来删本地仓库，那样会把简单问题拖成环境重建。

# 查看当前构建使用的 Java 与构建工具版本 mvn -v # 过滤查看测试相关依赖，定位重复或版本冲突 mvn -DskipTests dependency:tree -Dincludes=org.junit.jupiter:*,org.testng:*,io.rest-assured:*,org.seleniumhq.selenium:*

这段命令的逻辑是先确认运行环境，再缩小依赖范围。-DskipTests表示只解析依赖不执行测试；-Dincludes按groupId:artifactId过滤，星号是通配符，实际排查时把冲突的库替换成你看到的坐标。若工程使用 Gradle，可用gradle dependencies --configuration testRuntimeClasspath查看测试运行时依赖。依赖树里同一坐标出现多个版本时，先看dependencyManagement或强制版本配置，再决定排除哪一个，不要直接删除业务库。

JDK 匹配要看构建文件里的编译级别，而不是看本机装了多少个版本。培训代码里常见源码写法较新、构建声明较旧，或者反过来，结果是本地能编译、流水线报错。我的做法是把构建实际使用的 Java 版本、编译级别、测试框架版本三项记在排查笔记里，后面每换一台机器都先对齐这三项。> 提示：先跟随仓库声明的 JDK 基线，确认能跑后再评估升级；升级 Java 大版本要单独开分支验证，不要和业务改造混在一起。

3. 测试骨架分层：配置、参数化用例与失败断言怎么落到 Java 代码

培训代码能不能改成自己的项目，关键看分层是否清楚。包名好看不算分层，真正的边界是：配置从哪里来、测试数据谁负责、请求或页面动作放在哪、断言写在哪、失败后看什么。很多代码包把地址、账号、断言和清理全塞在一个测试方法里，单条能跑，批量就互相污染。下面按配置层、用例层、断言与报告层拆开，每一层都给一个能抄的 Java 落点。

3.1 配置层：环境参数不要散落在用例里

配置层的第一原则是“用例只认键，不认具体值”。环境地址、浏览器类型、超时时间、测试账号占位都从配置读取，命令行可以覆盖。常见优先级是命令行参数高于环境变量，环境变量高于本地配置文件，本地配置文件高于默认值。这样本地调试可以临时覆盖，流水线也能用环境变量注入，不需要改代码。配置读取类要早失败，缺键时直接抛出明确异常，别让空字符串流到请求里变成玄学报错。

import java.io.IOException; import java.io.InputStream; import java.util.Properties; public final class ConfigReader { private static final Properties PROPS = new Properties(); static { String env = System.getProperty("env", "local"); String path = "config/" + env + ".properties"; try (InputStream in = ConfigReader.class.getClassLoader().getResourceAsStream(path)) { if (in == null) { throw new IllegalStateException("找不到配置文件: " + path); } PROPS.load(in); } catch (IOException e) { throw new IllegalStateException("加载配置失败: " + path, e); } } public static String get(String key) { String fromCli = System.getProperty(key); if (fromCli != null && !fromCli.isBlank()) { return fromCli.trim(); } String envKey = key.toUpperCase().replace('.', '_'); String fromEnv = System.getenv(envKey); if (fromEnv != null && !fromEnv.isBlank()) { return fromEnv.trim(); } String value = PROPS.getProperty(key); if (value == null || value.isBlank()) { throw new IllegalArgumentException("缺少配置: " + key); } return value.trim(); } }

这段代码的逻辑是静态加载当前环境配置文件，再按命令行、环境变量、配置文件的顺序取值。env参数决定加载哪个文件，默认local；key是配置键，例如base.uri；环境变量会把点替换成下划线并转大写，方便流水线注入。配置文件放在测试资源目录下，示例只写占位值：

base.uri=http://127.0.0.1:8080 ui.browser=chrome request.timeout.seconds=10

base.uri是接口根地址，ui.browser是浏览器类型，request.timeout.seconds是超时秒数。真实账号、令牌和数据库密码不要提交到仓库，用环境变量或本地未跟踪文件覆盖。> 注意：配置类不要做成可随意 set 的全局变量，否则用例之间会互相改配置，批量执行时很难定位。

3.2 用例层：JUnit5 与 TestNG 的选择和参数化写法

代码包里如果两套框架都有，先跟随主运行入口，不要为了统一而大面积迁移。新写的用例可以优先选一套扩展模型清晰的框架，参数化、标签、并行和生命周期支持更完整；老用例保留原框架，通过构建配置分开跑。关键是不要混用断言包和生命周期注解，否则会出现@BeforeEach不执行、分组不生效、报告缺用例。参数化用例要把输入和期望放在一起，失败消息带上参数，不然批量跑完只能看到一行“断言失败”。

import org.junit.jupiter.params.ParameterizedTest; import org.junit.jupiter.params.provider.CsvSource; import static org.junit.jupiter.api.Assertions.assertEquals; class MobileRuleTest { @ParameterizedTest(name = "手机号={0} 期望={1}") @CsvSource({ "13800000000,true", "123,false", "1380000000x,false" }) void should_validate_mobile(String mobile, boolean expected) { boolean actual = MobileRule.isValid(mobile); assertEquals(expected, actual, () -> "手机号校验不符合预期: " + mobile); } }

这段代码的逻辑是用 CSV 行提供输入和期望，方法参数按列顺序接收。name里的{0}、{1}是参数占位，报告里能直接看到哪组数据失败；@CsvSource的每一行是一条数据；expected是期望布尔值；失败消息用 lambda 延迟拼接，避免每次执行都构造字符串。MobileRule是示例业务类，实际项目替换成代码包里的校验工具。参数化数据不要塞真实用户信息，用明显虚构的测试值。

3.3 断言与报告：让失败信息能定位

断言不是越多越好，而是失败时能回答三个问题：哪个入参、期望什么、实际什么。接口响应要同时校验业务码、关键字段和类型，不要只判断 HTTP 200；UI 断言要放在页面动作之后，不要在 Page Object 里散落业务断言。多个字段校验用聚合断言，一次跑出所有差异。报告里保留请求摘要、响应摘要和失败截图，但要注意脱敏，不要把令牌和账号打进附件。

import java.math.BigDecimal; import static org.junit.jupiter.api.Assertions.assertAll; import static org.junit.jupiter.api.Assertions.assertEquals; import static org.junit.jupiter.api.Assertions.assertNotNull; import static org.junit.jupiter.api.Assertions.assertTrue; class OrderAssertTest { void create_order_should_return_expected_fields() { OrderResp resp = new OrderResp(0, "order-demo-001", 2, new BigDecimal("19.90")); assertAll("创建订单响应校验", () -> assertEquals(0, resp.code(), "业务码"), () -> assertNotNull(resp.orderId(), "订单号不能为空"), () -> assertEquals(2, resp.quantity(), "购买数量"), () -> assertTrue(resp.totalAmount().compareTo(BigDecimal.ZERO) > 0, "金额应大于0") ); } }

这段代码的逻辑是用assertAll聚合业务码、订单号、数量和金额四类断言，任何一项失败都会带出对应消息。resp这里用构造示例代替真实请求，实际项目里换成接口返回对象；BigDecimal用于金额比较，避免浮点误差；compareTo判断金额大于零，不要用equals比较数值。报告插件是否生效要看产物目录，而不是看控制台有没有彩色输出。若报告为空，先检查测试插件是否挂载监听器，再看结果目录是否被清理任务误删。

4. 接口与 UI 自动化接入：请求封装、页面对象与数据清理的三条落地线

培训代码里最容易被直接复制的是接口请求和页面操作，但最容易留下债务的也是这两块。接口用例如果每条都写完整请求链，后面改地址、加请求头、换序列化方式会改到崩溃；UI 用例如果到处sleep，本地看着稳，批量执行就变成玄学。我的落地顺序是先把接口客户端收口，再把页面动作收口，最后把测试数据和清理收口。三条线都收住，代码包才有改造成回归工程的价值。

4.1 接口层封装：从请求链到业务方法

接口封装的目标不是再包一层 HTTP 工具，而是把“公共请求配置”和“业务动作”分开。根地址、内容类型、日志过滤、超时放在请求规格里；创建订单、取消订单这类动作放在业务客户端里；测试方法只负责准备数据、调用动作、断言结果。这样换环境只改配置，换接口路径只改客户端。日志过滤建议只在失败时输出详细内容，避免批量执行把敏感信息全打出来。

import io.restassured.builder.RequestSpecBuilder; import io.restassured.filter.log.ResponseLoggingFilter; import io.restassured.http.ContentType; import io.restassured.specification.RequestSpecification; import io.restassured.response.ValidatableResponse; import static io.restassured.RestAssured.given; public class OrderApi { private final RequestSpecification spec; public OrderApi(String baseUri) { this.spec = new RequestSpecBuilder() .setBaseUri(baseUri) .setContentType(ContentType.JSON) .addFilter(new ResponseLoggingFilter()) .build(); } public ValidatableResponse create(OrderReq req) { return given().spec(spec) .body(req) .when() .post("/orders") .then() .log().ifValidationFails(); } }

这段代码的逻辑是把根地址和 JSON 内容类型收进RequestSpecification，业务方法只保留请求体和路径。构造参数baseUri从配置层传入，不在类里写死；ContentType.JSON统一请求内容类型；ResponseLoggingFilter用于记录响应，实际项目里要配合脱敏；log().ifValidationFails()只在断言失败时输出详细日志，降低正常执行噪声。OrderReq和/orders是示例，按代码包里的接口替换。> 提示：接口客户端不要做成静态单例到处取，环境切换和并行执行时容易串配置。

4.2 UI 层封装：Page Object 与显式等待

UI 自动化在培训代码里通常以演示为主，直接全量搬进回归会很不稳。Page Object 只放定位器、页面动作和必要的等待，不放业务断言；断言留在测试方法里，失败时才能看清是页面没到位还是业务结果不对。等待策略优先显式等待，等元素可见、可点击或文本出现，不要用固定睡眠。浏览器驱动版本和浏览器版本要对齐，驱动管理方式跟随仓库，不要手工塞一个来路不明的驱动。

import java.time.Duration; import org.openqa.selenium.By; import org.openqa.selenium.WebDriver; import org.openqa.selenium.support.ui.ExpectedConditions; import org.openqa.selenium.support.ui.WebDriverWait; public class LoginPage { private final WebDriver driver; private final By username = By.id("username"); private final By password = By.id("password"); private final By submit = By.cssSelector("button[type='submit']"); public LoginPage(WebDriver driver) { this.driver = driver; } public void login(String user, String pwd) { WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10)); wait.until(ExpectedConditions.visibilityOfElementLocated(username)).sendKeys(user); driver.findElement(password).sendKeys(pwd); wait.until(ExpectedConditions.elementToBeClickable(submit)).click(); } }

这段代码的逻辑是把登录页的定位器和动作收在 Page Object 里，测试方法只调用login。Duration.ofSeconds(10)是显式等待上限，按页面实际加载调整；visibilityOfElementLocated等用户名输入框可见后再输入；elementToBeClickable等按钮可点击后再点，减少元素存在但被遮挡导致的失败。定位器集中放在字段里，页面改版时只改一处。UI 用例建议只保留核心链路冒烟，不要把几百条业务校验全塞进浏览器。

4.3 测试数据与清理：避免用例互相污染

批量执行失败的一大来源是数据残留：上一条用例创建的订单没删，下一条按固定条件查询就查到多条；账号被踢下线，后面的 UI 用例全部登录失败。测试数据要尽量唯一，例如用时间戳或随机后缀；清理动作放在@AfterEach或框架对应的清理钩子里，优先走接口清理，少走 UI。清理失败不要掩盖主断言，但要在日志里明确记录，方便判断是环境问题还是用例问题。

import org.junit.jupiter.api.AfterEach; import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertNotNull; class OrderFlowTest { private final OrderApi orderApi = new OrderApi(ConfigReader.get("base.uri")); private String orderId; @AfterEach void clean() { if (orderId != null) { orderApi.deleteQuietly(orderId); } } @Test void should_create_and_cancel() { orderId = orderApi.create(new OrderReq("sku-demo", 1)) .extract().path("orderId"); assertNotNull(orderId, "创建订单应返回orderId"); orderApi.cancel(orderId).statusCode(200); } }

这段代码的逻辑是每条用例执行后按订单号清理，避免数据堆积。orderId是实例字段，生命周期跟随测试实例；@AfterEach在用例结束后执行；deleteQuietly是示例清理方法，内部应捕获异常并记录日志，不让清理失败覆盖主断言。ConfigReader.get("base.uri")从配置层取根地址。若代码包使用 TestNG，把@AfterEach换成@AfterMethod，逻辑不变。数据库清理要加白名单和条件，不要写全表删除。

5. 避坑与排查：五类翻车现场从现象到解决

这套培训代码真正落地时，问题很少出在“不会写断言”，更多出在环境、数据和稳定性。下面五类是我在类似 Java 测试代码包里反复见到的翻车现场，每条按现象、原因、解决写。排查时先保现场：保留构建日志、失败报告、请求响应摘要和截图，再动手改代码。没有现场就直接重跑，很容易把偶发问题变成长期玄学。

5.1 环境类翻车：本地绿、流水线红

现象：本地执行通过，换到流水线就报UnsupportedClassVersionError，或者中文日志乱码、时间字段差几个小时。原因通常不是业务代码，而是构建使用的 Java 版本、文件编码、时区设置和依赖缓存不一致。解决顺序是先打印构建环境关键项，再对齐构建文件里的编译级别和测试插件参数。不要用本机最新 Java 硬顶仓库声明，也不要靠改系统环境碰运气。

# 输出构建环境关键项，先对齐再排查业务 mvn -v java -XshowSettings:properties -version 2>&1 | grep -E "file.encoding|user.timezone|java.version" # 清理当前工程构建产物后重跑，不要先删整个本地仓库 mvn -q clean test -Dtest=SmokeTest

这段命令的逻辑是先看构建工具和 Java 属性，再做工程级清理复跑。-XshowSettings:properties输出 JVM 属性，grep过滤编码、时区和版本；clean只清当前工程产物，避免旧 class 干扰；-Dtest=SmokeTest限定最小用例。若流水线仍报版本错误，检查流水线使用的构建镜像或代理节点，而不是继续改用例代码。> 注意：编码问题不要用“把日志改成英文”绕过去，配置、请求和报告都可能受影响。

5.2 数据类翻车：用例顺序一换就红

现象：单条用例执行通过，全量执行时失败；或者先跑 A 再跑 B 正常，先跑 B 再跑 A 报错。原因多是共享静态变量、固定测试账号、数据库残留和用例间隐式顺序依赖。解决方式是让每条用例自己准备最小数据，用唯一后缀区分，清理动作放在用例后置钩子；查询类用例不要假设“库里只有一条”，要么按唯一标识查，要么先构造前置数据。静态 WebDriver、静态请求上下文、静态用户令牌都要谨慎。

class UniqueDataDemoTest { private static String uniqueSuffix() { return String.valueOf(System.nanoTime()); } void demo() { String sku = "sku-demo-" + uniqueSuffix(); // 用唯一 sku 创建数据，后续查询和清理都围绕这个值 } }

这段代码的逻辑是用纳秒时间戳生成测试数据后缀，降低并行和连续执行时的碰撞概率。System.nanoTime()只用于测试数据区分，不作为业务主键；实际项目可以叠加线程名或随机串。sku要贯穿创建、查询、清理三个动作，不能创建时用随机值、清理时用固定值。若代码包里有全局登录工具，检查它是否在用例间复用同一个会话，必要时改为每条用例独立登录或按线程隔离。

5.3 稳定性与报告类翻车：偶发失败和空报告

现象一：UI 用例本地十次过一次，流水线偶发超时。原因多是把固定睡眠当等待、元素定位依赖页面布局、浏览器窗口大小不一致。解决是把固定睡眠换成显式等待，定位器优先用稳定属性，测试开始统一窗口和缩放；对确实不稳定的非核心 UI 用例打标签，不放进合并门禁。现象二：接口断言偶发失败，实际响应字段顺序变化或时间格式不同。原因是把 JSON 字符串整体比较，或者对浮点、时间做精确相等。解决是按字段断言，金额用高精度类型比较，时间统一格式后再比。

现象三：报告目录为空，或者失败用例没有附件。原因通常是报告插件没挂上、结果目录被清理任务删掉、并行执行时结果目录冲突。解决是先确认测试插件和报告监听器配置，再确认clean与报告生成顺序，最后给并行任务分配独立结果目录。排查时用标签只跑冒烟，能快速判断是框架问题还是某条用例问题。

# 按标签只跑冒烟，减少不稳定用例干扰排查 mvn -q -Dgroups=smoke test # 检查测试报告和结果目录是否生成 find target -maxdepth 3 -type d \( -name "surefire-reports" -o -name "allure-results" \) -print

这段命令的逻辑是用标签缩小执行范围，再检查产物目录。-Dgroups=smoke的具体参数名要跟随当前测试框架和构建插件，JUnit5 与 TestNG 的标签过滤写法可能不同；find只查两层到三层目录，避免扫进依赖缓存。若报告目录存在但没有内容，先看测试是否真的执行了，再看监听器是否绑定到当前测试引擎。我的习惯是每次改构建插件后都跑一条故意失败的用例，确认失败信息和附件能进报告。

6. 进阶验证：把培训代码改成可回归的 Java 测试工程并守住冒烟门禁

最后一层不是继续加用例，而是给这套 Java 测试代码做“可回归验证”。我会先给核心链路打冒烟标签，让合并门禁只跑稳定、快、可定位的用例；接口契约校验放在冒烟里，UI 只留登录和一条主流程。并行执行前先确认数据隔离，报告目录按任务分开。这样培训代码才从“能跑的示例”变成“每天敢跑的工程”。

import org.junit.jupiter.api.Tag; import org.junit.jupiter.api.Test; class CheckoutSmokeTest { @Test @Tag("smoke") void checkout_main_flow_should_work() { // 只覆盖核心链路：创建订单 -> 支付占位 -> 查询状态 // 具体客户端从配置层取地址，测试数据使用唯一后缀 } }

这段代码的逻辑是用@Tag("smoke")标记核心链路，构建时按标签过滤。标签名要和流水线参数一致，不要今天写smoke、明天写smoke-test；方法内部仍要遵守配置注入和唯一数据原则。运行命令跟随仓库测试插件，常见形式是mvn -q -Dgroups=smoke test，如果插件不识别groups，就改用对应的标签参数。

我现在拿到任何一套测试开发培训代码，都会先跑通一条冒烟，再让它进流水线，最后才扩用例；这个顺序救过我好几次，希望帮到你。如果你也准备把这套 Java 测试开发培训代码用起来，先按第 2 章做编译检查，再按第 5 章排掉环境和数据坑，最后用冒烟标签守住门禁；资源获取入口在资源页，拿到后别急着全量跑。

本文还有配套的精品资源，点击获取