自动化测试思路

自动化测试的目标，是确认用户实际使用的功能可用。

很多 AI 生成的项目，AI 已经测过，为什么第一次真正上手时，功能仍然大多不可用？因为 AI 更偏向测试底层接口。按钮能不能点、弹窗能不能关闭、页面切换后状态是否正常，这些都可能没有被覆盖。底层接口通过了，交互层却成了盲盒。

一套有效的自动化测试策略，至少需要满足两点：

第一，模拟用户的真实操作。《杀戮尖塔 2》没有给自动化测试机器人 API 或额外权限。它只能识别窗口中的可交互组件，模拟玩家真实操作。测试必须经过用户实际路径。例如，如果让机器人失败后继续游戏，测试效率提高了，但整个失败流程也被跳过了。放到产品中一样。支付接口能用，不代表用户点击按钮，页面跳转、状态加载、支付取消、失败等过程正常。

但仅仅模拟真实操作还不够。

第二，不预设固定流程。用户不会一直按照产品设计者设想的顺序操作。他们可能中途返回、重复点击、跳过步骤、停留很久，也可能在流程完成前关闭页面。如果自动化测试只执行几条固定脚本，它验证的只是预设路径，而不是产品面对真实用户时的稳定性。因此，《杀戮尖塔 2》的测试机器人不按照固定策略出牌，在可行操作中随机选择，覆盖尽可

产品中最危险的问题，往往不在已经被反复测试的主流程，而是那些设计者没有想到、也没被测试覆盖，用户却真实会走的路径。

所以，一套完整可行的自动化测试架构，需要同时满足两个条件：从用户真实可见的交互入口触发，并通过探索性的测试策略覆盖尽可能多的操作组合。真实操作保证用户功能正常，探索策略保证测试不止停留在开发者设想的路径上。