企业官网建设流程全解析

AI-Meeting是一个基于 Spring Boot 3 + Java 17 + Spring AI 的 AI 智能面试平台，仓库内置了一套可直接参考的测试与 CI 工程化方案：GitHub Actions 流水线 自动执行 Maven 构建校验，本地统一入口./mvnw -B -ntp clean verify覆盖单元测试、并发压测，并通过结构化的压测报告体系输出 p50/p95/p99 延迟指标，帮助新手快速建立可验证、可回滚的交付习惯。

为什么 AI 项目更需要测试工程化

AI 应用链路长（简历解析 → 出题 → 问答 → 评分 → 报告），涉及 MySQL、MongoDB、Redis、SSE/WebSocket 多种组件，任何一个环节的回归缺陷都可能让用户看到"答非所问"。AI-Meeting 的做法是把质量保障拆成三层：

1. 流水线门禁：提交代码后自动触发构建校验
2. 单元测试与控制器测试：隔离外部依赖，快速验证业务逻辑
3. 并发压测 + 结构化报告：验证高并发下接口稳定性并沉淀量化指标

下面逐层拆解，你可以直接把这些模式套到自己的 Spring Boot 项目里。

GitHub Actions 流水线：一次 push 都逃不过检查

CI 工作流定义在 backend-ci.yml 中，整体设计非常"轻"，新手友好：

这里有几个值得学习的细节：

• paths-ignore精准过滤：改 README 不跑构建，CI 队列更干净；
• Maven Wrapper：CI 里先chmod +x ./mvnw再执行，开发者和流水线用同一版本 Maven，避免"我本地是好的"；
• 构建期门禁插件：根 pom.xml 配置了maven-enforcer-plugin，在 validate 阶段强制要求JDK ≥ 17、Maven ≥ 3.6.3，环境不对直接失败而不是编译出奇怪错误；
• Spotless 格式检查：对.github/**/*.yml、*.yml、.gitignore等做尾部空白、换行与 pom 排序检查（verify 阶段执行），CI 配置文件的格式也纳入管控。

流水线刻意跳过了测试执行（-Dmaven.test.skip=true），把 CI 定位为快速构建门禁——保证代码能编译、环境合规、格式正确；完整的测试套件在本地与 PR 流程中运行，兼顾速度与覆盖率。

单元测试体系：38 个测试文件、90+ 个用例

测试代码集中在 admin/src/test/ 目录，共 38 个测试类、90 余个@Test用例，按业务域组织，与主代码包结构一一对应，找起来毫不费力。

分层看测试覆盖

• 纯单元测试（Mockito 隔离外部依赖）：面试域占比最高，包括分布式 Single-flight 服务、AI 调用守卫、追问规则链、状态机、评分策略等，例如 DistributedInterviewAiSingleFlightServiceTest.java 验证了"分布式开关关闭时回落本地执行"、"Owner 路径正确落盘结果"等关键行为；
• 控制器 / 服务层测试（MockMvc）：如 AgentPropertiesControllerTest.java 和 AiConversationServiceImplAuthTest.java 验证接口响应与鉴权逻辑；
• Spring 上下文测试：ActuatorHealthEndpointTest.java 用精简的TestApplication启动上下文，显式排除 Redis/Mongo/LiteFlow 自动装配，让健康检查测试无需真实中间件即可运行——这是"测试不依赖外部环境"的范本；
• 通用组件测试：限流服务、风控过滤器、全局异常处理器等均有对应测试。

构建插件如何支撑测试

admin/pom.xml 中maven-surefire-plugin（3.2.5）与maven-failsafe-plugin都配置了-javaagent指向 Mockito jar 的argLine，配合锁定的mockito.version（5.14.2），消除了 Mockito 字节码增强相关的运行时告警。这类"构建层解决测试环境噪音"的配置，比自己逐个查告警高效得多。

压测报告体系：把"高并发没问题"变成数字

