企业官网建设流程全解析

PRD、SSTS、CTS，这三个缩写放在一起，做汽车电子软件、嵌入式测试或者底盘车身域开发的朋友应该都不陌生。我见过太多项目，需求文档写得热热闹闹，一到系统测试规范（SSTS）和组件测试规范（CTS）阶段就开始抓瞎：要么PRD写得太空没法下手写用例，要么SSTS和CTS内容大量重复，要么测试项和需求对不上号，最后评审会上被质量工程师问得哑口无言。说白了，从产品经理脑子里那个“想法”，到最终能装车稳定运行的“零件”，中间这条“需求 → 系统软件测试规范 → 组件测试规范”的链路，才是决定项目能不能按时、按质交付的关键。

这篇文章我就从一个干了十多年汽车电子开发的工程师视角，用一个真实的功能例子，带你完整走一遍这条链路。我会把PRD里哪些话能直接变成测试用例、SSTS和CTS的粒度差别、追踪矩阵怎么做、AI写测试用例到底靠不靠谱都讲透。无论你刚入行做测试，还是被需求问题折腾得焦头烂额的项目经理，这篇都能给你一点能直接用的东西。

1. 三个文档的定位：先搞清楚谁给谁当输入

1.1 PRD、SSTS、CTS各自在干什么

PRD全称是Product Requirement Document，产品需求文档，回答的是“做什么”。它描述一个功能从用户视角看起来是什么样，比如“车主靠近车辆时车门自动解锁”“按下启动按钮车辆上电”。这一层基本不关心具体用哪个芯片、走CAN还是LIN，只关心功能行为和边界条件。

SSTS全称是System Software Test Specification，系统软件测试规范，回答的是“系统层面怎么验”。它站在整车或子系统的角度，验证多个控制器协同工作时功能是否满足PRD。比如无钥匙进入功能，需要车身控制器（BCM）、门模块、无钥匙进入控制器（PEPS）、低频天线、高频接收模块一起配合，SSTS就是把这些都连起来测。

CTS全称是Component Test Specification，组件测试规范，回答的是“单个零件层面怎么验”。它聚焦某一个控制器或软件组件，比如单独测PEPS控制器对上电时序、LIN唤醒、报文校验的处理是否正常。CTS的时代背景是ASPICE和功能安全越来越普及，大家发现如果每个组件都按自己的逻辑测一遍，组件之间根本不联动，系统集成时必然炸锅，所以CTS要和SSTS明确分工。

我常用一个盖房子的类比：PRD是建筑设计图，告诉你要盖一栋什么样的房子，几间卧室、几个卫生间；SSTS是监理的竣工验收方案，站在整栋楼的角度检查每个房间是否满足当初的设计意图；CTS则是每块砖、每扇窗的出厂检验标准，砖要承受多大压力，窗要抗多大风压。没有CTS，砖的质量参差不齐，最后墙体会裂；没有SSTS，每块砖都合格但拼起来的房子可能根本不是人住的。

1.2 为什么SSTS不能省、CTS不能直接抄SSTS

我接触过一些项目组，为了赶进度，拿到PRD直接让工程师写CTS，把SSTS跳过。理由是“我们本来就是做单控制器开发和测试的，直接写组件测试不更高效吗”。这个想法短期看确实省事，长期看是给自己埋雷。

CTS是由组件开发工程师写的，他对自己负责的那个控制器了解最深，但他天然缺乏“整车视角”。PEPS控制器单独测，所有报文都正常，但系统联调时发现BCM唤醒时序不对，PEPS发解锁指令太早，BCM还没完成初始化，指令丢了。这个问题只有在SSTS这一层才能暴露出来，因为SSTS要求你把BCM、PEPS、门模块、钥匙模拟器都搭在同一个测试环境里，按真实上电时序跑一遍。

从ASPICE和ISO 26262的角度看，需求追踪矩阵（RTM）是硬性要求。PRD的每一条需求，都要能追踪到至少一条SSTS用例和一条CTS用例；反过来每条测试用例都要能回溯到某条需求。如果跳过SSTS，PRD和CTS之间就缺了一层“系统级验证”，审计时这层追踪关系就断了。很多功能安全相关的控制器，这一项过不了，项目直接卡住。

所以正确的链路一定是：PRD → SSTS → CTS，每一层都拿上一层当输入，每一层都要有独立的测试目的和环境定义。这样才能保证“想法”在变成“零件”的过程中，每一层都有据可查、有迹可循。

2. 从PRD到SSTS：把“用户故事”翻译成“系统验收项”

2.1 一份能被测试用的PRD长什么样

