测试工具需求分析：功能需求、非功能需求与硬件接口

做量产测试工具，最怕什么？

我最怕的是需求没想清楚就开干。代码写了一半，发现串口协议变了，或者测试项漏了。那感觉，就像你焊好一块板子，才发现电源接反了——全白干。

所以，今天咱们把需求分析这一步走扎实。说白了，就是搞清楚三件事：测什么、怎么测、用什么测。

功能需求：校准、功能测试、数据记录

功能需求是工具的灵魂。没有它，工具就是个空壳。

1. 校准

血氧仪的核心是光电传感器。但每个传感器都有个体差异。我遇到过一批传感器，同一光源下，输出值能差20%。不校准，数据根本没法看。

校准需求包括：

• 暗电流校准：无光条件下，传感器输出应为零。实际会有偏移，需要补偿。
• 光源强度校准：用标准光源照射，调整驱动电流，使输出值在标准范围内。
• 温度补偿校准：温度变化会影响光电特性。我习惯在25℃和40℃两个点做补偿。
• 校准参数存储：校准值要写入设备EEPROM或Flash。掉电不丢失。

2. 功能测试

校准完了，得验证它能不能正常工作。功能测试就是给设备做体检。

我一般把功能测试分成这几块：

• 上电自检：检查MCU、传感器、通信模块能否正常启动。
• 信号质量测试：用模拟手指（一个标准反射板）测试PPG信号幅度和信噪比。
• 血氧精度测试：输入已知血氧值（比如98%、95%、90%），看设备输出是否在±2%误差内。
• 心率测试：模拟不同心率（60bpm、80bpm、120bpm），验证检测精度。
• 通信测试：验证串口或USB数据包格式是否正确，有没有丢包。

3. 数据记录

测试数据是宝藏。但前提是你要能把它记下来。

数据记录需求：

• 测试结果记录：每个测试项的结果（PASS/FAIL）、测试值、上下限。
• 设备信息记录：序列号、固件版本、校准日期。
• 时间戳：精确到毫秒，方便追溯。
• 日志格式：我推荐用CSV或JSON。Excel直接打开，方便分析。
• 存储位置：本地文件 + 数据库（可选）。小批量用SQLite，大批量用MySQL。

非功能需求：稳定性、效率、易用性

功能需求决定了工具能不能用。非功能需求决定了工具好不好用。

1. 稳定性

量产测试是7x24小时跑的。工具崩溃一次，产线就停一次。损失的是真金白银。

我总结了几点：

• 内存管理：C++写的工具，注意内存泄漏。我习惯用智能指针，省心。
• 异常处理：串口断开、设备无响应、文件写入失败……每种异常都要有处理逻辑。
• 看门狗机制：工具自身要有心跳检测。如果某个测试卡住超过30秒，自动重启。
• 数据备份：测试记录每10条自动保存一次。防止断电丢数据。

2. 效率

产线是按秒算钱的。测试工具慢一秒，一天就少测几百台。

效率优化点：

• 并行测试：如果硬件支持，同时测4台或8台设备。我做过一个方案，用多线程+串口分时复用，效率提升了3倍。
• 减少等待时间：串口通信用DMA，别用轮询。轮询太慢了。
• 测试流程优化：把耗时长的测试项（比如温度补偿）放在最后，不阻塞其他测试。
• UI响应：测试过程中UI不能卡死。用异步更新，别在主线程里做耗时操作。

3. 易用性

操作工具的是产线工人，不是工程师。界面要简单到「看一眼就会用」。

我的设计原则：

• 大按钮、大字：按钮至少60x60像素，字体不小于14号。
• 状态一目了然：PASS显示绿色大勾，FAIL显示红色大叉。别用文字描述，工人没时间看。
• 错误提示要明确：别只显示「Error 0x01」。要显示「串口连接失败，请检查USB线」。
• 一键操作：放上设备，点击「开始测试」，等结果。就这么简单。

硬件接口需求：串口、USB、GPIO

软件再牛，也得通过硬件跟设备打交道。接口选型很重要。

1. 串口

串口是嵌入式世界的通用语言。简单、可靠、成本低。

需求细节：

• 波特率：我一般用115200或921600。太低了传输慢，太高了容易丢包。
• 数据格式：8位数据位，1位停止位，无校验。这是最通用的配置。
• 流控：硬件流控（RTS/CTS）可选。如果通信距离超过2米，建议开启。
• 多设备支持：工具要能同时管理多个串口。每个串口一个独立线程。

2. USB

USB适合大数据量传输，比如固件升级、批量日志导出。

需求要点：

• HID设备：免驱，即插即用。适合简单命令交互。
• CDC虚拟串口：兼容性好，Windows/Linux都支持。
• 高速模式：如果传输固件（几百KB），建议用USB 2.0 High-Speed。
• 热插拔检测：工具要能自动识别USB插入和拔出。别让工人手动刷新。

3. GPIO

GPIO用来控制外部硬件，比如继电器、指示灯、夹具。

常见用途：

• 控制测试夹具：按下按钮，夹具夹紧设备，开始测试。
• 状态指示：绿色LED表示测试通过，红色表示失败。
• 触发信号：给设备一个上升沿，让它开始采集数据。
• 电平检测：检测设备是否上电、是否进入测试模式。

GPIO控制我一般用FT232H或CH347这类USB转GPIO芯片。Python的pyftdi库很好用。

总结一下

需求分析这一步，花再多时间都值得。你想想看，如果需求没理清，后面写代码、调试、上线，每一步都是坑。

我个人习惯，在动手写代码之前，先画一张需求脑图。把功能需求、非功能需求、硬件接口需求全列出来。然后跟产线负责人、硬件工程师、测试工程师一起过一遍。确认无误，再开工。

这样做的好处是，后面几乎不会有大改动。我做过好几个项目，都是这么来的，很少返工。

好了，下一章咱们聊聊工具的整体架构设计。到时候我会分享一个我常用的框架，保证你看了就能用。