为什么 E2E 自动化测试还是没办法（完全）解决软件测试上的问题

最近讨论到如何替产品添加自动化测试的话题：现在 AI 很厉害！产生浏览器脚本精准又快速，应该马上就能替代手动测试，每个情境都测过一次吧？

执行 E2E（End to End）测试有无法忽视的强大魅力：

• 黑箱测试易于执行
• 产生最高的信心度
• 一次测验整体代码
• AI 产固定测试脚本成熟稳定又高效

但真实环境实际要面对的考验是：

• 不清楚的规格：如果连系统的预期行为都不明朗，要如何测试？
• 副作用：测试操作会影响测试环境
• 测试环境：全面真实的环境构建缓慢
• 不稳定：程序有更多理由改变而破坏测试
• ⋯⋯

举例来说一个简单的删除角色功能：「点删除按钮，角色消失」，背后可能代表什么？

功能: 删除角色

场景: 正确删除
假如：已登入的管理员
当：删除角色
那么：角色正确删除

场景: 缺少参数
假如：已登入的管理员
当：删除角色（缺少必要参数）
那么：提示参数错误

场景: 没有管理员权限
假如：已登入的非管理员使用者
当：删除角色
那么：提示权限不足错误

场景: 删除自己
假如：已登入的管理员
当：删除自己的角色
那么：提示不可删除自己角色错误

场景: 删除不存在的角色
假如：已登入的管理员
当：删除不存在角色
那么：提示角色不存在错误

场景: 删除主管理员
假如：已登入的管理员
当：删除主管理员
那么：提示不可删除主管理员错误

1. 看似简单的功能也能有多种前提、坏掉的方式、坏掉的地方，AI 不会理解你的商业逻辑应该如何运作，陈旧系统大多都没有具体规格。
2. 6 个场景意味着一个功能就需要全面重启整个服务 6 次，如果不想？那么测试副作用将会不可避免地交叉影响造成虚假的信心和假警报。
3. 每个测试都是需要维护才能生效的资产，否则就是累赘，E2E 测试是最容易被破坏，且难以维护的测试形式。

AI 解决了「产自动化测试脚本」的问题，但那只是其中一个瓶颈，要达成有效的测试更多是需要：

• 理解产品运作，且能够有序定义规格的能力
• 能够善用测试种类，用合适的方式与工具导入测试的能力（静态测试、单元测试、组件测试、集成测试、E2E 测试、Mock Data、CI 反馈构建、架构分层⋯⋯）