2. 食品MES业务蓝图与测试依据

食品MES的测试与通用离散制造MES有本质差别。离散行业更关注工单进度、物料齐套和工序流转，而食品工厂的合规压力集中在四个地方：批次追溯、效期管理、配方保密、清洁消毒。这四项特点决定了业务蓝图必须写清什么，也决定了测试用例从哪里来、验收时拿什么作为判据。如果蓝图只画了“计划—执行—入库”的主流程，却没有把批次谱系、效期扣减、配方权限、清洗状态这些约束落到字段和状态机上，后续测试就只能测界面和按钮，无法验证系统是否真正支撑食品安全。

一、四个食品特点如何转化为测试需求

批次追溯要求系统能回答“这一包成品用了哪些原料批次、经过哪些工序、发往哪个客户”。落到蓝图上，必须定义批次号生成规则（如“原料代码+供应商代码+到货日期+流水号”）、批次正反向追溯的层级（原料批次→半成品批次→成品批次→发货单），以及混批、拆批、并批时的谱系记录方式。测试需求由此产生：给定一个成品批次，能否在可接受时间内列出全部上游原料批次和下游去向；反向给定一个可疑原料批次，能否圈定受影响成品范围。

效期管理不只是记录保质期。食品原料常有“到货日期、生产日期、保质期、复检期、先进先出建议出库期”多个时间点，半成品还有敞口存放时限。蓝图需要明确：效期由哪个字段驱动、到期前多少天预警、过期物料是否允许被工单领用、临期成品是否自动降级或锁定。测试时要构造边界数据，例如保质期剩余0天、剩余1天、已过期1小时，观察系统在领料、投料、入库、发货各环节的拦截行为是否与蓝图一致。

配方保密是食品企业特别敏感的一点。配方是核心资产，车间操作工不应看到完整配比，但必须知道“投哪几种料、按什么顺序、控制在什么范围”。蓝图应设计配方分层：研发端维护完整BOM和工艺参数，生产端只下发工序级指令和保密代号，称量环节由系统校验总量与允差而不显示单项明细。测试需求包括权限矩阵验证、脱敏字段检查、越权访问日志，以及配方变更后的版本冻结与追溯。

清洁消毒在食品行业属于生产状态的一部分。同一台灌装机从含乳产品切换到果汁产品，必须经过规定的CIP清洗并记录清洗参数（温度、浓度、时长）。蓝图要把设备状态扩展为“待机、运行、清洗中、已清洗待验证、禁用”等，并把清洗记录与下一批生产许可绑定。测试时要验证：未完成清洗验证的设备能否被工单占用；清洗记录缺失时批次能否放行。

二、URS、FDS、蓝图与验收标准的对应关系

很多项目把URS写成愿望清单，把FDS写成功能目录，结果验收时双方各执一词。正确的做法是建立一条可追踪的链条：URS提出业务需求与合规底线，FDS把它翻译成字段、状态和接口，蓝图流程说明角色如何操作，验收标准给出可测量的判定条件。四者应逐条编号对应，形成需求追踪矩阵。

以效期管理为例。URS写“系统应防止过期原料投入生产”；FDS写“物料主数据含保质期天数，收货时生成到期日，领料校验到期日≥当前日期，过期物料状态置为冻结且不可被工单引用”；蓝图流程写“仓管收货→系统计算到期日→质检放行→领料时系统校验”；验收标准写“构造到期日为昨日的原料批次，尝试领料，系统应拒绝并提示，且该批次在可用库存中不可见”。这样一条链下来，测试人员不需要猜，开发人员也不会漏做。

需要提醒的是，验收标准必须可测量。像“追溯要快”不是验收标准，“输入成品批次号后，在5秒内返回全部上游原料批次及对应供应商”才是。像“配方要保密”也不是标准，“以操作工角色登录，配方明细页面不显示各原料克重，仅显示保密代号与总量允差”才是。示例中的5秒属于合理假设，实际项目应结合数据量和硬件条件在URS阶段约定。

三、测试需求来源的梳理方法

测试需求不应只来自FDS。实践中至少有五个来源：一是URS中的合规条款，尤其是食品安全法规和客户审核要求；二是FDS中的功能点和状态机；三是蓝图流程中的角色交接与审批节点；四是接口清单，包括ERP物料同步、称量设备采集、标签打印；五是历史偏差与客诉记录，这类来源最容易被忽略，却最能暴露真实风险。建议在蓝图评审阶段就同步建立测试需求清单，每条需求标注来源文档编号和优先级，避免上线前临时补用例。

四、一个可执行的验收判据示例

下面给出批次追溯与效期联动的验收判据片段，可直接用于测试用例设计。示例数据为教学假设，不代表真实项目实测结果。

这张表的价值在于把“食品特点”变成了可执行的判定动作。测试人员照着做，开发人员照着改，验收会上双方对着同一份判据确认，而不是对着模糊的描述争论。业务蓝图的意义也正在于此：它不是给领导看的流程图，而是测试依据的源头。蓝图写得越具体，测试越有据可依，验收越少扯皮。