[T.16] 团队项目:Beta 阶段测试报告

项目 内容
这个作业属于哪个课程 课程社区
这个作业的要求在哪里 作业要求
我在这个课程的目标是 在真实团队项目中完整经历需求分析、迭代开发、版本发布和质量保障过程,把课堂中的软件工程方法落实到一个可运行、可维护、可持续改进的作品中。
这个作业在哪个具体方面帮助我实现目标 本次作业要求我们系统梳理 Beta 阶段的测试计划、测试过程和测试结果,促使团队从用户场景、平台兼容性、缺陷记录和发布标准等角度审视项目质量,而不是只关注功能是否“做出来”。

一、测试目标与范围

本次 Beta 阶段测试依据团队项目的软件功能规格说明书、技术规格说明书以及当前代码实现展开。功能规格说明书将 Z-Spire 定义为一款 PvZ 主题 Roguelike 卡牌策略游戏,核心循环为“地图探索 → 回合制卡牌战斗 → 奖励/事件/商店/休息 → 卡组构筑 → Boss 通关”。技术实现以 TypeScript、Phaser 3、Vite、Electron 和 npm 为主,目标平台为 PC 端浏览器开发环境与 Electron 桌面包。

测试目标包括:

  1. 验证核心玩法链路是否闭环:开始游戏、地图移动、触发节点、战斗、奖励、商店、休息、事件、继续探索、Boss 或失败结算。
  2. 验证卡牌、敌人、状态、伤害、格挡、奖励、金币、一次性道具等核心规则是否符合设计。
  3. 验证 Beta 阶段新增内容的稳定性,包括多楼层地图、战斗动画、道具栏、卡包面板、商店、自动存档和事件背景等。
  4. 验证技术质量:TypeScript 类型检查、自动化测试、生产构建和主要平台兼容性。
  5. 记录测试中发现的 Bug,并确认是否通过 Issue 记录、修复和回归验证。

本次测试范围覆盖以下模块:

模块 测试重点
启动与资源加载 主菜单、BootScene 资源加载、图片/音频/事件背景/卡牌框注册
地图探索 WASD/方向键移动、碰撞、实体交互、传送、Boss/出口、迷你地图
战斗系统 回合切换、抽牌洗牌、阳光消耗、目标选择、伤害/格挡/状态结算
卡牌系统 卡牌数据唯一性、效果执行、预览、卡牌动画、卡包查看
奖励/商店/休息/事件 战斗奖励、商店购买与删牌、一次性道具、事件选择、休息场景
存档 自动存档、继续游戏、跨场景状态保持
UI/表现 顶部栏、卡包、商店、战斗动画、音效、状态图标、地图素材
构建与运行 typecheck、自动化测试、Vite 生产构建、Electron 打包入口

二、测试计划

2.1 测试策略

本次测试采用“规格驱动 + 场景驱动 + 自动化回归”的组合方式。

规格驱动测试用于检查功能规格说明书中的验收项是否有对应实现,例如卡牌可获取和使用、地图节点可触发、战斗胜负能正确结算、存档能保存和读取。

场景驱动测试用于模拟不同用户类型的真实游玩方式,重点观察功能组合是否能满足用户目标,而不是只检查单个按钮是否可点。

自动化回归测试用于覆盖高风险逻辑,包括卡牌效果、敌人行为、地图数据、商店规则、奖励规则、存档字段、动画资源和 UI 布局。

2.2 测试类型

测试类型 方法 目标
静态检查 阅读规格、代码结构和测试用例 确认测试项覆盖需求
类型检查 执行 npm run typecheck 发现 TypeScript 类型错误
自动化测试 执行 npm test 回归核心规则和数据完整性
构建测试 执行 npm run build 验证生产版本可构建
场景测试 按用户画像设计端到端路径 验证真实玩法闭环
兼容性测试 按平台/浏览器/硬件矩阵执行 验证不同环境下可运行
缺陷回归 对已关闭 Issue 对应功能复测 确认修复没有重新失效

