1. 测试结果代号背后的门道为什么一个字母能决定整批货的命运刚入行那会儿我在产线跟着老师傅看测试报告满屏的OK、NG、NT、POK我心想这不就是过了和没过两件事吗干嘛整这么多花样。结果第一批独立负责的板子就因为把POK当成OK放行被下游客户整批退回那次的教训让我彻底明白这几个代号不是随便写的每一个都对应着完全不同的处理流程和责任归属。测试结果代号看起来只是几个字母的组合但它其实是整个质量体系里最基础也最容易被忽视的一环。写错一个代号轻则返工重测重则整批物料报废甚至影响客户对整条产线的信任。这篇文章我想把OK、POK、NG、NT这四个最常见的测试结果代号彻底讲清楚。它们分别代表什么、在什么场景下使用、判定逻辑是什么、记录时有哪些坑、不同行业里有没有差异以及怎么根据这些代号去设计测试流程和后续处置方案。不管你是刚进厂的测试员、负责质量管控的工程师还是自己做项目需要设计测试记录表的人这些内容都能直接拿去用。我会尽量用产线和实验室里的真实场景来拆解少讲空话多讲能落地的判断逻辑和操作细节。先说一个基本认知测试结果代号本质上是一套状态标记语言。它的作用是让不同岗位的人在看到同一个代号时能立刻知道这个被测对象处于什么状态、下一步该做什么。OK和NG是最基础的两极POK和NT则是在这两极之间或之外补充的中间态和特殊态。理解这套语言的关键不是背定义而是理解每个代号背后的判定边界和处置动作。2. 四个核心代号逐一拆解定义、判定逻辑与典型场景2.1 OK最 straightforward 的通过态但也有讲究OK代表测试通过被测对象的各项指标都在规格范围内可以正常流入下一道工序或直接出货。这个定义看起来简单到不需要解释但实际操作中有几个细节经常被忽略。第一OK的判定必须基于完整的测试项覆盖。我见过不少产线为了赶产能只测了关键几项就标OK结果漏测的项目在客户端暴雷。严格来说只有当测试计划中定义的所有必测项都执行完毕且全部通过才能标记OK。如果只测了部分项目那应该用POK或者加备注说明而不是直接写OK。第二OK的判定要区分单次通过和复测通过。有些测试系统会记录测试次数第一次就OK的和第三次才OK的虽然最终状态都是OK但质量含义完全不同。前者说明产品一致性很好后者可能暗示存在间歇性故障或接触不良。在汽车电子、医疗设备这类高可靠性要求的行业复测通过的OK通常需要额外标记或触发进一步分析。第三OK的记录格式要统一。我见过有的报告写OK有的写Pass有的写合格还有的写√。如果测试系统没有强制约束这些混用会给后续的数据统计和追溯带来很大麻烦。建议在测试规范里明确规定所有测试结果代号必须使用标准英文缩写OK就是OK不要用其他变体。实操心得在产线做首件测试时即使结果是OK也建议记录关键参数的实测值而不是只写一个OK。这样后续出现批次性偏差时你能快速判断是测试系统漂移还是产品本身变化。2.2 NG不只是没过还要区分怎么没过NG代表测试不通过被测对象至少有一项指标超出了规格范围。但NG这个代号本身携带的信息量其实很少真正有价值的是NG的具体原因和分类。从处置角度NG至少可以分为三类。第一类是功能性NG比如电路不通、信号无输出、机械卡死这类问题通常比较明确直接判定为不良品。第二类是参数性NG比如电压偏高0.1V、电流偏大5mA、尺寸超差0.02mm这类问题需要判断是产品本身的问题还是测试系统的误差。第三类是间歇性NG同一个产品多次测试结果不一致有时OK有时NG这类问题最棘手往往需要额外的应力测试或长时间监测才能定位。在记录NG时我强烈建议至少标注NG的具体测试项和实测值。只写一个NG后续做失效分析时等于什么都没有。比如NG和NG输出电压3.1V规格3.3V±5%这两条记录后者能让你立刻判断是电源问题还是负载问题前者只能让你重新测一遍。还有一个容易踩的坑NG的判定阈值。有些测试项的规格是单边限比如输出电压≥3.0V那3.0V整好卡在边界上算不算NG不同公司的处理方式不一样。有的按≥算通过有的按算通过还有的会设置一个guard band保护带比如实际判定用3.05V作为下限留出测量误差的余量。这个必须在测试规范里写清楚否则不同测试员会给出不同判定。2.3 POK最容易被误用的部分通过态POK是我见过被误用最多的代号。它的全称通常是Partial OK意思是部分通过、部分未通过。但在实际使用中很多人把它当成差不多OK或者基本OK来用这是非常危险的。POK的准确定义应该是测试计划中的部分测试项已执行且通过但还有部分测试项未执行或无法判定。注意这里的关键是未执行或无法判定而不是执行了但没过。如果执行了但没过那是NG不是POK。POK的典型使用场景包括测试设备临时故障导致部分项目无法测试、被测对象缺少某些接口或配置导致部分项目不适用、测试时间不够只完成了部分项目、或者客户只要求测试部分项目。在这些情况下POK表示已测的部分是好的但整体状态还不完整。POK的处置方式取决于具体场景。如果是设备故障导致的POK通常需要等设备修复后补测未完成的项目补测通过后才能转为OK。如果是客户只要求部分项目那POK可以直接出货但报告上必须明确标注哪些项目未测。如果是产品配置不适用某些测试项那需要在测试规范里提前定义好适用性判定规则避免测试员随意决定测不测。注意POK绝对不能等同于OK放行。我见过最离谱的案例是测试员因为赶下班把一批只测了一半项目的产品标成POK直接入库结果未测的那一半项目里有一个关键指标全部超差整批货在客户端被拦截。POK必须配合明确的补测计划或出货限制否则就是质量隐患。2.4 NT不是没测而是不适用或未触发NT通常代表Not Tested或Not Triggered但在不同的测试体系里它的含义有细微差别。最常见的两种用法是未测试和不适用。未测试的NT指的是这个测试项在本次测试中没有被执行。原因可能是测试计划里没有安排、测试设备不支持、或者测试员遗漏了。这种NT是需要跟进的因为未测试意味着状态未知不能默认它是好的。不适用的NT指的是这个测试项对被测对象不适用。比如一个只有2个通道的设备测试计划里有4个通道的测试项那第3、4通道的测试项就应该标NT并注明不适用设备仅2通道。这种NT是合理的不需要跟进。还有一种NT是未触发常见于条件测试。比如某个测试项只在特定条件下才执行如果条件没有满足这个测试项就不会被触发结果标NT。这种NT需要确认条件是否应该满足如果应该满足但没有满足那可能是一个测试覆盖率的漏洞。区分这三种NT的关键是看备注。只写一个NT你根本不知道是没测、不适用还是未触发。所以我的习惯是NT后面必须跟原因格式可以是NT设备不支持、NT不适用仅2通道、NT条件未触发温度未达到85℃。这样后续任何人看到这条记录都能立刻判断需不需要跟进。3. 代号背后的判定体系规格、误差与 guard band 的设计逻辑3.1 规格限、测量误差与判定边界的关系OK和NG的判定本质上是一个假设检验问题。被测对象的真实值落在规格范围内测试系统测量出一个值然后根据测量值判断是否合格。但测量值不等于真实值中间隔着测量误差。如果测量误差很大就可能出现真实值合格但测量值超差误判为NG或者真实值超差但测量值合格误判为OK的情况。为了控制这两种误判的风险工程上通常会设置guard band。简单说就是把判定边界从规格限往里收一点留出测量误差的余量。比如规格是10±0.5mm测量误差是±0.02mm那判定边界可以设为10±0.48mm。这样测量值在10.48mm以内的真实值几乎肯定在10.5mm以内判OK的风险就小很多。guard band的宽度取决于测量系统的重复性和再现性GRR。GRR好的系统guard band可以窄一点减少误判为NG的概率GRR差的系统guard band要宽一点减少误判为OK的概率。这个计算过程通常用测量系统分析MSA来完成核心指标是%GRR一般要求小于10%才算合格10%到30%之间可接受但需要加严判定超过30%说明测量系统本身不可靠需要先改进测量系统。3.2 不同行业的判定严格程度差异不同行业对OK/NG判定的严格程度差别很大。消费类电子通常按规格限直接判定guard band用得比较少因为成本压力大而且即使有个别误判售后成本也能承受。汽车电子和医疗设备就严格得多通常要求%GRR小于10%并且会设置明显的guard band有些关键安全项甚至要求零缺陷也就是任何超出规格的值都判NG不管测量误差多大。我做过一个汽车传感器的项目客户要求所有安全相关参数的判定必须用六西格玛方法计算guard band确保误判为OK的概率小于十亿分之一。这个要求听起来很夸张但考虑到安全件的失效后果这个严格程度是合理的。实际操作中我们用了三个月的生产数据来建立测量系统的误差模型然后反推出guard band的宽度最后把判定边界收紧了大约15%的规格范围。3.3 POK和NT在判定体系中的位置POK和NT不直接参与OK/NG的判定但它们影响测试覆盖率的评估。一个测试计划如果大量出现POK和NT说明测试覆盖率不足即使所有已测项目都是OK整体质量风险仍然很高。评估测试覆盖率时我通常会把测试项分为三类必测项、选测项和条件项。必测项必须100%执行出现POK或NT都要触发异常处理。选测项可以根据客户要求或产品等级决定是否执行出现POK或NT需要记录但不必触发异常。条件项只在特定条件下执行出现NT需要确认条件是否应该满足。这个分类必须在测试计划里提前定义好不能等到测试员看到结果再临时判断。我见过太多因为分类不清导致的扯皮测试员觉得这个项目不用测质量工程师觉得必须测最后产品卡在中间谁也不敢放行。4. 实操全流程从测试计划到结果记录的完整落地方法4.1 测试计划阶段的代号预定义在测试计划阶段就要把每个测试项的预期结果代号定义清楚。具体来说每个测试项要明确这个项目是必测还是选测、判定标准是什么、如果无法测试应该标什么代号、如果测试不通过应该记录哪些信息。我通常会用一张测试项定义表来管理这些信息表头包括测试项编号、测试项名称、测试类型必测/选测/条件、判定标准、测量设备、预期结果代号、NG记录要求、备注。这张表在测试计划评审时就要定稿后续测试执行和结果记录都以此为准。举个例子一个电源模块的测试项定义表可能长这样测试项编号测试项名称测试类型判定标准预期结果代号NG记录要求T001输出电压必测3.3V±5%OK/NG记录实测值T002输出电流必测≤500mAOK/NG记录实测值T003纹波必测≤50mVOK/NG记录实测值T004效率选测≥85%OK/NG/POK记录实测值T005高温输出条件3.3V±5%85℃OK/NG/NT记录实测值和温度这张表的好处是测试员拿到它就知道每个项目该怎么测、怎么判、怎么记不需要临时做决定。质量工程师拿到它也能快速评估测试覆盖率判断POK和NT是否合理。4.2 测试执行阶段的记录规范测试执行阶段记录规范的核心是及时、准确、完整。及时是指测试完一个项目就立刻记录不要等全部测完再补补记容易出错也容易遗漏。准确是指记录的值必须是实测值不能写约等于或者大概。完整是指该记的信息都要记包括测试条件、测试设备、测试时间、测试员。我见过不少测试员为了省事只写一个OK或NG其他什么都不写。这种记录在正常生产时看不出问题一旦出现批次性异常需要追溯时就会发现什么线索都没有。比如一批产品在客户端出现间歇性故障你想查生产时的测试数据结果发现只写了OK没有实测值没有测试条件你根本不知道是测试时就有隐患还是运输过程中出的问题。所以我的建议是关键测试项必须记录实测值非关键测试项可以只记代号但测试条件温度、电压、负载等必须记录。测试设备编号和测试时间也要记方便后续追溯设备状态和环境条件。4.3 结果判定与代号标记的实操细节结果判定时最容易出问题的是边界值和间歇性结果。边界值的处理前面已经讲过关键是guard band要提前定义好不能临时决定。间歇性结果的处理更复杂同一个产品多次测试结果不一致怎么标我的做法是如果测试规范里定义了复测规则就按复测规则执行。比如规定首次NG允许复测两次两次都OK则判OK并备注复测通过两次中任一次NG则判NG。如果测试规范里没有定义复测规则那首次结果是什么就标什么不要自行复测。因为自行复测会掩盖间歇性问题让真正有隐患的产品流入下一道工序。还有一个细节是代号的书写格式。我建议统一用大写字母不加空格不加标点。OK就是OK不要写O.K.或ok或OK.。NG就是NG不要写NG!或NG不合格。POK和NT同理。统一的格式能让后续的数据统计和自动判定少很多麻烦。实操心得在测试工位上贴一张代号速查表把OK、POK、NG、NT的定义和典型场景写清楚。新员工上手时能快速对照老员工也能避免习惯性错误。这张表不需要很复杂A4纸打印过塑就行但效果非常好。5. 常见问题与排查技巧实录5.1 代号混用与误判的典型场景场景一把POK当OK放行。这是最常见也最危险的问题。根源通常是测试员觉得已测的都过了没测的应该也没问题或者赶产能压力下选择性地忽略未测项目。排查方法是检查测试报告中的POK记录确认每个POK都有对应的补测计划或出货限制。如果没有就是管理漏洞。场景二把NT当OK处理。有些测试系统默认未测试项为通过或者测试员看到NT觉得反正没测应该没事。这种问题的排查方法是统计NT的比例如果某个测试项的NT比例异常高就要查原因是设备不支持、测试员遗漏还是条件设置有问题。场景三NG记录信息不足。只写NG不写原因和实测值导致后续失效分析无法进行。排查方法是抽查NG记录看是否包含测试项名称、实测值、测试条件。如果缺失需要完善记录规范并培训测试员。场景四边界值判定不一致。不同测试员对同一个边界值给出不同判定。排查方法是检查测试规范中guard band的定义是否清晰以及测试系统是否自动应用了guard band。如果依赖人工判定一致性很难保证。5.2 代号相关问题的速查表问题现象可能原因排查方法解决措施POK比例异常高测试设备故障、测试计划不完整检查设备状态和测试计划修复设备、补全测试计划NT比例异常高测试项不适用、测试员遗漏统计各测试项NT率更新适用性规则、培训测试员NG记录无实测值记录规范不完善抽查NG记录完善规范、增加系统强制字段边界值判定不一致guard band定义不清对比不同测试员判定明确guard band、系统自动判定复测通过率异常高间歇性问题、测试系统不稳定分析复测数据改进测试系统、加严判定代号格式混乱无统一规范检查测试报告制定代号书写规范并培训5.3 独家避坑技巧技巧一用颜色辅助代号识别。在测试报告或MES系统中给不同代号设置不同颜色OK绿色、NG红色、POK黄色、NT灰色。这样一眼扫过去就能看出整体状态比逐个读字母快得多。但要注意颜色不能替代代号代号仍然是唯一的判定依据。技巧二设置代号变更的审批流程。如果测试员需要把POK改成OK或者把NT改成OK必须经过质量工程师审批。这个流程能防止随意变更也能留下变更记录方便追溯。技巧三定期做代号一致性审计。每个月抽一批测试报告让不同的人重新判定一遍看是否和原始判定一致。不一致的地方就是需要改进的地方。这个审计不需要很频繁但要坚持做效果很好。技巧四在新产品导入阶段特别关注POK和NT。新产品导入时测试计划和测试系统都还不成熟POK和NT的比例通常比较高。这时候要特别关注这些代号背后的原因及时完善测试计划和测试系统避免问题带到量产阶段。技巧五把代号含义写进测试员培训教材。不要假设测试员都知道这些代号的含义尤其是新员工。培训教材里要用实际案例解释每个代号的判定逻辑和处置方式最好有测试报告样例让测试员对照学习。6. 从代号到体系如何用测试结果代号驱动质量改进6.1 代号数据的统计分析与趋势监控测试结果代号不只是单次测试的记录它们积累起来就是质量数据。通过统计OK、POK、NG、NT的比例和趋势能发现很多单次测试看不出来的问题。比如OK率突然下降可能是来料质量变差、测试系统漂移或者测试员操作变化。POK率上升可能是测试设备老化导致部分项目无法测试或者测试计划变更导致更多项目变成选测。NG率上升可能是设计余量不足、工艺窗口变窄或者测试条件变严。NT率上升可能是产品配置变化导致更多项目不适用或者测试员遗漏增加。我通常会做一个代号趋势图横轴是时间纵轴是各代号的比例。这个图放在质量看板上每天更新。一旦某个代号的比例超出控制限就触发异常处理流程。这个做法在多个项目上帮我提前发现了批次性问题避免了大量不良品流出。6.2 基于代号的测试流程优化代号数据还能用来优化测试流程。比如如果某个测试项的NG率一直很低可以考虑降低测试频次或者改为抽检。如果某个测试项的POK率很高说明测试设备或测试方法需要改进。如果某个测试项的NT率很高说明这个测试项可能不必要或者适用性规则需要调整。优化的核心原则是把测试资源集中在高风险项上。高风险项通常是NG率较高、对产品功能影响较大、或者客户特别关注的项目。低风险项可以适当减少测试频次或简化测试方法。这个优化过程需要数据支撑而代号数据就是最直接的数据来源。6.3 代号规范在团队协作中的价值在一个多岗位协作的质量体系中代号规范是沟通的基础。测试员、质量工程师、工艺工程师、设计工程师、客户所有人看到的都是同一套代号大家对代号的理解一致沟通成本就低误解就少。我见过因为代号理解不一致导致的扯皮测试员标了POK质量工程师以为是OK直接放行了结果客户发现未测项目有问题追责下来测试员说我标的是POK啊质量工程师说我以为POK就是OK。这种扯皮的根本原因就是代号规范不清晰或者培训不到位。所以代号规范不只是测试员的事整个团队都要理解。我建议在新员工入职培训里加入代号规范的课程并且定期做 refresher 培训。培训内容不需要很复杂把四个代号的定义、判定逻辑、处置方式讲清楚就行但一定要用实际案例让每个人都能对应到自己工作中的场景。6.4 代号体系的持续改进代号体系本身也需要持续改进。随着产品复杂度提高、测试技术发展、客户要求变化原有的代号定义和判定规则可能不再适用。比如以前只有OK和NG两个代号后来发现需要POK来表示部分通过再后来发现需要NT来表示不适用。未来可能还需要新的代号来表示其他状态。改进的触发点通常来自三个方面测试员反馈、质量数据分析和客户要求变化。测试员在实际操作中遇到代号无法覆盖的情况会提出改进建议。质量数据分析发现某些代号的比例异常或趋势异常会触发规则调整。客户要求变化比如要求更细化的测试结果分类也会推动代号体系更新。改进的流程我建议走变更控制提出变更申请、评估影响、更新规范、培训相关人员、监控变更效果。这个流程能确保变更不会引入新的混乱也能留下变更记录方便追溯。7. 我个人的一些实操体会做了这么多年测试和质量管控我对这四个代号最大的体会是它们看起来简单但真正用好需要体系支撑。单独背定义谁都会但在实际产线上在产能压力下在设备故障时在客户催货时能不能坚持按规范标记和处理才是真正的考验。我踩过的最大的坑就是早期觉得POK和NT是次要代号没有给予足够重视。结果一批POK产品因为没有补测计划直接出货客户端发现未测项目有问题整批退货。那次之后我把POK和NT的管理提到了和OK、NG同等重要的位置所有POK必须有补测计划所有NT必须有原因说明否则测试报告不完整产品不能放行。另一个体会是代号规范要简单可执行。我见过一些公司把代号体系搞得很复杂有十几个代号每个代号还有子代号结果测试员记不住经常用错。后来简化成四个核心代号加备注反而执行得更好。所以我的建议是核心代号不要超过五个其他状态用备注补充这样既保证了规范性又保证了可执行性。最后分享一个小技巧在测试工位上放一个代号判定辅助工具可以是一张卡片也可以是一个简单的脚本。测试员输入测试项和实测值工具自动给出代号建议。这个工具不需要很复杂但能显著减少判定错误尤其是对新员工来说。我用一个Excel表格做过这个工具把判定规则写成公式测试员输入实测值就自动显示代号效果很好后来推广到了整个产线。 测试结果代号OK、POK、NG、NT详解：判定逻辑、记录规范与质量改进
1. 测试结果代号背后的门道为什么一个字母能决定整批货的命运刚入行那会儿我在产线跟着老师傅看测试报告满屏的OK、NG、NT、POK我心想这不就是过了和没过两件事吗干嘛整这么多花样。结果第一批独立负责的板子就因为把POK当成OK放行被下游客户整批退回那次的教训让我彻底明白这几个代号不是随便写的每一个都对应着完全不同的处理流程和责任归属。测试结果代号看起来只是几个字母的组合但它其实是整个质量体系里最基础也最容易被忽视的一环。写错一个代号轻则返工重测重则整批物料报废甚至影响客户对整条产线的信任。这篇文章我想把OK、POK、NG、NT这四个最常见的测试结果代号彻底讲清楚。它们分别代表什么、在什么场景下使用、判定逻辑是什么、记录时有哪些坑、不同行业里有没有差异以及怎么根据这些代号去设计测试流程和后续处置方案。不管你是刚进厂的测试员、负责质量管控的工程师还是自己做项目需要设计测试记录表的人这些内容都能直接拿去用。我会尽量用产线和实验室里的真实场景来拆解少讲空话多讲能落地的判断逻辑和操作细节。先说一个基本认知测试结果代号本质上是一套状态标记语言。它的作用是让不同岗位的人在看到同一个代号时能立刻知道这个被测对象处于什么状态、下一步该做什么。OK和NG是最基础的两极POK和NT则是在这两极之间或之外补充的中间态和特殊态。理解这套语言的关键不是背定义而是理解每个代号背后的判定边界和处置动作。2. 四个核心代号逐一拆解定义、判定逻辑与典型场景2.1 OK最 straightforward 的通过态但也有讲究OK代表测试通过被测对象的各项指标都在规格范围内可以正常流入下一道工序或直接出货。这个定义看起来简单到不需要解释但实际操作中有几个细节经常被忽略。第一OK的判定必须基于完整的测试项覆盖。我见过不少产线为了赶产能只测了关键几项就标OK结果漏测的项目在客户端暴雷。严格来说只有当测试计划中定义的所有必测项都执行完毕且全部通过才能标记OK。如果只测了部分项目那应该用POK或者加备注说明而不是直接写OK。第二OK的判定要区分单次通过和复测通过。有些测试系统会记录测试次数第一次就OK的和第三次才OK的虽然最终状态都是OK但质量含义完全不同。前者说明产品一致性很好后者可能暗示存在间歇性故障或接触不良。在汽车电子、医疗设备这类高可靠性要求的行业复测通过的OK通常需要额外标记或触发进一步分析。第三OK的记录格式要统一。我见过有的报告写OK有的写Pass有的写合格还有的写√。如果测试系统没有强制约束这些混用会给后续的数据统计和追溯带来很大麻烦。建议在测试规范里明确规定所有测试结果代号必须使用标准英文缩写OK就是OK不要用其他变体。实操心得在产线做首件测试时即使结果是OK也建议记录关键参数的实测值而不是只写一个OK。这样后续出现批次性偏差时你能快速判断是测试系统漂移还是产品本身变化。2.2 NG不只是没过还要区分怎么没过NG代表测试不通过被测对象至少有一项指标超出了规格范围。但NG这个代号本身携带的信息量其实很少真正有价值的是NG的具体原因和分类。从处置角度NG至少可以分为三类。第一类是功能性NG比如电路不通、信号无输出、机械卡死这类问题通常比较明确直接判定为不良品。第二类是参数性NG比如电压偏高0.1V、电流偏大5mA、尺寸超差0.02mm这类问题需要判断是产品本身的问题还是测试系统的误差。第三类是间歇性NG同一个产品多次测试结果不一致有时OK有时NG这类问题最棘手往往需要额外的应力测试或长时间监测才能定位。在记录NG时我强烈建议至少标注NG的具体测试项和实测值。只写一个NG后续做失效分析时等于什么都没有。比如NG和NG输出电压3.1V规格3.3V±5%这两条记录后者能让你立刻判断是电源问题还是负载问题前者只能让你重新测一遍。还有一个容易踩的坑NG的判定阈值。有些测试项的规格是单边限比如输出电压≥3.0V那3.0V整好卡在边界上算不算NG不同公司的处理方式不一样。有的按≥算通过有的按算通过还有的会设置一个guard band保护带比如实际判定用3.05V作为下限留出测量误差的余量。这个必须在测试规范里写清楚否则不同测试员会给出不同判定。2.3 POK最容易被误用的部分通过态POK是我见过被误用最多的代号。它的全称通常是Partial OK意思是部分通过、部分未通过。但在实际使用中很多人把它当成差不多OK或者基本OK来用这是非常危险的。POK的准确定义应该是测试计划中的部分测试项已执行且通过但还有部分测试项未执行或无法判定。注意这里的关键是未执行或无法判定而不是执行了但没过。如果执行了但没过那是NG不是POK。POK的典型使用场景包括测试设备临时故障导致部分项目无法测试、被测对象缺少某些接口或配置导致部分项目不适用、测试时间不够只完成了部分项目、或者客户只要求测试部分项目。在这些情况下POK表示已测的部分是好的但整体状态还不完整。POK的处置方式取决于具体场景。如果是设备故障导致的POK通常需要等设备修复后补测未完成的项目补测通过后才能转为OK。如果是客户只要求部分项目那POK可以直接出货但报告上必须明确标注哪些项目未测。如果是产品配置不适用某些测试项那需要在测试规范里提前定义好适用性判定规则避免测试员随意决定测不测。注意POK绝对不能等同于OK放行。我见过最离谱的案例是测试员因为赶下班把一批只测了一半项目的产品标成POK直接入库结果未测的那一半项目里有一个关键指标全部超差整批货在客户端被拦截。POK必须配合明确的补测计划或出货限制否则就是质量隐患。2.4 NT不是没测而是不适用或未触发NT通常代表Not Tested或Not Triggered但在不同的测试体系里它的含义有细微差别。最常见的两种用法是未测试和不适用。未测试的NT指的是这个测试项在本次测试中没有被执行。原因可能是测试计划里没有安排、测试设备不支持、或者测试员遗漏了。这种NT是需要跟进的因为未测试意味着状态未知不能默认它是好的。不适用的NT指的是这个测试项对被测对象不适用。比如一个只有2个通道的设备测试计划里有4个通道的测试项那第3、4通道的测试项就应该标NT并注明不适用设备仅2通道。这种NT是合理的不需要跟进。还有一种NT是未触发常见于条件测试。比如某个测试项只在特定条件下才执行如果条件没有满足这个测试项就不会被触发结果标NT。这种NT需要确认条件是否应该满足如果应该满足但没有满足那可能是一个测试覆盖率的漏洞。区分这三种NT的关键是看备注。只写一个NT你根本不知道是没测、不适用还是未触发。所以我的习惯是NT后面必须跟原因格式可以是NT设备不支持、NT不适用仅2通道、NT条件未触发温度未达到85℃。这样后续任何人看到这条记录都能立刻判断需不需要跟进。3. 代号背后的判定体系规格、误差与 guard band 的设计逻辑3.1 规格限、测量误差与判定边界的关系OK和NG的判定本质上是一个假设检验问题。被测对象的真实值落在规格范围内测试系统测量出一个值然后根据测量值判断是否合格。但测量值不等于真实值中间隔着测量误差。如果测量误差很大就可能出现真实值合格但测量值超差误判为NG或者真实值超差但测量值合格误判为OK的情况。为了控制这两种误判的风险工程上通常会设置guard band。简单说就是把判定边界从规格限往里收一点留出测量误差的余量。比如规格是10±0.5mm测量误差是±0.02mm那判定边界可以设为10±0.48mm。这样测量值在10.48mm以内的真实值几乎肯定在10.5mm以内判OK的风险就小很多。guard band的宽度取决于测量系统的重复性和再现性GRR。GRR好的系统guard band可以窄一点减少误判为NG的概率GRR差的系统guard band要宽一点减少误判为OK的概率。这个计算过程通常用测量系统分析MSA来完成核心指标是%GRR一般要求小于10%才算合格10%到30%之间可接受但需要加严判定超过30%说明测量系统本身不可靠需要先改进测量系统。3.2 不同行业的判定严格程度差异不同行业对OK/NG判定的严格程度差别很大。消费类电子通常按规格限直接判定guard band用得比较少因为成本压力大而且即使有个别误判售后成本也能承受。汽车电子和医疗设备就严格得多通常要求%GRR小于10%并且会设置明显的guard band有些关键安全项甚至要求零缺陷也就是任何超出规格的值都判NG不管测量误差多大。我做过一个汽车传感器的项目客户要求所有安全相关参数的判定必须用六西格玛方法计算guard band确保误判为OK的概率小于十亿分之一。这个要求听起来很夸张但考虑到安全件的失效后果这个严格程度是合理的。实际操作中我们用了三个月的生产数据来建立测量系统的误差模型然后反推出guard band的宽度最后把判定边界收紧了大约15%的规格范围。3.3 POK和NT在判定体系中的位置POK和NT不直接参与OK/NG的判定但它们影响测试覆盖率的评估。一个测试计划如果大量出现POK和NT说明测试覆盖率不足即使所有已测项目都是OK整体质量风险仍然很高。评估测试覆盖率时我通常会把测试项分为三类必测项、选测项和条件项。必测项必须100%执行出现POK或NT都要触发异常处理。选测项可以根据客户要求或产品等级决定是否执行出现POK或NT需要记录但不必触发异常。条件项只在特定条件下执行出现NT需要确认条件是否应该满足。这个分类必须在测试计划里提前定义好不能等到测试员看到结果再临时判断。我见过太多因为分类不清导致的扯皮测试员觉得这个项目不用测质量工程师觉得必须测最后产品卡在中间谁也不敢放行。4. 实操全流程从测试计划到结果记录的完整落地方法4.1 测试计划阶段的代号预定义在测试计划阶段就要把每个测试项的预期结果代号定义清楚。具体来说每个测试项要明确这个项目是必测还是选测、判定标准是什么、如果无法测试应该标什么代号、如果测试不通过应该记录哪些信息。我通常会用一张测试项定义表来管理这些信息表头包括测试项编号、测试项名称、测试类型必测/选测/条件、判定标准、测量设备、预期结果代号、NG记录要求、备注。这张表在测试计划评审时就要定稿后续测试执行和结果记录都以此为准。举个例子一个电源模块的测试项定义表可能长这样测试项编号测试项名称测试类型判定标准预期结果代号NG记录要求T001输出电压必测3.3V±5%OK/NG记录实测值T002输出电流必测≤500mAOK/NG记录实测值T003纹波必测≤50mVOK/NG记录实测值T004效率选测≥85%OK/NG/POK记录实测值T005高温输出条件3.3V±5%85℃OK/NG/NT记录实测值和温度这张表的好处是测试员拿到它就知道每个项目该怎么测、怎么判、怎么记不需要临时做决定。质量工程师拿到它也能快速评估测试覆盖率判断POK和NT是否合理。4.2 测试执行阶段的记录规范测试执行阶段记录规范的核心是及时、准确、完整。及时是指测试完一个项目就立刻记录不要等全部测完再补补记容易出错也容易遗漏。准确是指记录的值必须是实测值不能写约等于或者大概。完整是指该记的信息都要记包括测试条件、测试设备、测试时间、测试员。我见过不少测试员为了省事只写一个OK或NG其他什么都不写。这种记录在正常生产时看不出问题一旦出现批次性异常需要追溯时就会发现什么线索都没有。比如一批产品在客户端出现间歇性故障你想查生产时的测试数据结果发现只写了OK没有实测值没有测试条件你根本不知道是测试时就有隐患还是运输过程中出的问题。所以我的建议是关键测试项必须记录实测值非关键测试项可以只记代号但测试条件温度、电压、负载等必须记录。测试设备编号和测试时间也要记方便后续追溯设备状态和环境条件。4.3 结果判定与代号标记的实操细节结果判定时最容易出问题的是边界值和间歇性结果。边界值的处理前面已经讲过关键是guard band要提前定义好不能临时决定。间歇性结果的处理更复杂同一个产品多次测试结果不一致怎么标我的做法是如果测试规范里定义了复测规则就按复测规则执行。比如规定首次NG允许复测两次两次都OK则判OK并备注复测通过两次中任一次NG则判NG。如果测试规范里没有定义复测规则那首次结果是什么就标什么不要自行复测。因为自行复测会掩盖间歇性问题让真正有隐患的产品流入下一道工序。还有一个细节是代号的书写格式。我建议统一用大写字母不加空格不加标点。OK就是OK不要写O.K.或ok或OK.。NG就是NG不要写NG!或NG不合格。POK和NT同理。统一的格式能让后续的数据统计和自动判定少很多麻烦。实操心得在测试工位上贴一张代号速查表把OK、POK、NG、NT的定义和典型场景写清楚。新员工上手时能快速对照老员工也能避免习惯性错误。这张表不需要很复杂A4纸打印过塑就行但效果非常好。5. 常见问题与排查技巧实录5.1 代号混用与误判的典型场景场景一把POK当OK放行。这是最常见也最危险的问题。根源通常是测试员觉得已测的都过了没测的应该也没问题或者赶产能压力下选择性地忽略未测项目。排查方法是检查测试报告中的POK记录确认每个POK都有对应的补测计划或出货限制。如果没有就是管理漏洞。场景二把NT当OK处理。有些测试系统默认未测试项为通过或者测试员看到NT觉得反正没测应该没事。这种问题的排查方法是统计NT的比例如果某个测试项的NT比例异常高就要查原因是设备不支持、测试员遗漏还是条件设置有问题。场景三NG记录信息不足。只写NG不写原因和实测值导致后续失效分析无法进行。排查方法是抽查NG记录看是否包含测试项名称、实测值、测试条件。如果缺失需要完善记录规范并培训测试员。场景四边界值判定不一致。不同测试员对同一个边界值给出不同判定。排查方法是检查测试规范中guard band的定义是否清晰以及测试系统是否自动应用了guard band。如果依赖人工判定一致性很难保证。5.2 代号相关问题的速查表问题现象可能原因排查方法解决措施POK比例异常高测试设备故障、测试计划不完整检查设备状态和测试计划修复设备、补全测试计划NT比例异常高测试项不适用、测试员遗漏统计各测试项NT率更新适用性规则、培训测试员NG记录无实测值记录规范不完善抽查NG记录完善规范、增加系统强制字段边界值判定不一致guard band定义不清对比不同测试员判定明确guard band、系统自动判定复测通过率异常高间歇性问题、测试系统不稳定分析复测数据改进测试系统、加严判定代号格式混乱无统一规范检查测试报告制定代号书写规范并培训5.3 独家避坑技巧技巧一用颜色辅助代号识别。在测试报告或MES系统中给不同代号设置不同颜色OK绿色、NG红色、POK黄色、NT灰色。这样一眼扫过去就能看出整体状态比逐个读字母快得多。但要注意颜色不能替代代号代号仍然是唯一的判定依据。技巧二设置代号变更的审批流程。如果测试员需要把POK改成OK或者把NT改成OK必须经过质量工程师审批。这个流程能防止随意变更也能留下变更记录方便追溯。技巧三定期做代号一致性审计。每个月抽一批测试报告让不同的人重新判定一遍看是否和原始判定一致。不一致的地方就是需要改进的地方。这个审计不需要很频繁但要坚持做效果很好。技巧四在新产品导入阶段特别关注POK和NT。新产品导入时测试计划和测试系统都还不成熟POK和NT的比例通常比较高。这时候要特别关注这些代号背后的原因及时完善测试计划和测试系统避免问题带到量产阶段。技巧五把代号含义写进测试员培训教材。不要假设测试员都知道这些代号的含义尤其是新员工。培训教材里要用实际案例解释每个代号的判定逻辑和处置方式最好有测试报告样例让测试员对照学习。6. 从代号到体系如何用测试结果代号驱动质量改进6.1 代号数据的统计分析与趋势监控测试结果代号不只是单次测试的记录它们积累起来就是质量数据。通过统计OK、POK、NG、NT的比例和趋势能发现很多单次测试看不出来的问题。比如OK率突然下降可能是来料质量变差、测试系统漂移或者测试员操作变化。POK率上升可能是测试设备老化导致部分项目无法测试或者测试计划变更导致更多项目变成选测。NG率上升可能是设计余量不足、工艺窗口变窄或者测试条件变严。NT率上升可能是产品配置变化导致更多项目不适用或者测试员遗漏增加。我通常会做一个代号趋势图横轴是时间纵轴是各代号的比例。这个图放在质量看板上每天更新。一旦某个代号的比例超出控制限就触发异常处理流程。这个做法在多个项目上帮我提前发现了批次性问题避免了大量不良品流出。6.2 基于代号的测试流程优化代号数据还能用来优化测试流程。比如如果某个测试项的NG率一直很低可以考虑降低测试频次或者改为抽检。如果某个测试项的POK率很高说明测试设备或测试方法需要改进。如果某个测试项的NT率很高说明这个测试项可能不必要或者适用性规则需要调整。优化的核心原则是把测试资源集中在高风险项上。高风险项通常是NG率较高、对产品功能影响较大、或者客户特别关注的项目。低风险项可以适当减少测试频次或简化测试方法。这个优化过程需要数据支撑而代号数据就是最直接的数据来源。6.3 代号规范在团队协作中的价值在一个多岗位协作的质量体系中代号规范是沟通的基础。测试员、质量工程师、工艺工程师、设计工程师、客户所有人看到的都是同一套代号大家对代号的理解一致沟通成本就低误解就少。我见过因为代号理解不一致导致的扯皮测试员标了POK质量工程师以为是OK直接放行了结果客户发现未测项目有问题追责下来测试员说我标的是POK啊质量工程师说我以为POK就是OK。这种扯皮的根本原因就是代号规范不清晰或者培训不到位。所以代号规范不只是测试员的事整个团队都要理解。我建议在新员工入职培训里加入代号规范的课程并且定期做 refresher 培训。培训内容不需要很复杂把四个代号的定义、判定逻辑、处置方式讲清楚就行但一定要用实际案例让每个人都能对应到自己工作中的场景。6.4 代号体系的持续改进代号体系本身也需要持续改进。随着产品复杂度提高、测试技术发展、客户要求变化原有的代号定义和判定规则可能不再适用。比如以前只有OK和NG两个代号后来发现需要POK来表示部分通过再后来发现需要NT来表示不适用。未来可能还需要新的代号来表示其他状态。改进的触发点通常来自三个方面测试员反馈、质量数据分析和客户要求变化。测试员在实际操作中遇到代号无法覆盖的情况会提出改进建议。质量数据分析发现某些代号的比例异常或趋势异常会触发规则调整。客户要求变化比如要求更细化的测试结果分类也会推动代号体系更新。改进的流程我建议走变更控制提出变更申请、评估影响、更新规范、培训相关人员、监控变更效果。这个流程能确保变更不会引入新的混乱也能留下变更记录方便追溯。7. 我个人的一些实操体会做了这么多年测试和质量管控我对这四个代号最大的体会是它们看起来简单但真正用好需要体系支撑。单独背定义谁都会但在实际产线上在产能压力下在设备故障时在客户催货时能不能坚持按规范标记和处理才是真正的考验。我踩过的最大的坑就是早期觉得POK和NT是次要代号没有给予足够重视。结果一批POK产品因为没有补测计划直接出货客户端发现未测项目有问题整批退货。那次之后我把POK和NT的管理提到了和OK、NG同等重要的位置所有POK必须有补测计划所有NT必须有原因说明否则测试报告不完整产品不能放行。另一个体会是代号规范要简单可执行。我见过一些公司把代号体系搞得很复杂有十几个代号每个代号还有子代号结果测试员记不住经常用错。后来简化成四个核心代号加备注反而执行得更好。所以我的建议是核心代号不要超过五个其他状态用备注补充这样既保证了规范性又保证了可执行性。最后分享一个小技巧在测试工位上放一个代号判定辅助工具可以是一张卡片也可以是一个简单的脚本。测试员输入测试项和实测值工具自动给出代号建议。这个工具不需要很复杂但能显著减少判定错误尤其是对新员工来说。我用一个Excel表格做过这个工具把判定规则写成公式测试员输入实测值就自动显示代号效果很好后来推广到了整个产线。