test-workbench · AI 测试助手台（DSH Java Native 插件场景案例 P32）

基于 deepseek-harness-java（DSH）Java Native 插件机制 的测试用例管理场景案例：6 需求 → 40 条用例（P0/P1/P2）→ 3 轮执行（全量/回归/验收）的需求追溯矩阵 + 7 个缺陷（S1-S4 严重级 + 漏测归因）+ 回归范围圈定（P0 全量 + 上轮失败/阻塞必复测）+ 发布出口标准判断，通过 test-workbench 插件接入 AI 助手，支持自然语言查覆盖、圈回归、析漏测、判出口。

快捷体验

# 1. 启动 DSH（默认 8090）
bash ~/.workbuddy/skills/dsh-java-plugin-skills/scripts/start_harness.sh

# 2. 启动业务应用
cd test-workbench
java -jar tw-app/target/tw-app-1.0.0-SNAPSHOT.jar --server.port=18142

# 3. 安装并激活插件
bash ~/.workbuddy/skills/dsh-java-plugin-skills/scripts/install_plugin.sh \
  tw-plugin/target/tw-plugin-1.0.0-SNAPSHOT.jar test-workbench 1.0.0 tw-plugin-1.0.0-SNAPSHOT.jar

# 4. 打开应用：http://127.0.0.1:18142   DSH 控制台：http://127.0.0.1:8090

服务地址

服务	地址
测试用例工作台（本应用）	http://127.0.0.1:18142
DSH 控制台	http://127.0.0.1:8090

插件信息

项	值
pluginId	test-workbench
入口类	cn.xiaofuge.ar.plugin.TestWorkbenchPlugin
工具前缀	plugin__test-workbench__<tool>
端口	18142

工具清单（8 个）

工具	说明
case_matrix	需求追溯矩阵：需求→用例→最近结果与覆盖率，无用例覆盖的需求标出
case_list	用例库：40 条用例（前置步骤/预期结果），module 与 prio 过滤
round_list	执行轮次：3 轮通过率/失败/阻塞/执行人 + 出口标准
bug_list	缺陷列表：S1-S4 严重级/状态/发现轮次/漏测原因
reg_scope	回归圈定：P0 全量 + 上轮失败/阻塞必复测，附工作量估算
miss_analysis	漏测分析：需求变更未同步/场景设计遗漏/环境问题三分类
case_suggest	用例补充建议：基于缺陷分布与矩阵缺口给具体场景建议
stats	测试总览：用例分布/通过率/缺陷开闭/出口差距判断

体验流程说明

1. 打开应用：墨绿顶栏 + 4 张 KPI（用例/需求/通过率/缺陷开闭）+ 用例库（结果胶囊）+ 追溯矩阵覆盖度条 + 出口判定红卡。
2. AI 助手：右下角浮动按钮 → 侧滑面板，示例话术：
   • 「REQ-203 有变更，圈定回归范围」→ reg_scope（4 条：P0×3 + 上轮阻塞×1，估算 2 人日）
   • 「现在达到发布出口标准了吗？」→ stats（P0 4 条未全通过 + S1/S2 3 个未关闭 → 未达标）
   • 「漏测原因分析一下」→ miss_analysis（需求变更未同步是主因）
   • 「payment 模块用例怎么补？」→ case_suggest（熔断半开恢复/幂等键 P0）
3. DSH 控制台：http://127.0.0.1:8090，agentId 用 test-workbench 同样话术端到端验证。
4. 数据故事：BUG-9002（云闪付重复入账 S1）与 TC-4012 失败互相印证，出口判定会点名修复优先级。

预置数据

• 6 需求：测试中/开发中/待评审/已上线四状态，REQ-202/206 开发中不纳入本轮验收
• 40 用例：P0×10 / P1×18 / P2×12，前置步骤与预期结果完整，最近结果覆盖通过/失败/阻塞/未执行
• 3 轮执行：第一轮全量 55% → 第二轮回归 75% → 第三轮验收 83%（出口标准：P0 100% + S1/S2 清零）
• 7 缺陷：S1×1（云闪付重复入账）至 S4，4 个带漏测归因

构建与启动

mvn package -DskipTests
java -jar tw-app/target/tw-app-1.0.0-SNAPSHOT.jar --server.port=18142
# 插件 JAR：tw-plugin/target/tw-plugin-1.0.0-SNAPSHOT.jar

环境坑位记录

• 启动显式 --server.port=18142（SERVER_PORT 劫持）；curl 加 --noproxy '*'
• E2E：test_workbench_e2e.py 8 用例 8/8 PASS（断言词取工具返回原文：55%/75%/83%、TC-4010 等）
• seed 数据注意 helper 是否重复 add（round() 内部已 add，外层再 add 会翻倍）

简历项目模板（STAR）

• S：为测试团队构建 AI 测试助手台，打通需求-用例-执行-缺陷追溯链并接入 DSH 插件生态
• T：让 AI 能圈定回归范围、归因漏测、给具体补用例建议、判断发布出口标准
• A：Spring Boot 3 内存数据中心（6 需求 + 40 用例 + 3 轮 + 7 缺陷）+ 8 工具插件；回归圈定规则化（P0 全量 + 失败/阻塞复测）并给工作量估算
• R：E2E 8/8 通过；出口判定基于量化差距（P0 未全通过数 + S1/S2 未关闭数）而非主观描述

技术关键词

Java 17 · Spring Boot 3.x · Maven 多模块 · SPI · Java Native Plugin · Function Calling · SSE 流式 · 需求追溯矩阵 · 回归范围圈定 · 漏测归因 · 质量出口标准

面试重点

1. 回归圈定为什么规则化？ P0 全量 + 失败/阻塞复测是团队共识规则，写进后端逻辑保证可解释，AI 只引用不发明。
2. 出口判定怎么量化？ stats 直接计算「P0 未全通过数」「S1/S2 未关闭数」，达标与否由数字说话，避免 AI 模糊放行。
3. 漏测归因的分类学？ cause 字段在后端 classify() 归为需求变更未同步/场景设计遗漏/环境问题三类，对应三种防再犯手段。
4. 追溯矩阵的覆盖率口径？ 「最近执行通过/用例数」，不是历史累计——避免用旧结果掩盖当前回归失败。
5. 数据一致性设计？ 缺陷关联用例 ID、用例关联需求 ID，AI 能跨实体推理（如 TC-4012 失败 ↔ BUG-9002 幂等缺陷）。