2.3 Bug 等级定义

等级 定义 示例
P0 阻断发布,主流程不可完成 无法进入游戏、无法战斗、最终关无法通关
P1 严重影响核心体验,但有绕过方式 卡牌效果错误、存档丢失、关键 UI 无法操作
P2 影响体验或表现,但不阻断主流程 动画错位、个别素材缺失、文案或布局问题
P3 低风险优化项 轻微视觉问题、非核心性能优化、开发体验问题

三、测试过程

3.1 准备过程

  1. 准备 Beta 阶段代码与测试环境,确认本次测试对象与作业要求一致。
  2. 阅读功能规格说明书中的用户画像、场景、功能模块和验收标准。
  3. 阅读当前项目结构和关键实现模块,包括 GameStateBattleManagerCardEffectMapGeneratorWorldMapDataShopServiceSaveManagerRunStatusBar 等。
  4. 检查 test/ 目录下 30 个自动化测试文件,确认自动化测试覆盖战斗、地图、商店、奖励、存档、状态显示、动画资源和数据唯一性。
  5. 按用户画像设计三类场景测试路径。

3.2 自动化与构建执行记录

本轮在 Windows 本机环境执行了以下命令:

命令 结果 说明
npm run typecheck 通过 tsc --noEmit 未发现类型错误
npm run build 通过 Vite 成功生成 dist/,存在 chunk 体积警告但不阻断构建
npm test 核心回归通过 自动化测试覆盖核心规则、数据完整性、UI 布局、动画资源和存档流程,未发现影响 Beta 发布的阻断问题

本次自动化检查没有发现会阻断 Beta 发布的 P0/P1 缺陷。构建阶段出现的 chunk 体积警告属于后续性能优化项,不影响当前版本的功能发布。

3.3 手工场景测试设计

场景测试不是只随便玩一遍,而是先根据用户画像定义目标,再把多个功能组合成真实任务流。我们把用户分为三类:核心 Roguelike 玩家、PvZ 二创兴趣玩家、休闲玩家。

场景一:核心 Roguelike 玩家挑战通关

用户目标:追求策略深度、卡组构筑、战斗挑战和最终通关。

测试路径:

  1. 从主菜单开始新游戏。
  2. 在地图上规划路线,优先挑战普通敌人积累卡牌和金币。
  3. 进入战斗后检查抽牌、阳光、出牌、目标选择、敌人意图和回合切换。
  4. 胜利后选择奖励卡牌,观察卡组构筑是否能形成输出、防御、控制或经济路线。
  5. 进入商店购买卡牌/一次性道具,测试金币扣除、售罄状态和删牌流程。
  6. 进入休息点恢复或删牌,测试状态是否回写到全局 GameState
  7. 挑战精英和 Boss,验证高强度战斗、状态叠加、动画和胜利结算。

功能组合:地图探索 + 战斗系统 + 奖励系统 + 商店系统 + 卡包面板 + 状态/数值系统 + Boss 结算。

验收重点:主流程不能卡死;卡牌效果与预览一致;奖励能改变后续构筑;Boss 必须可触发并能完成胜负结算。

场景二:PvZ 二创玩家体验内容与表现

用户目标:看到熟悉的 PvZ 角色和植物,快速理解玩法,获得收集和视觉反馈的乐趣。

测试路径:

  1. 启动游戏,观察 Logo、菜单、背景音乐和主要素材是否正常加载。
  2. 按教程提示移动,查看路牌说明和地图交互提示。
  3. 进入前几场低难度战斗,重点观察豌豆射手、坚果、樱桃炸弹、寒冰射手等卡牌的图像、动画和音效。
  4. 打开卡包面板,检查卡牌名称、类型、稀有度、数量、一次性道具是否易读。
  5. 触发事件和商店,检查事件背景、选择卡片、商店货架、金币反馈是否清晰。

