Files

T

Simon facc04aa65 chore: docs 结构整改 + compose 双目录对齐（合并重建提交）

本提交为 .git 对象库损坏后的重建提交，内容等价于原先三个本地提交
（5e2fd4c2 / 57a53c98 / 5d7e1873）的累积结果，未做任何额外改动。

一、docs 结构整改（整改 #14）
根因：重构时新结构为 untracked 文件，执行 git stash（未带 -u）未纳入，
随后 git reset 拉回 HEAD 旧 tracked 树，导致旧树复活、新旧两棵目录
树并存于 docs/，共 791 文件、双分类体系冲突。

修复动作：
- b2 同名异主题文件改名迁移保全 9 个
- C 类 39 个孤立文件按主题正确归类
- A/B1 类 222 个重复文件删除（新结构已有内容副本）
- 9 个旧独有空目录删除
- 270 处内部引用按 verified 映射改写
- 整改记录 #14 登记于 04-运维文档/部署运维

结果：docs 791 → 569 文件，顶层仅规范 8 类 + 治理文件，单树恢复。
残留：约 20 处指向从未存在文件的陈旧死链，归入独立文档卫生任务。

二、compose 双目录对齐（消除踩坑 A）
- docker-compose.yml：nginx 前端挂载全部由根目录 frontend-*/dist
  改为 src/frontend-*/dist（h5 / agent / admin / terminal）
- docker-compose.dev.yml：dev 服务 build context 与卷同步改 src/
- 效果：本地 docker compose up 不再把根目录 stale dist 挂回，
  与线上一致，分叉隐患消除（已 docker compose config 校验通过）

防复发铁律：
- 重构须提交；仓库修复须 git stash -u 或先 commit
- 新结构须 git add 并提交，避免再次 untracked 复活
- H5 改动只动 src/frontend-h5/，禁改根目录遗留 frontend-*/

2026-08-07 22:31:32 +08:00

17 KiB

Raw Blame History

测试用例 - 快速回复规则后台管理

REQ编号: REQ-通用-002 版本: v1.2 日期: 2026-07-28 作者: 宋献 关联文档:

PRD：01-产品文档/00-产品规划/PRD-REQ-通用-002-快速回复规则后台管理-v1.2.md

技术方案：02-技术文档/技术方案-REQ-通用-002-快速回复规则后台管理.md

原型图：01-产品文档/01-02产品设计/快速回复规则后台管理-原型图.html

部署文档：04-运维文档/快速回复规则后台管理-部署文档-v1.0.md （按命名规范存量豁免条款保留历史文件名及根目录位置）

一、用例汇总

类别	用例数	通过	失败	阻塞
功能测试（规则 CRUD）	6	0	0	0
功能测试（审计日志）	4	0	0	0
功能测试（置信度三档）	3	0	0	0
功能测试（降级兜底）	2	0	0	0
功能测试（灰度开关）	2	0	0	0
功能测试（启动加载）	2	0	0	0
功能测试（前端集成）	3	0	0	0
功能测试（v1.2 UI 整理）	3	0	0	0
接口测试	4	0	0	0
总计	29	0	0	0

二、功能测试用例

2.1 规则 CRUD

TC-ID	TC-001
用例名称	列表查询 - 按规则类型筛选
前置条件	1) 登录管理后台（账号 X） 2) 数据库有 12 条 greeting + 33 条 routing_prefilter + 6 条 routing_target + 2 条已停用规则
测试步骤	1. 进入"快速回复规则 > 规则列表" 2. 类型筛选取 `greeting` 3. 检查列表展示数
预期结果	列表展示 12 条 greeting 规则，关键词、优先级、状态、最后修改时间字段完整
测试结果	⬜ 待测试

TC-ID	TC-002
用例名称	单条查询 - 通过 ID
前置条件	已知数据库存在 id=1 的 greeting 规则
测试步骤	1. 进入"规则详情" 2. 输入 id=1 3. 检查返回字段
预期结果	返回规则完整字段（rule_type/category/keyword/priority/response_template/extra_data/is_active/created_at/updated_at）
测试结果	⬜ 待测试

