JSON 解码只能确认格式不代表字段齐全把第三方日志转换成本文中间格式时应另外核对键名、单位和类型。本文从Node构建JSON清单的受控中间格式读取记录统一使用毫秒和退出码。同一步骤多次出现时先统计执行次数比直接推断重试原因更可靠。先固定可回放的数据前端构建包装器可在一次运行结束后把各阶段结果整理为受控中间格式交给离线看板回放。这里采用对象数组保存完整快照故意留下两次同名测试使失败尝试不会被后来的成功覆盖。验收先确认数组成员仍是独立事件再检查耗时与退出状态没有被显示层改写。importjson raw[{step:build,ms:120,code:0},{step:test,ms:40,code:1},{step:test,ms:60,code:0},{step:pack,ms:80,code:2}]恢复结构并统一字段清单顶层是记录数组每条记录包含步骤名、毫秒数和退出码。读取结构化 JSON 可以保留数值类型不需要从彩色终端输出里猜测字段。rowsjson.loads(raw)ifany(r[ms]0forrinrows):raiseValueError()计算本篇的指标按步骤名累计执行次数重复出现并不自动等同于故障重试。这里输出事实计数让上层结合任务标识决定是否属于重跑。result{}forrinrows:namer[step];result[name]result.get(name,0)1对照独立期望值检查期望字典的每个键与计数再确认所有计数相加等于原记录数量。若只有重复名字那一项不正确优先查是否把赋值写成固定一或者读取输入时已经将事件错误合并。want{build:1,test:2,pack:1}ifresult!want:raiseValueError(result)print(result)准备数据时保留两个名称相同但结果不同的执行以测试字典累计是否覆盖旧值。其他只出现一次的步骤能够帮助区分“独立名称数量”和“总执行次数”这两个量都不能替代频次表。同名并行任务和同一任务重试可能采用相同名字。要准确统计重试还需保留任务唯一标识、尝试号或父运行编号不能仅依赖名称推断。