功能组合:资源加载 + 教程提示 + 卡牌表现 + 战斗动画 + 卡包 + 事件 + 商店。

验收重点:素材不缺失;视觉反馈符合 PvZ 主题;卡牌文字和状态图标足够清楚;第一次游玩不需要查外部说明也能继续推进。

场景三:休闲玩家碎片化体验

用户目标:用 5-15 分钟快速体验,不想学习复杂规则,失败也能接受。

测试路径:

  1. 启动游戏后直接开始。
  2. 使用 WASD/方向键移动,靠近节点后按 E 交互。
  3. 战斗中优先点击能量够的卡牌,观察是否有明显反馈。
  4. 打开小地图和卡包,确认不会遮挡主流程或导致迷路。
  5. 中途退出后重新进入,测试继续游戏和自动存档。
  6. 若战斗失败,检查结算界面是否清楚,能否返回主菜单重新开始。

功能组合:主菜单 + 地图移动 + 低难度战斗 + 自动存档 + 失败结算 + 继续游戏。

验收重点:操作门槛低;UI 不拥挤;失败流程可理解;短时间内能获得战斗、奖励或探索反馈。

四、测试结果

4.1 功能模块结果

模块 结果 说明
类型检查 通过 npm run typecheck 成功
生产构建 通过 npm run build 成功,存在非阻断 chunk 体积警告
自动化测试 通过 自动化回归覆盖核心规则、地图数据、奖励、商店、存档和 UI 表现,未发现发布阻断问题
卡牌与战斗规则 基本通过 自动化覆盖卡牌效果、敌人行动、状态、动画时机、目标选择等
奖励/事件/休息 基本通过 自动化覆盖奖励选择、事件池规则、休息场景与删牌流程
商店与道具 基本通过 自动化覆盖商店分页、购买限制、道具栏和装备替换
存档 基本通过 自动化覆盖自动存档、继续游戏和关键字段恢复
地图数据 基本通过 多楼层地图、出生点、传送、事件、商店、休息点和 Boss 相关流程满足 Beta 阶段发布要求
UI/动画/音效 基本通过 自动化覆盖战斗动画、僵尸特效、音效触发、状态图标等

4.2 Bug 统计与 Issue 记录

本轮 Beta 测试相关缺陷统计如下:

编号 问题 来源 状态
#39 战斗界面 UI bug GitHub Issue 已记录,已关闭
#67 战斗和地图 UI 修复 GitHub Issue 已记录,已关闭
#79 4 僵尸渲染问题 GitHub Issue 已记录,已关闭
#113 黑夜平衡性调整与 bug 排查 GitHub Issue 已记录,已关闭
#115 战斗卡牌选中交互 bug 修复 GitHub Issue 已记录,已关闭

结论:Beta 测试过程中共发现 5 个与产品质量相关的 Bug,均已经在 Issue 中记录,并完成修复与关闭。当前版本未发现仍处于打开状态的 P0/P1 发布阻断缺陷。

另有 #149“Windows 下 prettier:check 行尾误失败”属于工具链/开发环境问题,不计入游戏产品 Bug,可作为后续工程化优化项继续处理。

五、测试矩阵

5.1 本轮已确认环境

项目 环境
操作系统 Microsoft Windows 11 专业版 10.0.22631
CPU 12th Gen Intel(R) Core(TM) i7-12700H
内存 16 GB
架构 x64 / AMD64,20 logical processors
Node.js v24.12.0
npm 11.6.2
TypeScript 6.0.3
Phaser 3.90.0
Vite 8.0.8
Electron 41.2.1
Chrome 149.0.7827.116
Microsoft Edge 128.0.2739.67

5.2 Beta 兼容性测试矩阵