TC-ID	TC-003
用例名称	创建规则 - 合法参数
前置条件	1) 数据库无 `rule_type=greeting, keyword="您好呀"` 记录 2) 管理员账号权限完整
测试步骤	1. 进入"新建规则" 2. rule_type=greeting, keyword="您好呀", priority=10, response_template="您好，我是智能助手..." 3. 提交
预期结果	1. 数据库新增 1 条记录 2. 审计日志表新增 1 条 `action=create, operator=当前账号` 3. 前端 toast "创建成功" 4. 列表自动刷新
测试结果	⬜ 待测试

TC-ID	TC-004
用例名称	创建规则 - 关键词重复被唯一约束拒绝
前置条件	数据库已有 `rule_type=greeting, keyword="你好"` 记录
测试步骤	1. 新建规则，rule_type=greeting, keyword="你好" 2. 提交
预期结果	1. 后端返回 400 错误 `IntegrityError / quick_rules_type_keyword_unique` 2. 前端 toast "该规则类型下已存在相同关键词" 3. 不写入数据库
测试结果	⬜ 待测试

TC-ID	TC-005
用例名称	更新规则 - 修改 priority 与 response_template
前置条件	数据库存在 id=1 的 greeting 规则（priority=10）
测试步骤	1. 编辑规则 2. 修改 priority=20、response_template="新模板" 3. 提交
预期结果	1. 数据库字段更新 2. 审计日志表新增 1 条 `action=update, before={"priority":10,...}, after={"priority":20,...}` 3. 缓存自动失效（下次查询读 DB 新值）
测试结果	⬜ 待测试

TC-ID	TC-006
用例名称	删除规则 - 二次确认
前置条件	数据库存在 id=5 的 routing_prefilter 规则
测试步骤	1. 行操作菜单点"删除" 2. 二次确认弹窗点"确定删除"
预期结果	1. 数据库删除该行（硬删或软删需在 PRD 中明确，本用例假设硬删） 2. 审计日志表新增 1 条 `action=delete, before=完整快照` 3. 前端列表自动消失该行
测试结果	⬜ 待测试

2.2 审计日志

TC-ID	TC-007
用例名称	创建规则自动写审计
前置条件	满足 TC-003 前置条件
测试步骤	1. 完成 TC-003 创建 2. 切换到"审计日志"页 3. 筛选 action=create
预期结果	1. 最新一条审计记录 operator=管理员账号、action=create、target_id=新规则 id、after=规则完整快照 2. created_at 与规则创建时间一致
测试结果	⬜ 待测试

TC-ID	TC-008
用例名称	更新规则自动写审计（保留 before/after）
前置条件	完成 TC-005
测试步骤	1. 完成 TC-005 更新 2. 切换到"审计日志"页 3. 筛选 action=update
预期结果	审计记录含 before/after 两个 JSON，差异字段 priority 和 response_template
测试结果	⬜ 待测试

TC-ID	TC-009
用例名称	删除规则自动写审计（after=null）
前置条件	完成 TC-006
测试步骤	1. 完成 TC-006 删除 2. 切换到"审计日志"页 3. 筛选 action=delete
预期结果	审计记录含 before=完整快照、after=null
测试结果	⬜ 待测试

TC-ID	TC-010
用例名称	审计日志列表分页与筛选
前置条件	审计日志表有 ≥100 条记录
测试步骤	1. 进入"审计日志"页 2. 按 operator 筛选、按时间倒序 3. 翻页至第二页
预期结果	1. 倒序展示 2. 第二页数据正确（无重复、无缺失） 3. 筛选生效（仅显示指定 operator 的记录）
测试结果	⬜ 待测试

2.3 置信度阈值三档

