“本文首发于知乎，现同步至CSDN，方便更多同行检索交流。”

智驾测试提效第二步：用Python搭建一键生成报文报告 - 知乎

一、为什么测试数据需要“自动分析”

• 一句话痛点：手动分析上百MB的CAN日志，效率低、易遗漏、结果无法复用。
• 三个具体场景：
  • 每次回归测试产生数万条报文，人工逐帧分析耗时2天以上。
  • 跨版本对比困难：新旧版本的数据差异靠肉眼比对，容易漏掉微小退化。
  • 报告格式不统一：不同工程师的分析结论写在Excel里，格式各异，难以追溯。

• 解决思路：写一套自动分析脚本，把原始CAN日志自动处理成标准化测试报告。

二、技术实现：从报文到报告的完整链路

• 输入：TSMaster录制的blf文件。
• 处理流程：
  mainDeal.py(主逻辑) -> xxxproc（具体主机厂的处理逻辑）-> process_case_analysis(判断是制动性能分析、转向性能分析还是其他) -> analyze_performance_xxx(具体的分析逻辑)

三、坦诚复盘：初版架构的“坑”

• 三个核心问题：
  • 耦合太紧：解析、计算、报告三个模块相互依赖，改报告格式会影响计算逻辑。
  • 扩展困难：新增一个主机厂或者信号分析，需要在多个文件里同步修改。
  • 硬编码过多：不同车型的CAN ID和信号定义写在代码里，维护成本高。

• 我的反思：
  • 初版是为了“快速验证能不能跑通”，牺牲了长期可维护性。
  • 重构方向：模块解耦 + 配置文件驱动 + 数据层抽象。

第二版

vehicleCANAnalyzer.py (处理单个blf文件) -> CaseTypeDetector.py (根据文件名适配测试案例类型和厂商) -> VendorAwareConfigManager() （根据适配的测试类型和厂商找到相关配置）-> DataManager() （根据适配到的信号解析blf文件）-> PerformanceAnalyzer(can_file_path, self.config_manager) （主分析逻辑，使用反射根据配置内容来调用处理函数）-> ResultVisualizer() （分析结果可视化）

四、实战效果：提效了多少

• 量化对比：
  • 手动分析：2天/轮 → 自动分析：10分钟/轮。
  • 问题发现：自动分析的标准更客观，人工分析无法做到逐帧比较，所以部分数据看似没有问题，自动分析出来的数据会暴露每个问题。

并且新的迭代版本也减少了开发维护工作量，只需要简单配置就可以因对新厂商新车型和新信号的处理。

• 附一张自动生成的报告截图。