从一个具体的结果开始#
定义预期的变化:最大船体,价格,宏,按或实物. 分析XML和飞行正确装备的船是不同的结果.
单个玩家验证序列#
检查扩展结构,ID和依赖性;XML语法和方案;进口,补丁和运行时间日志;实际游戏值或对象;UI点击,关闭,更新和重新开放;然后在完全重新启动后相同的事实. 没有任何操作程序. 研究发现,一个方案接受的构建,但MD解析器拒绝了.
区分场景#
对于房产,检查有效值和相矛盾的补丁. 对于船只,检查注册,外观,设备连接,飞行和可用性. 对于设置,检查重复重置的持续性和缺失. 新的和保存的物体可能具有不同的生命周期.
重复昂贵的测试,有理由#
按标签更改需要影响的UI检查. 需要相关的游戏场景进行加载或连续化变化. 首先收集完整的事实,然后比较所有差异. 一艘船不能证明每一个船体类. 记录确切的条件和未经测试的情况;通过手动修复测试设备,不要掩盖故障. 看到 树木, MD 持久化 和 互动性.