📚 课程目录第2章项目启动与需求澄清

2. 项目启动与需求澄清

TestStand 项目失败最常见的原因，不是序列写得不好，而是需求从一开始就没有对齐。产品团队关心功能是否达标，制造团队关心节拍与直通率，质量团队关心追溯与判废边界，三方对“测试通过”的定义往往并不一致。项目启动阶段的核心任务，就是把这些分散的期望收敛成一份可执行、可验证、可追溯的测试需求规格（Test Requirement Specification，TRS）。

一、先明确三方各自真正关心什么

需求澄清不是开一次会就能完成的，它需要把三个团队的语言翻译成同一套工程语言。产品团队通常提供设计规格书、关键性能参数与容差；制造团队提供工位布局、节拍目标、操作员技能水平与设备能力；质量团队提供缺陷历史、判废规则、追溯字段与审核要求。三者关注点不同，但最终都要落到 TestStand 的测试项、判定限值、数据记录和报告上。

一个实用的做法是：在启动会上不讨论“怎么做”，只讨论“测什么、判什么、留什么”。把每个测试项拆成四要素——被测对象、激励条件、测量量、判定规则。例如“电源板 5V 输出”这个测试项，被测对象是 U12 输出端，激励条件是输入 12V 且使能拉高，测量量是电压值，判定规则是 4.75V～5.25V。只有四要素齐全，后续才能在 TestStand 中直接映射为 Step 与 Limit。

二、需求澄清的输入与输出

启动阶段需要收集的输入包括：产品设计规格（DDS）、关键特性清单（KCC）、制造工艺流程图、工位节拍要求、质量追溯字段清单、历史失效模式（FMEA 或客诉记录）。输出则是一份 TRS，它至少应包含测试项清单、每项的激励与测量方法、判定限值、采样率或稳定时间、数据记录字段、失败处理策略以及追溯要求。

TRS 不是越厚越好，而是越可执行越好。判断标准很简单：一个不熟悉该产品的测试工程师，能否仅凭 TRS 在 TestStand 中把对应 Step 写出来，并知道失败时该判重测、返修还是报废。如果做不到，说明需求还停留在“功能描述”层面，没有落到工程参数。

三、对齐过程中的关键动作

第一，建立需求条目编号。每个测试项分配唯一 ID，如 TRS-PWR-001，后续 TestStand 的 Sequence 名称、报告字段、追溯记录都引用该 ID，避免口头需求与实现脱节。第二，明确限值来源。限值不能由测试工程师自行决定，必须来自产品规格或质量判废标准，并在 TRS 中标注来源文件与版本。第三，定义失败分类。常见分类包括：测量超限、通信失败、仪器超时、夹具接触不良、操作员误操作。不同分类对应不同处理路径，不能一律判 FAIL。

第四，确认节拍预算。制造团队给出的节拍目标需要拆解到每个测试项，例如总节拍 45 秒，其中上电稳定 3 秒、电源测试 5 秒、通信测试 8 秒、功能测试 20 秒、数据上传 4 秒、余量 5 秒。若某项测试实际耗时超出预算，应在 TRS 评审阶段就暴露，而不是等到产线调试时才发现。

需求评审时建议让产品、制造、质量三方共同在 TRS 上签字确认版本号与日期。后续任何限值或测试项变更，都必须走变更记录，避免“口头改一下”导致追溯断链。

四、从需求到 TestStand 的映射关系

TRS 中的每个测试项，在 TestStand 中通常对应一个 Sequence 或一个 Step Group。测试项 ID 映射为 Sequence 名称或 Step 的 Additional Results 字段；激励条件映射为仪器配置 Step；测量量映射为 Numeric Limit Test 或 String Value Test；判定规则映射为 Limit 的 Low/High 或 Pass/Fail 表达式；追溯字段映射为 Report 的 File Globals 或 Database 列。

下面这张图展示了三方需求如何汇聚为 TRS，再映射到 TestStand 执行与数据记录的完整关系。图中左侧是三个团队的输入，中间是 TRS 的核心字段，右侧是 TestStand 中的对应对象与最终输出。

五、TRS 示例片段

下面给出一份可直接参考的 TRS 条目示例，字段按实际项目需要裁剪。示例中的参数为教学假设值，实际项目应以产品规格书和质量判废标准为准。

TRS-PWR-001  电源输出电压测试
被测对象：U12 输出端（5V 轨）
激励条件：输入 12V，EN 拉高，负载 0.5A
测量量：直流电压
判定限值：4.75V ~ 5.25V（来源：DDS-RevC 第 4.2 节）
稳定时间：上电后 200ms 采样
失败分类：超限 → 返修；无输出 → 检查夹具接触
追溯字段：序列号、工位号、测试时间、测量值、判定结果

TRS-COM-002  通信回环测试
被测对象：UART1 TX/RX
激励条件：发送 0x55 回环帧，波特率 115200
测量量：接收字节与校验结果
判定限值：接收字节 == 0x55 且校验通过
超时：500ms
失败分类：超时 → 重测一次；仍失败 → 返修
追溯字段：序列号、固件版本、测试时间、判定结果

六、评审与冻结

TRS 初稿完成后，应组织一次跨团队评审。评审重点不是文字措辞，而是三件事：限值是否有明确来源、失败分类是否覆盖已知失效模式、节拍预算是否可达成。评审通过后冻结版本号，例如 TRS-v1.0，并记录三方签字。后续若产品改版或质量规则调整，必须走变更流程，更新版本号并同步到 TestStand 的 Sequence 与报告模板。

不要在没有冻结 TRS 的情况下直接开始写 TestStand 序列。需求未冻结就开发，后期限值变更会导致大量 Step 返工，且追溯记录无法对应到具体需求版本，质量审核时会出现断链。

完成需求澄清后，项目才真正具备进入 TestStand 工程搭建的条件。此时每个测试项都有唯一 ID、明确限值、失败路径和追溯字段，后续的序列开发、仪器配置、报告设计和产线部署才有稳定的依据。