我见过大量PRD，最大的问题就是“形容词太多、数字太少”。比如“车主靠近车辆时，车门应在合理时间内解锁”，这句话里的“靠近”和“合理时间”都没法测。什么叫靠近？是手机蓝牙连上就算靠近，还是走到驾驶座门把手才算靠近？什么叫合理时间？是1秒还是10秒？

一份能被测试直接使用的PRD，至少要具备三个要素：边界、时间、环境条件。我举一个无钥匙进入（PEPS）的例子：

• FR-PEPS-001：当合法钥匙位于车外左前门1.5米范围内，且用户拉动左前门把手时，左前门应在2秒内完成解锁。
• FR-PEPS-002：当合法钥匙位于车内，且车辆处于电源OFF状态时，用户按下启动按钮，车辆应在500ms内切换到ACC电源状态。
• FR-PEPS-003：当检测到钥匙位于车内但驾驶员在车外且试图锁车时，车辆应禁止锁车，并发出3次蜂鸣提示。

大家看这几条PRD，每条都有明确的触发条件（钥匙位置、用户动作）、时间要求（2秒、500ms）、行为结果（解锁、切换电源状态、禁止锁车）。测试工程师拿到这种PRD，几乎不需要二次解读，直接对着写用例就行了。

我特别想强调“环境条件”这一项，这是新手最容易漏的。还是FR-PEPS-001，如果是在地库低温环境下，钥匙和车辆的通信距离可能缩短，解锁时间可能变长。所以PRD最好写成：在常温、无强干扰条件下满足上述时间要求；在-40℃环境温度下，解锁时间放宽到3秒。有了这种分级描述，SSTS也好，CTS也好，才能在设计测试用例时区分标定目标值和法规极限值。

2.2 SSTS编写：系统级的四步走

拿到PRD之后，编写SSTS的时候，我一般按四步走。

第一步是列测试目的和测试环境。测试目的要写清楚这个SSTS文档覆盖哪些PRD条目，是验证功能、验证鲁棒性还是验证故障响应。测试环境要写明用什么工具链，是HIL（硬件在环）台架、实车还是子系统台架。比如测PEPS无钥匙进入，我建议用HIL台架，因为可以在台架上灵活控制钥匙位置、天线状态、总线信号，比实车更容易构造边界条件。

第二步是逐条映射PRD到系统级测试用例，这是SSTS的核心工作。一条PRD可以衍生多条SSTS用例，因为系统级验证要考虑正常路径、异常路径、性能边界、故障注入等。比如FR-PEPS-001，至少可以衍生出：

• SSTS-PEPS-001（正常路径）：合法钥匙在1.5米内，拉动门把手，验证左前门解锁，耗时≤2秒。
• SSTS-PEPS-002（边界路径）：合法钥匙在1.6米处，拉动门把手，验证不解锁，这是为了确认“1.5米”这个边界不是虚的。
• SSTS-PEPS-003（故障注入）：低频天线故障，车门处于上锁状态，拉动门把手，验证车辆不解锁并记录故障码。

第三步是定义通过准则。这看起来简单，但实际最容易写含糊。比如SSTS-PEPS-001的通过准则，我会写成：从拉手开关信号被整车CAN读取的时间点起，到BCM发出门锁解锁命令的时间点止，间隔≤1.5秒；门锁机械结构实际动作完成时间≤2秒；整个过程中无任何故障码上报。这里我做了个细节：CAN报文时间和机械动作时间是分开计量的，因为电子信号快、机械动作慢，混在一起以后排查问题分不清是电控问题还是机械问题。

第四步是写前置条件和初始状态。前置条件包括车辆电源状态、钥匙电池电量、天线位置、总线负载率、诊断仪的连接方式等。比如测PEPS解锁，整车网络里要模拟钥匙认证通过后的状态，如果前置条件里没写清楚“钥匙已通过RF认证”，同一个用例两个工程师能测出不一样的结果。

我特别要强调，SSTS这一层级不要写“具体读哪个引脚、用哪个寄存器、焊哪根线”。那是CTS该管的事。SSTS站在系统视角，关心的是信号流和最终行为；如果SSTS写得太底层，组件测试就没事可干了，而且还会导致底层实现变了之后SSTS跟着频繁改，维护成本非常高。

3. 从SSTS拆到CTS：组件级用例是怎么一步步落地的

3.1 先划组件边界

SSTS写完后，进入CTS编写阶段。这里很多团队会问一个问题：CTS到底是给每个控制器写一份，还是给每个软件组件写一份？我的经验是，CTS的拆分粒度取决于组件边界怎么划。

在无钥匙进入这个功能里，涉及PEPS控制器、BCM、左前门模块、钥匙模拟器这四个主要组件。每个组件都需要单独的CTS。但CTS不是把SSTS用例简单地“按组件过滤一遍”，而是要从组件自身的行为完整性出发，把该组件在各种输入下的响应都测全。

