第4章 FCT功能测试

第4章 FCT功能测试：核心功能验证、治具与测试软件架构

FCT，全称Functional Circuit Test，功能电路测试。说白了，就是验证你的药盒能不能干活。

我见过不少团队，硬件设计完了，软件也调通了，结果一到产线就翻车。为什么？因为FCT没做好。你想想看，药盒这种产品，出错了可是要出人命的。所以FCT这一关，必须扎扎实实过。

4.1 FCT到底测什么？

FCT不是简单的“通电看看亮不亮”。它要验证的是：

核心功能完整性：每个药仓能不能正常开合？电机转不转？
传感器准确性：药仓有没有药？门关没关好？这些信号必须准。
通信接口正常：蓝牙连得上吗？WiFi能配网吗？串口数据对不对？
电源管理：电池电压正常吗？充电电路工作吗？
异常处理：卡药了怎么办？低电量报警灵不灵？

核心原则：FCT要覆盖用户能遇到的所有正常场景，以及可能出现的异常场景。少测一个，就是一颗雷。

我记得有一次，一个药盒项目在产线上FCT全过了，结果用户反馈说“药盒半夜自己开仓”。查了半天，原来是FCT没测休眠唤醒后的状态保持。嗯，从那以后，我的FCT用例里永远多一条：休眠唤醒后状态验证。

4.2 治具设计：FCT的骨架

治具，就是用来固定产品、连接测试设备的“架子”。别小看它，治具设计不好，FCT效率直接腰斩。

4.2.1 治具的核心组成

组件	作用	我的建议
定位夹具	固定产品，保证每次位置一致	用防静电材料，别刮花外壳
探针模组	接触测试点，传输信号	探针选型要看寿命，至少10万次
负载模拟	模拟真实负载（如电机、传感器）	用可调负载，方便切换测试条件
气动/电动机构	自动压合、开盖等动作	气动便宜，电动精度高，看预算选

小技巧：治具上留一个“快速换型”设计。不同型号的药盒，换几个定位块就能测，不用重新做治具。我见过一个工厂，光治具就做了30套，浪费啊。

4.2.2 探针布局的坑

探针不是随便戳的。我曾经吃过一次亏：探针顶到了电容的焊盘，直接把电容怼短路了。从那以后，我定了个规矩：

探针必须避开高密度元件区域
测试点直径不小于1mm
探针压力控制在100-150g，太大伤焊盘，太小接触不良
每个测试点留一个“冗余探针”，万一有一根断了，还能测

4.3 测试软件架构：FCT的大脑

治具是骨架，软件就是大脑。没有好的软件架构，FCT就是一盘散沙。

4.3.1 我常用的三层架构

我个人习惯把FCT软件分成三层：

硬件抽象层（HAL）：封装所有硬件操作，比如读GPIO、写I2C、控制继电器。换硬件时，只改这一层。
测试用例层：每个测试项是一个独立函数。比如“test_motor_open()”、“test_sensor_detect()”。
调度执行层：管理测试流程，记录结果，生成报告。

为什么要这么分？你想想看，如果所有代码揉在一起，产线说“加一个测试项”，你得改半天。分层之后，加一个用例就是写一个函数，然后注册到调度器里。简单、干净。

4.3.2 一个简单的测试用例示例

// 测试药仓电机是否正常
bool test_motor_open(uint8_t chamber_id)
{
    // 1. 发送开仓指令
    send_command(chamber_id, CMD_OPEN);
    
    // 2. 等待电机到位信号（超时5秒）
    if (wait_for_signal(chamber_id, SIG_OPEN_DONE, 5000))
    {
        // 3. 验证霍尔传感器状态
        if (read_hall_sensor(chamber_id) == HALL_OPEN)
        {
            log_result("Chamber %d open: PASS", chamber_id);
            return true;
        }
    }
    
    // 超时或状态不对，报失败
    log_result("Chamber %d open: FAIL", chamber_id);
    return false;
}

注意：超时时间一定要设。我见过一个案例，电机卡住了，测试软件一直等，整个产线停了10分钟。后来加了超时，卡住就报错，产线继续跑。

4.3.3 测试流程管理

测试流程不是死的。我建议用配置文件来定义流程：

# test_sequence.yaml
- name: "电源检测"
  function: test_power
  params: {voltage_min: 3.3, voltage_max: 3.6}
  
- name: "蓝牙连接"
  function: test_bluetooth
  params: {timeout: 10}
  
- name: "药仓1电机"
  function: test_motor_open
  params: {chamber_id: 1}
  
- name: "药仓2电机"
  function: test_motor_open
  params: {chamber_id: 2}

这样改流程不用改代码，产线工程师自己就能调。我曾经在产线蹲过三天，就是为了把流程调顺。后来改成配置文件，再也不用半夜被叫起来改代码了。

4.4 数据记录与追溯

FCT不只是“过”和“不过”。每一台药盒的测试数据都要存下来。为什么？

质量追溯：用户退货了，你能查到这台机器当时测了哪些项，数据是多少。
趋势分析：如果连续10台机器都在同一个测试项上失败，说明产线有问题，得赶紧停线排查。

我建议的数据格式：

{
  "sn": "MEDBOX20241001A001",
  "test_time": "2024-10-01 14:30:25",
  "result": "PASS",
  "items": [
    {"name": "power", "value": 3.35, "unit": "V", "result": "PASS"},
    {"name": "motor_1", "value": 120, "unit": "mA", "result": "PASS"},
    {"name": "sensor_1", "value": 1, "unit": "", "result": "PASS"}
  ]
}

经验之谈：数据要存两份。一份本地，一份上传服务器。本地防断网，服务器方便分析。我见过一个工厂，服务器挂了，所有数据丢了，那叫一个惨。

4.5 避坑指南

最后，分享几个我踩过的坑：

治具接地：一定要接地。不接地的话，静电能把芯片打坏。我曾经一个月烧了5块板子，后来发现是治具没接地。
测试顺序：先测电源，再测功能。电源都不对，后面的测试全是白费。
异常处理：测试软件要能处理“测试中拔掉产品”的情况。不然产线工人手一抖，软件崩了，整条线等你重启。
人机界面：给产线工人的界面要简单。红绿指示灯+蜂鸣器就够了。别搞复杂菜单，工人没时间看。

嗯，FCT这一块，说难不难，说简单也不简单。关键是细节。你把治具做稳了，软件架构搭好了，数据管住了，产线就能跑得顺。下一章，我们聊聊老化测试，那又是另一番天地。

📚 课程目录