yumooo

# WildCard Beta 阶段测试报告

## 1. 测试目标与范围

Beta 阶段的测试目标是验证本轮新增和完善的功能是否可以稳定支撑真实用户使用，包括用户资料、规则发布审核、房间对局、规则市场、举报管理、回放和测试度量等模块。根据现有功能规格和技术规格，本次测试重点放在以下几条主线上。

- 用户系统：注册、登录、用户名登录、退出、当前用户状态、头像、用户名修改、密码修改、密码重置、邮箱验证码、登录失败状态保持。

- 房间系统：创建房间、加入房间、密码房间、准备状态、离开房间、房主开始游戏、房间路由守卫。

- 对局系统：战斗页展示、当前对局快照、出牌合法性、跳过动作、结算展示、历史对局、回放时间线。

- 规则系统：规则构建页面、JSON 预览、规则结构面板、保存草稿、编辑草稿、发布审核、审核预览、规则市场、规则 Fork、评论和图片上传。

- 管理系统：管理员路由保护、规则审核、举报提交、举报列表、举报详情、处罚动作、关联举报合并关闭、撤销处罚。

- 会话语义与稳定性：房间参与者加入、离开、重复加入、稳定排序、幂等离开、房间与对局压力测试。

- 工程质量：前端单元测试、前端 E2E、前端构建、后端格式检查、Clippy、后端测试、后端覆盖率。

## 2. 测试过程

本轮测试计划采用“自动化回归 + 专项测试 + 手工验收”的方式执行。自动化测试用于保证主流程和接口契约稳定，专项测试用于补充覆盖率和压力数据，手工验收用于确认真实页面交互、视觉状态和权限跳转符合预期。

- CI/CD 对前端执行依赖安装、单元测试、Cypress 安装检查、E2E 测试和生产构建检查。

- 前端单元测试覆盖 API 请求层、用户状态、路由守卫、房间页面、准备房间、对局页面、规则构建器、规则市场、举报审核、回放和基础工具函数。

- 前端 E2E 覆盖登录注册、受保护路由、创建/加入/准备房间、对局流程、规则市场、规则发布、管理员审核、举报审核、历史对局回放和卡牌样式设置。

- CI/CD 对后端执行格式检查、Clippy 静态检查、Rust 测试、覆盖率统计。

- 后端测试覆盖用户注册登录、验证码、头像、房间创建、规则 payload 校验、规则引擎执行、规则审核、市场接口、回放接口、举报处罚模型和 session/通信语义行为。这里的覆盖主要是后端 join/leave、多用户和幂等性语义，不代表前端已经完成真实 WebSocket 联调。

- 后端 coverage job 输出覆盖率摘要，并上传 backend-lcov artifact，便于后续接入覆盖率看板。

- 压测通过后端 ignored 测试手动执行，覆盖房间创建/加入以及对局快照/出牌动作的并发基线。

- 手工测试按照核心用户路径执行，覆盖普通用户、规则作者、房主、普通玩家和管理员五类角色。

### 2.1 Bug 记录与修复情况

| 编号 | 问题 | 原因 | 是否记录并修复 |

|—|—|—|—|

| BUG-BETA-001 | 用户头像在房间界面不显示 | 房间玩家列表只使用了用户名和用户 ID，没有把用户资料接口返回的头像字段同步到房间成员展示结构中 | 已记录并修复 |

| BUG-BETA-002 | 邮箱验证码无法发送 | 版本合并错误 | 已记录并修复 |

| BUG-BETA-003 | 规则文件写入失败 | 规则草稿保存和发布审核共用写入逻辑，首次保存时没有创建规则资源目录，导致后端写入 JSON 文件失败 | 已记录并修复 |

| BUG-BETA-004 | 头像上传失败 | 前端上传头像时没有按文件接口要求提交 multipart/form-data，后端无法解析文件字段和 MIME 类型 | 已记录并修复 |