比如PEPS控制器的CTS，除了覆盖SSTS里跟PEPS相关的那几条（如唤醒、低频驱动、高频接收、钥匙认证），还应该覆盖PEPS控制器自身软硬件边界：低电压下LF天线驱动能力是否下降、钥匙认证失败的次数统计逻辑是否正确、本地存储的钥匙ID表是否在掉电后丢失等等。这些内容是SSTS完全不关心的，因为在系统层面这些细节被其他组件覆盖了，但对PEPS这个“零件”本身来说，这些都是它正常工作的前提。

我给一个具体的组件划分思路：把每个控制器当成一个黑盒，列出它的所有输入（总线报文、硬线信号、无线信号、供电状态）、所有输出（总线报文、硬线输出、无线信号、故障码），CTS就围绕“给定输入组合，验证输出是否符合预期”来组织。这一步做完，CTS的骨架基本就有了。

3.2 用追踪矩阵拆用例

CTS用例必须能回溯到SSTS或PRD，这是硬要求。我一般会建一个RTM表格，把三层关系一张表拉通。还是无钥匙进入的例子：

看这张表，有几个信息值得细讲。第一，一条PRD对应多条CTS用例，因为一个系统功能横跨多个组件。第二，有些需求只在组件级验证，比如低功耗电流，系统级测试很难单独测量某一个控制器的休眠电流，放进CTS更合理。第三，CTS用例的数量通常远大于SSTS用例，这是正常的，但要确保多出来的用例是组件自身行为，而不是SSTS用例的简单复制。复制粘贴式的CTS，评审时一眼就能看出来，质量很低。

实操中我建议用专门的工具链来维护RTM，比如Polarion、DOORS或者Jama，哪怕团队小，Excel也能用，但一定要保证编号唯一、变更可追溯。项目后期客户审计时，这个表就是救命稻草。

3.3 用AI根据PRD生成测试用例的实操与反思

最近圈子里很多人问“AI能不能根据PRD直接生成测试用例”，我也试过不少。可以负责任地说，AI能帮你写出80%的“基础用例”，但那20%的“边界用例”和“时序相关用例”，才是决定测试质量的关键，这20%恰恰是AI目前最薄弱的环节。

我用AI工具生成SSTS和CTS初稿时，一般会用一个固定套路：给角色、给样例、给约束、让AI补边界。比如我会这样说：“你是汽车电子领域的测试架构师，请根据以下PRD条目生成SSTS用例。PRD条目用统一格式，每个用例包含用例编号、前置条件、测试步骤、通过准则、验证层级。请额外列出你认为容易遗漏的边界条件和异常路径。”然后把FR-PEPS-001这类条目扔进去。

AI给我的初稿里，正常路径用例质量很高，步骤也完整。但当我让它列异常路径时，它给我的多是“钥匙信号丢失”“电池电量低”这种通用异常，很少会主动想到“低频天线驱动器过温导致LF场强下降”这种模块级失效场景。所以我现在的做法是，AI生成初稿后，我会重点做三件事：一是检查每个用例是否引用了真实的信号名和报文ID，AI经常会编造不存在的信号；二是检查前置条件里的系统状态是否可达，比如某个用例要求“车辆处于运输模式”，如果这个模式在实车上不可配置，这条用例就无法执行；三是把AI漏掉的跨控制器时序用例补上，比如“BCM唤醒后5秒内PEPS必须完成初始化”这种，AI几乎不会主动生成。

我把这个经验总结成一句话：AI当一个不会累的助手用，能快速给你一个还算像样的草稿，但别指望它替你完成测试设计中最需要经验和跨模块视野的部分。用的时候还要注意，生成结果里一旦出现非公共交通类、非专业术语的奇怪表述，记得清理干净再入文档。

4. 同一套缩写，两套语境：术语歧义与测试中的典型问题

4.1 “CTS不balance只解DRC”是什么语境的话

写到这里，我想插一个很多工程师都遇到过的情况：同一个缩写，在不同背景的人嘴里，完全是不同的东西。有一次我在一个群里看到有人在讨论“CTS不balance只解DRC”，当时我就愣了一下，这不是我们测组件测试规范（Component Test Specification）的说法啊，这是芯片后端设计里的概念。

在那个语境下，CTS指Clock Tree Synthesis，也就是时钟树综合，是数字芯片物理设计里的一个步骤。DRC是Design Rule Check，检查版图里的线宽、间距、天线效应等制造规则是否违例。Balance指时钟树的平衡，就是让时钟信号从根部到达每个触发器的延迟尽量一致，通常用时钟偏斜（skew）来度量。

