UEFI裸金属自检工具：21项测试一键定位硬件故障

机房那台服务器又起不来了。BMC 上能看到机器通电、风扇狂转，但过了 UEFI 自检就停住不动，屏幕显示 0x99 这类不知所云的 POST 码。System Event Log 里只躺着一条“Corrected Machine Check”的记录，再没有其他信息。操作系统进不去，常规日志抓不到，整台机器就像一块会亮灯的铁疙瘩。这种状态在运维圈子里叫“裸金属装死”——硬件就在那儿，但你拿它没有任何办法。很多人第一反应是拿内存条挨根换、拔显卡、擦金手指，过程基本靠玄学。这篇博文要聊的就是我基于 UEFI 自己写的一个整机自检工具，21 项测试、全程可视化、一键出报告，专门用来应对裸金属硬件故障排查这种场景。它在操作系统之下运行，不受系统崩溃影响，能在最早阶段告诉你这台机器到底是谁在“闹脾气”。这篇文章既讲设计思路、也讲开发踩坑，适合运维工程师、服务器管理员、硬件测试相关从业者参考。

1. 裸金属机器“装死不说话”时，我们到底缺什么

1.1 硬件故障排查的常见困局

先梳理一下裸金属环境下，硬件出了问题之后我们通常面临什么。

第一道坎是进不去系统。系统启动到一半卡住、循环重启、或者直接黑屏，此时操作系统层面的检测工具全部失效。你无法运行 stress 工具、无法看系统日志、连 dmesg 都敲不了。

第二道坎是 BMC/IPMI 信息有限。带外管理能给出传感器读数、SEL 日志，但很多故障并不会产生带外告警。比如某条 PCIe 链路训练失败，或者某个 DIMM 槽位上的内存控制器报了可纠正错误，SEL 里往往只是“threshold exceeded”之类没营养的记录。

第三道坎是诊断卡越来越没用。传统的 POST 卡现在确实还能用，但 UEFI 时代的 POST code 大量被固件内部消化，板卡上的两位数码管能显示的信息越来越少。

这三种情况凑在一起，整个排查过程就变成了：拔插、替换、重新开机、看结果，运气好是内存问题，运气不好折腾几个小时还是一头雾水。

1.2 UEFI 这一层的独特优势

UEFI（Unified Extensible Firmware Interface）是操作系统启动前的固件环境，它天然躲开了上述困境。原因不复杂：

• 运行在 CPU 实模式或保护模式/长模式早期，最基本的 x86/ARM 指令集已经可用。
• 不依赖硬盘上的操作系统，因此系统崩溃、引导分区损坏都不影响自检工具加载。
• 可以调用固件内置的协议，比如 Graphics Output Protocol、Block I/O Protocol、Simple Network Protocol，直接访问显示、磁盘、网卡等硬件。
• 绝大多数主板固件自带 UEFI Shell，或至少支持从 FAT32 分区引导 .efi 应用。

很多人对 UEFI 的理解停留在“设置界面”或者“Windows 11 强制要求的引导模式”，但 UEFI 本身是一个完整的运行时环境，不仅能加载引导管理器，也能跑独立的诊断程序。我选择在这一层做自检工具，就是看中了它的“开机即用、不依赖操作系统、直接面对硬件最底层”这三条特性。

对比传统工具链，也很直观：DOS 下的诊断工具在现代平台上几乎找不到合适的驱动，而且很多服务器已经不再兼容 Legacy MBR 启动；Memtest86 这类工具覆盖面太窄，只测内存；专业的裸金属诊断工具（比如商用 OOB 诊断平台）价格不低且绑定厂商硬件。所以与其受制于这些限制，不如直接在 UEFI 环境里做一个可控的自检工具。

1.3 工具定位：不是压测，而是“排队排除”

讲清楚边界很重要：这个工具不是用来替代 Prime95、FurMark 这种长时间高负载压测的。它的目标是做“分级排查”——在硬件故障出现的早期，快速定位可疑组件，缩小范围。相当于你先做一个全身体检，确认哪个器官指标异常，再去做针对性的深度检测。

基于这个定位，我把测试项设计成 21 项，覆盖 CPU、内存、存储、网络、外设/系统五类。每一项都有明确的判定标准，结果只有 PASS/FAIL/WARN 三态，避免过度解读。下面我会展开每项测试的设计逻辑。

