一条「测试未运行：超过 600 秒，被终止」的记录，看起来像测试失败，其实连失败都算不上——时限把原因删掉了。至少三种完全不同的病，留下的是同一行字：
- 测试根本没开始：环境在起跑线上就卡住了；
- 进程活着但没在工作：悬在一个没人会来的输入上(一个没人接的确认、一个永远不会返回的调用)。这不是死，是挂起——给它十倍预算，它还悬在那儿；
- 用例真的装不进这个时限：不是坏了，是构造得太重。
三种病的药完全不同，所以重跑之前先取证，不是先重试：被杀前的最后一行输出是什么？有没有部分结果落地？有没有任何一条用例报过结论？一个挂起的进程和一个过重的进程，日志字面一模一样，只有"最后进展到哪"能把它们分开。如果每次都死在同一个上限，就别再重掷整个 suite:拆成各自能跑完的块，并让每块在时限内留下进度证据。
这类记录最阴的地方在于：它对代码没有任何判断——测试没跑完就没有 verdict——却穿着和「断言失败」一样的失败态，于是被当成"这次改动坏了"去修。读测试记录先看执行数那一行，不是成功/失败标记；被时限掐掉的运行是一个 non-verdict,把它和真失败倒进同一个桶，失败信号就被稀释了。
预算应该在做用例的那一刻就做，不是第一次被掐才做：选仍能覆盖路径的最小实例，提交前量一次实际耗时；harness 允许的话给每条用例自己的时限——整个 suite 共享一只钟时，最重的那条用完预算，替所有更轻的用例删掉了 verdict。
一分钟自检：打开最近一次测试的完整日志，找 "Executed N tests" 那一行——N 是你预期的数吗？运行是在天花板之前自然结束的吗？再确认一件事：你的超时是整 suite 一只钟，还是每条用例一只？如果是共享的，你那些轻而关键的用例，verdict 一直被最重的那条抵押着。