| BUG-BETA-005 | 举报后管理员界面不显示新举报 | 举报提交接口写入的 targetType 与管理员筛选接口使用的枚举值不一致，新举报被过滤在列表之外 | 已记录并修复 |

| BUG-BETA-006 | 规则审核通过后规则市场不可见 | 审核通过时只更新了草稿状态，没有同步生成市场发布记录，导致用户无法在规则市场检索到新规则 | 已记录并修复 |

| BUG-BETA-007 | 历史对局回放无法打开 | 历史列表跳转回放页时传递的是房间号，回放详情接口需要对局 session id，前后端字段映射不一致 | 已记录并修复 |

| BUG-BETA-008 | 管理员撤销处罚后状态没有完全恢复 | 撤销处罚时只恢复了举报状态，没有同步恢复被下架规则或被封禁用户的业务状态 | 已记录并修复 |

| BUG-BETA-009 | 规则上传图片按钮没显示 | 前端页面遗漏了该按钮的渲染，导致上传入口未显示 | 已记录并修复 |

### 2.2 CI 检查与覆盖率结果

Beta 阶段 CI 主要承担回归验证、静态质量检查和覆盖率统计。后端本轮补充了认证提取、错误映射、用户封禁写入、规则市场过滤、举报持久化错误路径、历史回放持久化降级和卡牌展示等测试；rule_engine 由于规则执行状态空间较大，本轮只保留已有核心规则样例，没有为了覆盖率强行堆分支。

| 仓库 | CI 项 | 覆盖内容 | 结果 |

|—|—|—|—|

| 后端 | Rustfmt | Rust 代码格式 | 通过 |

| 后端 | Clippy | 全目标静态检查，警告按错误处理 | 通过 |

| 后端 | Test | 共 36 个测试文件、239 个测试标记，覆盖领域模型、接口契约、规则市场、举报处罚、历史回放、用户封禁和 session/通信语义 | 通过 |

| 后端 | Coverage | 生成覆盖率 summary 和 backend-lcov artifact，总行覆盖率 75.08% | 通过 |

| 后端 | AutoCorrect | 中英文排版检查 | 通过 |

| 前端 | Unit | 共 40 个 Vitest spec、222 个用例，覆盖 API、store、router、组件和页面 | 通过 |

| 前端 | E2E | 共 18 个 Cypress spec、70 个用例，覆盖主要用户路径和管理员路径 | 通过 |

| 前端 | Static Pages | 前端生产构建和 Pages fallback | 通过 |

后端覆盖率统计排除了启动入口和状态注入胶水代码，重点统计领域逻辑、接口层、基础设施适配和错误映射。本轮整体行覆盖率达到 75.08%，满足 Beta 阶段 75%-85% 的覆盖率目标。

需要特别说明的是，Beta 阶段报告中凡是提到 WebSocket/session 的地方，主要指后端侧的会话和实时通信语义测试，以及历史设计文档中的接口命名；当前前端准备房和对局刷新仍采用轮询方案，因此本报告不将“已完成前后端 WebSocket 实时联调”作为既成事实。

| 模块 | 行覆盖率 | 函数覆盖率 | 区域覆盖率 |

|—|—:|—:|—:|

| domain/replay.rs | 100.00% | 100.00% | 100.00% |

| domain/report.rs | 100.00% | 100.00% | 99.77% |

| domain/room.rs | 100.00% | 100.00% | 100.00% |

| domain/rule_engine.rs | 68.57% | 63.97% | 67.79% |

| domain/user.rs | 100.00% | 100.00% | 100.00% |

| error.rs | 100.00% | 100.00% | 100.00% |

| infrastructure/email.rs | 75.26% | 82.35% | 70.21% |

| infrastructure/user.rs | 64.49% | 91.89% | 58.33% |

| interface/auth.rs | 96.77% | 85.71% | 91.67% |

| interface/market.rs | 73.42% | 75.38% | 73.67% |

