作者：csdngouwei ｜ 2026-09-10
关键词：单元测试、工控软件、接口抽象、Mock、AI编程、C#
开篇：工控代码为什么"没法测"
工控上位机的代码天生依赖真机：读个传感器要走 PLC，拍张图要开相机，动一下要伺服使能。没有设备，测试无从下手——所以大多数工控项目的测试方式是"现场跑一跑，出事再说"。
但这弹我想说：不是没法测，是分层没做好。把"逻辑"和"硬件"分离后，80% 的业务逻辑可以在没有真机的开发机上跑自动化测试。
核心思路：硬件藏在接口后面
定义一组接口：IPlc（读写点位）、ICamera（采图）、IAxis（运动）。业务代码只依赖接口；真机实现和 Mock 实现各自实现接口。测试时注入 Mock：
MockPlc可以编程返回点位序列，模拟"气缸到位→传感器触发"的时序；MockAxis模拟运动耗时和到位信号，甚至可以故意注入"轴报错"，测试你的异常分支。
这些 Mock 类本身没有业务含义、行为可配置，是 AI 生成代码的理想素材——把接口定义贴给它，十分钟出全套 Mock 框架。
值得测的三类代码
- 流程逻辑：步序状态机的跳转（"上料→定位→加工→下料"每一步的条件与出口）；
- 数据换算：像素坐标转世界坐标、AD 值转工程量、节拍统计——纯函数，最好测；
- 异常分支：超时怎么办、NG 怎么流转、断线怎么重连。这些在真机上很难复现，恰恰是 Mock 的主场。
不值得测的：接口实现本身（真机 PLC 驱动包装类，Mock 它自己没有意义）、UI 窗体代码（人工点检更划算）。
AI 写测试的分工
- AI 生成：测试骨架、边界值用例（0、最大值、负数、null）、Mock 时序脚本；
- 人工补充：只有现场工程师才知道的"坑用例"——比如传感器信号抖动 50ms、气缸到位后又弹回去这类真实世界的脏数据场景。
让 AI 补完用例后跑覆盖率，80% 以上不难；但别追求 100%——工控代码里剩下的 20% 往往是 UI 和驱动壳，性价比极低。
一次真实的回报
用这套分层 + 测试，我们项目遇到过一次：客户要求改 NG 品重新流入的规则，改完跑了 137 个单元测试，3 个红了——全是当年埋的边界 bug，改规则把它们引爆了。没有测试，这仨 bug 就是现场停机两小时。
Mock 时序脚本示例
MockPlc最有价值的用法是编排时序，而不只是返回固定值：
mockPlc.SetupSequence("X0",delayMs:50,// 50ms 后到位 —— 正常returns:true);mockPlc.SetupJitter("X1",jitterMs:30);// 信号抖动 30ms —— 现场最常见的脏场景让步序引擎在"正常时序 / 到位超时 / 信号抖动 / 中途报警"四种剧本下各跑一遍，状态机所有出口都被覆盖。剧本编排这种声明式代码，AI 写起来又快又不容易错。
怎么在团队里推
工控团队推测试最大的阻力是"没时间"。我的落地经验：
- 不搞全量覆盖运动，只给新代码定规矩：新写的业务类必须带测试，老代码遇改才补（ opportunistic testing）；
- 测试跑进 CI（哪怕是本地一键脚本），跑不起来的测试活不过三个月；
- 让 AI 在 code review 环节自动检查"这个 bug 有没有对应测试用例"，没有就当场生成——测试欠账就这样一点点还清。
要点回顾
- 硬件藏到
IPlc/ICamera/IAxis接口后面，业务逻辑就能脱离真机测试； - 测三类：流程逻辑、数据换算、异常分支；不测 UI 和驱动壳；
- AI 生成测试骨架和边界用例，人工补"现场坑用例"；
- 覆盖率 80% 够用，100% 是过度设计。
下一弹讲第三方工控库的"逆向求生"：没有源码、没有文档，怎么办。
