4. 测试需求分析
在PLC控制器量产测试工程中，测试需求分析是承上启下的关键环节。它把产品规格书、客户需求和行业标准这些“源头文档”，转化为产线可执行、可判定、可追溯的测试项。若跳过这一步直接写测试脚本，往往会出现漏测关键功能、测试项无法判定、量产节拍不达标等问题。本节围绕“转化方法”展开，给出可落地的分析路径。
一、核心原理：三类输入，一条转化链
测试需求的输入通常来自三个方向：产品规格书（电气参数、通信协议、IO能力、环境指标）、客户需求（验收标准、特殊工况、交付节拍）、行业标准（IEC 61131-2、GB/T 15969、EMC与安规要求）。这三类输入的语言不同：规格书是“能力描述”，客户需求是“验收条件”，行业标准是“合规底线”。测试需求分析的本质，是把它们统一翻译成可测试性需求——即具备测试对象、测试条件、激励方式、判定阈值和观测点的条目。
转化链可以概括为：
原始需求 → 需求条目化 → 可测试性判定 → 测试项映射 → 测试用例骨架 → 产线可执行需求
原始需求 → 需求条目化 → 可测试性判定 → 测试项映射 → 测试用例骨架 → 产线可执行需求
其中“可测试性判定”是最容易被忽略的一步。一个需求如果无法在产线节拍内施加激励或观测结果，就必须拆解、替代或降级为抽检项，而不是硬塞进量产测试。
二、方法流程：五步转化法
- 需求条目化：把规格书和客户文档拆成独立、可编号的条目，例如“DI响应时间≤10ms”“RS485波特率支持9600~115200”“工作温度-20~60℃”。
- 可测试性判定：对每条需求问三个问题——能否在产线施加激励？能否自动观测？判定阈值是否明确？三者缺一，就需要替代方案。
- 测试项映射：把可测试条目映射为测试项，如“DI响应时间”映射为“数字输入响应时间测试”，“RS485波特率”映射为“通信参数遍历测试”。
- 测试用例骨架：为每个测试项定义激励、观测点、判定条件和失败处理，形成用例骨架。
- 产线可执行需求：结合节拍、工装、仪器能力，确定测试顺序、并行度和抽检策略，输出最终测试需求清单。
下面这张图展示了从三类输入到产线可执行需求的转化关系，以及每一步的关键动作。
三、案例场景：某PLC控制器DI响应时间需求转化
假设规格书写明“数字输入响应时间≤10ms”，客户要求“产线全检”，行业标准要求“符合IEC 61131-2”。转化过程如下：
| 步骤 | 动作 | 输出 |
|---|---|---|
| 需求条目化 | 拆出“DI响应时间≤10ms” | REQ-DI-001 |
| 可测试性判定 | 可用信号发生器施加阶跃，示波器观测输出 | 可测，需工装夹具 |
| 测试项映射 | 映射为“DI响应时间测试” | TEST-DI-001 |
| 用例骨架 | 激励：0→24V阶跃；观测：输出翻转时间；判定：≤10ms | 用例骨架 |
| 产线可执行 | 节拍2s/通道，8通道并行，全检 | 产线测试需求 |
若产线节拍无法满足逐通道测试，可降级为“抽检+过程能力监控”，但必须在测试需求中明确标注降级原因和风险。
四、误区与复盘
常见误区一：把规格书参数直接当测试项。规格书说“支持Modbus RTU”，但产线测试需要明确测试哪些功能码、哪些波特率、哪些异常帧。不拆解就无法执行。
常见误区二：忽略客户节拍要求。客户要求“每台30秒完成测试”，但需求分析时未考虑并行度，导致测试项堆叠后节拍超标，后期被迫删减测试项。
常见误区三：行业标准只做形式合规。EMC、安规等标准要求往往需要专用设备，若不在需求分析阶段识别，量产时会出现“无法测试”的尴尬。
复盘建议：建立“需求-测试项”双向追溯矩阵，每条测试项都能回溯到原始需求，每条原始需求都有对应的测试项或明确的“不测试理由”。这样在客户审核或产线异常时，可以快速定位是需求遗漏还是测试失效。
测试需求分析不是一次性文档工作，而是贯穿产品导入、试产、量产的过程。建议在试产阶段用实际测试数据反哺需求，修正判定阈值和测试顺序，使测试需求真正成为产线可执行、可维护的工程资产。