| interface/replay.rs | 87.04% | 79.63% | 83.89% |

| interface/report.rs | 62.04% | 71.01% | 56.67% |

| interface/room.rs | 93.72% | 92.47% | 89.44% |

| interface/rule.rs | 75.34% | 77.47% | 77.64% |

| interface/user.rs | 88.10% | 76.56% | 90.77% |

| TOTAL | 75.08% | 76.29% | 73.16% |

### 2.3 压力测试结果

本次压测覆盖房间生命周期和对局接口并发基线。

| 压测项 | 请求数 | 成功 | 失败 | QPS | 平均延迟 | P95 | 最大延迟 | 结论 |

|—|—:|—:|—:|—:|—:|—:|—:|—|

| room/create | 48 | 48 | 0 | 7029.92 | 2.74ms | 3.61ms | 4.47ms | 通过 |

| room/join | 48 | 48 | 0 | 14309.87 | 1.38ms | 1.57ms | 1.60ms | 通过 |

| game/current | 192 | 192 | 0 | 13349.86 | 0.42ms | 0.48ms | 0.82ms | 通过 |

| game/choose | 24 | 24 | 0 | 324.01 | 40.18ms | 66.92ms | 72.93ms | 通过 |

### 2.4 手工测试结果

| 手测功能 | 具体步骤 | 是否通过 |

|—|—|—|

| 登录与注册 | 打开用户页，完成登录；切换注册页，发送验证码并注册新用户；刷新确认登录态保持 | 通过 |

| 修改个人信息 | 于用户信息页面修改用户米、密码、邮箱，上传头像 | 通过 |

| 受保护路由 | 退出登录后访问创作中心、创建房间、管理员审核页 | 通过 |

| 首页导航 | 点击创建房间、加入房间、团队介绍、联系我们、帮助中心 | 通过 |

| 规则市场浏览 | 搜索规则，进入详情，查看评论和开发者信息 | 通过 |

| 规则 Fork | 在规则详情页 Fork 规则，确认进入草稿或创作中心可见 | 通过 |

| 规则草稿保存 | 新建规则，编辑基础信息和流程，保存草稿，刷新后重新打开 | 通过 |

| 规则发布 | 从创作中心提交规则审核，检查发布表单校验和提交结果 | 通过 |

| 管理员规则审核 | 管理员打开审核页，预览规则 JSON 和只读画布，批准或驳回 | 通过 |

| 创建公开房间 | 选择规则创建无密码房间，复制房间号，普通用户 B 加入 | 通过 |

| 创建加密房间 | 创建带密码房间，使用错误密码和正确密码分别加入 | 通过 |

| 准备与开局 | 两名玩家进入准备房间，非房主准备，房主开始游戏 | 通过 |

| 对局出牌与结算 | 当前玩家选择手牌出牌，非当前玩家不能操作，对局结束后查看结果 | 通过 |

| 历史对局回放 | 打开历史对局，进入回放页，步进时间线并返回 | 通过 |

| 卡牌样式设置 | 修改卡牌样式，刷新页面后确认保存，再恢复默认 | 通过 |

| 举报提交 | 在规则市场或评论区域提交举报，检查表单校验和成功提示 | 通过 |

| 举报用户 | 在规则市场或房间界面举报用户，检查表单校验和成功提示 | 通过 |

| 举报审核处罚 | 管理员筛选待处理举报，执行处罚、撤销处罚，确认计数和列表刷新 | 通过 |

## 3. 场景测试

### 3.1 场景一：普通玩家加入朋友房间并参与对局

用户画像：已有账号，不创建规则，只想输入房间号加入朋友创建的房间。

需求和目标：快速进入房间、准备、开始游戏、按提示出牌，并在结束后查看结果和回放。

预期流程：登录 -> 加入房间 -> 输入房间号和密码 -> 进入准备房间 -> 点击准备 -> 房主开始游戏 -> 出牌或跳过 -> 查看结算 -> 查看历史对局回放。

