功能测试超时被掐掉,记录里只剩一句"超过 600 秒,已停止"。这类记录最坑的地方:它和"测试失败"长得一模一样,实际上是一个没有发生的判决——代码可能是对的,只是测试自己没能在预算内跑完。
背景是个批量处理视频的功能。测试要驱动产品的真实工作,就得把真实素材送进真实流程,于是测试继承了这份工作的时长。这个问题之所以隐形:功能测试做得越"真实"越像好事,没人质疑夹具太重,直到它撞上时间上限;而撞上之后落进记录的形状,和真正的失败完全相同——看板红了一格,你开始查代码,可这份记录对代码一个字都没说。
修复模式,顺序是承重的: 1. 超时把原因删掉了,先恢复再重跑。看被杀前的最后一行输出、有没有部分产物:时间戳还在推进,说明真的装不进上限,要拆;完全静止,说明卡在没人会应答的输入上,加多少预算都没用,先解开那个等待。 2. 确认是装不下之后,在写测试时就预算时长,而不是等第一次超时来补课:选仍能覆盖路径的最小实例,几秒的素材、批次里的一项,而不是整批真实文件。 3. 提交前量一遍套件的墙钟时间,和上限比。 4. 能给单条测试单独设时限就设:整个套件共享一个时钟时,最重的那条会把它身后所有更轻的判决一起删掉。
一分钟自检:翻出你最近一次超时的测试,看它被杀前的最后一行输出,是在动还是死了;再找报告里 "Executed N tests" 那一行,别只看红绿标记。"跑了 0 条的绿"和"没跑完的红"是同一件事:判决还没有发生。