2. 21 项测试到底测什么：一份有分工的硬件体检清单

2.1 五类测试的划分与优先级

优先级的原则是“由内向外、先基础后复杂”。CPU 和内存处于最高优先级，因为这两个部件一旦出问题，其他测试根本无法稳定运行。其次是存储，因为存储故障往往导致系统无法引导，是“进不去系统”的主要来源。网络和外设排最后，这类故障的影响相对局部，不太会让整机完全瘫痪。

19. 21 项的选题也有讲究，不能随便凑数。每一项都要在 UEFI 环境下可判定、可复现、不依赖特定厂商工具。比如 CPU 温度这一项，如果没有 ACPI 表或 PECI 接口，宁可标记 SKIP 也不能硬报 FAIL，否则会产生大量误报。

2.2 CPU 与内存测试：不是跑分，而是可判定验证

CPU 部分的第一件事是识别。通过 CPUID 指令可以拿到厂商、家族、型号、步进等信息，还能查询缓存大小、支持的指令集等特性。举个例子，CPUID 叶子 0 返回厂商字符串，叶子 1 返回 Family/Model/Stepping，叶子 4 返回缓存拓扑。有了这些基础信息，至少能确认固件对 CPU 的识别是正常的，不会出现“明明是 E5-2680 v4，系统里却认成 Unknown CPU”的情况。

核心枚举需要借助 EFI_MP_SERVICES_PROTOCOL。这个协议能让我们查询当前逻辑处理器数量，以及每个处理器的运行状态。多核 CPU 最常见的故障是某些核心无法被启动或很快报 MCE，通过 MP 服务协议做一轮“谁在线、谁缺席”的检查，能快速发现核心被禁用或掉线的问题。

缓存测试这里很多人会忽略一个前提：在 UEFI 环境下，Cache 通常是开启的，如果没有做 Cache 一致性处理，单纯往一段内存写数据再读回来，读到的可能只是 Cache 里的旧值，测试结果没有任何意义。所以我的实现思路是：先用 GetMemoryMap 获取内存映射表，过滤出可用的常规内存区段，再对这些区域执行 Write-Back 模式的读写校验，同时从 Cache 参数中识别 L1/L2/L3 大小，对 Cache 本身做命中率相关的间接验证。严格来说，这算不上对 Cache 硬件的深度压力测试，但足以在系统层面发现明显的缓存异常。

内存部分实现的是传统但有效的测试模式：

1. 内存控制器识别：读取 SMBIOS Type 17 表，确认每个 DIMM 槽位的存在与否、容量、频率、厂商。
2. 基础读写测试：对每个可用的内存区域写入 0x55、0xAA、0x00、0xFF 这种特征 pattern，再读回比对。
3. 地址线测试：Walking 1s 模式，检查地址线的短路或断线问题。实现方式是对 0x01、0x02、0x04……这种逐个翻倍的地址值写入标记数据，再验证能否正确读回，一旦地址线粘连，特定地址的数据会互相覆盖。
4. 压力循环：在基础读写没问题之后做多轮全量 pattern 循环，捕捉偶发的刷新错误或 bit flip。

这里必须提一个容易踩的坑：某些区域（比如 ACPI Reclaim Memory、MMIO 映射区）如果被普通读写测试覆盖到，可能直接导致系统行为异常。我在工具里做的事情是读取 UEFI 的内存属性表，将所有非 EfiConventionalMemory 的区域全部跳过。这是在开发初期被单独编写内存测试时付出的代价——当时不懂过滤，一个简单的全地址遍历直接让一台实验室服务器在测试中途黑屏。

2.3 存储、网络与外围设备的检测思路

存储部分挂载在 Block I/O Protocol 之上。UEFI 环境下这个协议可以枚举到 NVMe、SATA、USB 中的磁盘设备，我要做的事情是：

• 枚举每个块设备，读取容量、块大小、设备路径。
• 对 NVMe 设备，额外尝试读取 Identify Controller 数据，解析厂商、序列号、固件版本。
• 通过读写校验验证扇区可访问性。这里不会做全盘扫描（那会花太多时间），而是对头部、中部、尾部各取 1MB 区域做完整性检查。
• 如果设备支持 S.M.A.R.T. 命令，尽量读取健康状态信息。