“CTS不balance只解DRC”这个说法，我理解是：在做时钟树综合时，如果只解决制造相关的DRC违例，不去做时钟树的平衡，甚至不做有用的时序收敛，最后做出来的芯片可能功能都正常，但时序是坏的。DRC和balance是两个维度的事，只解决几何规则，不解决时钟到达时间一致性，芯片流片后跑高频可能就崩。这个道理放到我们测试文档领域，换成“只管解决表面问题，不解决本质问题”也完全成立。

我特别想提醒大家，在写SSTS和CTS文档时，一定要在文档开头加一个术语表。同一个CTS，在软件测试文档里是组件测试规范，在芯片设计文档里是时钟树综合。如果你不给团队定义清楚，评审时做芯片的同事和做测试的同事真的能鸡同鸭讲半小时。给团队维护一份统一的术语表，成本很低，收益极高。

4.2 测试“假绿”案例：SSTS过了、CTS全过，整车还是出问题

说一个我在实际项目中踩过的坑。当时我们在做一个遥控钥匙解锁功能，SSTS用例和CTS用例全部通过，测试报告一片绿。结果送去整车做路试，出现一个偶发问题：钥匙在车后方时解锁成功率很低。我们发现HIL台架上的LF天线位置和增益模型设置得太理想，实车的天线布局经过座椅、内饰遮挡后，实际场强比台架衰减了很多。

这问题出在哪呢？SSTS用例里写了“合法钥匙在1.5米范围内”，但没区分方位角。PRD里的“1.5米范围”描述的是一个理想球面，但实际整车天线是全向里有方向性的，车头和车尾的覆盖差别很大。CTS这一层更是没机会暴露这个问题，因为CTS只测PEPS控制器的LF驱动能力，不会真的去关心电磁场在座舱里的分布。

排查这个问题的思路还是靠RTM表往回倒查。我们从实车失效现象出发，找是哪条SSTS用例没有覆盖“钥匙位于不同方位角”这个条件，再找PRD里有没有要求“全向覆盖”，最后发现PRD本身就在“1.5米范围内”这句话上留了歧义。修复方案是：PRD增加方向性描述和最小覆盖场强要求，SSTS增加两个方位角用例，CTS则补充一条LF天线输出电压在不同负载下的校准用例。

这个案例我记到现在，就是因为“假绿”比“真红”危险多了。真红至少说明测试发现了问题，假绿则让所有人都以为没问题，问题在量产阶段爆发，代价翻好几倍。我现在每次看测试报告，都会特别留意“测试环境配置”和“实车环境的差异度”，如果差异度大，即使报告全绿我也会多问一句。

4.3 流程管理避坑：文档版本、评审记录、自动化平台

最后聊几个流程上的坑，都是我在项目里被现实教育过的。

第一个坑是文档版本控制。PRD改了需求，SSTS和CTS没同步更新，导致测试按旧用例测新功能。这个问题的根源是文档间的关系没有在工具层面建立起来。我现在要求所有项目必须在同一个平台里管理需求、测试用例和缺陷，比如用Polarion或者Jama，至少也要用同一个目录下的受控文档，而不是你发一个“PRD_v7_final_最终版_v2.doc”我发一个“SSTS_new_version_修改版.docx”。

第二个坑是评审走过场。很多时候SSTS和CTS评审会就开半小时，大领导在会议室刷手机，工程师念PPT，最后签字。我建议评审时不要逐条念用例，而是重点看三类内容：新增需求和变更需求对应的用例是否存在且可测、每条用例是否有明确的通过准则、RTM表是否有断链。把评审时间花在这三件事上，比念PPT有用得多。

第三个坑是测试工具链自动化程度太低。CTS里大量用例是重复性的硬件在环回归，如果全靠人工操作，凌晨两点你在测试台架旁边换线束的事情一点不稀奇。我一般建议团队做两件事：能自动生成的测试报告让脚本自动生成，连线束状态检测都做成半自动。自动化工具建设初期投入可能看起来不划算，但只要这个项目还做第二版，回报就非常明显。

我把这个经验总结成一张表，给团队做流程检查时用：

我在实际做项目时，最大的一个感受是：文档是写给自己三个月后看的。现在不写清楚的关键参数和边界条件，三个月后上线前排查故障时会让你加班三个通宵。PRD里多写一个明确的时间值，比写十页“满足用户预期”这种话有价值一万倍。

最后再分享一个小技巧：编写SSTS和CTS时，把PRD原文复制到用例的“需求来源”一栏里，不要只填一个需求编号。这样不管是评审时还是三年后翻文档，打开用例就知道这条用例到底在验证什么，不用再回头翻需求文档。这一步很不起眼，但维护过老项目的人都知道它有多好用。