简介这份资源面向具备一定编程基础、熟悉 Java 与 Vue 的中高级研发与测试开发人员聚焦企业级端到端自动化测试平台的设计与实现帮助解决复杂业务系统回归测试效率低、失败定位难、测试资产分散等痛点可支撑 CI/CD 质量门禁与测试流程标准化。资源以完整项目实例形式呈现涵盖分层架构、测试用例模型、任务调度、变量作用域、断言与报告等核心机制并给出任务状态枚举、变量解析器、接口请求执行器、断言处理器、任务执行服务等代码示例以及数据库表设计、API 规范与前后端交互逻辑。压缩包共 1 个 docx 文档约 135KB内容为项目实例的详细说明便于按目录结构系统阅读。目前已有 92 人学习。读者可据此理解页面与接口混合编排、并发任务隔离、失败追踪与可视化报告的实现思路并基于该项目进行二次开发或功能扩展。1. 为什么端到端自动化测试平台需要 Java 与 Vue 分工很多团队做自动化测试第一反应是堆脚本Selenium 写一批、Appium 写一批、接口用例再写一批跑起来靠命令行结果靠邮件截图。三个月后脚本没人敢改环境一换全红测试报告散落在各个机器上。问题不在脚本本身而在于缺少一个把「用例管理、调度执行、结果聚合、可视化」串起来的平台层。基于 Java 与 Vue 的端到端自动化测试平台解决的正是这个断层。Java 侧承担执行引擎、任务调度、用例解析和数据库交互Vue 侧承担用例编排、执行看板、报告展示和实时日志。端到端意味着一条用例可以从 UI 操作走到接口校验再走到数据库断言而不是割裂的三套工具。这套方案适合测试开发、有自动化诉求的后端工程师以及需要把自动化测试从「个人脚本」升级为「团队资产」的测试负责人。下面从架构选型讲到可复现的实现细节。2. Java 执行引擎与 Vue 前端的架构选型2.1 为什么执行引擎选 Java 而不是 Python自动化测试领域 Python 生态确实更早成熟但平台化场景下 Java 有几个绕不开的优势。第一Spring Boot 提供成熟的依赖注入、事务管理和线程池调度并发用例时不用自己造轮子。第二TestNG 和 JUnit5 的用例组织能力比 pytest 更适合平台化解析注解驱动让用例元数据可以直接映射到数据库字段。第三团队里后端是 Java 的话测试平台可以复用同一套构建、部署和监控体系。常见做法是 Spring Boot 做服务端TestNG 做用例运行容器Selenium 4 和 REST Assured 分别负责 UI 与接口层。Vue 3 加 Vite 做前端Element Plus 提供表格和表单组件ECharts 画执行趋势。前后端通过 REST 接口和 WebSocket 通信WebSocket 专门推实时日志。2.2 平台分层与核心模块划分一个能落地的端到端平台通常分四层。接入层是 Vue 前端和开放 API调度层是任务队列和线程池执行层是用例解析器和各端 Driver存储层是 MySQL 加对象存储存截图和日志文件。核心模块包括用例管理CRUD 加版本、环境配置多套 baseUrl 和账号、任务调度定时和手动触发、执行引擎并行跑用例、报告中心聚合结果和趋势、通知钉钉或企微 webhook。模块之间通过接口解耦执行引擎不直接依赖前端前端也不直接操作数据库。2.3 数据库表设计的最小可用集合平台起步不需要几十张表下面这几张能撑起完整闭环。-- 用例表一条记录对应一个可执行用例 CREATE TABLE test_case ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL COMMENT 用例名称, module VARCHAR(64) COMMENT 所属模块, type VARCHAR(16) COMMENT UI/API/MIXED, script_path VARCHAR(256) COMMENT 脚本或类路径, params JSON COMMENT 参数化数据, env_id BIGINT COMMENT 关联环境, status TINYINT DEFAULT 1 COMMENT 1启用 0禁用, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 执行记录表一次任务一条 CREATE TABLE test_run ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_id BIGINT, env_id BIGINT, trigger_type VARCHAR(16) COMMENT manual/cron, total INT DEFAULT 0, passed INT DEFAULT 0, failed INT DEFAULT 0, start_time DATETIME, end_time DATETIME, status VARCHAR(16) COMMENT running/done/aborted ); -- 用例结果表一次执行里每条用例一条 CREATE TABLE case_result ( id BIGINT PRIMARY KEY AUTO_INCREMENT, run_id BIGINT, case_id BIGINT, result VARCHAR(16) COMMENT pass/fail/skip, duration_ms INT, log_path VARCHAR(256), screenshot_path VARCHAR(256), error_msg TEXT );test_case的params用 JSON 字段存参数化数据避免为每组数据建一行。test_run冗余存 passed 和 failed 计数是为了看板查询不用每次聚合case_result。case_result的log_path和screenshot_path指向对象存储数据库只存路径避免大字段拖慢查询。2.4 前后端接口约定与 WebSocket 日志通道接口用 RESTful 风格执行触发是POST /api/run/start返回 runId。前端拿到 runId 后建立 WebSocket 连接/ws/log/{runId}服务端在执行过程中逐条推送日志。// 执行触发接口返回 runId 供前端订阅日志 PostMapping(/api/run/start) public ResultLong startRun(RequestBody RunRequest req) { // 校验用例和环境是否存在 ListTestCase cases caseService.listByIds(req.getCaseIds()); if (cases.isEmpty()) { return Result.fail(用例不存在); } // 创建执行记录状态 running TestRun run runService.create(cases, req.getEnvId(), manual); // 提交到线程池异步执行不阻塞接口返回 executor.submit(() - engine.execute(run, cases)); return Result.ok(run.getId()); }RunRequest里带caseIds和envId接口只做校验和落库真正执行交给线程池。这样前端能立刻拿到 runId 去订阅日志不用等执行完。executor是自定义的ThreadPoolTaskExecutor核心线程数按机器核数配队列满了走拒绝策略记录日志避免任务丢失。3. 用 TestNG 与 Selenium 跑通一条端到端用例3.1 用例解析器如何把数据库记录变成可执行任务平台里的用例不是硬编码在代码里而是数据库记录加脚本路径。执行时解析器根据type字段决定用哪个 Driver。UI 类型走 SeleniumAPI 类型走 REST AssuredMIXED 类型先跑接口再跑 UI。public class CaseExecutor { public CaseResult execute(TestCase tc, EnvConfig env) { long start System.currentTimeMillis(); CaseResult result new CaseResult(); result.setCaseId(tc.getId()); try { switch (tc.getType()) { case UI: uiRunner.run(tc, env); break; case API: apiRunner.run(tc, env); break; case MIXED: // 先接口准备数据再 UI 验证 apiRunner.run(tc, env); uiRunner.run(tc, env); break; default: throw new IllegalArgumentException(未知用例类型); } result.setResult(pass); } catch (AssertionError | Exception e) { result.setResult(fail); result.setErrorMsg(e.getMessage()); // 失败时截图路径写入结果 result.setScreenshotPath(screenshotService.capture(tc)); } finally { result.setDurationMs((int)(System.currentTimeMillis() - start)); } return result; } }switch分支对应三种用例类型MIXED 类型先跑接口是为了准备测试数据再跑 UI 做端到端验证。finally里统一算耗时保证异常时也有时长记录。截图只在失败时触发避免每次执行都产生大量文件。3.2 Selenium 4 的 Driver 管理与并行执行参数并行执行最容易踩的坑是 Driver 共享。Selenium 4 内置了 Driver 管理但平台化场景建议自己封装 ThreadLocal。public class DriverManager { private static final ThreadLocalWebDriver HOLDER new ThreadLocal(); public static WebDriver get() { if (HOLDER.get() null) { ChromeOptions options new ChromeOptions(); options.addArguments(--headlessnew); options.addArguments(--no-sandbox); options.addArguments(--disable-dev-shm-usage); options.addArguments(--window-size1920,1080); HOLDER.set(new ChromeDriver(options)); } return HOLDER.get(); } public static void quit() { WebDriver driver HOLDER.get(); if (driver ! null) { driver.quit(); HOLDER.remove(); } } }ThreadLocal保证每个线程有独立 Driverquit后必须remove否则线程池复用时会拿到已关闭的 Driver。--headlessnew是 Chrome 新版无头模式比旧版--headless更接近真实浏览器行为。--disable-dev-shm-usage在容器里必须加否则共享内存不足会导致浏览器崩溃。并行度通过 TestNG 的parallel和thread-count控制常见配置是parallelmethods thread-count4具体数值按机器内存定每个 Chrome 实例大约占 300MB 到 500MB。3.3 接口层用 REST Assured 做数据准备与断言端到端用例里接口层通常负责准备数据和清理数据UI 层负责验证。public class ApiRunner { public void run(TestCase tc, EnvConfig env) { JSONObject params JSON.parseObject(tc.getParams()); // 准备数据创建订单 Response createResp given() .baseUri(env.getApiBaseUrl()) .header(Authorization, Bearer env.getToken()) .contentType(ContentType.JSON) .body(params.getJSONObject(createOrder).toJSONString()) .when() .post(/api/order/create) .then() .statusCode(200) .extract().response(); // 把返回的订单号存入上下文供 UI 层使用 String orderNo createResp.jsonPath().getString(data.orderNo); ContextHolder.put(orderNo, orderNo); } }given().when().then()是 REST Assured 的标准链式写法extract().response()拿到完整响应。ContextHolder是自定义的线程上下文把接口返回的订单号传给 UI 层实现真正的端到端串联。statusCode(200)是基础断言业务断言可以再加body(data.status, equalTo(CREATED))。3.4 执行结果回写与失败重试策略执行完一条用例就回写case_result不要等整个任务结束再批量写否则中途崩溃会丢结果。public void execute(TestRun run, ListTestCase cases) { for (TestCase tc : cases) { CaseResult result caseExecutor.execute(tc, envService.get(run.getEnvId())); // 失败重试一次仍失败才记为 fail if (fail.equals(result.getResult()) retryEnabled) { result caseExecutor.execute(tc, envService.get(run.getEnvId())); } result.setRunId(run.getId()); caseResultMapper.insert(result); // 通过 WebSocket 推送单条结果 wsService.push(run.getId(), result); } runService.finish(run.getId()); }重试只做一次避免不稳定用例反复占用资源。wsService.push让前端实时看到每条用例的结果不用等全部跑完。runService.finish更新test_run的汇总计数和结束时间。4. Vue 3 执行看板与实时日志的落地细节4.1 用 WebSocket 订阅执行日志的 Vue 实现前端拿到 runId 后建立 WebSocket日志按行追加到虚拟列表。// 执行详情页订阅日志 import { ref, onUnmounted } from vue export function useRunLog(runId) { const logs ref([]) let ws null const connect () { ws new WebSocket(/ws/log/${runId}) ws.onmessage (event) { const msg JSON.parse(event.data) // 日志和结果分开处理 if (msg.type log) { logs.value.push(msg.content) } else if (msg.type result) { updateCaseResult(msg.data) } } ws.onclose () { // 非主动关闭时重连 if (!manualClose) setTimeout(connect, 2000) } } const close () { manualClose true ws ws.close() } onUnmounted(close) connect() return { logs, close } }onmessage里按type区分日志和结果结果直接更新对应用例行的状态不用重新拉整个列表。onclose里做重连但主动关闭时不重连避免组件卸载后还在重连。onUnmounted里关闭连接防止内存泄漏。4.2 执行看板的 ECharts 趋势图与失败分布看板需要两个图近 30 天执行趋势和失败用例分布。// 趋势图配置数据来自 /api/report/trend const trendOption { tooltip: { trigger: axis }, legend: { data: [通过, 失败] }, xAxis: { type: category, data: dates }, yAxis: { type: value }, series: [ { name: 通过, type: line, data: passedCounts, smooth: true }, { name: 失败, type: line, data: failedCounts, smooth: true } ] }dates、passedCounts、failedCounts由后端聚合接口返回前端只负责渲染。失败分布用饼图按module字段分组快速定位哪个模块最不稳定。4.3 用例编排页面的表单校验与参数化配置用例编辑页需要校验名称非空、类型合法、脚本路径存在。参数化数据用 JSON 编辑器提交前做 JSON 合法性校验。const rules { name: [{ required: true, message: 用例名称必填, trigger: blur }], type: [{ required: true, message: 请选择用例类型, trigger: change }], params: [{ validator: (rule, value, callback) { if (!value) return callback() try { JSON.parse(value) callback() } catch (e) { callback(new Error(参数必须是合法 JSON)) } }, trigger: blur }] }params的校验用自定义 validator先判断空值放行再尝试JSON.parse失败时提示。这样避免把非法 JSON 存进数据库执行时才报错。4.4 环境切换与多套配置的前端状态管理平台通常有多套环境开发、测试、预发。前端用 Pinia 存当前环境切换时刷新用例列表和执行记录。// stores/env.js import { defineStore } from pinia export const useEnvStore defineStore(env, { state: () ({ currentEnvId: null, envList: [] }), actions: { async loadEnvs() { this.envList await api.get(/api/env/list) // 默认选第一个启用的环境 const first this.envList.find(e e.status 1) if (first) this.currentEnvId first.id }, switchEnv(id) { this.currentEnvId id // 触发用例列表重新加载 useCaseStore().reload() } } })currentEnvId作为全局状态所有请求带上这个 id。switchEnv里主动触发用例列表重载保证数据一致。环境配置里存apiBaseUrl、webBaseUrl、账号密码执行时由后端读取前端不接触敏感信息。5. 平台稳定性与执行效率的进阶调优5.1 用例隔离与数据清理的三种策略端到端用例最大的不稳定来源是数据污染。常见三种策略一是每次执行前重建数据库快照适合数据量小的项目二是用例自带清理逻辑在finally里删掉自己创建的数据三是用独立测试账号和独立数据前缀执行后按前缀批量清理。我一般用第二种加第三种组合用例创建的数据带唯一前缀比如时间戳加随机数finally里按前缀删除。这样即使用例中途失败清理逻辑也能兜底。数据库层面给测试数据加is_test标记定期任务清理超过 24 小时的测试数据。5.2 失败用例的自动归因与截图对比失败归因能大幅减少人工排查时间。平台可以在用例失败时自动收集当前 URL、页面截图、浏览器控制台日志、接口请求响应。截图对比用像素级 diff和上次通过的截图比对高亮差异区域。// 失败时收集上下文 public MapString, Object collectContext(WebDriver driver) { MapString, Object ctx new HashMap(); ctx.put(url, driver.getCurrentUrl()); ctx.put(title, driver.getTitle()); ctx.put(screenshot, screenshotService.captureBase64(driver)); // 控制台日志需要开启 loggingPrefs ctx.put(consoleLogs, driver.manage().logs().get(browser).getAll()); return ctx; }loggingPrefs需要在 ChromeOptions 里开启setCapability(goog:loggingPrefs, Map.of(browser, ALL))否则拿不到控制台日志。截图存 base64 直接塞进结果里前端展示不用再请求文件。5.3 定时任务与并发执行的参数配置表定时任务用 Spring 的Scheduled加 cron 表达式并发执行的关键参数如下。参数建议值说明核心线程数CPU 核数执行引擎线程池最大线程数CPU 核数 × 2峰值时扩容队列容量200超出走拒绝策略单用例超时120 秒防止卡死任务级超时30 分钟整体兜底重试次数1只重试失败用例截图保留30 天定期清理单用例超时用Future.get(timeout)实现超时后强制中断线程并标记失败。任务级超时在调度层判断超过就 abort 剩余用例。截图保留 30 天是平衡存储成本和排查需求超过的定时任务删除。5.4 从脚本到平台接入已有自动化资产的迁移路径已有 Selenium 或 Appium 脚本的团队不用推倒重来。迁移分三步第一步把脚本里的硬编码配置抽成环境变量对应平台的env表第二步把脚本入口改成实现统一接口CaseRunner让平台能调用第三步把用例元数据录入test_case表脚本路径指向改造后的类。// 统一用例接口已有脚本实现这个接口即可接入 public interface CaseRunner { void run(TestCase tc, EnvConfig env) throws Exception; }改造一个脚本大约半小时主要是抽配置和加接口实现。迁移后脚本能享受平台的调度、报告和通知能力不用再手动跑命令行。对于用 pytest 的团队可以用 Jython 或直接重写成 Java重写成本高的话平台也支持通过 shell 调用外部命令把 pytest 的输出解析成平台结果格式。本文还有配套的精品资源点击获取