网络部分的测试相对“轻量级”。UEFI 下有 SNP（Simple Network Protocol），可以获取 MAC 地址、链接状态；再往上走一层，Managed Network Protocol 能支持简单的 UDP 收发。我的实现是发送 ARP 请求到网关地址，如果能收到回复，说明 PHY 链路和 MAC 转发链路基本可用。此外还会对网卡的环回缓冲描述符做一轮基本写入读取测试，确认 DMA 通路没有明显异常。

外围设备检测涵盖 RTC、串口、USB 控制器枚举、PCIe 设备枚举。RTC 测试直接调用 gRT->GetTime()，检查年份、日期是否在一个合理范围内，再写入一个临时时间，等待 1 秒后读回，验证 RTC 是否在正常走时。串口测试则利用 UEFI Serial I/O Protocol，向串口写入一串特征数据，再从接收端读回比对——如果没有接回环线，这项测试会显示 WARN 而不是 FAIL，避免误报。PCIe 枚举的手段是遍历 PCIe 配置空间，检查设备 Vendor ID/Device ID 是否有效、Class Code 是否合法，以及是否存在中断路由冲突的明显迹象。

21 项测试的完整口径写出来大概是这样：

1. CPUID 厂商与型号识别
2. CPU 特性标志位检查
3. 逻辑处理器核心枚举（MP 服务）
4. CPU 缓存拓扑识别
5. CPU 温度/热传感器读取
6. 内存控制器信息识别
7. 内存基础 pattern 读写测试
8. 内存地址线 Walking 1s 测试
9. 内存压力循环测试
10. 块设备枚举与容量检查
11. NVMe/SATA 设备健康信息读取
12. 扇区抽样读写测试
13. 磁盘读性能 Spot Check
14. 有线网卡 PHY 链路检测
15. 网卡 MAC 地址读取与环路检查
16. UDP/ARP 连通性测试
17. 实时时钟（RTC）走时验证
18. 串口收发回环测试
19. USB 控制器与设备枚举
20. PCIe 设备枚举与配置空间检查
21. 系统信息汇总报告

3. 让自检过程“看得见”：UEFI 图形界面的选型与绘制

3.1 GOP 协议如何在固件环境里画界面

普通程序里做界面，有现成的 GUI 框架，但在 UEFI 环境下一切都要从底层来。UEFI 图形输出的核心协议是 GOP（Graphics Output Protocol），它提供了查询显示模式、设置分辨率、以及把像素数据从 CPU/GPU 内存传输到屏幕的 Blt 操作。

我的界面绘制流程大概是这样的：

1. 通过 LocateHandleBuffer 扫描所有支持 GOP 协议的句柄。
2. 对每个句柄查询支持的显示模式，找到能匹配原生分辨率或最接近 1920x1080 的模式。
3. 调用 SetMode 设置分辨率，然后拿到 Framebuffer 地址和像素格式。
4. 使用 GOP->Blt() 把内存中的像素缓冲区内容传送到屏幕。

这里有个关键细节：Blt 操作在部分固件上性能很差，尤其是老服务器主板，全屏刷新可能要 100ms 以上。所以界面上我做了局部刷新策略，只有状态变化的那一小块区域才重绘，而不是每一帧都全屏刷新。

3.2 字库、进度条和状态色的处理

在 UEFI 里画文字没有系统字库可用。两种方案，一是用 EDK2 自带的 HII Font，通过字符串 DisplayString 输出，但字体样式受固件限制，排版不够灵活；二是内置点阵字库，把 16x16 的 ASCII 点阵数组嵌进可执行文件，每个像素自己算。我最终选了后者，理由很简单：点阵字库不依赖固件接口，显示效果可控，尤其在远程控制卡串流画面时更清晰。

中文字库本来打算集成进去，但发现 HZK16 字库转成数组后体积有 256KB 左右，放进 UEFI 应用会让 .efi 文件变得臃肿，而且启动加载过程会更久。实际发布版本保留了英文字符和数字的点阵渲染，中文信息统一输出到报告文件中，界面只显示测试项英文缩写和状态标记。

进度条的实现也不难：在主界面的底部维护一个横向的像素条，每次测试完成，按已完成项占总项数的比例更新长度。状态颜色则用一个 32 位像素结构体表示——绿色表示 PASS、红色表示 FAIL、黄色表示 WARN、灰色表示 SKIP。对比度需要特别注意，部分 BMC 通过 1080p 分辨率压缩串流画面时，暗色背景的红色字几乎看不清，所以我把背景设为浅灰，文字用深灰色，状态图标用高饱和色块，同时在文字旁附加字母缩写（P/F/W/S），避免只靠颜色传递信息。