这是 AI-Meeting 测试体系中最有参考价值的部分。压测类测试分布在控制器层（InterviewSessionControllerPressureTest.java）、门面层（InterviewSessionFacadePressureTest.java）和收尾流程（InterviewRecordFinalizeConcurrencyTest.java），覆盖了 20~48 并发规模的真实接口路径。

压测的典型写法

以InterviewSessionControllerPressureTest为例，套路统一且易复制：

1. MockMvc 独立装配控制器，Mock 掉 Facade 层，注入自定义用户参数解析器与 GlobalExceptionHandler；
2. 线程池 + CountDownLatch 齐射：40 个并发请求同时打到/interview/answer-json接口，每个请求断言 HTTP 200 与jsonPath响应字段；
3. 逐请求计时，收集延迟列表后输出结构化报告；
4. verify校验调用次数：Mock 被调用次数必须等于并发数，确保没有请求被静默丢弃。

并发收尾场景（InterviewRecordFinalizeConcurrencyTest）则验证"24 个并发请求下只有 1 个最终写入者"，用AtomicBoolean + compareAndSet模拟锁竞争，确保面试报告不会重复落库——这类竞态问题靠 code review 很难发现，只有并发测试能暴露。

结构化报告：PRESSURE_REPORT

所有压测统一通过 PressureTestReportUtil.java 输出报告，格式固定为一行PRESSURE_REPORT {json}，包含：

{ "scenario": "controller.answer-json.concurrent", "concurrency": 40, "success": 40, "successRate": 100.0, "latency": { "unit": "ms", "min": 12, "p50": 35, "p95": 88, "p99": 120, "max": 150, "avg": 41.2 } }

固定前缀 + 单行 JSON 意味着：可以直接在 CI 日志中用grep PRESSURE_REPORT提取所有场景数据，甚至脚本化对比版本间的 p95 变化。压测从"跑一遍看看"变成了可量化、可回归的工程手段。

测试如何贯穿交付全链路

测试工程化的价值不止在 CI 里，AI-Meeting 把它延伸到了部署与协作规范：

• Docker 构建：Dockerfile 采用多阶段构建，builder 阶段mvn clean package -Dmaven.test.skip=true保持镜像构建快速，运行时通过HEALTHCHECK定期访问/actuator/health——而这个端点正是被ActuatorHealthEndpointTest单测覆盖的，形成"单测守护健康检查、健康检查守护容器"的闭环；
• 贡献规范：CONTRIBUTING.md 要求提交前本地执行./mvnw -B -ntp clean verify，新增功能必须补充最小可验证测试；
• PR 模板：pull_request_template.md 内置"测试方式"清单（./mvnw -B -ntp clean verify+ 手动验证关键接口），强制每个 PR 交代测试结论。

本地一键复现：完整验证步骤

# 1. 克隆仓库 git clone https://gitcode.com/gh_mirrors/ai/AI-Meeting.git cd AI-Meeting # 2. 统一校验入口（构建 + 测试 + 格式检查） ./mvnw -B -ntp clean verify # 3. 只跑某个压测类并查看报告 ./mvnw -pl admin test -Dtest=InterviewSessionControllerPressureTest grep PRESSURE_REPORT admin/target/surefire-reports/*.txt

💡 小技巧：-ntp（no transfer progress）让日志更干净，-B（batch mode）适合脚本与 CI 场景，二者搭配是 Maven 工程化的常用组合。

总结：可以直接抄的 5 个实践

1. 用paths-ignore让文档改动免触发 CI，保持流水线轻快；
2. maven-enforcer-plugin前置校验 JDK/Maven 版本，环境错误在 validate 阶段就暴露；
3. Spring 测试显式排除无关自动装配，做到"无中间件也能跑"；
4. 并发测试用CountDownLatch 齐射 + verify 调用次数，竞态问题用单写者断言锁住；
5. 压测输出一行固定前缀 JSON 报告（含 p50/p95/p99），让性能数据可 grep、可对比、可回归。

这套体系不依赖任何重型工具链，纯 JUnit 5 + Mockito + MockMvc 就能落地，非常适合想给自己的 Spring Boot 项目补齐测试工程化的同学参考。