第四章：CAPL流程控制——让脚本学会“思考”

流程控制，说白了就是让脚本根据条件做决策，或者重复执行某段任务。没有流程控制的脚本，就像一条笔直的单行道——从起点跑到终点，中间没有任何变化。但实际项目中，你面对的报文千变万化，信号值忽高忽低，没有条件判断和循环，根本写不出实用的脚本。

我个人习惯把流程控制分成两大类：条件分支和循环迭代。今天咱们就把这两块彻底讲透。

4.1 if-else条件判断：最基础的决策逻辑

if-else 是 CAPL 里最常用的条件判断结构。它的逻辑很简单：如果条件成立，执行 A；否则执行 B。但实际项目中，很多人会栽在条件表达式的细节上。

核心语法：

if (条件表达式) {
    // 条件为真时执行
} else if (另一个条件) {
    // 第一个条件不满足，但第二个条件满足时执行
} else {
    // 以上条件都不满足时执行
}

我在项目中遇到过一个问题：一个新手同事写了个判断车速的脚本，条件写成了 if (speed = 100)。你猜怎么着？CAPL 里单等号是赋值，双等号才是比较。结果车速永远被赋值为 100，整个测试都乱了。嗯，这里要注意：CAPL 的条件判断里，比较用 ==，赋值用 =，千万别搞混。

再举个例子，判断报文是否超时：

on timer CheckTimeout {
    if (msgReceived == 0) {
        write("警告：报文超时！");
        // 触发故障处理
    } else {
        write("报文正常接收");
        msgReceived = 0;  // 重置标志
    }
}

你想想看，如果没有 if-else，你只能写两个独立的 timer 事件，代码量翻倍不说，逻辑还容易乱。if-else 让代码有了「智能感」。

我的小技巧：写 if-else 时，把最可能发生的条件放在最前面。比如报文错误率很低，那就先判断正常情况，再判断异常。这样执行效率更高，代码可读性也更好。

4.2 switch-case多分支：告别冗长的if-else链

当你有超过 3 个分支时，if-else 链会变得又臭又长。这时候 switch-case 就派上用场了。它专门处理「一个变量取不同值」的场景。

语法结构：

switch (变量) {
    case 值1:
        // 处理逻辑
        break;
    case 值2:
        // 处理逻辑
        break;
    case 值3:
    case 值4:
        // 值3和值4共用逻辑
        break;
    default:
        // 所有case都不匹配时执行
        break;
}

我曾经写过一个诊断测试脚本，需要根据不同的诊断服务 ID 执行不同操作。如果用 if-else，大概要写 20 多个 else if，看着就头疼。换成 switch-case 后，代码清晰得像表格一样。

举个例子，处理 CAN 报文 ID 对应的节点：

on message * {
    switch (this.id) {
        case 0x100:
            write("收到发动机报文");
            // 解析发动机数据
            break;
        case 0x200:
            write("收到变速箱报文");
            // 解析变速箱数据
            break;
        case 0x300:
        case 0x301:
            write("收到ABS报文（主/副）");
            // 两个ID共用逻辑
            break;
        default:
            write("未知报文ID: 0x%x", this.id);
            break;
    }
}

注意：每个 case 后面一定要加 break;，否则会「穿透」到下一个 case。我见过有人故意利用穿透特性写合并逻辑，但新手不建议这么玩，容易出 bug。

4.3 for循环：精确控制循环次数

for 循环适合「我知道要循环多少次」的场景。比如遍历数组、发送固定次数的报文、或者做 N 次采样。

标准语法：

for (初始化; 条件判断; 步进操作) {
    // 循环体
}

我个人习惯用 for 循环处理数组。比如我要检查 10 个信号值是否都在范围内：

int signalValues[10];
int i;

for (i = 0; i < 10; i++) {
    if (signalValues[i] < 0 || signalValues[i] > 100) {
        write("信号[%d]超出范围: %d", i, signalValues[i]);
    }
}

你想想看，如果没有 for 循环，你得写 10 个 if 语句，每个都手动索引数组。代码量翻 10 倍，而且容易漏掉某个索引。for 循环让重复劳动变得优雅。

还有一个常用场景：发送连续 ID 的报文。

on key 's' {
    int id;
    for (id = 0x100; id <= 0x10F; id++) {
        message CAN1.msgTx msg;
        msg.id = id;
        msg.dlc = 8;
        msg.byte(0) = id & 0xFF;  // 用ID填充第一个字节
        output(msg);
        write("已发送报文 ID: 0x%x", id);
    }
}

避坑指南：我曾经在 for 循环里忘记更新循环变量，导致死循环。那次脚本跑了一整夜，第二天发现 CANalyzer 日志文件撑爆了硬盘。所以写 for 循环时，一定确认步进操作能最终让条件为假。