3.3 界面状态机的整体流程

整个可视化流程是一个典型的状态机：

• 启动阶段显示工具名称、版本、固件平台信息，等待 3 秒让使用者看清。
• 测试阶段左侧列出 5 个分类，右侧列出 21 个测试项，当前正在执行的项高亮显示。
• 单项测试结束立即更新状态标记，不需要等全部跑完。
• 全部测试结束后，界面自动跳转到汇总页，显示 PASS/FAIL/WARN 统计数字。
• 如果存在 FAIL 或 WARN 项，提供“查看详情”入口，让用户选择具体项来查看日志。

从交互角度来看，UEFI 应用只有一个键盘输入，所以所有操作都用上下箭头和回车完成，本质上是一个列表驱动的菜单系统。中间也尝试过鼠标事件，但兼容性问题太多，果断放弃。

有一个细节值得分享：在测试过程中按下 ESC 做了“跳过当前项”的处理，而不是直接退出整个测试。因为某些长耗时的测试（比如内存压力循环）在真实硬件上有概率被意外中断，强制退会让已完成的测试结果丢失。跳过当前项，再在报告中标记为 SKIP，更符合实际排查需要。

4. 一键出报告的完整链路：从测试日志到可读文档

4.1 报告格式与存储位置的选择

UEFI 环境里能直接读写的文件系统主要是 FAT32。找到块设备后，通过 Simple File System Protocol 打开卷并在根目录写文件，这个方案最通用——绝大多数没有操作系统的裸金属服务器都能通过 BMC 虚拟介质映射出一块 FAT32 分区，或者直接插个 U 盘。

报告格式我首选纯文本，带固定的字段分隔符。原因有两个：

• 文本文件在任何环境都能打开，运维同事不用装额外软件。
• 字段化结构可以直接被脚本进一步解析，方便后续接入监控平台。

生成的文件名按“HWREPORT_YYYYMMDD_HHMMSS.txt”的规则命名，放在 U 盘根目录的 TOOL_REPORT 文件夹里。如果检测到没有可写文件系统，工具会退回到内存中存放报告数据，并在界面提示用户“检测到无文件系统，请挂载虚拟介质后再试”，不会直接报错退出。

HTML 报告我也考虑过，但在 UEFI 环境下生成 HTML 文件需要处理大量字符串拼接和转义，而且最终在浏览器里打开时，如果字体和编码环境不一致，渲染效果可能比纯文本还差。所以现在的主版本只出带字段结构的文本报告。

4.2 异常项的日志抓取与格式化输出

测试跑完并不代表工作结束，如何把异常项的关键日志提取出来更重要。我的处理方式是每项测试维护一个内部日志缓冲，记录测试过程中收集到的关键状态码、寄存器值、错误地址。例如内存测试失败时，报告里会记录具体失败地址（物理地址）、期望值、实际读回值；网络测试失败时，记录链路状态寄存器和 MAC 寄存器转换后的可读描述。

这样的结果落实到报告里，大致是下面这种格式：

[TEST_ITEM] Memory_Basic_Pattern_RWTest [STATUS] FAIL [DURATION] 12.518s [ERROR_ADDR] 0x7F4A2000 [EXPECTED] 0xAA [ACTUAL] 0x00 [RESULT_LOG] Memory region [0x7F4A0000 - 0x7F4A2FFF] hit uncorrectable pattern mismatch. Possible causes: DRAM cell failure, address line short, or insufficient refresh.

这样做的好处是，拿到报告的人不需要再执行任何额外命令，就能直接定位到故障的物理地址范围，甚至可以进一步推断是“内存颗粒问题”还是“地址线问题”。

4.3 报告字段设计：让运维同事一眼看懂

报告文件的结构分为三块：设备摘要、测试明细、附录信息。

状态值统一使用 PASS/FAIL/WARN/SKIP，不额外发明新词。同一份报告既适合只看汇总的前台运维，也适合需要原始数据的 BIOS 工程师。我甚至加了一行 CSV 头——直接把整个报告复制出来，粘进 Excel 就能生成筛选表格，省了专门写解析脚本的工作。