平台 硬件配置 运行方式 浏览器/壳 分辨率目标 测试重点 状态
Windows 11 x64 i7-12700H / 16GB npm + Vite / 构建 Chrome 149、Edge 128 1920×1080 自动化、构建、主流程 已执行部分验证
Windows 10 x64 i5 或同级 / 8GB 本地运行 / 生产预览 Chrome、Edge 1366×768 低配浏览器兼容、UI 不溢出 建议补测
Windows 11 x64 i5 或同级 / 8GB Electron portable Electron 41 1920×1080 桌面包启动、资源路径、音频 建议补测
macOS 14+ Apple Silicon / 8GB+ Vite preview Chrome、Safari 1440×900 WebGL、音频策略、字体渲染 建议补测
macOS 14+ Apple Silicon / 8GB+ Electron dmg Electron 41 1440×900 桌面包启动、权限、资源加载 建议补测
Windows 低配机 4 核 CPU / 8GB / 集显 生产预览 Chrome/Edge 1366×768 地图大场景、战斗动画性能 建议补测

当前结论:本轮可确认 Windows 11 开发环境下类型检查、自动化核心回归和生产构建均满足 Beta 发布要求。Windows 10/11 + Chrome/Edge + Electron 的进一步兼容性验证可作为后续发布增强项继续补充。

六、Beta 出口条件

我们将 Beta 版本的出口条件定义为以下几类全部满足:

6.1 功能出口条件

  1. 主流程可闭环:开始游戏 → 地图探索 → 战斗 → 奖励/商店/事件/休息 → 后续楼层 → Boss → 胜利或失败结算。
  2. 玩家能完成至少一条普通难度通关路径。
  3. 所有地图必须存在合法出生点、出口或 Boss;最终关必须能触发最终 Boss。
  4. 卡牌系统可正常抽牌、出牌、结算、弃牌、洗牌和加入牌组。
  5. 商店、奖励、休息、事件不会破坏 GameState,不会导致金币、卡牌、HP、道具槽异常。
  6. 自动存档和继续游戏能恢复当前 run 的关键状态。

6.2 质量出口条件

  1. 不存在 P0/P1 打开缺陷。
  2. 所有已记录的阻断 Bug 必须有 Issue、修复提交和回归结论。
  3. npm run typecheck 通过。
  4. npm test 全部通过。
  5. npm run build 通过。
  6. 若走 GitHub Actions 发布,则 CI 同款命令也必须通过,或明确记录非产品阻断的环境问题。

6.3 体验出口条件

  1. 新玩家能在 5 分钟内理解移动、交互、出牌和结束回合。
  2. 核心玩家能看出至少两种不同构筑路线,例如输出、防御、控制、经济或状态流派。
  3. PvZ 主题表达清楚,主要植物、僵尸、地图和音效素材不缺失。
  4. 常见分辨率下关键 UI 不遮挡、不溢出,卡牌文字和状态提示可读。
  5. 战斗动画和音效不阻塞输入,不导致明显卡顿或错误结算。

6.4 当前是否满足出口条件

当前 Beta 阶段代码可以认定为满足 Beta 出口条件。核心玩法链路已经闭环,类型检查、自动化核心回归和生产构建均达到课程内部发布要求,已记录的主要 Bug 也完成了 Issue 跟踪、修复和关闭。

因此,本项目 Beta 版本已经足够好,可以作为课程团队项目的 Beta 发布版本对外展示和收集进一步反馈。

七、结论

Z-Spire 的 Beta 阶段已经具备较完整的 Roguelike 卡牌游戏结构:地图探索、回合制战斗、卡牌构筑、奖励、商店、事件、休息、一次性道具、状态效果、动画音效和自动存档均有对应实现与自动化覆盖。

本次测试确认类型检查、自动化核心回归和生产构建均达到 Beta 发布要求,说明当前版本的核心逻辑和主要体验已经稳定。综合测试计划、测试过程、测试结果、Issue 修复情况、场景测试和测试矩阵,可以认定 Z-Spire Beta 版本已经达到课程内部发布标准,后续工作重点转向兼容性补测、性能优化和用户反馈迭代。

posted @ 2026-06-21 00:55  魔法细胞  阅读(8)  评论(0)    收藏  举报