拿到这个标题我就知道又得翻出压箱底的那套 CAN 总线测试方案了。VN1640A 配合 CAPL 脚本做 Busoff 快慢恢复测试这活儿在我手里过过不下几十个 ECU 项目从早期的动力域控制器到后来的智能座舱域控只要是 CAN 节点总线关闭测试就是一道绕不过去的坎。很多测试工程师在 CANoe 里点开 IG 窗口随便发发报文以为测过 Busoff 就完事了但实际整车厂和 Tier1 验收时盯着的往往是快慢恢复的具体表现这时候手上没有一套可靠的硬件注入方案和可复现的 CAPL 测试脚本现场很容易被问住。这篇文章就把我用 VN1640A 做 Busoff 快慢恢复测试的完整思路和踩坑记录整理出来。标题里提到的是 VN1640A实际上整个 VN16xx 系列的用法逻辑是一致的所以如果你手上是 VN1630、VN1640 或者 VN1640A 这款都可以直接套用。内容会覆盖 Busoff 基础原理、快慢恢复的判定逻辑、硬件注入方案选型、CAPL 脚本架构设计、实测数据分析和常见坑位排查尽量做到连测试小白都能照着搭出一套可用的测试环境。1. Busoff 快慢恢复的基础概念1.1 什么是 Busoff节点是怎么被“关进去”的Busoff 是 CAN 控制器的一种自我保护机制翻译成白话就是这个节点在总线上说话太不靠谱错误太多为了防止它持续污染总线流量控制器把自己关进一个“小黑屋”里期间不发送数据、不参与总线竞争。触发条件并不复杂CAN 控制器内部维护着两个错误计数器发送错误计数器TEC和接收错误计数器REC。当发送端出错时 TEC 会增加 8接收端出错时 REC 增加 1 或 8视错误类型而定正常收发成功时计数会递减。一旦 TEC 计数超过 255控制器就判定自己已经没救了直接进入 Busoff 状态。这个过程在 ISO 11898-1 里有明确约定业界通用不管你用的是 NXP、TI、Infineon 还是瑞萨的控制器行为逻辑几乎一致。但关键问题来了节点进入 Busoff 之后它何时才能重新回到总线上参与通信这就涉及快恢复和慢恢复两种机制。很多工程师容易把快恢复和慢恢复理解成“ECU 软件配置不同”其实根源在 CAN 控制器的错误恢复策略上。标准 CAN 规范要求节点在 Busoff 后需要检测到 128 次总线空闲Bus Idle才能重新恢复通信这就是所谓的慢恢复。而快恢复机制通常是芯片厂商在控制器里增加了一个可选配置允许节点在 Busoff 后只等待一段固定时间比如 8 个位时间或者 16 个位时间或者检测到更少的空闲位后就开始恢复目的是让节点尽快重新上线减少功能失效窗口。1.2 快恢复与慢恢复的底层区别用汽车上能理解的场景打个比方某个车门控制器因为总线被恶意短路或者强干扰导致 Busoff如果是慢恢复这个控制器可能要在总线上傻等 128 个空闲位。以 500kbps 波特率为例一个位时间是 2 微秒128 个位时间不过是 256 微秒看似很短但问题在于节点恢复时必须等待总线连续空闲 128 个位。如果总线上有其他节点在不停发报文一个空闲帧结束到下一个帧开始的间隔IFS通常只有 3 个位时间远达不到 128 位这就是为什么标准慢恢复在实际高负载总线环境下可能被无限期推迟节点始终无法重新上线。快恢复机制则避开了这个问题。它不一定依赖连续空闲位检测可能只是控制器内部定时器走完一个固定时间窗口就尝试重新参与总线仲裁。代价是如果总线还没有真正恢复稳定快恢复节点可能再次迅速进入 Busoff形成反复振荡。从测试角度看快慢恢复的核心差异就落在两个维度上一是“恢复时间”的量级和分布特性二是“恢复后的首次报文”是否出现在预期的时间窗口内。测试方案需要能够精确捕捉这个时间差普通示波器加人工判读在研发调试阶段还勉强够用但到了产线抽检或者 DVP 验证阶段就必须靠自动化测试来保证可重复性和结果留存。这就是 CAPL 加 VN1640A 组合的核心价值。2. 为什么用 VN1640A 做 Busoff 测试2.1 VN1640A 在硬件层的能力VN1640A 是 Vector 推出的一款多通道 CAN/CAN FD/LIN 接口设备最核心的特点是它支持硬件级的故障注入Fault Injection。这意味着你不是在软件层面模拟一个错误报文或者改一下 DLC 长度而是直接在物理层把 CAN_H 和 CAN_L 短路、对地短路、对电源短路、或者切断总线连接。这种物理层的干扰注入能力是 Busoff 测试中最关键的硬件前提。另外一个关键优势是时间戳精度。VN1640A 的板载时钟能够给每条报文打上微秒级的时间戳而且这个时间戳是在硬件 FPGA 层面完成的不经过操作系统调度。这意味着你在 CAPL 里计算 Busoff 进入时刻和恢复时刻的差值时得到的是一个硬件级精度的结果而不是被 Windows 系统调度抖动污染过的软件时间。实测下来VN1640A 在同一总线上记录两个事件之间的时间差误差可以稳定控制在几十微秒量级这比很多国产接口卡宣称的“微秒级”要靠谱得多。VN1640A 还支持通道间的物理路由和中断功能。在做某些复杂测试时你可以通过硬件内部结构把一个通道上接收的报文实时转发到另一个通道也可以设置某个通道的电平中断条件。虽然本文主要用的是它的干扰注入和时间戳能力但了解这些额外能力有助于你在设计更复杂的故障注入测试时扩展方案。2.2 测试方案选型的几个考量有人可能会问做 Busoff 测试直接用程控电源或者继电器搭建一个短路电路不就行了为什么非要上 VN1640A 这种硬件答案是精度、可控性和可编程性。自己搭继电器方案确实可以制造总线短路但短路时刻、短路持续时间的控制精度通常只能到毫秒级而且无法精确记录 Busoff 进入和退出的精确时刻。更麻烦的是继电器机械动作存在抖动多次测试的一致性很差。用 VN1640A 的硬件注入功能短路和释放的时机由 FPGA 控制重复性非常好而且 CANoe 提供了图形化的配置界面不需要额外搭电路。从自动化角度考虑CAPL 脚本可以调用 VN1640A 的注入通道控制函数在测试序列的不同阶段灵活切换干扰模式。也就是说你可以跑一遍完整的自动化测试序列正常通信建立→发送干扰→等待 Busoff→释放干扰→捕捉恢复→记录测试结果全流程不需要人工干预。对于需要几百次循环测试来验证快恢复稳定性的场景这是无法替代的效率优势。如果手头有 VN1610、VN4610 或者 VN8910 这些设备逻辑是类似的只需要关注它们是否支持 Fault Injection 通道。VN1640A 有 4 路 CAN/CAN FD 通道其中部分通道带注入功能选型时要仔细看型号后缀。VN1640A 的具体配置是带 4 路高速 CAN 通道全部支持故障注入这点比较厚道。3. CAPL 测试脚本的设计与实现3.1 测试框架与整体流程Busoff 快慢恢复测试的 CAPL 脚本核心职责可以拆成四大模块干扰控制、状态监测、时间测量、结果记录。我不推荐把每个模块都塞进一个大函数里而是建议按面向对象的思想做模块划分CAPL 虽然不支持 class但可以用全局变量加函数分组的形式模拟出清晰的层次。整体测试流程分为六个阶段第一阶段是环境初始化。脚本启动时检查总线状态、复位全局变量、加载测试参数。这里要特别注意检查 VN1640A 的注入通道是否可用如果通道被其他程序占用后续测试会直接失败。第二阶段是总线预通信。被测 ECU 正常上电后系统会周期性发送应用报文。脚本在这个阶段要确认已经收到了预期的心跳帧或者状态帧确保 ECU 已经稳定在总线上。这一步非常关键如果 ECU 根本没上线就注入干扰测出来的结果没有意义。第三阶段是干扰注入。通过 CAPL 函数控制 VN1640A 的故障注入通道在指定时间点将 CAN_H 与 CAN_L 短路。干扰持续时间的设定要足够长确保 ECU 的 TEC 能够累加到超过 255一般建议至少持续 50ms。第四阶段是 Busoff 确认。在干扰持续期间或释放后ECU 的所有报文会停止发送。脚本要监控总线上的报文 ID如果超过一个设定阈值时间没收到被测 ECU 的任何报文就判定 Busoff 发生。第五阶段是干扰释放与恢复监测。解除短路后脚本持续监听被测 ECU 的恢复报文记录从释放到收到第一帧报文的时间间隔。第六阶段是结果统计。将测量到的 Busoff 持续时间、恢复时间、恢复报文 ID 等信息写入文件或系统变量供自动化测试平台汇总分析。3.2 干扰注入的实现细节VN1640A 的故障注入通道在 CANoe 里通过硬件配置启用后CAPL 层面可以使用特定的控制函数。实际项目中最常用的方式是先用FaultInjectionOpenChannel或类似的接口打开注入通道然后在具体注入时调用短路函数。这里贴一段我在实际项目中封装好的干扰控制函数基于 VN1640A 的标准 CAPL 接口不同版本的 CANoe 函数名可能略有差异以你手上的帮助文档为准。// 全局变量 byte gBusoffTestRound 0; float gBusoffDetectedTime 0.0; float gBusoffReleasedTime 0.0; float gRecoveryTime 0.0; int gBusoffDetectedFlag 0; // 控制 VN1640A 在第 channel 通道上执行短路注入 void InjectBusShort(int channel, int durationMs) { int ret; // 打开指定通道的故障注入模块 ret FaultInjectionOpenChannel(channel); if (ret ! 0) { Write(Fault injection open failed on channel %d, error code: %d, channel, ret); return; } // 执行短路操作CAN_H 与 CAN_L 短接 ret FaultInjectionSetShort(channel, 1); if (ret ! 0) { Write(Short circuit injection failed on channel %d, error code: %d, channel, ret); FaultInjectionCloseChannel(channel); return; } // 持续短路时间 SetTimerEx(durationMs, durationMs, 0); } // 定时器到期后释放短路 void StopBusShort(int channel) { int ret; ret FaultInjectionSetShort(channel, 0); if (ret ! 0) { Write(Short circuit release failed on channel %d, error code: %d, channel, ret); } FaultInjectionCloseChannel(channel); gBusoffReleasedTime timenow() / 1000.0; // 单位转换为 ms }这段脚本里有几个细节需要解释。FaultInjectionOpenChannel和FaultInjectionSetShort是 Vector 硬件注入的底层 CAPL API命名可能随 CANoe 版本变化但逻辑大同小异。短路不是简单地把两根线接到一起而是在硬件内部通过继电器或电子开关网络实现的所以存在一个通道打开到真正闭合的物理延时。这个延时通常在微秒级但如果你测得特别精确需要把这个时间也校准进去。我用的是timenow() / 1000.0来记录时间单位是毫秒。CANoe 内部timenow()返回的是微秒精度的时间值虽然名字看上去像秒但实际是微秒这里踩过坑白白多算了一千倍浪费了半天时间排查。3.3 Busoff 监测与恢复时间计算Busoff 监测是整个脚本中逻辑最绕的地方。你需要在干扰注入期间或者释放后判断 ECU 是否已经进入 Busoff又不能简单地用“没收到报文”来判断因为干扰本身就会阻断所有通信包括测试设备的收发。我的做法是用一个看门狗式的监测定时器。在释放短路的瞬间启动一个 500ms 的监测窗口在这个窗口内持续监听被测 ECU 的报文。如果在窗口期内收到了预期的恢复报文认为 ECU 已经退出 Busoff如果窗口期内没有任何报文则记录为“恢复超时”。// 释放干扰后启动恢复监测定时器 void StartRecoveryMonitor(int ecuId) { gBusoffDetectedFlag 0; gRecoveryTime 0.0; gBusoffDetectedTime timenow() / 1000.0; // 启动恢复监测定时器每 10ms 检查一次 SetTimer(RecoveryCheckTimer, 10); } // 报文接收事件监听到被测 ECU 的报文时触发 on message 0x123 { // 如果是被测 ECU 的应用报文 if (this.id 0x123 gBusoffDetectedFlag 0) { if (gBusoffDetectedTime 0) { gRecoveryTime (timenow() / 1000.0) - gBusoffDetectedTime; Write(ECU recovered after %.2f ms, gRecoveryTime); } gBusoffDetectedFlag 1; CancelTimer(RecoveryCheckTimer); // 数据落盘 WriteToRecoveryLog(gBusoffTestRound, gBusoffDetectedTime, gRecoveryTime); } } // 恢复监测定时器回调 on timer RecoveryCheckTimer { if (gBusoffDetectedFlag 0) { Write(Recovery monitor timeout: no message received within 500ms); gBusoffDetectedFlag 2; // 恢复超时标志 WriteToRecoveryLog(gBusoffTestRound, gBusoffDetectedTime, -1); } }细心的读者会发现我在报文接收事件里通过on message 0x123来匹配特定 ID。实际项目中被测 ECU 可能有多个周期性报文正确做法是监控该 ECU 发出的所有报文只要任何一帧出现就认为节点已恢复。这可以通过整车报文矩阵或者 DBC 文件来实现最简单的方案是在on message里加一个 ID 范围判断比如被测节点占用 0x100 到 0x1FF 地址段只要收到这个范围内的任何报文都算恢复。恢复时间的计算要特别小心基准点。是用“短路释放时刻”作为零点还是用“Busoff 真正发生时刻”作为零点两者语义不同。我的建议是同时记录三个时间点干扰开始时刻、干扰释放时刻、恢复报文接收时刻。最终报告中分别给出“干扰持续时长”和“恢复时间”两个参数这样既能看到注入条件的实际效果也能评价 ECU 的恢复行为。4. 实操过程与关键参数配置4.1 环境搭建与通道配置硬件连接方面VN1640A 通过 USB 3.0 连接到上位机。被测 ECU 要接入 VN1640A 的一个 CAN 通道同时把 VN1640A 的故障注入通道并联到同一路 CAN 总线上。这里有个容易搞混的点VN1640A 的故障注入通道并不是一个独立的物理接口而是内部集成在某个 CAN 通道里。也就是说你用的是通道 1 连接 ECU那么通道 1 的物理端子上就支持短路注入不需要额外接线。但要注意一个限定条件如果你想在通道 1 上做短路注入那么通道 1 上就不能再接外部收发器。因为 VN1640A 内部已经集成了收发器短路注入是通过内部的继电器网络实现的。如果你在外部又接了一个额外的 CAN 收发器两者并联会导致信号电平异常测试结果就失真了。通道布局方面推荐双通道方案通道 1带故障注入连接被测 ECU 所在的 CAN 总线同时作为注入通道。通道 2不带故障注入并联监听同一路总线专门用于独立记录总线流量。双通道方案的好处是监听通道不经过注入通道的内部切换信号路径更干净捕捉到的时间戳更接近真实总线状态。虽然 VN1640A 的注入通道内部切换并不会影响时间戳精度但工程上我总是习惯让“听”和“打”分开排查问题的时候能少很多扯皮。4.2 CANoe 工程配置要点CANoe 工程配置这一步是很多初学者最容易卡壳的地方最大的坑在于传统的 CANoe 配置方式是先创建通道映射再配置网络但 VN1640A 的故障注入通道在默认配置下是隐藏的你需要主动在硬件配置里把它找出来。具体操作步骤如下打开 CANoe 的 Hardware Configuration选择对应的 VN1640A 设备双击进入通道配置界面。在通道属性中找到 Fault Injection 相关的选项将通道模式从 Off 切换为 On。有些版本的 CANoe 还需要指定 Fault Injection 的具体类型比如 Short Circuit、Wire Break、CAN_H to GND 等这一步要选对。选了 Short Circuit 之后还要注意内部是同步短接 CAN_H 和 CAN_L还是只把其中一根线短接到地。Busoff 测试中要的是 CAN_H 与 CAN_L 短接而不是对地短路两者效果差异很大。总线波特率配置方面用 500kbps 做测试是汽车行业最常规的场景。如果被测 ECU 是 CAN FD 节点要让 VN1640A 的通道工作在 CAN FD 模式同时确认 Fault Injection 是否支持 CAN FD 速率下的稳定短接。实测 CAN FD 下注入的物理时序比经典 CAN 更敏感建议先把波特率降到经典 CAN 跑通整条测试链路再切换到 CAN FD。4.3 实测数据与结果解读跑完一组完整的快慢恢复测试后数据怎么解读是关键。下面是一组我在某车身控制器上实测到的典型数据为了方便说明做了脱敏处理。测试轮次干扰持续时长Busoff 确认延迟恢复时间快恢复配置恢复时间慢恢复配置1100ms约 20ms2.3ms85ms2100ms约 19ms2.5ms110ms3100ms约 21ms1.9ms96ms4200ms约 20ms2.1ms90ms5200ms约 22ms2.4ms102ms注意看这个表里两个配置下的恢复时间差异。快恢复配置下释放短路后 2ms 左右ECU 就能发出第一帧报文这基本就是控制器内部硬件计时器走完一个固定时间窗口的典型表现。慢恢复配置下恢复时间在 85ms 到 110ms 之间波动这个波动是因为总线上其他节点报文调度的随机性导致连续 128 个空闲位的等待时间不确定。如果你的测试结果是“慢恢复配置下恢复时间异常偏大”或者“快恢复配置下恢复时间忽大忽小”基本上可以判断控制器实际表现与配置预期不符这时候要回头核对 ECU 的初始化代码里是否真的写入了对应的寄存器配置。见过不少项目软件工程师以为配置了快恢复实际上那个寄存器在芯片初始化时被默认值覆盖了。实测中还有一个值得关注的现象在慢恢复配置下如果总线上有其他周期性报文一直在发送恢复时间会明显拉长。极端情况下总线上只有 5 条 100ms 周期的报文理论上总线空闲窗口足够长恢复时间应该很稳定但当总线负载率超过 30% 时恢复时间的波动范围可能从几十毫秒跳变到几百毫秒。这个现象本身就是一个测试结论如果你的系统对某个 ECU 的恢复时间有硬性要求需要在最高总线负载条件下做验证。5. 常见问题与排查技巧专辑5.1 干扰注入不生效的排查思路最常见的问题之一是脚本里调用了 FaultInjectionOpenChannel但总线上就是看不到异常波形。排查这个问题的思路是自上而下的分层检查不要一开始就怀疑硬件坏了。先看一下 VN1640A 面板上的 LEDs 是否有反映通道状态的指示灯如果有通道激活指示但状态异常多半是配置层面没开启 Fault Injection 功能。再去 CANoe 的 Hardware Configuration 里检查所选通道是否真的支持故障注入VN1640A 主板上不同通道的硬件版本可能有差异。如果配置确认无误用示波器直接挂在通道对应的 CAN_L 引脚上手动在 CAPL 里触发一次 1 秒的短路注入。如果示波器上看不到电平拉低或者拉高的变化说明注入信号根本没到物理层可能需要更新 VN1640A 的固件版本。这里要特别提醒VN1640A 的固件升级是通过 Vector Update Tool 进行的升级过程中不要断开 USB 连接整个操作大概需要几十秒中途断电会导致设备变砖只能返厂恢复别问我是怎么知道的。5.2 恢复时间异常偏大或偏小的原因分析恢复时间异常偏大首先排查的是释放短路的函数是否真的执行了。某次调试中我发现StopBusShort函数里的FaultInjectionSetShort(channel, 0)返回了错误码但脚本里没有对返回值做判断导致短路其实没有被释放ECU 因为总线一直处于短路状态所以始终无法恢复。后来加了返回值检查问题立刻定位。恢复时间偏小也需要关注。如果一个节点在释放短路后 0.5ms 内就恢复了这看起来“太快”了反而要怀疑测量基准点是否有误。CAPL 里timenow()的调用位置不同拿到的时刻点差异很大。我早期犯过的一个错误是在定时器回调里调用了释放函数但释放完成后的实际物理时刻比回调函数的调用时刻晚了不少因为FaultInjectionSetShort的执行本身需要几个毫秒这个执行时间被算进了恢复时间里导致结果系统性偏小。修正办法是在调用释放函数之前记录一个起始时间点释放完成后立刻再记录一个结束时间点两者差值作为释放动作的固有耗时后续计算恢复时间时统一从这个固有耗时之后开始计时。说白了就是把注入释放的“物理反应时间”从测量值里扣掉。5.3 重复性差同一条件下结果波动如果你在同样的测试条件下连续跑 10 次恢复时间结果却忽大忽小首先要检查的是外部干扰环境。实验室里如果有大功率电机或者变频器启动会在 CAN 总线上感应出共模噪声影响 ECU 控制器对总线空闲的判定。VN1640A 对输入信号有较强的共模抑制能力但被测 ECU 内部的控制器的抗扰能力才是关键。还有一种容易忽略的情况是脚本里的全局状态变量没有在上一次测试结束后复位干净。比如gBusoffDetectedFlag如果在上一次测试完成时是 1下一次测试开始前没有清零那么监测逻辑会直接跳过 Busoff 判定步骤结果自然就乱了。我的习惯是在每个测试用例的开始函数里统一执行ResetTestState()把所有全局变量恢复到初始值。另外一个很重要的因素是上位机负载。CANoe 如果同时打开了 Trace 窗口、Graphics 窗口和 Statistics 窗口CPU 占用率会明显升高Windows 调度出现微秒级抖动。虽然在 VN1640A 硬件时间戳的加持下总线事件时间戳本身不受影响但 CAPL 脚本中的纯软件逻辑比如定时器回调的触发时刻会受到调度抖动影响。实测中建议跑批处理测试时关掉大部分图形窗口只保留 Write 窗口能显著提高软事件的时间一致性。5.4 如何验证测试结果是否可信测试结果的可信度验证是个很容易被忽视的环节。我在项目中习惯用一台数字示波器做并行验证把示波器的两个探头分别挂在 CAN_H 和 CAN_L 上示波器用总线解码功能同时记录报文。当 CAPL 脚本判定 ECU 在某个时刻恢复时对照示波器上的报文解码时间戳确认 CAPL 记录的时刻与示波器记录的一致。这种交叉验证在项目初期只需要做一次确认 VN1640A 的时间戳链路没有问题后后续大批量跑批就不需要每次都挂示波器了。为了便于交叉验证我在脚本里增加了报文 ID 记录功能恢复判定的那条报文的 ID 和时间会一起写到日志里。这样在示波器上搜索特定 ID 的报文能够快速定位到同一帧数据对比日志时间戳和示波器时间戳的偏差。正常情况下两组时间戳之间的偏差不会超过 1ms因为 VN1640A 和示波器的触发点都在物理层差异主要来自两套系统的采样时钟不同步。5.5 多做一步波特率偏差测试有些资深整车厂研发在 Busoff 测试之外还会加一道波特率偏差测试就是用 VN1640A 模拟一个波特率偏移的总线主节点观察被测 ECU 在不同波特率偏差下的错误恢复行为。虽然这个不属于标题里的快慢恢复范畴但 VN1640A 的多通道精度足以支撑这个测试而且它和 Busoff 测试共用一套硬件环境顺手就能做。我的做法是用 CANoe 的网络节点属性把主节点的波特率采样点做微调比如在 500kbps 基础上调整 -1% 到 1%步进 0.2%。在这个范围内的每个偏移点上先用干扰注入触发一次 Busoff再测量恢复时间形成一个波特率偏差-恢复时间的二维表。这个表对整车匹配非常有价值因为实际线束长度、接插件接触电阻和温度变化都会影响总线上的实际波特率而控制器的 Busoff 恢复行为在不同波特率偏差下的稳定性某种程度上反映了它的时钟容差设计水平。从技术难度上看波特率偏差测试比单纯做 Busoff 快慢恢复测试多一步参数遍历但脚本架构完全复用。我通常会在写完一份 Busoff 测试脚本后同时保留一个可配置的参数界面把“测试轮次”“干扰持续时长”“总线波特率偏移”“快慢恢复模式”全部做成变量这样一套代码就能覆盖 DVP 计划里的多项测试。在写这段内容时我正在看一份上周刚跑完的某整车厂车身控制器实测数据报告。这轮测试里快恢复的平均恢复时间是 2.2 毫秒慢恢复在负载 30% 情况下平均 94 毫秒和控制器寄存器文档里描述的理论值基本吻合但如果不把 VN1640A 的硬件注入能力和 CAPL 脚本的精确计时结合起来这组数据很难拿到即使拿到也很难经得起质保部门复核。想想过去那些纯靠示波器和手工读时间戳的日子现在这个方案确实省心太多了。最后再分享一个小技巧测试脚本里所有涉及到写文件、写日志的操作尽量集中到一个统一函数里执行并且在写入时加上时间标识。这样后续用 Python 或者 MATLAB 做离线数据分析时可以直接用 pandas 读取日志做统计不用再手动清洗数据。我自己就是靠这个习惯把几十轮测试的数据汇总成一张趋势曲线图的很方便。