这里有个经验：报告内容的输出顺序和测试执行顺序尽量保持一致，否则在多个内存测试连续失败时，使用者要来回翻页对照编号，体验很差。

5. 实测中被逼疯的几个坑和排查思路

5.1 QEMU 里一切正常，真机却花屏或黑屏

开发初期我用 QEMU + OVMF 做模拟 UEFI 环境，界面逻辑在模拟器上跑得飞起。第一次拿到真机上测试，结果屏幕花成一团。问题出在两个地方：

第一是分辨率适配。QEMU 的 OVMF 默认给出的模式很规整，而部分真机主板固件提供的 GOP 模式列表中，1920x1080 模式虽然在列表里，但实际刷新率、像素格式和 QEMU 模拟的不一样。我的解决方案是写了一个 QueryMode 轮询函数，对每个模式都尝试设置，然后用 Blt 画一帧测试图案，再读取帧缓冲中对应位置的颜色值验证是否能正确点亮像素，验证失败则跳过该模式，最终回退到 1024x768 这个最保险的分辨率。

第二个坑是局部刷新策略在真机上的性能差异。部分 B750 芯片组主板的 GOP Blt 实现会把整个 Range 重新压缩，如果小范围刷新频繁，反而会花屏。后来把刷新策略改成“同一测试项状态变化合并为一次重绘，最多每 500ms 触发一次”，真机上的稳定性明显提升。

5.2 内存测试直接把系统写挂的边界保护

早期版本做内存基础读写测试时，我天真地遍历了 GetMemoryMap 返回的所有可用区域，结果在测试进行到某一段地址时，机器直接 freeze。排查下来原因并不复杂：那个区域虽然被标记为可用常规内存，但实际映射到了某个板载设备的内存映射区或者系统管理中断处理使用的保留内存，不可以被诊断程序直接写入。

修复方式是加了一组白名单过滤规则：

1. 排除 EfiReservedMemoryType、EfiRuntimeServicesCode/Data、EfiMemoryMappedIO、EfiACPIReclaimMemory、EfiACPIMemoryNVS 等所有非普通消费类内存。
2. 对整个可用内存区域用 GetMemoryMap 的对齐属性做 4KB 对齐划分。
3. 对剩余区域再次执行 0x00/0xFF 写入测试，若某个页面在写入后读回结果持续异常，标记为“可疑内存”，不再继续深入。

经过这三层保护，内存测试才敢在真机上放开跑。

5.3 UEFI 看门狗把长时压力测试“强制重启”了

这大概是所有 UEFI 应用开发者都会遇到的坑。UEFI 规范规定 Boot Services 阶段有一个平台看门狗，默认超时时间是 300 秒（5 分钟）。如果没有定期调用 gBS->SetWatchdogTimer 重置计时器，固件会认为系统启动进入死循环，强制触发重启。

我没记错的话，EDK2 提供的标准做法是：在 UEFI Application 的入口函数中立即调用 SetWatchdogTimer(0, 0, 0, NULL) 关闭看门狗，或者按照自己的节奏定期重启计时器。刚开始没有处理这个细节，内存压力循环测试跑到第四分钟，机器直接重启，我还以为是测试逻辑触发硬件故障，排查了整整两天才发现是看门狗没有关掉。

在这里提醒所有从事 UEFI 应用开发的同行：任何超过 5 分钟的执行路径，必须把看门狗处理放在入口函数的第一段代码里。

5.4 NVMe 在 UEFI 阶段枚举不到的兼容性处理

存储测试的兼容性问题主要集中在 NVMe 设备上。部分服务器主板的 UEFI 固件没有内置 NVMe 驱动，或者 Sharge 设置里关闭了 NVMe Support，导致 UEFI 环境下根本看不到 NVMe 盘。这个问题在 Windows 下一般不会暴露，因为操作系统自带 NVMe 驱动；但在纯 UEFI 自检环境里就藏不住了。

我的处理策略是分三步降级。

• 先用 Block I/O Protocol 枚举，如果能看到 NVMe 设备，正常执行测试。
• 如果看不到，则尝试通过 PCIe 配置空间直接扫描 NVMe Controller，读取 Vendor ID、Device ID 和 BAR 寄存器，判断是否存在硬件但缺少 UEFI 驱动。
• 如果 PCIe 层存在但无法正常读写寄存器，则在报告中标记为“Controller Present, Driver/Protocol Missing”，并建议用户先到固件设置里确认 NVMe Support 是否打开。

