去年年中我接手的一个MES项目准备上线当时整个团队卡在同一个问题上功能联调到底在哪里做。产线是24小时不停机的不可能让现场停下来配合你造数据开发环境里数据又太少工单只有三五笔撑不起一张像样的生产看板。更麻烦的是我们曾经直接在真实环境里做过一轮联调结果报表错乱、工单状态对不上、追溯链断裂车间主任差点把项目叫停。自那以后我就下定决心MES交付之前必须先有一套属于自己的虚拟测试系统。这套用Python写的MES虚拟测试系统V1.0就是冲着这个痛点去的。它做的事情很简单用代码虚拟出一个完整的车间环境包括工单、物料批次、设备状态、报工动作、质检任务让MES业务逻辑在没有真实产线的情况下也能被完整走通。适合谁看如果你是做MES、SFC这类制造系统的开发或实施人员正在为测试环境发愁或者想找一个低成本方式验证工单闭环、评估报表口径这篇内容应该能给你一些可以直接落地的思路。1. 为什么需要一套虚拟测试系统来支撑MES交付——从一次糟糕的上线经历说起1.1 真实产线环境不适合做功能验证的三大原因先说那段让我下定决心写这套系统的经历。当时做的是一个汽配零部件工厂的MES覆盖机加车间和装配车间的工单流转、工序报工、质量检验和批次追溯。项目进入联调阶段后我们试图直接在车间的测试工位上验证流程。结果发现自己陷入了一个死循环验证工单报废重开流程需要真实物料条码要造一个不良品得产线真的做出一个次品来想测设备故障降级总不能把机台真停了。更麻烦的是时间问题。一张工单从下达到完工在真实产线上要跑大半天而我们需要在两天内验证七八条业务主线根本等不起。最终我们硬着头皮在真实环境里并行测试结果生产数据被测试数据污染车间看板上出现了凭空多出的三千件在制品仓库那边库存账也对不上最后还是找数据库管理员手工清理才恢复。那次之后我彻底确认了三点真实产线无法配合你制造异常场景而异常场景恰恰是MES最容易翻车的地方。真实业务数据太稀疏一个班次才几十条报工记录根本压不出报表的边界问题。测试数据一旦混入真实数据清理成本极高甚至会直接影响生产账实一致。1.2 虚拟测试系统应该模拟到什么程度想清楚痛点之后问题就变成了这套系统到底要模拟到什么程度才算够用我的答案是不追求仿真设备的物理行为而是把MES业务交互涉及的所有外部输入都虚拟化。什么意思MES系统的输入无外乎几类计划系统的工单下达、操作工的开工报工动作、设备的状态上报、质检员的检验结果录入。虚拟测试系统只需要按照业务时序把这些输入按规则生成出来灌给MES服务端就能驱动业务逻辑流转。也就是说我不需要一个仿真的3D车间也不需要模拟PLC的物理信号我要的是业务逻辑层面的“真实”工单状态按规则推进库存扣减和产出增加在账面上能对上条码能被追溯到底。这套系统测的是MES自身的业务规则而不是自动化设备。这个定位让整个项目的工作量大大降低也让后续所有的代码设计都有了明确边界。2. 整体架构设计把整个车间折叠进一个Python进程里2.1 模块划分与数据流向想清楚模拟边界之后我把这套虚拟测试系统划分成了三个层次虚拟数据层、场景驱动层、业务验证层。虚拟数据层负责生成和存储模拟数据包括工单、物料批次、设备台账、操作工账号、检验计划。这些数据都存放在独立的测试数据库里和开发库、生产库物理隔离。场景驱动层是系统的引擎按照预设的生产场景以事件驱动的方式产生业务动作比如“开线”、“报工”、“质检送检”、“完工入库”。业务验证层则负责比对系统返回结果是否符合预期比如工单是否按预期状态流转、库存扣减是否正确、追溯查询能否返回完整链路。整体数据流向是这样的场景驱动层从虚拟数据层取出一张待执行的工单模拟操作工在某个工位执行开工动作调用MES服务端的开工接口MES根据自身逻辑校验物料齐套、校验工单状态然后更新数据库场景驱动层接着模拟报工接口、质检接口逐步把工单向完工推进最后验证层检查数据库里的最终状态和台账数据。说起来简单但这里有个关键决定所有驱动动作都通过接口走不直接改数据库。为什么要这样设计因为虚拟测试系统的价值就在于验证MES服务端逻辑如果测试脚本绕过接口直接操作数据库那测出来的结果毫无意义。哪怕第一次写脚本时感觉绕圈子也值得坚持这么做。2.2 技术选型与项目结构技术选型上我全部选了Python生态里最稳的组合。MES服务端本身在实际项目里是独立部署的但虚拟测试系统需要调用它所以测试系统内部保留了一个轻量的HTTP客户端封装。场景驱动层和数据库操作层都在同一个Python进程里减少部署复杂度。数据库用了SQLite为什么不用MySQL因为虚拟测试系统的数据量上限大概在几万条SQLite单文件特性让初始化、备份、重置都非常方便跑测试前一行命令就能恢复到干净状态。实测下来几万条记录下SQLite的性能完全不是瓶颈。项目结构是这样的mes_virtual_test/ ├── data/ # 初始化脚本、种子数据目录 │ ├── init_database.py │ └── seed_profiles.py # 产线、工位、工序定义 ├── driver/ # 场景驱动层 │ ├── order_driver.py # 工单生命周期驱动 │ ├── device_driver.py # 设备状态上报驱动 │ └── quality_driver.py # 质检流程驱动 ├── client/ # MES接口调用封装 │ └── mes_client.py ├── verifier/ # 业务验证层 │ └── assert_engine.py ├── sim_clock.py # 模拟时钟 └── main.py # 场景入口目录层级不复杂但每一层职责都单一。我最满意的部分是sim_clock.py它解决了一个很容易被忽略的问题业务场景的时间推进。虚拟测试不能真的等上八个小时才模拟一个班次所以系统里维护了一个可变速的模拟时钟场景驱动层生成的所有时间戳都通过它取而不是取操作系统当前时间。加速倍数设成60倍一秒模拟一分钟业务时间一个八小时班次大约八分钟就能跑完。代码上就是一个简单的类import time from datetime import datetime, timedelta class SimClock: def __init__(self, base_time: datetime, speed: int 60): self.epoch base_time self.speed speed def now(self) - datetime: elapsed_real time.time() - self.start_real return self.epoch timedelta(secondselapsed_real * self.speed) def advance(self, minutes: int): # 手动跳过一段时间用于跨天、换班场景 self.epoch self.epoch timedelta(minutesminutes)这里有几个细节需要说明。epoch一定要手动指定一个业务基准时间比如某天早上八点开线而不是直接用当前时间这样你才能稳定复现“跨天班次”、“月底结账”这类边界场景。另外真实时间通过time.time()获取保证时间推进是连续的而不是靠循环sleep硬等这样在跑自动化测试时效率会高很多。3. 核心业务场景的实现路径从工单下发到成品入库的主线闭环3.1 工单生命周期状态机的约束力量MES里最核心的主线就是工单。工单从计划系统下发到车间执行再到完工入库整个生命周期里的状态流转必须被严格约束。虚拟测试系统的第一个任务就是把这条主线原原本本跑通并且验证工单状态不允许发生非法跳转。在设计虚拟工单模型时我把状态定义成枚举并为每个状态定义合法的迁移路径from enum import Enum, auto class OrderStatus(Enum): CREATED auto() # 已创建 RELEASED auto() # 已下达 IN_PROGRESS auto() # 生产中 PAUSED auto() # 暂停 COMPLETED auto() # 完工 CLOSED auto() # 关闭 def can_transit(self, target): if self OrderStatus.CREATED: return target in (OrderStatus.RELEASED, OrderStatus.CLOSED) if self OrderStatus.RELEASED: return target in (OrderStatus.IN_PROGRESS, OrderStatus.CLOSED) if self OrderStatus.IN_PROGRESS: return target in (OrderStatus.PAUSED, OrderStatus.COMPLETED) if self OrderStatus.PAUSED: return target in (OrderStatus.IN_PROGRESS, OrderStatus.CLOSED) if self OrderStatus.COMPLETED: return target OrderStatus.CLOSED return False状态机写起来很直白但它带来的约束价值很大。之前真实环境里就出现过一种情况操作工在工单还没下达时就能报工因为旧版接口没有做状态校验。虚拟测试系统里专门构造了这种越权场景用pytest断言系统必须拒绝否则测试直接失败。这就是V1.0里最值得保留的一部分逻辑相当于把MES的工单规则用代码钉死了。你可能会问为什么不在MES服务端进一步加强状态校验反而在测试系统里花时间写状态机原因是两边都做了但目的不同。MES服务端做校验是业务防线虚拟测试系统里做状态机则是为了生成合理的测试数据——只有状态机约束正确场景驱动层才不会跑出一个逻辑混乱的工单后续的追溯断言也才有意义。3.2 报工逻辑让每一笔产出都落到账上工单处于生产中状态后就进入报工环节。报工的动作看起来只是填一个数字实际上牵动的是整个台账链路良品数增加、不良品数增加、在制品减少、完成数量更新、工位产出记录落表。虚拟测试系统里我实现了一套报工驱动脚本专门检验这个链路的一致性。核心逻辑简化后大致是这样的def report_production(order_id, station_id, operator, good_qty, bad_qty): with db.transaction(): order get_order(order_id) if order.status ! OrderStatus.IN_PROGRESS: raise BusinessError(工单不在生产状态不能报工) wip get_wip(order_id, station_id) wip.good_qty good_qty wip.bad_qty bad_qty order.total_good good_qty order.total_bad bad_qty if order.total_good order.total_bad order.plan_qty: order.status OrderStatus.COMPLETED save(order, wip) record_production_log(order, station_id, operator, good_qty, bad_qty, sim_clock.now())这里有三个点需要特别注意。第一事务性。报工导致的工单更新和在制品更新必须在一个事务里绝不允许出现工单累计数变了、在制品却没有扣减的半截状态。我在虚拟测试脚本里专门构造过事务中途失败的情况验证回滚是否彻底。第二完工条件的边界。很多MES会允许超额报工比如计划100件但实际操作中可以超产到105件也可能最后只做98件就强制关闭。我实现的是大于等于计划数就置为完工但实际做需求分析的时候一定要确认你们业务方接受哪种策略因为这直接影响报工的判定条件。第三记录的同时用模拟时钟时间而不是真实时间。这一点对于班次归属的验证至关重要后面会单独说。3.3 虚拟质检与不良品处置让质量流程也能被排练质检对生产业务来说是不折不扣的关键路径。MES里常见的质检流程是这样的报工达到一定数量之后系统按检验计划生成送检任务质检员在虚拟测试中模拟抽样录入合格数和不合格数系统根据不良率触发判定或放行或判退。我在虚拟质检模块里实现的核心验证点是不良品必须能够反查到对应工位、对应批次、对应操作工。也就是说一个批次出了质量异常系统按产品条码回溯能一直查到它是哪张工单、哪个工序、哪个工位流出来的。虚拟测试系统在造数据时会刻意让一批产品带着一定的缺陷标记待质检判定后再调用MES的追溯接口断言返回链路完整。除了正常流程还需要模拟一些偏执场景。比如操作工报工100件但质检任务只生成了80件的送检需求剩余20件是否被正确标记为待检再比如批量不合格导致的工单强制关闭是否同步触发了物料冻结这些场景在真实环境里可能一个月都遇不到一次但在虚拟测试系统里我一天可以跑二十遍确保每一次行为都符合预期。4. 让虚拟环境更可信的四个关键机制4.1 模拟时钟与班次归属的正确性很多MES系统有一个隐藏的雷班次归属。夜班跨天凌晨一点钟的报工记录到底算昨天夜班还是今天白班如果系统按自然日去归集报表就会在换班日出现严重错位。真实项目里我们吃过这个亏夜班产量被记到当天导致车间主任看到的凌晨班产量永远是低的。虚拟测试系统里我专门用模拟时钟把时间推进到一个夜班的凌晨时段然后驱动报工流程最后查看班次统计报表。这个场景我跑了不下十遍直到确认系统的班次归属逻辑是按交班时刻切分而不是按零点切分。如果你也要做类似的虚拟测试建议把跨天班次作为头号边界场景写进测试计划不要等到客户上线报表发现问题才补。4.2 数据生成策略与边界压力虚拟测试系统不能只用干净温和的数据。我在种子数据里准备了几个固定档位基础档位几千条工单压力档位一次性生成几万条报工记录专门用来测分页和聚合查询。生成器本身不复杂但有一个设计要点数据必须带可辨识特征比如批量号里嵌入一个固定前缀方便测试后按前缀批量清理。边界数据方面我覆盖了这些场景计划数量为1的工单验证最小粒度的承接。计划数量为99999的大工单验证数量字段是否溢出、汇总是否异常。完全没有任何物料BOM的工单验证物料齐套校验能否正确拦截。设备台账里存在停用设备验证开线动作是否会引用到停用设备。这些数据看起来极端但它们恰恰是MES系统里最容易出现隐性Bug的地方。4.3 异常场景注入把故障提前暴露在测试期V1.0里我专门做了一个故障注入模块用法是在场景驱动脚本里主动制造非预期输入。比如操作工连扫两次同一个条码、报工数量为负数、工单未下达就尝试开工、设备离线状态下仍然上报产出数据。这部分的代码逻辑不复杂但价值非常大因为MES实施过程中最怕的事就是你无法判断系统在真实异常面前是否能够优雅处理。有了故障注入我可以在版本发布前就知道接口是返了明确错误码还是直接抛了一个难以追踪的异常。实测下来光这一个模块就在测试期帮我们拦下了三个必现的接口空指针问题。4.4 可重置性让每一次测试都从同一条件出发最后要说的是可重置性。虚拟测试系统如果没有一键初始化的能力用着用着数据就会越跑越脏最后连自己都分不清哪些是预期数据、哪些是残留数据。我实现了python main.py --reset命令执行后直接删除数据库文件重建表结构灌入种子数据整个过程保持幂等。一开始团队成员并不重视这个设计觉得多写一个初始化脚本无所谓。直到有一次联调A同学的测试工单和别人的测试工单互相串号排查了半天才发现是共享数据库导致的。从那天起大家都默认在跑测试前先执行一次重置命令彻底避免了这种互相污染的问题。5. 联调与验收中踩过的坑虚拟环境暴露的真实缺陷5.1 跨天班次报表错位最先暴露第三部分提到的班次归属问题不是我在设计时主动发现的而是虚拟测试系统第一次跑全流程生产报表时暴露的。当时我模拟了一个从早上八点到第二天早上六点的长班次半小时驱动一次报工跑完后打开班次产量报表发现凌晨的产量全部被归到了新的一天。如果这套系统没有虚拟时钟我根本不可能在一个下午内复现这种跨天的时序问题它靠真实环境可能要在工厂上跑两个星期才能暴露。5.2 并发报工导致工单累计数丢失还有一次印象深刻的Bug是并发报工引起的。虚拟测试系统里我写了多线程脚本模拟五个工位同时给同一张工单报工每个工位各报20件。线程跑完后检查工单总完成数发现只有60件有40件凭空丢了。排查后发现根因是报工接口里先读后写并发情况下读取到的是旧值然后各自覆盖写入后写的那次把前一次的结果冲掉了。这个Bug在真实产线迟早会出现——因为产线本来就是多工位同时作业的。虚拟测试系统把这个并发场景稳定重现提供了一个默默修炼出来的重要价值MES联调期一定要做并发测试单线程跑通只代表功能正确不代表数据正确。5.3 设备心跳状态机不一致开线卡壳还有一个典型的MES问题体现在设备管理上。设备驱动脚本按顺序上报了“开机、待机、运行、待机、报警、恢复”结果MES里的设备状态在报警恢复后没有同步回运行态而是变成了空闲状态。原因是设备模块的状态迁移只在特定上报类型里处理“恢复”事件漏写了状态回切逻辑。虚拟测试系统里的设备驱动脚本相当于把一整天的设备运行序列浓缩在几分钟里跑完任何一个状态回切遗漏都会在测试期冒出来而不是等客户在现场盯着看板时才发现。这个排查过程给我的启发是设备虚拟化不能只模拟正常开关机必须把报警、恢复、离线、重连、换型等中间状态全部纳入场景设计否则设备看板的状态展示就永远不可信。6. 虚拟测试系统的扩展价值与维护心得6.1 从测试工具到业务沙盘的延伸V1.0原本只是为解决测试环境问题而生但用了一段时间后我发现它的价值远超预期逐渐变成了一个业务沙盘。一方面车间管理人员可以用它来做操作培训。新员工在虚拟环境里操作MES点错了不会产生真实后果效率却比在产线上培训高很多。另一方面新需求评审时我可以直接在虚拟环境里跑一遍当前逻辑再跑一遍改后逻辑用账单对比的方式看清楚行为差异。有些改造在纸面上说不清楚的在沙盘里一比就直观了。6.2 维护这套系统的几条心得最后分享几条维护层面的实在体会。第一场景驱动脚本要按业务主线组织不要全部揉进一个main.py。工单主线是工单驱动者质量主线是质检驱动者即使它们在业务上有先后关系代码上也应该保持解耦。否则等场景变多脚本文件会变成一团乱麻。第二初始化数据要纳入版本管理。种子数据的变动会影响测试结果所以我把data/seed_profiles.py放在Git里任何变更都要走代码评审避免有人默默改了种子数据导致场景失效。第三验证断言不要只盯着接口返回的code。接口返回成功不代业务真的成功必须加数据库层面的核对断言比如工单最终状态、库存余额、在制品数量。我在V1.0中后期把绝大部分断言都改成了“接口断言落库断言”双层结构这才真正建立起了测试可信度。第四也是最想强调的一点虚拟测试系统不是一次性交付物而是需要和MES本体共同演进。MES每次加字段、加接口虚拟测试脚本就要同步更新。V1.0只覆盖了机加工序的主链路装配环节的成套件管理、委外工序回参、计划变更冲销都还没有覆盖这些是下一步准备补齐的方向。目前已跑通的场景脚本我会持续回填到自动化流水线里让每次MES版本提交都自动跑一遍虚拟产线降低回归测试的成本。说到底MES系统的上线靠人肉验证是靠不住的一套能模拟车间运转的虚拟测试系统才是把交付风险挡在门外的最后一道闸。这套V1.0的代码量不算多但它在那个项目里实实在在帮我避开了好几个真要炸到现场才发现的雷。如果你也在做MES相关的实施或开发不妨按这个思路搭一套自己的虚拟车间成本不高收益却很直接。 
长河君 · 2026/10/13 20:12:12 · 阅读 1.2k 用Python构建MES虚拟测试系统：从车间仿真到业务验证
去年年中我接手的一个MES项目准备上线当时整个团队卡在同一个问题上功能联调到底在哪里做。产线是24小时不停机的不可能让现场停下来配合你造数据开发环境里数据又太少工单只有三五笔撑不起一张像样的生产看板。更麻烦的是我们曾经直接在真实环境里做过一轮联调结果报表错乱、工单状态对不上、追溯链断裂车间主任差点把项目叫停。自那以后我就下定决心MES交付之前必须先有一套属于自己的虚拟测试系统。这套用Python写的MES虚拟测试系统V1.0就是冲着这个痛点去的。它做的事情很简单用代码虚拟出一个完整的车间环境包括工单、物料批次、设备状态、报工动作、质检任务让MES业务逻辑在没有真实产线的情况下也能被完整走通。适合谁看如果你是做MES、SFC这类制造系统的开发或实施人员正在为测试环境发愁或者想找一个低成本方式验证工单闭环、评估报表口径这篇内容应该能给你一些可以直接落地的思路。1. 为什么需要一套虚拟测试系统来支撑MES交付——从一次糟糕的上线经历说起1.1 真实产线环境不适合做功能验证的三大原因先说那段让我下定决心写这套系统的经历。当时做的是一个汽配零部件工厂的MES覆盖机加车间和装配车间的工单流转、工序报工、质量检验和批次追溯。项目进入联调阶段后我们试图直接在车间的测试工位上验证流程。结果发现自己陷入了一个死循环验证工单报废重开流程需要真实物料条码要造一个不良品得产线真的做出一个次品来想测设备故障降级总不能把机台真停了。更麻烦的是时间问题。一张工单从下达到完工在真实产线上要跑大半天而我们需要在两天内验证七八条业务主线根本等不起。最终我们硬着头皮在真实环境里并行测试结果生产数据被测试数据污染车间看板上出现了凭空多出的三千件在制品仓库那边库存账也对不上最后还是找数据库管理员手工清理才恢复。那次之后我彻底确认了三点真实产线无法配合你制造异常场景而异常场景恰恰是MES最容易翻车的地方。真实业务数据太稀疏一个班次才几十条报工记录根本压不出报表的边界问题。测试数据一旦混入真实数据清理成本极高甚至会直接影响生产账实一致。1.2 虚拟测试系统应该模拟到什么程度想清楚痛点之后问题就变成了这套系统到底要模拟到什么程度才算够用我的答案是不追求仿真设备的物理行为而是把MES业务交互涉及的所有外部输入都虚拟化。什么意思MES系统的输入无外乎几类计划系统的工单下达、操作工的开工报工动作、设备的状态上报、质检员的检验结果录入。虚拟测试系统只需要按照业务时序把这些输入按规则生成出来灌给MES服务端就能驱动业务逻辑流转。也就是说我不需要一个仿真的3D车间也不需要模拟PLC的物理信号我要的是业务逻辑层面的“真实”工单状态按规则推进库存扣减和产出增加在账面上能对上条码能被追溯到底。这套系统测的是MES自身的业务规则而不是自动化设备。这个定位让整个项目的工作量大大降低也让后续所有的代码设计都有了明确边界。2. 整体架构设计把整个车间折叠进一个Python进程里2.1 模块划分与数据流向想清楚模拟边界之后我把这套虚拟测试系统划分成了三个层次虚拟数据层、场景驱动层、业务验证层。虚拟数据层负责生成和存储模拟数据包括工单、物料批次、设备台账、操作工账号、检验计划。这些数据都存放在独立的测试数据库里和开发库、生产库物理隔离。场景驱动层是系统的引擎按照预设的生产场景以事件驱动的方式产生业务动作比如“开线”、“报工”、“质检送检”、“完工入库”。业务验证层则负责比对系统返回结果是否符合预期比如工单是否按预期状态流转、库存扣减是否正确、追溯查询能否返回完整链路。整体数据流向是这样的场景驱动层从虚拟数据层取出一张待执行的工单模拟操作工在某个工位执行开工动作调用MES服务端的开工接口MES根据自身逻辑校验物料齐套、校验工单状态然后更新数据库场景驱动层接着模拟报工接口、质检接口逐步把工单向完工推进最后验证层检查数据库里的最终状态和台账数据。说起来简单但这里有个关键决定所有驱动动作都通过接口走不直接改数据库。为什么要这样设计因为虚拟测试系统的价值就在于验证MES服务端逻辑如果测试脚本绕过接口直接操作数据库那测出来的结果毫无意义。哪怕第一次写脚本时感觉绕圈子也值得坚持这么做。2.2 技术选型与项目结构技术选型上我全部选了Python生态里最稳的组合。MES服务端本身在实际项目里是独立部署的但虚拟测试系统需要调用它所以测试系统内部保留了一个轻量的HTTP客户端封装。场景驱动层和数据库操作层都在同一个Python进程里减少部署复杂度。数据库用了SQLite为什么不用MySQL因为虚拟测试系统的数据量上限大概在几万条SQLite单文件特性让初始化、备份、重置都非常方便跑测试前一行命令就能恢复到干净状态。实测下来几万条记录下SQLite的性能完全不是瓶颈。项目结构是这样的mes_virtual_test/ ├── data/ # 初始化脚本、种子数据目录 │ ├── init_database.py │ └── seed_profiles.py # 产线、工位、工序定义 ├── driver/ # 场景驱动层 │ ├── order_driver.py # 工单生命周期驱动 │ ├── device_driver.py # 设备状态上报驱动 │ └── quality_driver.py # 质检流程驱动 ├── client/ # MES接口调用封装 │ └── mes_client.py ├── verifier/ # 业务验证层 │ └── assert_engine.py ├── sim_clock.py # 模拟时钟 └── main.py # 场景入口目录层级不复杂但每一层职责都单一。我最满意的部分是sim_clock.py它解决了一个很容易被忽略的问题业务场景的时间推进。虚拟测试不能真的等上八个小时才模拟一个班次所以系统里维护了一个可变速的模拟时钟场景驱动层生成的所有时间戳都通过它取而不是取操作系统当前时间。加速倍数设成60倍一秒模拟一分钟业务时间一个八小时班次大约八分钟就能跑完。代码上就是一个简单的类import time from datetime import datetime, timedelta class SimClock: def __init__(self, base_time: datetime, speed: int 60): self.epoch base_time self.speed speed def now(self) - datetime: elapsed_real time.time() - self.start_real return self.epoch timedelta(secondselapsed_real * self.speed) def advance(self, minutes: int): # 手动跳过一段时间用于跨天、换班场景 self.epoch self.epoch timedelta(minutesminutes)这里有几个细节需要说明。epoch一定要手动指定一个业务基准时间比如某天早上八点开线而不是直接用当前时间这样你才能稳定复现“跨天班次”、“月底结账”这类边界场景。另外真实时间通过time.time()获取保证时间推进是连续的而不是靠循环sleep硬等这样在跑自动化测试时效率会高很多。3. 核心业务场景的实现路径从工单下发到成品入库的主线闭环3.1 工单生命周期状态机的约束力量MES里最核心的主线就是工单。工单从计划系统下发到车间执行再到完工入库整个生命周期里的状态流转必须被严格约束。虚拟测试系统的第一个任务就是把这条主线原原本本跑通并且验证工单状态不允许发生非法跳转。在设计虚拟工单模型时我把状态定义成枚举并为每个状态定义合法的迁移路径from enum import Enum, auto class OrderStatus(Enum): CREATED auto() # 已创建 RELEASED auto() # 已下达 IN_PROGRESS auto() # 生产中 PAUSED auto() # 暂停 COMPLETED auto() # 完工 CLOSED auto() # 关闭 def can_transit(self, target): if self OrderStatus.CREATED: return target in (OrderStatus.RELEASED, OrderStatus.CLOSED) if self OrderStatus.RELEASED: return target in (OrderStatus.IN_PROGRESS, OrderStatus.CLOSED) if self OrderStatus.IN_PROGRESS: return target in (OrderStatus.PAUSED, OrderStatus.COMPLETED) if self OrderStatus.PAUSED: return target in (OrderStatus.IN_PROGRESS, OrderStatus.CLOSED) if self OrderStatus.COMPLETED: return target OrderStatus.CLOSED return False状态机写起来很直白但它带来的约束价值很大。之前真实环境里就出现过一种情况操作工在工单还没下达时就能报工因为旧版接口没有做状态校验。虚拟测试系统里专门构造了这种越权场景用pytest断言系统必须拒绝否则测试直接失败。这就是V1.0里最值得保留的一部分逻辑相当于把MES的工单规则用代码钉死了。你可能会问为什么不在MES服务端进一步加强状态校验反而在测试系统里花时间写状态机原因是两边都做了但目的不同。MES服务端做校验是业务防线虚拟测试系统里做状态机则是为了生成合理的测试数据——只有状态机约束正确场景驱动层才不会跑出一个逻辑混乱的工单后续的追溯断言也才有意义。3.2 报工逻辑让每一笔产出都落到账上工单处于生产中状态后就进入报工环节。报工的动作看起来只是填一个数字实际上牵动的是整个台账链路良品数增加、不良品数增加、在制品减少、完成数量更新、工位产出记录落表。虚拟测试系统里我实现了一套报工驱动脚本专门检验这个链路的一致性。核心逻辑简化后大致是这样的def report_production(order_id, station_id, operator, good_qty, bad_qty): with db.transaction(): order get_order(order_id) if order.status ! OrderStatus.IN_PROGRESS: raise BusinessError(工单不在生产状态不能报工) wip get_wip(order_id, station_id) wip.good_qty good_qty wip.bad_qty bad_qty order.total_good good_qty order.total_bad bad_qty if order.total_good order.total_bad order.plan_qty: order.status OrderStatus.COMPLETED save(order, wip) record_production_log(order, station_id, operator, good_qty, bad_qty, sim_clock.now())这里有三个点需要特别注意。第一事务性。报工导致的工单更新和在制品更新必须在一个事务里绝不允许出现工单累计数变了、在制品却没有扣减的半截状态。我在虚拟测试脚本里专门构造过事务中途失败的情况验证回滚是否彻底。第二完工条件的边界。很多MES会允许超额报工比如计划100件但实际操作中可以超产到105件也可能最后只做98件就强制关闭。我实现的是大于等于计划数就置为完工但实际做需求分析的时候一定要确认你们业务方接受哪种策略因为这直接影响报工的判定条件。第三记录的同时用模拟时钟时间而不是真实时间。这一点对于班次归属的验证至关重要后面会单独说。3.3 虚拟质检与不良品处置让质量流程也能被排练质检对生产业务来说是不折不扣的关键路径。MES里常见的质检流程是这样的报工达到一定数量之后系统按检验计划生成送检任务质检员在虚拟测试中模拟抽样录入合格数和不合格数系统根据不良率触发判定或放行或判退。我在虚拟质检模块里实现的核心验证点是不良品必须能够反查到对应工位、对应批次、对应操作工。也就是说一个批次出了质量异常系统按产品条码回溯能一直查到它是哪张工单、哪个工序、哪个工位流出来的。虚拟测试系统在造数据时会刻意让一批产品带着一定的缺陷标记待质检判定后再调用MES的追溯接口断言返回链路完整。除了正常流程还需要模拟一些偏执场景。比如操作工报工100件但质检任务只生成了80件的送检需求剩余20件是否被正确标记为待检再比如批量不合格导致的工单强制关闭是否同步触发了物料冻结这些场景在真实环境里可能一个月都遇不到一次但在虚拟测试系统里我一天可以跑二十遍确保每一次行为都符合预期。4. 让虚拟环境更可信的四个关键机制4.1 模拟时钟与班次归属的正确性很多MES系统有一个隐藏的雷班次归属。夜班跨天凌晨一点钟的报工记录到底算昨天夜班还是今天白班如果系统按自然日去归集报表就会在换班日出现严重错位。真实项目里我们吃过这个亏夜班产量被记到当天导致车间主任看到的凌晨班产量永远是低的。虚拟测试系统里我专门用模拟时钟把时间推进到一个夜班的凌晨时段然后驱动报工流程最后查看班次统计报表。这个场景我跑了不下十遍直到确认系统的班次归属逻辑是按交班时刻切分而不是按零点切分。如果你也要做类似的虚拟测试建议把跨天班次作为头号边界场景写进测试计划不要等到客户上线报表发现问题才补。4.2 数据生成策略与边界压力虚拟测试系统不能只用干净温和的数据。我在种子数据里准备了几个固定档位基础档位几千条工单压力档位一次性生成几万条报工记录专门用来测分页和聚合查询。生成器本身不复杂但有一个设计要点数据必须带可辨识特征比如批量号里嵌入一个固定前缀方便测试后按前缀批量清理。边界数据方面我覆盖了这些场景计划数量为1的工单验证最小粒度的承接。计划数量为99999的大工单验证数量字段是否溢出、汇总是否异常。完全没有任何物料BOM的工单验证物料齐套校验能否正确拦截。设备台账里存在停用设备验证开线动作是否会引用到停用设备。这些数据看起来极端但它们恰恰是MES系统里最容易出现隐性Bug的地方。4.3 异常场景注入把故障提前暴露在测试期V1.0里我专门做了一个故障注入模块用法是在场景驱动脚本里主动制造非预期输入。比如操作工连扫两次同一个条码、报工数量为负数、工单未下达就尝试开工、设备离线状态下仍然上报产出数据。这部分的代码逻辑不复杂但价值非常大因为MES实施过程中最怕的事就是你无法判断系统在真实异常面前是否能够优雅处理。有了故障注入我可以在版本发布前就知道接口是返了明确错误码还是直接抛了一个难以追踪的异常。实测下来光这一个模块就在测试期帮我们拦下了三个必现的接口空指针问题。4.4 可重置性让每一次测试都从同一条件出发最后要说的是可重置性。虚拟测试系统如果没有一键初始化的能力用着用着数据就会越跑越脏最后连自己都分不清哪些是预期数据、哪些是残留数据。我实现了python main.py --reset命令执行后直接删除数据库文件重建表结构灌入种子数据整个过程保持幂等。一开始团队成员并不重视这个设计觉得多写一个初始化脚本无所谓。直到有一次联调A同学的测试工单和别人的测试工单互相串号排查了半天才发现是共享数据库导致的。从那天起大家都默认在跑测试前先执行一次重置命令彻底避免了这种互相污染的问题。5. 联调与验收中踩过的坑虚拟环境暴露的真实缺陷5.1 跨天班次报表错位最先暴露第三部分提到的班次归属问题不是我在设计时主动发现的而是虚拟测试系统第一次跑全流程生产报表时暴露的。当时我模拟了一个从早上八点到第二天早上六点的长班次半小时驱动一次报工跑完后打开班次产量报表发现凌晨的产量全部被归到了新的一天。如果这套系统没有虚拟时钟我根本不可能在一个下午内复现这种跨天的时序问题它靠真实环境可能要在工厂上跑两个星期才能暴露。5.2 并发报工导致工单累计数丢失还有一次印象深刻的Bug是并发报工引起的。虚拟测试系统里我写了多线程脚本模拟五个工位同时给同一张工单报工每个工位各报20件。线程跑完后检查工单总完成数发现只有60件有40件凭空丢了。排查后发现根因是报工接口里先读后写并发情况下读取到的是旧值然后各自覆盖写入后写的那次把前一次的结果冲掉了。这个Bug在真实产线迟早会出现——因为产线本来就是多工位同时作业的。虚拟测试系统把这个并发场景稳定重现提供了一个默默修炼出来的重要价值MES联调期一定要做并发测试单线程跑通只代表功能正确不代表数据正确。5.3 设备心跳状态机不一致开线卡壳还有一个典型的MES问题体现在设备管理上。设备驱动脚本按顺序上报了“开机、待机、运行、待机、报警、恢复”结果MES里的设备状态在报警恢复后没有同步回运行态而是变成了空闲状态。原因是设备模块的状态迁移只在特定上报类型里处理“恢复”事件漏写了状态回切逻辑。虚拟测试系统里的设备驱动脚本相当于把一整天的设备运行序列浓缩在几分钟里跑完任何一个状态回切遗漏都会在测试期冒出来而不是等客户在现场盯着看板时才发现。这个排查过程给我的启发是设备虚拟化不能只模拟正常开关机必须把报警、恢复、离线、重连、换型等中间状态全部纳入场景设计否则设备看板的状态展示就永远不可信。6. 虚拟测试系统的扩展价值与维护心得6.1 从测试工具到业务沙盘的延伸V1.0原本只是为解决测试环境问题而生但用了一段时间后我发现它的价值远超预期逐渐变成了一个业务沙盘。一方面车间管理人员可以用它来做操作培训。新员工在虚拟环境里操作MES点错了不会产生真实后果效率却比在产线上培训高很多。另一方面新需求评审时我可以直接在虚拟环境里跑一遍当前逻辑再跑一遍改后逻辑用账单对比的方式看清楚行为差异。有些改造在纸面上说不清楚的在沙盘里一比就直观了。6.2 维护这套系统的几条心得最后分享几条维护层面的实在体会。第一场景驱动脚本要按业务主线组织不要全部揉进一个main.py。工单主线是工单驱动者质量主线是质检驱动者即使它们在业务上有先后关系代码上也应该保持解耦。否则等场景变多脚本文件会变成一团乱麻。第二初始化数据要纳入版本管理。种子数据的变动会影响测试结果所以我把data/seed_profiles.py放在Git里任何变更都要走代码评审避免有人默默改了种子数据导致场景失效。第三验证断言不要只盯着接口返回的code。接口返回成功不代业务真的成功必须加数据库层面的核对断言比如工单最终状态、库存余额、在制品数量。我在V1.0中后期把绝大部分断言都改成了“接口断言落库断言”双层结构这才真正建立起了测试可信度。第四也是最想强调的一点虚拟测试系统不是一次性交付物而是需要和MES本体共同演进。MES每次加字段、加接口虚拟测试脚本就要同步更新。V1.0只覆盖了机加工序的主链路装配环节的成套件管理、委外工序回参、计划变更冲销都还没有覆盖这些是下一步准备补齐的方向。目前已跑通的场景脚本我会持续回填到自动化流水线里让每次MES版本提交都自动跑一遍虚拟产线降低回归测试的成本。说到底MES系统的上线靠人肉验证是靠不住的一套能模拟车间运转的虚拟测试系统才是把交付风险挡在门外的最后一道闸。这套V1.0的代码量不算多但它在那个项目里实实在在帮我避开了好几个真要炸到现场才发现的雷。如果你也在做MES相关的实施或开发不妨按这个思路搭一套自己的虚拟车间成本不高收益却很直接。