第二章：测试需求分析——读懂产品规格书，才能写好测试规范

做FCT功能测试系统开发，最怕什么？

我个人觉得，最怕的是需求没搞清楚就动手。你想想看，硬件搭好了，软件写完了，结果发现测试项漏了，或者测试标准搞错了——那真是欲哭无泪。我在项目中遇到过好几次这样的教训，后来总结出一句话：测试需求分析做得好，项目就成功了一半。

这一章，我们就来聊聊怎么把产品规格书吃透，怎么提取测试项，怎么制定测试计划，最后输出一份靠谱的测试规范文档。

2.1 产品规格书——测试需求的源头

产品规格书（Product Specification）是测试需求的唯一权威来源。说白了，产品要测什么、怎么测、标准是什么，都得从这里面找。

拿到一份规格书，我一般会按以下步骤来读：

  1. 先看功能描述——搞清楚这个产品是干什么的，有哪些功能模块。
  2. 再看电气参数——电压、电流、频率、时序，这些是测试的核心。
  3. 然后看接口定义——每个引脚的功能、电平标准、通信协议。
  4. 最后看环境要求——温度、湿度、振动等，决定测试条件。
我的习惯：读规格书时，我会拿一支红笔，把每个可能成为测试项的参数圈出来。比如“输出电压3.3V±5%”，这个“±5%”就是测试标准。

举个例子，我曾经接手过一个电源管理模块的项目。规格书上写着“待机电流小于10μA”。嗯，这个看起来很简单对吧？但仔细一看，规格书里还写着“在待机模式下，I2C总线必须保持高电平”。这就意味着，测试待机电流时，I2C总线状态也要监控。如果你漏掉了这个细节，测试结果可能就不准确。

2.2 提取测试项——从规格书到测试清单

读懂了规格书，下一步就是提取测试项。这一步很关键，我把它叫做“翻译工作”——把产品设计语言翻译成测试语言。

提取测试项，我一般遵循以下原则：

  • 每个可测参数都是一个测试项——电压、电流、频率、时序、通信协议等。
  • 每个功能都要有对应的测试——上电、复位、模式切换、异常处理等。
  • 边界条件必须测——比如输入电压的上限和下限、温度的高温和低温。
  • 异常情况也要考虑——短路、开路、过压、欠压等。

我习惯用表格来整理测试项，这样一目了然：

测试项编号 测试项名称 测试条件 判定标准 测试方法
TC-001 输入电压测试 上电后，输入电压5V 4.75V ~ 5.25V 万用表测量VIN引脚
TC-002 输出电压测试 正常负载下 3.3V ± 2% 万用表测量VOUT引脚
TC-003 待机电流测试 待机模式，I2C高电平 < 10μA 串联电流表测量
TC-004 I2C通信测试 发送0x55数据 回读数据一致 逻辑分析仪抓波形
注意：测试项不是越多越好。我曾经见过一份测试清单，把每个引脚的电压都列出来了，结果测下来全是正常的，白白浪费了时间。测试项要有针对性，重点覆盖关键参数和风险点。

2.3 制定测试计划——把测试项串起来

测试项提取完了，接下来就是制定测试计划。测试计划解决的是“怎么测、用什么测、测多久”的问题。

我个人习惯把测试计划分成三个层次：

  1. 测试策略——整体思路，比如先测功能后测性能，先测正常后测异常。
  2. 测试资源——需要哪些仪器设备、工装夹具、软件工具。
  3. 测试流程——测试的顺序、步骤、时间安排。

这里我画了一张流程图，帮你理清测试需求分析的整体逻辑：

测试需求分析流程图 产品规格书 功能描述、电气参数 提取测试项 可测参数、功能验证 制定测试计划 策略、资源、流程 编写测试规范 文档化、评审确认 迭代优化 整个流程是迭代的，测试过程中发现的问题可能会反馈回规格书解读或测试项提取 关键评审点 关键评审点

制定测试计划时，有几个要点需要注意：

  • 测试顺序要合理——先做基础功能测试，再做性能测试。基础功能不过，性能测试做了也白做。
  • 资源要提前确认——仪器设备是否到位？工装夹具是否设计好了？软件驱动是否准备好了？
  • 时间要留余量——测试过程中总会遇到意外，比如仪器坏了、样品不够了。我一般会留20%的缓冲时间。
避坑指南：我曾经在一个项目中，测试计划排得太满，结果第一天就发现测试夹具接触不良，导致所有测试数据都无效。后来我学乖了，测试计划里一定会加一项“工装验证”，先跑一遍确认工装没问题，再正式开始测试。

2.4 编写测试规范文档——把需求固化下来

测试规范文档是测试需求分析的最终输出。它不仅是测试执行的依据，也是项目评审、验收的重要参考。

一份完整的测试规范文档，我一般会包含以下章节：

  1. 概述——测试目的、适用范围、参考文档。
  2. 测试环境——硬件平台、软件工具、仪器设备清单。
  3. 测试项清单——每个测试项的编号、名称、条件、标准、方法。
  4. 测试步骤——每个测试项的具体操作步骤，包括初始状态、操作动作、预期结果。
  5. 判定规则——PASS/FAIL的判定标准，以及异常处理流程。
  6. 附录——测试数据记录模板、问题跟踪表等。

这里我分享一个测试步骤的写法示例：

测试项：TC-003 待机电流测试
测试条件：待机模式，I2C总线保持高电平
测试步骤：
  1. 将产品置于待机模式（通过GPIO拉低EN引脚）
  2. 确认I2C总线SCL和SDA均为高电平
  3. 在电源输入端串联电流表
  4. 读取电流表数值
  5. 记录数据到测试记录表
判定标准：电流值 < 10μA
注意事项：测量前需等待10秒，确保产品进入稳定待机状态
我的经验：测试步骤写得越详细越好。不要觉得“这个大家都知道”，实际上测试人员可能换了一拨又一拨。写得清楚，后面的人一看就懂，不用再来问你。

2.5 测试规范的评审与确认

测试规范写完了，别急着发出去。一定要做评审。

评审我一般会邀请这几类人：

  • 产品工程师——确认测试项是否覆盖了所有功能。
  • 硬件工程师——确认测试条件是否合理，会不会损坏产品。
  • 软件工程师——确认测试方法是否可行，是否需要开发测试软件。
  • 测试工程师——确认测试步骤是否可执行，仪器设备是否到位。

评审会上，我通常会问三个问题：

  1. 这个测试项真的需要测吗？——避免冗余测试。
  2. 这个测试方法能测出问题吗？——避免无效测试。
  3. 这个判定标准合理吗？——避免过严或过松。
注意：评审不是走过场。我曾经见过一个项目，测试规范评审时大家都没意见，结果测试过程中发现有个测试项根本没法测——因为产品上没有对应的测试点。这就是评审没到位的结果。

好了，这一章的内容就到这里。测试需求分析是FCT测试系统开发的基石，花再多时间都值得。下一章我们会聊测试系统的硬件架构设计，到时候见。

专注资料整理

← 上一章 📖 返回目录 下一章 →