这种降级逻辑非常重要，否则很容易把一个“固件配置缺失”误判成“NVMe 硬件故障”，给运维决策带来误导。

5.5 报告写入失败的一个隐蔽原因

还有一个细节是报告文件写入失败的问题。在 Fat32 分区写入时，如果 U 盘是 USB 3.0 且插在 USB 2.0 端口上，传输速度会降很多，但如果同时遇到坏块，写入时间会异常拉长，可能接近看门狗超时边界。我后来加了写入时间和写入字节数的进度提示，并把写报告操作放在看门狗临时重置之后执行。之前有人反馈“为什么测试全部 PASS 了，报告文件却没生成”，十有八九就是这个原因。

6. 这个工具适合谁用、能用来干什么

从功能完备性来看，这个工具目前还称不上专业商业诊断平台，但它在几个场景下非常有用。

第一个场景是二手服务器和整机验收。买进一批二手裸金属机器，先把自检工具跑一轮，任何内存、CPU、板载设备的问题都会在报告中列出来，比人工手动检查靠谱得多。我认识的做二手服务器贸易的同行，已经开始把这种 UEFI 自检纳入验收标准，报告存档，跟供应商扯皮时也有据可依。

第二个场景是服务器批量巡检。跑一趟全量 21 项测试的时间大约在 10~20 分钟（取决于内存容量和磁盘扫描范围），配合 BMC 虚拟介质的批量挂载能力，可以实现远程批量体检，不用派工程师去机房逐台插 U 盘。

第三个场景是产线自动化测试。设备组装完成后，在出厂前让整机自检工具自动跑一遍，输出的 PASS/FAIL 结果直接对接生产管理系统。由于工具仅依赖 FAT32 和 UEFI，不需要安装操作系统，整个流程可以做到完全自动化。

但也必须承认它的局限：它解决不了高负载场景下的稳定性问题。内存压力测试能发现明显的 bit flip，但不会像 Memtest86+ 那样跑一整晚；网络测试能验证链路和协议栈基础功能，但不会做高吞吐下的稳定性验证。真正的压测还是需要进系统用专业工具。我的定位是“快速体检+故障导向”，把明显的问题筛查出来，把可疑点留给更专业的后续测试。

7. 开发和扩展时的一些建议

最后分享一点开发层面的心得，给想自己动手写 UEFI 自检工具的朋友。

开发环境方面，直接用 EDK2 作为底座是目前最成熟的路线。搭建流程大致是：安装 Python 3.x、编译工具链（Windows 下用 VS，Linux 下用 GCC），克隆 Tianocore/edk2 仓库，用 build 命令编译一个 UEFI Application 工程。调试阶段优先用 QEMU + OVMF，通过串口输出和输入调试命令，没问题了再上真机。

代码结构上我建议把测试逻辑和界面逻辑分成两个独立模块。测试模块只负责调用固件协议、执行检测、生成标准化结果；界面模块负责消费结果并更新渲染。这样既能快速更换图形前端（比如输出成文本模式），也方便后续把核心测试逻辑移植到其他环境。我最初就是因为把界面和测试逻辑写在一起，导致想增加串口输出日志时改动量巨大，后来不得不重构成两层。这个重构几乎是必然的，早做比晚做好。

报告存储方案上，预留一个扩展点：除了 FAT32 文件系统导出，可以加一个 MTFTP 上传到远端日志服务器的选项。UEFI 环境下网络栈已经存在，实现一个 TFTP 客户端并不难，这样在没有 USB 介质的场景下也能把报告传出来。

对于 UEFI 图形界面的性能问题，我再补充一点：如果需要显示的内容很多，优先用双缓冲，即先在内存里完成所有绘制，然后一次性 Blt 到屏幕。不然每次画一个字符都触发一次 Blt，在低速固件上会让界面看起来卡顿。

这套工具从最初的一个“黑屏命令行工具”到现在的“21 项可视化自检+报告导出”，前前后后用了大概两个月业余时间。回看整个过程，最值得记录的并不是某个技术难点怎么攻克，而是“在资源受限的裸金属环境下，如何设计一套能高效定位故障的流程”——从测试项的选择、执行顺序、到报告输出，每一步都要站在使用者的角度去思考。希望这篇整理能对你有所帮助，也欢迎在类似的场景里交流实际遇到的新问题。