TC-ID	TC-011
用例名称	置信度 ≥0.85 — 自动应用规则
前置条件	1) AI 引擎对用户消息"重置密码"返回 routing_confidence=0.92 2) routing_target 规则已配置"IT支持"分类，kfid 可用
测试步骤	1. 用户发送"重置密码" 2. 等待 3 秒 3. 检查 WS 双通道推送
预期结果	1. 收到 `action=route_recommend` 消息，含 target 信息 2. `messages.reply_source` 字段包含 `"quick_rule"` 标识 3. 前端路由卡片自动展示
测试结果	⬜ 待测试

TC-ID	TC-012
用例名称	置信度 0.5~0.85 — 进入待审核
前置条件	AI 引擎 routing_confidence=0.72（落在待审核区间）
测试步骤	1. 用户发送对应消息 2. 后端日志确认收到 AI 响应 3. 检查是否触发路由卡片
预期结果	1. 后端写 audit log `action=pending_review, confidence=0.72` 2. 前端不自动展示路由卡片 3. 管理员后台"待审核列表"展示该条
测试结果	⬜ 待测试

TC-ID	TC-013
用例名称	置信度 <0.5 — 直接拒绝
前置条件	AI 引擎 routing_confidence=0.32
测试步骤	1. 用户发送对应消息 2. 等待 3 秒
预期结果	1. 走正常 AI 回复流程，不触发任何快速规则相关推送 2. 后端 debug 日志标记 `quick_rule.skipped: low_confidence=0.32` 3. 审计日志表无该记录
测试结果	⬜ 待测试

2.4 降级兜底

TC-ID	TC-014
用例名称	quick_rules 表为空 — 业务不中断
前置条件	1) `TRUNCATE quick_rules RESTART IDENTITY` 2) 重启后端（load_all 重新加载）
测试步骤	1. 用户发送"打印机没墨" 2. 观察是否触发路由推荐
预期结果	1. 后端日志 "QuickRuleService 加载完成: greeting=0, routing_keywords=0, routing_targets=0" 2. 上层 routing_service 走 `ROUTING_TARGETS` 硬编码兜底 3. 用户仍收到 6 类业务路由卡片，业务不中断
测试结果	⬜ 待测试

TC-ID	TC-015
用例名称	routing_target 字段未配置 — 走硬编码兜底
前置条件	quick_rules.routing_target 表为空，但 greeting 和 routing_prefilter 有数据
测试步骤	1. 用户发送"想订机票" 2. Dify 命中 routing_prefilter 关键词 → business_category="行政" 3. 检查是否返回路由卡片
预期结果	1. 上层 routing_service 检测到 `routing_targets={}` 为空 2. 自动降级到 `ROUTING_TARGETS["行政"] = 机票酒店前台` 3. 用户收到正确的路由卡片
测试结果	⬜ 待测试

2.5 灰度开关（QUICK_RULE_ENABLED，v1.1 新增）

TC-ID	TC-016
用例名称	开关 = true — check_* 方法生效
前置条件	1) `.env` 配 `QUICK_RULE_ENABLED=true` 2) 重启后端，确认 settings.quick_rule_enabled=True 3) greeting 规则存在关键词"你好呀"
测试步骤	1. 用户发送"你好呀" 2. 检查后端日志与前端回复
预期结果	1. `check_greeting("你好呀") = True` 2. 命中后直接返回规则 response_template 3. `messages.reply_source` 含 `"quick_rule"`
测试结果	⬜ 待测试

TC-ID	TC-017
用例名称	开关 = false — check_* 全员旁路（秒级回退）
前置条件	1) `.env` 改 `QUICK_RULE_ENABLED=false` 2) `docker compose up -d backend` 重启后端容器 3) greeting 规则存在关键词"你好呀"
测试步骤	1. 用户发送"你好呀" 2. 检查后端日志与前端回复
预期结果	1. `check_greeting("你好呀") = False`（旁路） 2. `check_routing_keyword(...) = False`（旁路） 3. 走正常 AI 回复流程（Dify 主对话） 4. 用户收到的回复不再是规则的固定模板 5. 业务不中断（仅失去快速规则拦截） 6. routing_target 仍由 routing_service 自带的 `ROUTING_TARGETS` 兜底
测试结果	⬜ 待测试

