4. 项目需求澄清与测试规格书编写

新能源测试项目最常见的返工来源，不是设备能力不足，而是需求在早期没有被翻译成可验证的工程语言。客户说“要测一下充电兼容性”“要验证一下BMS保护逻辑”“要看看低温下续航衰减”，这些表述都停留在业务意图层面，无法直接映射到测试台架、仪器配置和判定准则。需求澄清的任务，就是把这些模糊意图逐层拆解为可执行、可测量、可判定的测试规格书。

一、需求澄清的三个输入面

需求澄清不是一次会议，而是三条信息线的收敛：客户访谈提供使用场景与验收期望，工况拆解把场景还原为物理量随时间的变化，标准对标把变化约束到行业公认的测试条件与限值框架内。三者缺一，规格书就会出现盲区。

客户访谈要问的不是“你要测什么”，而是“这个产品在什么场景下必须不出问题”。例如某OBC（车载充电机）项目，客户最初只提“交流充电要可靠”。通过追问使用场景，得到三条关键信息：家用7kW单相桩、公共三相11kW桩、以及电网电压跌落至180V的弱网环境。这三条场景直接决定了测试项必须覆盖单相/三相切换、宽压输入和欠压恢复。

工况拆解是把场景翻译成物理量。以“弱网充电”为例，需要明确：输入电压从220V跌落到180V的速率、持续时间、恢复方式，以及在此期间OBC的输出电流是否允许降额、降额到多少、恢复后是否要求满功率回冲。这些参数不明确，测试就无法复现，判定也无从谈起。

标准对标则提供限值和测试方法的依据。例如充电兼容性可对标GB/T 18487.1和GB/T 27930，低温性能可参考GB/T 31486或企业标准。标准不是用来照抄的，而是用来确认“客户期望是否低于或高于标准要求”，从而决定测试严酷度。

二、从需求到测试项的映射逻辑

需求澄清的产出不是一段描述，而是一张可追溯的映射表。每个测试项都应能回答四个问题：测什么对象、在什么条件下、施加什么激励、以什么准则判定通过。这四个要素构成测试规格书的最小完整单元。

以“BMS过流保护”为例，模糊需求是“过流时要保护”。澄清后应形成如下规格：对象为BMS高压回路；条件为25℃、SOC 50%；激励为以100A/s速率将放电电流从200A升至600A；判定准则为在电流超过500A后100ms内断开接触器，且断开后无复闭。这里每一个数字都需要与客户确认或由标准推导，不能由测试方自行假设。

映射过程中最常见的陷阱是把测试方法当成测试项。例如“用示波器测纹波”不是测试项，“在额定输入、满载输出条件下，输出电压纹波峰峰值不超过200mV”才是。规格书必须描述可观测的结果，而不是描述操作动作。

三、测试规格书的结构与编写要点

一份可交付的测试规格书通常包含以下部分：测试目的、适用对象与边界、引用标准、测试条件、测试项清单、每项的激励与判定准则、数据记录要求、以及安全与异常处理。其中最容易写空的是“测试条件”和“判定准则”，而这两项恰恰是复现性的关键。

测试条件必须写到可设置的程度。例如“常温”应写为“25℃±2℃，风速≤0.5m/s，DUT温度稳定后30min开始测试”。判定准则必须包含时间维度。例如“过压保护”不能只写“电压超过阈值时保护”，而应写“电压超过4.25V后，在10ms内将充电电流降至0，并在电压回落至4.10V以下后允许恢复”。

另一个关键点是边界与例外。新能源测试中，很多失效并非发生在额定点，而是发生在边界附近。规格书应明确：测试是否覆盖上下边界、是否允许降额、降额后是否要求恢复、以及恢复时间是否计入判定。这些内容如果在规格书中缺失，测试执行时就会产生争议。

四、可追溯性与变更控制

需求澄清的最终成果，是每条测试项都能追溯到一条客户需求或一条标准条款。建议在规格书中为每条测试项分配唯一编号，并记录其来源。例如：

测试项编号：TC-OBC-012
测试名称：交流输入欠压恢复充电
需求来源：客户访谈记录 CR-007 / GB/T 18487.1 第A.3条
测试条件：25℃，输入220V→180V（跌落时间10ms），维持5s后恢复220V
激励方式：可编程交流源按上述曲线输出
判定准则：180V期间输出电流≥额定值的50%；恢复220V后3s内恢复满功率
数据记录：输入电压、输出电流、输出功率，采样率≥10kHz
备注：若客户允许降额至30%，需在规格书签署前书面确认

变更控制同样重要。需求澄清阶段确认的参数，在项目执行中可能因客户设计变更而调整。规格书应保留版本号和变更记录，每次变更明确影响哪些测试项、是否需要重新执行。没有变更控制的规格书，在项目后期会变成“谁都可以解释”的文档，失去判定依据的作用。

五、常见问题与规避

第一类问题是把企业标准直接当客户需求。企业标准是底线，客户可能有更严苛的场景要求。第二类问题是测试项粒度过粗，例如“充电兼容性测试”一项涵盖单相、三相、宽压、谐波、效率，执行时无法分配资源和判定。第三类问题是判定准则缺少时间窗口，导致保护动作“是否及时”无法量化。

规避方法是在规格书评审时做一次“反向验证”：随机抽取三条测试项，让未参与编写的工程师仅凭规格书复现测试并给出通过/不通过结论。如果复现结果不一致，说明规格书仍有歧义。这个动作比任何格式检查都更能暴露问题。

需求澄清与规格书编写的本质，是把项目后期的争议前移到文档阶段解决。一份好的规格书，应该让测试工程师不需要再问“客户到底想要什么”，只需要按条件执行、按准则判定、按记录留痕。