福大兄弟队——Alpha测试随笔:从规则验证到完整游戏验收
福大兄弟队——Alpha测试随笔:从规则验证到完整游戏验收
| 这个作业属于哪个课程 | 2601_FZU_SE 软件工程实践 |
|---|---|
| 这个作业要求在哪里 | 团队第四次作业-站立式会议+α冲刺 |
| 团队名称 | BroFuTo 福大兄弟队 |
| 这个作业的目标 | 完成七日Alpha开发与并行测试,交付七张地图、七位首领、无尽模式和完整校园游戏流程。 |
| 其他参考文献 | 《构建之法》第2章、第13章;Godot、SQLite、FastAPI官方文档;项目需求与设计文档。 |
| 团队仓库 | BroFuTo · master |
目录
- 福大兄弟队——Alpha测试随笔:从规则验证到完整游戏验收
- 一、测试目标与整体思路
- 1.1 《构建之法》学习与本项目的结合
- 1.2 优先检查哪些问题
- 二、测试分工与七日推进
- 三、测试环境、工具与实际运用
- 3.1 工具选择
- 3.2 测试入口与结果保存
- 四、用例如何设计
- 4.1 主要功能用例
- 4.2 七首领的专项关注点
- 五、执行结果与数据分析
- 5.1 分项结果
- 5.2 自动游玩与角色对照
- 5.3 路径与密集场景
- 5.4 音频与独立包
- 六、发现的问题与修复复验
- 6.1 地形卡住:从直线追击到共享路径
- 6.2 打光师移动后继续连发
- 6.3 成长与交易跨状态不一致
- 6.4 预警、界面与音频反馈
- 七、最终人工验收与运行画面
- 八、AI技术员在测试中的作用
- 九、测试体会、项目评述与下一步
- 测试资料入口
一、测试目标与整体思路
BroFuTo以校园题材的生存构筑玩法为核心。一局游戏会连续经过角色选择、战斗、升级、超市、装备调整、下一波和最终结算;保存与云同步还会跨越这些阶段。测试围绕这条实际使用路径展开,既检查单项规则,也检查状态能否连续传递。
本轮冲刺为2026年10月23日至29日,验收版本为 Alpha Day7 Balance v1.3 Audio v3。目标包括七张普通地图各十波、七位独特首领、无尽模式,以及成长、交易、保存恢复、科技、图鉴和主动云存档。
测试从第一天就与开发并行。规则刚确定时先列输入、状态和预期;模块接通后验证真实调用;版本集成后再跑长流程、网络、画面和独立包。每次发现问题,都保留复现条件、修改位置和复验结果,逐步形成可重复执行的检查。
1.1 《构建之法》学习与本项目的结合
围绕第2章的学习,我们把“这个功能应该正确”转成具体输入和输出。例如,合成成功需要核对材料数量、生成武器、成长值和槽位;合成失败则核对交易前后的完整状态。测试进入日常开发步骤,帮助成员及时发现接口理解的差异。
结合第13章对测试工作的讨论,团队把测试贯穿需求、开发和交付。机制正确性由自动化反复检查,连续流程由固定策略自动玩家覆盖,操作体验与设备差异由人工验收确认,发布包再单独验证启动与资源加载。
1.2 优先检查哪些问题
| 风险 | 可能出现的后果 | 对应测试重点 |
|---|---|---|
| 交易与存档不一致 | 学分已扣但武器未到账,或读档后重复领取 | 完整事务、失败恢复、检查点与一次性结算 |
| 跨阶段状态残留 | 换波继续旧计时,角色技能收益异常 | 初始化、时间推进与保存恢复 |
| 七地图规则不同 | 水面越界、台阶穿弹、敌人持续撞墙 | 七图通行、高矮障碍、身形和高度判断 |
| 长流程组合问题 | 无尽换图后阶段、价格或首领不正确 | 10/11、20/21边界与连续三十波 |
| 页面信息失真 | 武器详情与实际伤害不同,解锁状态不刷新 | 共用计算、完整操作、截图和人工复核 |
| 声音与特效过密 | 重要反馈被掩盖,长时间游玩疲劳 | 通道、优先级、静音、混音和密集场景 |
二、测试分工与七日推进
詹铖煜负责测试入口、执行结果和证据整理;功能负责人同时负责模块自查、问题定位与修复。石华波整合版本,陈炳珲核对需求与验收条件。跨模块问题按同一份输入和运行记录讨论,避免各自修改不同的样例。
| 成员 | 本轮测试职责 | 主要产出 |
|---|---|---|
| 石华波 | 战斗、波次、无尽、伤害、集成与导出 | 可运行集成版、难度参数、Windows启动记录 |
| 陈炳珲 | 需求与内容覆盖、记录一致性 | 七图70波矩阵、任务验收、问题与提交索引 |
| 朱宇濠 | 升级、装备、持久化与结算 | 真实SQLite往返、交易回滚、成长继承与续玩用例 |
| 游诗可 | 页面、输入、碰撞与显示反馈 | 两分辨率画面、交互与键位、角色技能UI检查 |
| 郭锦蓉 | 怪物、首领、预警与资源 | 行为及阶段验证、预警几何和七图资源复核 |
| 吴江彬 | 认证、快照、网络和设备同步 | 普通/无尽往返、版本冲突、备份与弱网验证 |
| 詹铖煜 | 自动化、长流程、性能与交付核对 | 分项报告、固定策略样本、最终人工结论和证据包 |
| 日次 | 与开发并行的测试内容 | 当日形成的检查基础 |
|---|---|---|
| Day1 | 工程启动、数据库建表、首图与物理 | 27项Python、10项引擎检查,首图实际画面 |
| Day2 | 移动暂停、属性、认证和仓储 | 基础输入输出、认证与存储的回归入口 |
| Day3 | 升级、超市、六槽、合成与快照 | 交易完整状态、失败恢复、原生SQLite与Python往返 |
| Day4 | 前三图十波、首领、高度、科技与云页面 | 正式通关、场景约束、准备与战斗检查点 |
| Day5 | 后四图、七首领、无尽与下载恢复 | 10/11、20/21边界,普通与无尽双向恢复 |
| Day6 | 全武器道具、怪物差异、演示模式与公网 | 内容行为、连续游玩、网络、密集场景和候选包 |
| Day7 | 集成修复、平衡寻路、技能、UI与音频 | 当前专项、80张最终画面、Windows包和13项人工验收 |
三、测试环境、工具与实际运用
3.1 工具选择
| 层次 | 使用工具 | 选择原因与实际用法 |
|---|---|---|
| 游戏机制 | Godot 4.7.2 stable、SceneTree脚本 | 直接加载实际模块与主场景,使用固定输入检查状态、伤害和事件 |
| 服务与存储 | Python unittest、FastAPI测试客户端、SQLite | 调用服务及仓储,执行真实SQL,核对外键、事务、账号和版本约束 |
| 网络集成 | 独立Godot实例与HTTP/HTTPS服务 | 让原生客户端实际上传、下载、恢复和处理连接失败 |
| 自动游玩 | 固定种子机器人、真实游戏更新循环 | 连续执行移动、升级、购买和战斗,记录到达波次与死亡位置 |
| 视觉检查 | 隐藏窗口实渲染与图片复核 | 在1280×720和1920×1080下检查文字、图标、托盘与遮挡 |
| 音频 | 素材清单、原生播放器、实际混音录音 | 验证事件播放、循环、音量、静音、场景切换和信号峰值 |
| 发布验证 | 独立Windows导出包 | 在完整解压目录运行exe,核对pck、SQLite扩展和资源是否可用 |
客户端采用GDScript,测试直接执行游戏代码;云服务与SQL检查使用Python。这样一套入口既能验证模块,也能进入实际数据库、网络和导出环境,方便成员在集成时复现相同问题。
3.2 测试入口与结果保存
在仓库根目录,将 godot 替换为本机Godot控制台程序后,可分别运行以下专项。运行结果按脚本输出的JSON和日志保存,再核对退出码、检查项和失败条件。
# 寻路:独立执行,不启动完整长流程
python Tests/run_navigation.py --godot godot --output 验证输出/寻路
# 七角色技能
godot --headless --path Client --script res://tests/role_skills_smoke.gd -- --output=验证输出/技能.json
# 音频事件、音量及设置
godot --headless --path Client --script res://tests/audio_smoke.gd -- --output=验证输出/音频.json
Tests/run_day7.py 串联既有回归和发布阶段检查,Tests/run_balance.py 加入曲线验证,balance_benchmark.gd 输出角色对照样本。完整入口还包含固定策略自动通关断言;当前MAP03失败样本在该入口中会继续被报告。
原始记录在仓库的 Documents/AlphaSprint/evidence/、Documents/Balance/ 和 Documents/Navigation/ 中。随笔附有测试用例与结果、可整理的CSV用例表及各专项JSON,方便答辩时逐项追溯。
四、用例如何设计
从状态转换入手。 购买不是一个按钮事件,而是“验证余额—构造新装备状态—事务保存—更新界面”的过程。测试同时观察余额、材料、槽位和候选,保存后重新读取数据库,确认内存与存储描述的是同一份结果。
围绕边界设置输入。 装备检查六槽满与未满,经济检查余额足够与不足,场景检查扩散距离内外、台阶两侧和不同身体半径。无尽重点覆盖第10波之后进入第11波、第20波之后进入第21波的转换。
对规则使用固定条件。 角色技能检查有效击杀来源、负属性、零伤害、致命伤害、独立冷却和暂停时间。平衡对照固定角色、地图、种子及自动策略,修改前后使用同样的输入,比较变化发生在什么波次。
把界面操作接到真实业务。 六槽满后实际购买并管理背包,合成后继续查看成长参数,再保存退出恢复。界面判断除了能否显示,也检查点击结果、信息更新和保存位置,避免界面与游戏状态分离。
4.1 主要功能用例
| 编号 | 场景 | 操作与输入 | 预期结果 | 结果 | 证据范围 |
|---|---|---|---|---|---|
| T01 | 移动与焦点 | 使用WASD和点地移动;打开并关闭操作界面。 | 移动输入生效,UI操作结束后仍能正常移动。 | 通过 | 输入与交互回归 |
| T02 | 暂停与时间 | 在移动、弹体和持续伤害运行时暂停,再恢复。 | 暂停期间战斗时间、再生、冷却与弹体停止;恢复后继续。 | 通过 | 暂停和对局流程回归 |
| T03 | 统一伤害预览 | 比较武器基础值、角色加成、全伤害和最终命中。 | 详情与实战使用相同参数入口,结果一致。 | 通过 | 伤害与装备预览回归 |
| T04 | 暴击与化学 | 分别触发直接伤害暴击和化学持续结算。 | 武器暴伤与角色加算;化学持续伤害不暴击。 | 通过 | 属性和化学专项 |
| T05 | 化学扩散 | 在扩散距离内外安排目标,检查层数和到期时间。 | 每次传播一层,遵守层数上限,继承来源层到期时间。 | 通过 | 角色与持续效果回归 |
| T06 | 最大生命提升 | 在非满血状态提高最大生命。 | 最大生命与当前生命同时增加相同数值。 | 通过 | 属性成长回归 |
| T07 | 连续升级 | 积累多次升级后结束波次。 | 先逐次完成全部升级,再进入超市,剩余次数准确。 | 通过 | 准备阶段回归 |
| T08 | 余额与刷新 | 在足额和不足额学分下购买、刷新。 | 成功扣费并保存;不足额提示,已有状态保持。 | 通过 | 交易回归 |
| T09 | 六槽与背包 | 装备六把后继续购买,再替换或卸下。 | 新增武器进入背包,只有上阵武器参与攻击。 | 通过 | 装备回归及M08 |
| T10 | 合成成长 | 将带成长值的同级武器合成,保存再继续。 | 两件材料变为高级实例,成长值相加并正确恢复。 | 通过 | 技能、交易及恢复回归 |
| T11 | 交易失败恢复 | 注入数据库写入失败,再重新读取准备状态。 | 余额、材料、槽位、候选和随机状态保持事务前的一致状态。 | 通过 | SQLite事务与回滚回归 |
| T12 | 双阶段保存 | 分别在战斗和准备阶段保存退出后继续。 | 战斗恢复当前波起点;准备保留已做选择和购买。 | 通过 | 检查点回归及M09 |
| T13 | 结算与解锁 | 通过首图并重复请求同一局结算。 | 角色和下一地图解锁,科研点、历史与记录只结算一次。 | 通过 | 存储结算与选择页回归 |
| T14 | 七图与无尽 | 检查70波配置与10/11、20/21阶段转换。 | 第十波派发正确首领;换图、阶段、购买与恢复状态一致。 | 通过 | 七图、无尽与快照回归 |
| T15 | 低矮、高大与高度 | 对花坛、垃圾桶和教室台阶分别进行移动与射击。 | 低矮挡移动、高大同时挡弹体;跨高度边界的子弹消失。 | 通过 | 场景和碰撞回归 |
| T16 | 不同体型寻路 | 让不同半径怪物与地面首领绕过障碍追击。 | 路径适合实体体型,连线可通行,窄缝不会造成穿墙。 | 通过 | 59项寻路专项 |
| T17 | 受阻与远程视线 | 移动目标或遮挡路径,让远程敌人失去射击视线。 | 受阻和停滞后重算;远程移动至可射击位置后恢复攻击。 | 通过 | 59项寻路专项 |
| T18 | 阶梯教室首领 | 使首领与玩家处于不同层,观察换层追击。 | 经楼梯换层,保持高度规则,换层状态能够结束。 | 通过 | 寻路和首领机制回归 |
| T19 | 预警与实际命中 | 逐个触发范围、冲锋与封线攻击,检查危险区域边缘。 | 预警和命中共用几何规则,轨迹、范围与安全通道对应。 | 通过 | 44项敌人与预警回归及M10 |
| T20 | 角色奖励与成长 | 核对bobo波后经验、笔锋来源及计算器当前余额。 | 经验每波发一次;有效击杀触发成长;持币加成随余额更新。 | 通过 | 38项技能专项 |
| T21 | 角色时间与反击 | 打光师静止连发后移动;检查惨叫冷却与闪避增伤恢复。 | 移动取消未发出的攻击;反击、增伤和检查点状态一致。 | 通过 | 38项技能及D7回归 |
| T22 | 账号与版本冲突 | 不同账号访问存档;两个客户端持不同版本上传。 | 账号数据隔离,陈旧版本覆盖被拒绝,确认后按所选方向同步。 | 通过 | 云接口、原生往返及M01—M05 |
| T23 | 弱网与设备设置 | 断网重试,并在另一设备下载快照。 | 本地继续可用;下载恢复游戏进度,接收设备的键位保持。 | 通过 | 人工M01—M05 |
| T24 | 资源与音频事件 | 读取素材清单,触发按钮、攻击、交易及静音设置。 | 资源可加载;交易成功后播放反馈;普通怪物受击保持静音。 | 通过 | UI与73项音频专项 |
| T25 | 音乐循环与切换 | 让原生播放器跨过曲尾,再进入战斗和返回主页。 | 循环不中断,选择页持续播放,进战淡出,返回淡入并续播。 | 通过 | 5项原生音乐检查 |
| T26 | 分辨率与独立运行 | 两种分辨率采集界面,在另一台设备启动完整解压包。 | 文字和按钮完整可用;无需Godot编辑器即可进入游戏。 | 通过 | 80张截图、导出记录及M11—M13 |
4.2 七首领的专项关注点
| 地图与首领 | 重点验证 |
|---|---|
| 博学苑·闹钟宿管 | 冲撞轨迹、扇形射击、三铃召唤与对应阶段变化 |
| 玫瑰园·暴走电饭煲 | 压力积累、技能释放、泄压窗口与压力条同步 |
| 风雨操场·杠铃教练 | 冲锋、砸地、体力消耗与喘息窗口 |
| 方镜桥·折纸龙舟 | 上下水域活动、跃龙门危险区域、换岸与安全空间 |
| 福友阁·莲灯魁首 | 灯座贴图、熄灯状态、技能范围和易伤窗口 |
| 东三·试卷审判官 | 点名区域、高度判断、楼梯换层与首领追击 |
| 晋江楼·终稿打印机 | 原稿、卡纸、封线间隙与阶段切换后的对象状态 |
五、执行结果与数据分析
5.1 分项结果
| 验证范围 | 结果 | 记录与解释 |
|---|---|---|
| Python服务、SQL与存储 | 104项通过 | 失败0、错误0、跳过0;33项SQL设计检查包含在该统计中。 |
| Godot功能与曲线回归 | 935项通过 | 平衡与寻路阶段保留的回归记录,覆盖既有机制和259项曲线检查。 |
| 怪物与首领寻路 | 59项通过 | 覆盖不同体型、七图通行、受阻重算、射击视线和楼梯换层。 |
| 七角色技能 | 38项通过 | 检查动态配置、触发来源、实际伤害、计时、成长和恢复。 |
| 角色平衡对照 | 56组前后对照 | 7角色×2张地图×2个种子×调整前后两版;中间迭代另有28组记录。 |
| 主页与角色UI | 27项通过 | 按钮图标、角色专用界面、技能展示与对齐检查。 |
| 音频专项 | 73项通过 | 66个事件与75个WAV变体,包含静音、音量、交易和攻击反馈。 |
| 原生音乐播放 | 5项通过 | 实际播放、跨循环点、选择页持续、进战淡出和返回续播。 |
| 最新固定策略自动游玩 | 8组中7组达到目标 | 六张普通地图通关、无尽达到30波;MAP03第10波CH06被首领击败。 |
| 人工验收 | 13项全部通过 | 2026年10月29日团队确认,覆盖真实设备、弱网与完整操作。 |
| 最终界面截图 | 80张 | 1280×720与1920×1080各40张,来自当前客户端实际渲染。 |
| Windows独立启动 | 通过 | Audio v3导出包退出码0,采集4帧,运行日志无ERROR。 |
以上按原始报告分别统计。935项Godot记录包含既有回归与259项曲线检查,其他专项和多轮游玩按各自范围列示,便于看清验证对象与版本。
5.2 自动游玩与角色对照
平衡对照覆盖7名角色、MAP01与MAP07、两个固定种子,调整前后各28组。中间迭代另有28组,用来观察参数方向。记录包括角色、地图、构筑、逐波状态和最终结果,重点比较启动速度、成长收益与后期压力。
调整后,bobo在四组样本中的通关由2次变为3次,像素晚八点平均到达波次由6.25变为7.75。铅笔侠的通关数提高,但平均到达波次下降;打光师通关数下降、平均波次略提高。这些结果提示团队结合具体构筑和操作路线分析,而不是只看一个平均值。
最新八组长流程中,六张普通地图完成通关,无尽运行到第30波;操场第10波的CH06机器人被首领击败,保留为后续对照样本。早期RC2的八组曾全部通过,当前随笔采用调整后的最新结果,人工完整操作则按单独清单记录。
5.3 路径与密集场景
寻路压力记录使用120个敌人。首次路径构建帧约78.449ms,后续600帧模拟耗时的第95百分位约2.458ms、最大约7.936ms。后续移动计算较稳定,首次建图的集中开销是下一轮优化重点,可考虑预热和分帧构建。
这些数值描述模拟层耗时。密集特效、弹体和渲染的整体体验另由场景游玩确认;M13人工验收结果正常。性能记录保留输入规模,后续调整时可以在相同条件下比较。
5.4 音频与独立包
最终音频包含66个事件、75个WAV及独立主页音乐。原生检查实际跨过循环点,并验证选择页持续播放、进入战斗淡出、返回主页淡入续播。7.1秒实际混音录音的峰值约0.186,削波样本为0。
Windows运行包从最终客户端导出,完整目录包含exe、pck与SQLite扩展。原生启动退出码为0,采集4帧且运行日志无ERROR;另一台未安装Godot的Windows设备已通过人工启动验收。操作与目录说明见Windows运行说明。
六、发现的问题与修复复验
6.1 地形卡住:从直线追击到共享路径
花坛、桌椅和楼梯让直线追击不断发生碰撞。修复时按实体半径建立共享AStar2D路径图,检查每段连线的连续通行,再平滑路径。目标移动、路线受阻或持续停滞会触发重算,远程怪物失去视线后寻找新的射击位置。
复验覆盖17种怪物、地面首领、七图不同体型、薄障碍、不可达窄门、分裂出生和楼梯换层。59项寻路专项通过,人工观察也确认首领与怪物能正常绕障追击。
6.2 打光师移动后继续连发
静止触发订书机连发后,角色开始移动,排队的后续攻击原先仍会发射。修复在实际移动时取消未发出的队列,并在新波次归零静止计时。测试分别检查移动前后、换波和保存恢复,确认停步条件与实际攻击一致。
6.3 成长与交易跨状态不一致
笔锋需要保留武器实例成长,合成后把两件材料成长相加;计算器需要在拾取、购买和出售后更新持币收益;bobo经验需要每波只发一次。这些规则进入统一配置和角色运行状态,测试通过实际击杀、交易和读档核对结果。
交易失败则通过真实写盘失败检查回滚。余额、材料、槽位、候选和随机状态一并保留,数据库重新打开后仍保持一致,避免只退还学分却留下其他变化。
6.4 预警、界面与音频反馈
范围与冲锋攻击采用共同几何描述生成预警和命中,便于校对边缘和轨迹。角色与障碍采用脚底碰撞和前后遮挡,子弹按高矮障碍与高度边界处理,视觉表现与移动、射击规则能够对应。
界面修正集中在属性行高、按钮内容居中、技能图标位置、详情分页、解锁与退出选项。音频经过实际反馈后改用短促操作声、合成受伤声和钢琴主页音乐,普通怪物受击静音,重要预警与交易结果更容易辨认。
七、最终人工验收与运行画面
2026年10月29日,团队确认13项人工测试全部完成、结果正常。人工验收从真实设备和完整操作出发,覆盖以下内容:
| 编号 | 人工验收内容 | 验收结果 |
|---|---|---|
| M01 | A设备上传普通整备进度,B设备下载 | 通过:地图、波次、余额、武器和升级选择一致,B设备键位保持。 |
| M02 | B继续游戏并上传,A下载新进度 | 通过:双向往返可继续,覆盖前备份保留。 |
| M03 | 持旧摘要覆盖新云版本 | 通过:显示版本变化并阻止静默覆盖。 |
| M04 | 无尽10波准备与11波起点同步 | 通过:阶段、地图与收入正确,不重复抽图。 |
| M05 | 断网后恢复网络重试 | 通过:本地进度完整,恢复后可正常同步。 |
| M06 | 教学关卡完整操作 | 通过:移动、自动攻击、升级和购买流程清楚。 |
| M07 | 七角色分别游玩 | 通过:技能限制、加成和显示一致,操作正常。 |
| M08 | 满槽购买、替换、出售和合成 | 通过:上阵与背包正确,成长和准备操作可恢复。 |
| M09 | 战斗保存、继续,再结算退出 | 通过:恢复波次起点,结束只结算一次科研点。 |
| M10 | 七首领预警、躲避和二阶段 | 通过:预警可辨识,命中、遮挡和机制表现正常。 |
| M11 | Windows 100%、125%、150%缩放与两分辨率 | 通过:文字、托盘和点击区域完整可用。 |
| M12 | 未安装Godot的另一台Windows设备启动 | 通过:完整解压包正常进入教学与正式挑战。 |
| M13 | 密集敌人、弹体和化学效果连续游玩 | 通过:暂停、保存和连续运行正常。 |





