ERROR401—— Alpha阶段测试随笔

目录

• 一、测试思路与工作安排
• 二、测试工具与环境
• 三、测试用例文档
• 四、自动化执行与实际结果
• 五、问题定位与回归
• 六、AI技术员的作用
• 七、测试体会与项目评述

一、测试思路与工作安排

结合《构建之法》第2章关于个人开发质量和测试意识、第13章关于软件测试的学习要求，我们将测试落实为可重复执行、结果可核查的工程活动。这里说明本项目的实践理解，不摘录教材，也不把章节阅读次数作为成果。

我们把“预期是什么”和“程序实际做了什么”分别记录：先根据规则定义输入与预期，再观察实际输出。开发者自测不能取代独立复核，一次演示正常也不能替代边界和回归检查。测试与开发并行，接口或状态入口发生变化时，及时复查相关模块，而不是等全部功能写完后才集中找问题。

本轮代码已基本具备运行能力，因此测试重点是验证已有功能、识别版本差异、保存证据和控制发布风险。没有复现的问题不强行登记成缺陷，没有执行的用例不填写“通过”。

职责安排：111汇总测试与缺陷；129组织验收和核对材料；130负责武器规则说明及复测；110负责AI/地图；127负责流程；132负责统计对账；112负责集成和发布依赖；116负责UI与输入。模块成员解释预期行为，测试成员检查实际行为，129据证据决定任务是否收口。职责安排不代替个人签名或真实提交记录。

二、测试工具与环境

引擎配置记录为2022.3.62t16，项目同时声明团结引擎1.10.4。本次为当前Windows本机运行；独立设备型号、系统版本和跨设备兼容性不能从现有日志推导，需在外部验收时记录。

本次运行包程序集SHA-256：d4598ae531ebce21299a8fcafad3d2e5cfffe710feb980d0e4390469c9ade99a。源码HEAD为5d18bc16751c25fb511de8f3d2a9e28c0fdddbbd；当时存在40条已跟踪修改和21条未跟踪记录，不能把该HEAD单独当作运行包的完整源码身份。

三、测试用例文档

用例统一记录编号、前置条件、操作/输入、预期、实际、版本、证据和复核人。下列编号服务于本文；不能与每日清单中的T编号机械等同。

断言是脚本中的具体检查点，一个用例可能展开成很多断言。不能以断言条数冒充独立人工用例数量。

四、自动化执行与实际结果

以下检查均于2026年10月27日执行，10月29日汇总；没有把旧报告重新标成今天的实测。

成功的三组检查共1260条PASS断言。首次中断前的186条不重复加入成功统计；没有以“1260/1260”计算项目整体通过率，也未测量代码覆盖率、分支覆盖率或全项目缺陷率。

重现入口如下。每组单独运行，输出目录使用空目录；会修改并恢复用户设置的检查须具备正常配置读写权限。UI截图检查需要图形环境，不能随意加-batchmode或-nographics。

CampusStrike.exe -screen-fullscreen 0 -v181-ui-review "<独立UI输出目录>" -logFile "<UI日志路径>"
CampusStrike.exe -screen-fullscreen 0 -v18-network-optimization-review "<独立网络输出目录>" -logFile "<网络日志路径>"
CampusStrike.exe -screen-fullscreen 0 -v18-world-optimization-review "<独立世界输出目录>" -logFile "<世界日志路径>"

原始成果入口：

• 本次运行汇总JSON
  
  本次运行汇总.json 112.74K
• UI复测原始记录
  
  presentation.success 80.14K
• 首次失败记录
  
  presentation.failure 14.33K
• 网络历史回归记录
  
  network-optimization.success 772B
• 世界交互回归记录
  
  world-optimization.success 3.07K
• 发布文件逐项CSV
  
  发布文件逐项核对.csv 39.47K

本次地图0暂停检查

本次地图1结算检查

五、问题定位与回归

配置写入异常。 首次运行在设置昵称写入时出现PlayerPrefsException: Could not store preference value，调用链经过设置提交和页面构建。我们保存失败日志，在正常权限环境复测相同入口，完成1204条断言。当前结果支持权限环境相关判断；未修改游戏代码，也不据此断言所有写入失败场景已得到产品级处理。R01仍应补测。

报告身份不一致。 原归档UI报告有1187条PASS，与当前验收清单声明不一致。本次真实复测产生1204条PASS，新报告SHA-256为80b65051d792164a7fb717146706d5362721927516f29ddf22f2cc8b126b9445，与验收清单一致。我们保留旧记录，交付引用新记录，避免直接改动哈希或报告文字制造一致。

构建入口差异。 默认Build Settings为3个场景，专用v18.1构建入口列5个场景。源场景存在，本次已实际进入两张游戏地图，不能仅凭默认配置断言运行包缺地图；后续构建应使用明确入口并复跑地图检查。

六、AI技术员的作用

本次使用Codex分析每日执行清单、源码与日志，识别项目已有的可选运行检查入口，协助执行自动检查、校验文件、生成汇总和报告。项目运行中的AI敌人与辅助开发的AI技术员是不同对象，本文讨论的是后者。

AI减少了重复整理和交叉核对的人工操作，但没有记录人工对照工时，不能编造“效率提升百分比”。AI同样可能误读覆盖范围，需要人工审查预期、脚本及结论。界面和世界检查入口禁用战术在线顾问，本次没有主动发起收费模型服务调用。

七、测试体会与项目评述

第一，测试首先要保证身份一致。程序集、压缩包、报告都需要能对应同一个候选版本；程序能运行不意味着报告可以沿用。

第二，自动化适合重复、边界明确的检查。时间窗、姿态恢复、拾取距离与UI边界能稳定形成断言；自然对局体验、复杂AI行为和外部设备适配仍需要人工观察。只增加断言数，不能自动提高测试充分性。

第三，失败输出也有价值。首次配置异常帮助我们发现执行环境对结论的影响；保留失败和复测比只展示成功截图更利于复现。

当前评述：本机UI、网络历史组件、世界交互及文件一致性已有可核验结果；整体质量仍应定位为有证据支持的候选版本。尚未完整证明自然胜负流程、连续三次重开、当前包AI专项、隔离新用户及另一设备验收，因此不能宣称全部功能通过或无缺陷。下一阶段优先补齐这些高风险覆盖，再考虑扩展自动化框架和持续集成。