2.6 启动加载

TC-ID	TC-018
用例名称	lifespan 阶段 load_all 调通
前置条件	数据库初始化数据完整（53 条）
测试步骤	1. 冷启动后端容器 2. 等待 health check 通过 3. 读取启动日志
预期结果	1. 启动日志含 "QuickRuleService 加载完成: greeting=12, routing_keywords=33, routing_targets=6" 2. 数字与初始 SQL 完全一致 3. 无异常堆栈
测试结果	⬜ 待测试

TC-ID	TC-019
用例名称	QuickRuleAuditLog 表已注册到 models/__init__.py
前置条件	Alembic 已 upgrade 到 055 迁移
测试步骤	1. 启动后端 2. 用 psql 检查表结构
预期结果	1. `quick_rule_audit_logs` 表存在 2. 含 id/rule_id/action/operator/before/after/created_at 字段 3. （回归 BUG-REQ-002-A）若 `models/__init__.py` 未注册，该表将不创建，本用例为该 BUG 的回归保险
测试结果	⬜ 待测试

2.7 前端集成

TC-ID	TC-020
用例名称	列表页正确展示规则
前置条件	后端 quick_rules API 返回 12 条 greeting 规则
测试步骤	1. 使用 agent-browser 技能加载管理后台 URL `/quick-rules` 2. 输入账号密码登录 3. 等待列表渲染
预期结果	1. 表格展示 12 条记录 2. 不复现 BUG-通用-001（深色表格白底白字） 3. 类型筛选、关键词搜索均可用
测试结果	⬜ 待测试

TC-ID	TC-021
用例名称	表单提交不报 .data undefined
前置条件	前端项目已 build 到 dist（hash 包含 2026-07-28 修复）
测试步骤	1. 进入"新建规则" 2. 填写表单，提交
预期结果	1. 不复现 BUG-20260728-01（`sr.data` undefined TypeError，拦截器已返回 inner data 时多取一层） 2. 提交成功 toast "创建成功"
测试结果	⬜ 待测试

TC-ID	TC-022
用例名称	选项点击只发 WS，不再本地立即加消息
前置条件	1) 前端 dist 已部署 2) 用户发"重置密码"，AI 返回一组路由选项
测试步骤	1. 点击其中一个选项（如"行政-物业"） 2. 观察消息流
预期结果	1. 前端不本地立即添加消息 2. WS 收到对端推送后才添加到列表 3. `processedMessageIds` Set 去重生效（轮询补集不会重复）
测试结果	⬜ 待测试

2.8 v1.2 UI 整理

TC-ID	TC-027
用例名称	页面加载后顶部无 `.stats-row` 卡片
前置条件	管理后台 v1.2 前端页面已部署，管理员已登录
测试步骤	1. 打开 `/itadmin/quick-rules` 2. 等待页面和规则列表加载完成 3. 检查标签导航上方 DOM
预期结果	页面顶部不存在 `.stats-row` 及其 3 张规则统计卡片；筛选区和表格布局正常
测试结果	⬜ 待测试

TC-ID	TC-028
用例名称	标签导航徽标数字正确显示
前置条件	stats 接口返回 greeting=12、routing_prefilter=35、routing_target=6
测试步骤	1. 打开 `/itadmin/quick-rules` 2. 检查打招呼规则、路由关键词、路由目标三个标签的 count 徽标
预期结果	三个标签徽标依次正确显示 12 / 35 / 6，规则计数信息仅由标签导航徽标呈现
测试结果	⬜ 待测试

