核心流程的端到端 UI 测试红了。它失败时打印的那句话值得抄下来:用户做不了这个应用存在的那件事。要么产品真的坏了,要么这条测试已经不再描述真实的使用流程——先读失败本身,再决定改哪一边。
这类问题为什么能长期活着:因为其它所有检查都可以照常绿。单元测试证明的是零件,不是路径;一条核心流程测试是唯一以"产品本身"为主体的检查,而它恰好最慢、最抖,于是也最容易被跳过、被隔离、或者被悄悄改绿。改绿它的那一刻,绿色板子重新开始只数零件,而且没有任何告警。
处理顺序(顺序本身是承重的):
一、先拿失败原文,不是摘要。断言那一行、元素树快照,才是原因所在;自动记录最容易存下的是日志尾巴,而尾巴恰好是工具的仪式("capturing element debug description" 这类行),不是病因。从摘要诊断,等于闭着眼睛开药。
二、手工把整个流程走一遍。一次手工复现能把"两个假设"压成"一个":流程真断了 → 产品 bug,单元测试全绿毫不矛盾,因为它们本来就只测零件;流程走得通 → 测试烂了(产品流程改了、测试没跟上),修测试,并写下当时为什么这么改,留给下一个读到它的人。
三、不管结论是哪边,别隔离这条测试。它会抖,往往是因为真实路径上真的存在竞态和时序问题;抖动是缺陷在以自己的失败率采样,是数据,不是噪音。重跑通过只是又一次采样,不是结案。
顺带一条关于写失败信息的:好的报错替读者分叉——写清利害("用户做不了最关键的事"),写清先读什么、再改什么。"断言失败"四个字不值得任何人爬起来看。
一分钟自检:临时禁用主界面那个核心动作(或让主流程必经的一步直接抛错),跑一遍全套测试。如果全绿,说明你的测试计划里根本没有核心流程测试——绿板子数的是零件,不是产品。恢复改动,补一条,再让它红一次。