当前测试覆盖：加入房间页面、准备房间页面、战斗页、回放页、房间接口、对局快照、出牌合法性和规则引擎动作执行。

### 3.2 场景二：房主创建房间并开局

用户画像：已登录，希望选择一套规则创建房间，邀请其他玩家加入。

需求和目标：房间配置正确，密码房逻辑正确，玩家到齐并准备后可以稳定开局。

预期流程：登录 -> 进入创建房间页 -> 加载可用规则列表 -> 选择规则并设置回合时间和密码 -> 创建房间 -> 等待玩家加入 -> 玩家准备 -> 房主开始游戏。

当前测试覆盖：创建房间页、规则选项加载、无规则校验、公开房/密码房加入、准备状态、房主开始游戏、房间生命周期压测。

### 3.3 场景三：规则作者设计并上传规则

用户画像：希望用规则构建器设计自己的卡牌玩法，并发布到规则市场。

需求和目标：编辑规则结构、配置牌型和流程，先保存草稿，确认后提交审核，通过后可被其他用户使用。

预期流程：登录 -> 进入规则构建器 -> 编辑基础信息和流程 -> 查看 JSON -> 保存草稿 -> 继续编辑 -> 提交审核 -> 管理员批准 -> 在规则市场查看和使用。

当前测试覆盖：规则构建页面、工作区切换、保存草稿、编辑草稿、JSON 预览、发布表单、审核预览、规则市场详情、Fork 和图片上传。

### 3.4 场景四：管理员审核规则并处理举报

用户画像：管理员负责审核规则质量和处理违规内容举报。

需求和目标：只能管理员进入审核页；审核时能完整预览规则；处理举报时能执行处罚、合并关联举报，并在必要时撤销处罚。

预期流程：管理员登录 -> 进入规则审核页 -> 预览规则 -> 批准或驳回 -> 进入举报审核页 -> 筛选待处理举报 -> 查看详情 -> 执行处罚或撤销 -> 列表和待处理计数刷新。

当前测试覆盖：管理员路由保护、规则审核页面、只读预览、举报列表、举报详情、处罚动作、关联关闭、撤销处罚、非管理员访问拦截。

## 4. 测试矩阵

| 操作系统/环境 | 浏览器/运行器 | 用户登录注册 | 创建/加入房间 | 准备与对局 | 创建/审核规则 | 规则市场 | 举报审核 | 结论 |

|—|—|—|—|—|—|—|—|—|

| Windows 11 | Chrome | 通过 | 通过 | 通过 | 通过 | 通过 | 通过 | 通过 |

| Windows 11 | Microsoft Edge | 通过 | 通过 | 通过 | 通过 | 通过 | 通过 | 通过 |

|

## 5. Beta 出口条件

我们认为 WildCard Beta 版本可以发布，需要满足下面条件。

### 5.1 功能条件

- 用户可以完成注册、登录、用户名登录、退出和个人资料更新。

- 用户可以创建公开房间和密码房间，也可以通过房间号加入房间。

- 房间内玩家可以准备、离开，房主可以开始游戏。

- 内置规则可以完成开局、出牌、结算和回放。

- 规则作者可以保存草稿、编辑草稿、提交审核，并在审核通过后进入规则市场。

- 管理员可以完成规则审核、举报审核、处罚和撤销处罚。

- 规则市场支持浏览、搜索、详情、评论、Fork 和快速创建房间入口。

### 5.2 质量条件

- 前端单元/组件测试全部通过。

- 前端 E2E 测试全部通过。

- 前端构建通过。

- 后端 fmt、clippy、cargo test 全部通过。

- 后端总行覆盖率不低于 75%。

- 手工验收核心路径全部通过。

- 不存在 Blocker/Critical 级别未修复 Bug；Major 级问题必须有记录、影响说明和规避方式。