1. 从一张产线报表说起为什么这四个缩写总让人犯迷糊如果你在制造业、硬件测试、软件质量或者任何跟“检验”打交道的岗位上待过大概率见过这样的场景一份测试报表上密密麻麻标着OK、POK、NG、NT新人看了半天不敢下结论老手扫一眼就知道哪批货能放行、哪批要返工、哪批还得等结果。这四个缩写看起来简单但真正把它们用对、用准其实藏着不少门道。我第一次系统接触这套标记是在一条电子组件的测试线上。当时产线主管指着报表问我“这批POK的能不能直接入库”我愣了一下——POK不是“Pass OK”吗那不就是OK后来才明白这两个词在测试语境里根本不是一回事。OK是最终判定合格POK是“本次测试项目合格”但它可能只是整个检验流程中的一个环节后面还有别的关卡等着。这个区别要是搞混轻则报表填错重则整批货被误放行或者误拦截。所以这篇内容我想把OK、POK、NG、NT这四个测试结果标记彻底讲清楚。它们分别代表什么、在什么场景下用、容易踩哪些坑、报表上怎么组合使用才不出错。不管你是刚入行的测试员、质量工程师还是做测试系统开发的程序员只要你的工作里会出现“判定结果”这四个字这些内容都用得上。我会尽量用产线和实验室里的真实逻辑来讲不堆术语把每个缩写的来龙去脉和实操细节都摊开说。2. 四个标记的底层逻辑它们到底在判定什么2.1 OK最终放行的“通行证”不是随便给的OK这个词太常见了常见到很多人觉得它没什么好讲的。但在测试领域OK的含义非常明确被测对象在所有规定的检验项目上均满足判定标准且整个检验流程已经走完可以进入下一环节。注意这里有两个关键词——“所有规定项目”和“流程走完”。我见过不少新手把某个单项测试通过就标成OK这是典型的误用。举个例子一个电源模块要测输出电压、纹波、效率、温升四个项目。如果只测了输出电压合格其他三项还没测这时候标OK就是给自己挖坑。正确的做法是标POK表示当前这项过了但整体结论还没出来。等四项全过才能把最终状态改成OK。从系统设计角度OK通常对应一个终态。在MES制造执行系统或者测试管理软件里OK状态往往意味着这条记录可以被锁定、可以触发入库或出货流程。所以给OK要谨慎它不是一个“还不错”的评价而是一个具有流程意义的放行信号。提示如果你的测试系统里OK可以被随意修改建议加一道权限控制。终态被误改是产线数据混乱的常见根源。2.2 POK过程合格但别急着下最终结论POK是这四个标记里最容易被误解的。有人说是“Pass OK”有人说是“Partial OK”其实在多数测试规范里POK指的是当前测试项目或当前测试站点的判定结果为合格它是一个过程性、阶段性的结论。为什么需要POK因为现代测试流程往往是分站点的。比如一个产品要经过ICT在线测试、FCT功能测试、老化测试、外观检验四道关。每道关都有自己的判定。如果每道关都只标OK那最后汇总时根本分不清是哪个环节的OK。POK的出现就是为了把“局部合格”和“整体合格”区分开。在实际报表里POK经常和站点编号一起出现比如“POK-ICT”“POK-FCT”。这样追溯的时候一目了然这个产品在ICT站点是合格的在FCT站点也是合格的但最终OK还没生成可能还在等老化结果。我个人的经验是POK最适合用在多工序、多站点的测试场景。如果是单站点一次性测完POK和OK的区别就不大但为了规范还是建议统一用OK表示终态POK表示过程态。这样换线、换产品的时候报表逻辑不用改。2.3 NG不合格就是不合格别用“差不多”来模糊它NG是Not Good的缩写在测试领域就是判定不合格。这个词没有歧义但围绕它的操作细节却不少。首先NG必须对应明确的判定标准。比如输出电压要求5V±0.1V实测5.15V那就是NG。不能因为“只超了一点点”就放行。测试的本质是边界判定标准是5.0到5.15.15就是出界出界就是NG。这一点在培训新人时我会反复强调测试不是凭感觉是凭标准。其次NG之后要有处理动作。是直接报废、返修、还是复测这取决于NG的类型和严重程度。有些NG是致命缺陷比如短路、开路直接报废有些NG是参数漂移可以调试后复测。报表上标NG只是第一步后续的处置记录同样重要。还有一个容易忽略的点NG的判定要可复现。如果同一个产品第一次测NG第二次测OK那说明测试系统本身可能不稳定。这时候不能简单地把结果改成OK了事而要排查是接触不良、环境干扰还是仪器漂移。我见过一条线因为测试夹具氧化导致同一批产品反复在OK和NG之间跳最后查了半天才发现是夹具问题。2.4 NT不是“没测”而是“还没到时候”NT是Not Tested的缩写意思是未测试。但这里有个细微差别NT通常指“按计划应该测但尚未测”而不是“不需要测”。如果一个项目根本不打算测那应该标N/A不适用而不是NT。NT在报表上的价值在于完整性检查。一份测试记录如果出现NT说明流程还没走完不能进入最终判定。质量审核的时候审核员会专门看NT项为什么没测是设备故障、人员遗漏还是计划调整每一个NT都应该有对应的说明。我经历过一次客户审核对方发现一批产品的报表里有三个NT项追问原因。结果是当天测试设备临时故障操作员先跳过了这三项打算第二天补测但忘了在系统里备注。虽然产品本身没问题但审核还是开了不符合项因为NT没有闭环。从那以后我在任何测试流程里都要求NT必须挂备注且必须有补测计划。3. 报表上的组合逻辑四个标记怎么搭配才不出乱子3.1 单站点测试的标记流转先看最简单的场景一个产品只经过一个测试站点所有项目一次测完。这时候标记的流转逻辑很清晰阶段标记说明测试中NT项目尚未执行单项完成POK该项目合格但整体未完成全部完成且合格OK最终放行任一项不合格NG触发不合格处理流程这里的关键是POK是中间态OK是终态。系统设计时POK可以多次出现OK只能出现一次。如果测试过程中出现NG流程直接跳到不合格处理不再生成OK。我见过一些测试软件把POK和OK混用结果报表导出后分不清哪些是过程记录、哪些是最终结论。后来统一规范过程记录一律用POK最终结论用OK问题就解决了。3.2 多站点测试的标记叠加多站点场景更复杂因为每个站点都有自己的判定最后还要汇总。这时候常见的做法是每个站点内部NT → POK/NG站点汇总所有站点POK → 整体OK任一站点NG → 整体NG有站点NT → 整体NT这个逻辑看起来简单但实操中容易出问题的地方在于站点之间的依赖关系。比如老化测试必须在功能测试POK之后才能开始。如果功能测试是NG老化测试就不应该启动它的状态应该是NT未测试而不是NG。因为NG意味着“测了但不合格”而这里根本没测。注意依赖关系没满足时下游站点标NT不要标NG。NG和NT在质量统计里的含义完全不同混用会导致不合格率虚高。3.3 NT的闭环管理最容易被忽视的一环NT之所以特殊是因为它不是一个“结果”而是一个“待办”。OK、POK、NG都是已经发生的判定NT是尚未发生的判定。所以NT的管理重点在于闭环。我的做法是任何NT项都必须关联三个信息——原因、责任人、计划完成时间。在测试系统里NT状态可以设置自动提醒超过计划时间未补测就升级告警。这样能避免“测了一半就忘了”的情况。另外NT在最终报表里的处理要明确。如果出货前还有NT项那这批货不能放行。有些企业为了赶交期把NT当成“默认合格”处理这是非常危险的做法。NT就是NT没测就是没测不能默认。4. 实操中最容易踩的五个坑4.1 把POK当OK用导致未完成品被放行这是最典型的错误。操作员看到POK以为就是通过了直接转到下一工序。结果下一工序发现前道还有项目没测整批货卡住。根因在于培训不到位以及报表界面设计不合理。如果POK和OK在界面上颜色一样、图标一样操作员很容易看错。我的建议是POK和OK在视觉上要有明显区分比如POK用蓝色、OK用绿色或者POK加一个“进行中”的角标。别小看这个细节产线上一天看几百条记录视觉区分能省很多事。4.2 NG没有及时隔离混入合格品NG品必须物理隔离这是质量管理的铁律。但实操中如果测试站和返修站距离远或者操作员手头忙NG品可能被随手放在合格品旁边。一旦混料后果严重。我见过一个案例测试员把两个NG的电路板放在合格品托盘边缘打算下班前一起送返修。结果中途换班接班的人没注意直接把整盘送进了包装线。最后客户投诉才发现问题。所以NG的隔离要即时、就地、有标识。测试站旁边就应该有红色的NG盒测出NG立刻放进去不要等。4.3 NT项没有备注审核时说不清前面提过NT闭环的重要性这里再强调一次NT必须挂备注。备注内容至少包括为什么没测、什么时候补测、谁负责。没有备注的NT在审核员眼里就是一个“失控点”。我自己的习惯是在测试系统里把NT的备注字段设为必填。不填备注就不能保存NT状态。这样虽然多花几秒钟但省去了后续追溯的麻烦。4.4 复测后直接改结果丢失原始记录产品测出NG返修后复测OK这时候报表怎么记有些系统直接覆盖原始NG记录只留一个OK。这是大忌。原始NG记录必须保留复测OK应该新增一条记录并关联原始NG记录。为什么因为质量分析需要看一次通过率FPY。如果NG被覆盖FPY就虚高了掩盖了真实的工艺问题。正确的做法是原始记录标NG复测记录标OK两条记录通过产品序列号关联。这样既能看到最终结果也能追溯过程。4.5 测试系统状态机设计混乱标记随意跳转最后一个坑是系统层面的。如果测试软件的状态机设计不严谨可能出现NT直接跳OK、NG直接跳POK这种不合理流转。比如一个项目没测NT突然变成OK这中间缺少了测试执行和判定环节。好的状态机应该是NT → POK/NG → OK仅当所有项目POK。任何跳转都要有日志。我在评审测试系统需求时会专门画一张状态流转图把每个标记的进入条件和退出条件写清楚。这张图后来成了开发和测试的共同语言减少了很多扯皮。5. 从标记到决策怎么用这四个结果驱动质量改进5.1 用POK和NG的分布定位瓶颈工站如果一条线上某个站点的NG率明显高于其他站点那这个站点就是瓶颈。但光看NG率还不够还要看POK的分布。比如ICT站点POK率很高但FCT站点NG率很高说明问题可能出在ICT没覆盖到的功能上或者ICT的测试项目设置不合理。我习惯每周拉一次各站点的POK/NG/NT统计做成趋势图。如果某个站点的NT数量突然上升通常意味着设备故障或人员变动。如果NG率突然上升可能是来料批次问题或工艺漂移。这些信号比最终OK率更早暴露问题。5.2 NT的时长分析发现流程中的隐形等待NT不仅是一个状态还可以记录持续时间。一个项目从进入NT到变成POK/NG中间隔了多久这个时长反映了测试流程的效率。比如老化测试的NT时长通常是固定的比如8小时但如果实际NT时长是12小时说明中间有等待。可能是老化架不够用或者排程不合理。把NT时长纳入监控能发现很多流程上的浪费。5.3 从NG的复测通过率看返修质量NG品返修后复测如果通过率高说明返修有效如果通过率低说明返修工艺有问题或者原始NG的根因没找对。我见过一个产品NG后返修复测还是NG再返修再测来回三次才过。这种反复返修不仅浪费工时还可能损伤产品。所以我会跟踪一次返修通过率。如果这个指标低于80%就要审查返修流程。是返修人员技能不足还是NG判定本身有误有时候测试系统的误判会导致“假NG”返修自然修不好因为根本没坏。5.4 标记数据的追溯价值客诉时的第一手证据当客户投诉产品问题时第一件事就是查测试记录。如果记录完整能快速定位是哪个站点、哪个项目、什么时间测的、结果如何。如果记录混乱OK/POK/NG/NT分不清那追溯就变成了猜谜。我经历过一次客诉客户说产品功能异常。我们查了测试记录发现该产品在FCT站点是POK但老化站点是NT——因为当天老化设备故障这批产品跳过了老化直接出货。问题就出在这里跳过老化导致早期失效没被筛出来。如果没有NT记录我们可能永远找不到原因。6. 写给测试系统设计者的几个建议6.1 状态字段不要用布尔值用枚举有些测试系统为了简单用一个布尔字段表示结果trueOKfalseNG。这种设计无法表达POK和NT。一旦业务需要区分过程合格和最终合格或者需要记录未测试状态就得改表结构。我的建议是从一开始就用枚举类型至少包含NT、POK、NG、OK四个值。如果还有“测试中”“暂停”等状态也一并加进去。枚举字段的扩展性比布尔值好得多。6.2 每个状态变更都要留痕谁在什么时候把NT改成了POK谁把NG改成了OK这些变更必须记录。不是不信任操作员而是为了追溯。当出现质量争议时变更日志能还原整个过程。日志至少包含时间戳、操作人、原状态、新状态、变更原因。如果系统支持还可以记录IP或设备编号。这些信息在排查异常时非常有用。6.3 报表导出时标记要带上下文单独一个“OK”没有意义必须带上下文哪个产品、哪个站点、哪个测试项目、什么时间。所以报表设计时标记字段要和产品序列号、站点编号、项目名称、时间戳一起导出。这样拿到报表的人才能看懂。我见过一些系统导出的报表只有一列“结果”全是OK/NG没有其他信息。这种报表除了统计数量什么都做不了。好的报表应该让人一眼看出“谁在什么时间对什么产品做了什么判定”。6.4 给NT设置超时告警NT状态如果长时间不闭环应该自动告警。比如设置4小时未补测就发邮件给主管。这个功能看似简单但能避免很多遗漏。尤其是在多班次交接的时候NT项容易被遗忘。告警阈值可以根据测试项目的正常时长来定。比如功能测试通常30分钟那NT超过1小时就告警老化测试通常8小时那NT超过10小时才告警。灵活设置避免误报。7. 我自己的使用习惯和最后几点体会说了这么多最后分享几个我个人的操作习惯都是踩坑之后慢慢养成的。第一看到POK先问一句“还有哪些没测”。POK只说明当前项目过了不代表整体过了。养成这个习惯后我很少再犯“把半成品当成品”的错误。第二NG记录绝不删除。哪怕后来复测OK了原始NG记录也保留。这些记录是分析工艺问题的金矿删了就没了。第三NT必须当天闭环。如果当天实在补测不了也要在系统里更新备注说明原因和计划。绝不让NT过夜而不留说明。第四定期导出标记分布做趋势分析。不用很复杂每周花十分钟看看各站点的POK/NG/NT比例有没有异常波动。这个习惯帮我提前发现过好几次设备老化和来料批次问题。这四个标记看起来只是几个字母但它们背后是一整套质量判定的逻辑。用对了报表清晰、追溯顺畅、决策有据用错了轻则返工重则客诉。希望这些内容能帮你把OK、POK、NG、NT用得明明白白。