4.4 while循环：条件驱动型循环

while 循环和 for 循环的区别在于：for 循环是「数着次数」跑，while 循环是「看着条件」跑。你不知道要循环多少次，但你知道什么时候该停下来。

语法：

while (条件表达式) {
    // 循环体
    // 记得在循环体内改变条件，否则会死循环
}

我在项目中用 while 循环最多的场景是：等待某个信号达到特定值。比如等待发动机转速稳定后再记录数据：

on key 'r' {
    // 等待发动机转速稳定在2000±50 RPM
    while (abs(engineSpeed - 2000) > 50) {
        write("当前转速: %d, 等待稳定...", engineSpeed);
        testWaitForTime(100);  // 等待100ms再检查
    }
    write("转速已稳定，开始记录数据");
    // 开始记录
}

你想想看，如果用 for 循环，你得先估算大概需要多少次循环。但实际项目中，转速稳定时间受温度、负载影响，根本无法预判。while 循环就是为这种「不确定次数」的场景设计的。

致命陷阱：while 循环最容易出现死循环。我见过一个同事写 while 循环时，条件里用的变量在循环体内根本没更新，结果脚本卡死，CANalyzer 界面都点不动。解决办法：永远在循环体内加一个超时退出机制。

安全写法示例：

int timeout = 0;
while (abs(engineSpeed - 2000) > 50 && timeout < 100) {
    testWaitForTime(100);
    timeout++;
}
if (timeout >= 100) {
    write("超时：转速未能稳定");
} else {
    write("转速已稳定");
}

4.5 do-while循环：至少执行一次的循环

do-while 和 while 的唯一区别：do-while 先执行一次循环体，再判断条件。这意味着循环体至少会执行一次。

语法：

do {
    // 循环体
} while (条件表达式);  // 注意这里的分号不能少

说实话，do-while 在 CAPL 里用得不多。但我有一个场景非它不可：读取传感器数据，至少读一次，然后根据结果决定是否继续读。

int sensorValue;
int retryCount = 0;

do {
    sensorValue = readSensor();  // 至少读一次
    retryCount++;
    if (sensorValue < 0) {
        write("传感器读取失败，第%d次重试", retryCount);
        testWaitForTime(50);
    }
} while (sensorValue < 0 && retryCount < 5);

if (sensorValue >= 0) {
    write("传感器读取成功: %d", sensorValue);
} else {
    write("传感器读取失败，已重试5次");
}

为什么这里用 do-while 而不是 while？因为传感器读取操作本身可能失败，但你必须先尝试一次才知道结果。如果用 while，你得在循环外面先写一次读取代码，然后在循环里再写一次——代码重复了。do-while 完美解决了这个问题。

我的建议：do-while 虽然用得少，但用对地方能省不少代码。记住它的核心特征——「至少执行一次」。如果你需要先做再判断，就用它。

4.6 流程控制实战：组合使用

实际项目中，很少只用一种流程控制。往往是 if-else 套着 for 循环，for 循环里又嵌着 while。我分享一个我写过的真实案例：自动化测试脚本，需要发送 100 次报文，每次都要等待应答，如果超时则重试。

on key 't' {
    int i;
    int retry;
    int ackReceived;

    for (i = 0; i < 100; i++) {
        retry = 0;
        ackReceived = 0;

        // 发送请求报文
        message CAN1.msgTx request;
        request.id = 0x500;
        request.byte(0) = i;  // 序列号
        output(request);

        // 等待应答，最多重试3次
        while (ackReceived == 0 && retry < 3) {
            testWaitForTime(200);  // 等待200ms
            if (ackFlag == 1) {    // ackFlag在on message中设置
                ackReceived = 1;
                write("第%d次发送成功", i);
            } else {
                retry++;
                if (retry < 3) {
                    write("第%d次超时，重试第%d次", i, retry);
                    output(request);  // 重发
                }
            }
        }

        if (ackReceived == 0) {
            write("第%d次发送失败，已放弃", i);
        }

        // 重置标志
        ackFlag = 0;
    }
    write("测试完成");
}

你看，这个脚本里 for 循环控制 100 次发送，while 循环控制每次的重试逻辑，if-else 判断是否收到应答。三种流程控制嵌套使用，才构成了一个完整的自动化测试流程。

总结一下我的经验：

  • if-else：做决策，判断条件是否成立
  • switch-case：多分支选择，替代冗长的 if-else 链
  • for：知道循环次数时用，比如遍历数组
  • while：不知道次数，但知道停止条件时用
  • do-while：至少执行一次的场景，比如先读再判断

最后说一句：流程控制是脚本的骨架。骨架搭得稳，后面的逻辑才能站得住。多写、多练、多踩坑，慢慢你就能写出既高效又健壮的 CAPL 脚本了。

← 上一章 📖 返回目录 下一章 →