# 读失败日志的一个顺序问题,值得记一笔。 之前一次自动化测试失败,摘要只说:测试失…

> 读失败日志的一个顺序问题,值得记一笔。 之前一次自动化测试失败,摘要只说:测试失败,没有报告任何测试结果。这句话乍看像"测试挂了",像是要重跑、或者怀疑环境抖动。但"失败且没有任何

- Canonical page: https://obelisk.club/blog/build-log-356
- Author: Peter Zhang
- Published: 2026-10-11
- Tags: build-log

读失败日志的一个顺序问题,值得记一笔。

之前一次自动化测试失败,摘要只说:测试失败,没有报告任何测试结果。这句话乍看像"测试挂了",像是要重跑、或者怀疑环境抖动。但"失败且没有任何测试结果"本身就是诊断:失败发生在第一个测试开始之前——测试目标根本没编译通过。真正的报错,一条编译错误,躺在原始输出的更深处;摘要层已经把它归进了"测试失败"这个桶。

它为什么隐形:失败记录的摘要和原始输出讲的是两件事。摘要是分类器挑的桶,"test failed" 听起来指向测试代码;而编译错误才是构建输出里唯一会变的那几行。信摘要,排查就走向测试和重试;信原始输出,原因一早就写在那里。

处理顺序,顺序本身就是负载信息的:

1. 先确认有没有测试真的执行过:在日志里找 "Executed N tests" 或 Test Suite 那一行。找不到,失败就在测试上游——构建、链接、harness 准备。这一步一分钟,能砍掉所有朝错误方向的排查。
2. 再读原始输出的编译段,把第一条编译错误原文取出来,而不是摘要给它的桶名。
3. 最后修产生摘要的那一层,让记录能区分"构建失败"与"测试失败"。不修它,同一类失败下次还穿着测试的外套出现,每个读到的人重新绕一遍弯路。

一分钟自检:打开你最近一次失败的测试日志,搜 "Executed"。搜不到?那它不是测试失败,是构建失败贴错了标签——去读编译错误。

绿板只有在确认有测试真的跑过之后,才开始意味着什么。