作者csdngouwei 2026-09-10关键词单元测试、工控软件、接口抽象、Mock、AI编程、C#开篇工控代码为什么没法测工控上位机的代码天生依赖真机读个传感器要走 PLC拍张图要开相机动一下要伺服使能。没有设备测试无从下手——所以大多数工控项目的测试方式是现场跑一跑出事再说。但这弹我想说不是没法测是分层没做好。把逻辑和硬件分离后80% 的业务逻辑可以在没有真机的开发机上跑自动化测试。核心思路硬件藏在接口后面定义一组接口IPlc读写点位、ICamera采图、IAxis运动。业务代码只依赖接口真机实现和 Mock 实现各自实现接口。测试时注入 MockMockPlc可以编程返回点位序列模拟气缸到位→传感器触发的时序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% 是过度设计。下一弹讲第三方工控库的逆向求生没有源码、没有文档怎么办。