两种分辨率的80张画面由最终客户端实际渲染生成。云摘要与覆盖确认截图采用本地界面夹具,网络验证结果对应真实客户端往返及M01—M05人工验收。
八、AI技术员在测试中的作用
把机制说明变为可观察条件。 团队给出技能与交易规则后,AI协助整理触发来源、时间、状态与存档字段,形成边界输入和断言。七角色测试因此覆盖直接伤害、持续伤害、成长继承、静止计时与冷却,而不仅检查面板文字。
围绕失败记录定位问题。 寻路测试要求输出路径、体型、受阻线段和逐步位移;技能问题要求记录事件来源和前后状态。AI协助缩小问题范围,成员依据同一组结果核对修复,随后运行相应专项和集成回归。
提高重复验证效率。 AI协助制作固定种子自动玩家、采集最终截图、检查资源映射和实际混音。重复劳动交给脚本执行后,团队将更多时间用于观察构筑、躲避体验、页面可读性和不同设备上的实际操作。
实际协作中,清楚说明输入、期望和证据比笼统要求“检查整个游戏”更有效。AI生成的用例也需要核对规则含义,尤其是准备波次游标、击杀来源和跨层移动;修复后通过数据库、原生播放器与导出包继续验证。
九、测试体会、项目评述与下一步
本轮最直接的收获,是把测试提前后,很多问题能在集成之前找到共同语言。保存恢复明确了阶段含义,交易测试明确了事务边界,预警测试明确了可见范围与命中范围,角色专项则让技能描述、配置和实际触发相互对应。
七图与无尽的流程已贯通,人工13项验收全部通过,当前版本具备Alpha展示与体验条件。自动化主要规则检查通过,最新固定策略长流程保留7/8结果,团队继续跟踪操场首领样本、角色构筑和首次路径构建开销。
下一阶段将扩大种子、构筑路线和玩家样本,记录不同角色在各波次的伤害、资源和生存情况;性能优化沿用固定压力输入;云同步继续积累真实设备使用记录。新增机制和修改参数时,优先扩展现有专项,再进入完整回归。
测试资料入口
| 资料 | 入口与内容 |
|---|---|
| 完整业务用例 | 26个测试场景与结果 · CSV用例表 |
| 最终人工验收 | 13项人工结果 |
| 技能与平衡 | 原始汇总 |
| 寻路 | 原始汇总 |
| 长流程自动游玩 | 逐轮记录 |
| 音频与播放器 | 73项音频 · 5项原生播放 · 混音信号 |
| UI与独立包 | UI专项 · Windows启动 |
| 项目源码 | 华为云master,客户端位于Client,服务位于Server,自动化入口位于Tests |
相关推荐
浅谈Alpha和Beta测试
大型通用软件,在正式发布前,通常需要执行Alpha和Beta测试,目的是从实际终端用户的使用角度,对软件的功能和性能进行测试,以发现可能只有最终用户才能发现的错误。 Alpha 测试。一般来说 alphatest 测试是在公司内部组织进行的面向于部分职工的,自愿参与的产品试用。其主要目的就是以最终用户的视角去发现产品的设计缺陷和功能的不足,发现问题后,测试者可以提交BUG(硬件,软件,结构,外观方面) 给开发部门和质量部门以确保产品在最终上市前达到比较理想的状态。此测试在正规的手机研发公司和游戏开发公司中有着较为广泛的开展,也是新产品引入流程中重要的一环。 Alpha测试是由一个用户在
游戏测试的主线流程
在游戏测试的各个阶段,测试人员都要及时记录和整理发现的问题,与开发人员密切沟通协作,推动问题的解决。同时,要对测试结果进行总结和分析,为游戏的优化和改进提供依据,以确保游戏最终能够以高质量的状态发布到市场上。
alpha测试和beta测试Gamma测试的区别是什么?
前言 在产品项目的最后推进过程中,会经过一系列的测试来判断以及优化产品,在测试中使产品的属性特征最优化,最终达到吸引更多客户的目的;本文作者分享了三种软件测试的主流方式,我们一起来了解一下。 在产品概念阶段,开展“电梯测试”是为了确定定位策略,将产品特征转化成显著的客户利益;在产品设计阶段,只有产品模型,测试目的是如果使产品的属性特征最优化,从而更吸引客户。 当产品最终完成但还没有引入市场时,实施产品测试是为了控制产品质量,维持产品生命。在产品正式上市前进行小范围的市场测试,目的在于识别竞争...
关于α和β测试以及验收测试
关于α和β测试以及验收测试的相关解释,以及它们各自特点
软件项目验收测试流程.rar
软件项目验收测试流程!!!!!