TC-ID	TC-029
用例名称	删除卡片后管理功能完整回归
前置条件	管理后台 v1.2 前端页面已部署，后端 quick-rules API 可用
测试步骤	1. 依次点击三个规则标签并检查表格加载 2. 执行筛选、搜索和分页 3. 验证批量删除、编辑、启停开关
预期结果	标签切换、表格加载、筛选、搜索、分页、批量删除、编辑和启停开关全部正常，无控制台错误
测试结果	⬜ 待测试

三、接口测试

TC-ID	IT-001
端点	`GET /api/admin/quick-rules?type=greeting`
测试步骤	1. 用 curl 调用 2. 检查响应
预期结果	200 OK，items.length=12，每项含 to_dict 全部字段
测试结果	⬜ 待测试

TC-ID	IT-002
端点	`POST /api/admin/quick-rules`
测试步骤	1. 用 curl 创建重复关键词规则（与 TC-004 同） 2. 检查响应
预期结果	400 BadRequest，detail 含 IntegrityError 描述
测试结果	⬜ 待测试

TC-ID	IT-003
端点	`DELETE /api/admin/quick-rules/{id}`
测试步骤	1. 用 curl 删除已删除的 ID 2. 检查响应
预期结果	404 NotFound，detail="规则不存在"
测试结果	⬜ 待测试

TC-ID	IT-004
端点	`GET /api/admin/quick-rules/audit?operator=admin&page=2`
测试步骤	1. 查询第二页审计日志（≥100 条假设） 2. 检查响应
预期结果	200 OK，items 含完整审计字段，total/page/size 正确
测试结果	⬜ 待测试

四、回归测试

TC-ID	RT-001
用例名称	深色表格可读性回归
前置条件	主题 = dark
测试步骤	1. 打开规则列表、审计日志、配置历史等所有 el-table 视图 2. 滚动检查偶数行、固定列、hover 状态
预期结果	不复现 BUG-通用-001（白底白字），固定列与普通列底色一致
测试结果	⬜ 待测试

TC-ID	RT-002
用例名称	拦截器 .data 层数一致性回归
前置条件	全部列表/详情接口
测试步骤	1. 浏览 8 个 quick_rules 相关视图（list/edit/audit/welcome/通用规则） 2. 浏览器 console 无 `TypeError: Cannot read properties of undefined (reading 'data')`
预期结果	不复现 BUG-20260728-01（已修复 7 处 `.data` 重复取数）
测试结果	⬜ 待测试

五、测试完成判定

标准	要求
通过率	功能测试 25 条 + 接口测试 4 条 = 29 条核心用例，100% 通过
阻塞	0
回归	RT-001 / RT-002 必须通过
验收	TC-016 / TC-017（灰度开关）必须双跑：true / false 各一次

六、变更记录

日期	版本	变更内容	变更人	变更原因	影响范围
2026-07-28	v1.2	新增 TC-027～TC-029，覆盖顶部统计卡片移除、标签徽标计数及管理功能回归；核心用例由 26 条增至 29 条	宋献	验证 v1.2 UI 去重不影响既有功能	管理后台 `/quick-rules` 页面
2026-07-28	v1.1	新增 §2.5 灰度开关、§2.7 前端集成及第四章回归测试 9 条用例	宋献	配合部署文档 v1.1 同步发布	CRUD、审计、置信度、降级、灰度、启动及前端
2026-07-27	v1.0	初版基础 22 条用例	宋献	配合部署文档 v1.0 发布	快速回复规则后台管理基础功能

17 KiB Raw Blame History Unescape Escape

测试用例 - 快速回复规则后台管理

一、用例汇总

二、功能测试用例

2.1 规则 CRUD

2.2 审计日志

2.3 置信度阈值三档

2.4 降级兜底

2.5 灰度开关（QUICK_RULE_ENABLED，v1.1 新增）

2.6 启动加载

2.7 前端集成

2.8 v1.2 UI 整理

三、接口测试

四、回归测试

五、测试完成判定

六、变更记录

17 KiB

Raw Blame History