M1-03 DVP&R 与验证计划管理

课程代码 M1-03 · 板块 M 项目、质量、成本与合规 / M1 研发流程与项目管理 时长 约 3.5 小时（6 讲 + 1 次 DVP&R 矩阵实操） 适合对象 试验工程师与项目经理；凡要编写、评审或签署 DVP&R 的人（试验岗必修，系统岗选修） 前置 B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件；M1-01 汽车研发流程（APQP/IATF16949）与热管理里程碑 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 M1-03 大纲的完整展开版

---

引言：那一行判了「通过」，它到底证明了什么

一份 DVP&R（设计验证计划与报告，Design Verification Plan and Report）交到评审桌上，最常见的样子是这样的：几十上百行，每一行都填满了字，试验名称写得规整，责任人一列没有空格，汇总页上需求覆盖率是一个漂亮的 100%，结论栏里清一色「通过」。会开得很顺，也提不出什么问题——因为看不出哪一格是错的。

麻烦要到后面才露头，而且形态相当固定：PV 阶段某一项复现不出 DV 的结果；某个边界工况在量产之后才被发现从来没有人验过，而它当初确实不在矩阵上；或者更常见的一种——某条需求中途改过一版，矩阵没跟着动，覆盖率照样算得出 100%，因为分母用的是旧版本。复盘时你会发现一件很不舒服的事：没有人违规。试验做了，报告有，判据栏也写了字，签字齐全。缺的东西不在任何一格里，它缺在「这些格子合起来到底证明了什么」这个问题上——而这个问题在评审时没有人问过。

⇒ 所以本课处理的不是「怎么做试验」。各类试验怎么做、上什么台架、按什么规程，是 L 板块与各产品课的内容，本课一条方法都不重讲，只做选路并给去向。本课处理的是矩阵里的那一行本身：它由哪几格构成、每一格空着会让「通过」两个字失去什么、以及这一行写完之后，它证明的范围到哪里为止。

钉子 A —— DVP&R 的一行不是「一个要做的试验」，是一条从需求到证据的闭合链；链上少一环，「通过」两个字就不成立。这条链有六环，而六讲恰好一讲钉一环：① 需求条目（可追溯的 ID 与版本，第 1 讲）→ ② 验证方式与试验层级（用什么方式验、上哪一级设施，且必须写明它能回答什么、明确不能回答什么，第 2 讲）→ ③ 样件状态（这一版样件与量产状态之间还差哪几个变量，第 3 讲）→ ④ 抽样与统计口径（样本量、置信度、可靠度、寿命节点、失效判据，第 4 讲）→ ⑤ 判定准则（被测量、数值范围、测量条件、环境窗口、复测规则，第 5 讲）→ ⑥ 证据与闭环（报告可追溯、不合格出口、再验证触发，第 6 讲）。★ 这根钉子的可操作形式是一句问句，全课每一讲末尾都要拿它自检：这一行如果判「通过」，它到底证明了什么？答不出来，就说明六环里有环是空的。⚠ 而空的那一环不会以「表格里有个空格」的形式暴露——它通常被一句「按标准执行」「见试验规范」填掉，于是这一行看起来是满的。开头那份全绿的汇总页，就是这么来的。

钉子 B —— 「通过」永远是有射程的：它只对被试的那个样件状态、那个环境窗口、那个统计口径成立，超出射程一个字都不能推。这根钉子把全课看起来互不相干的好几处收成同一件事：DV 通过推不出 PV 会过（样件状态这一维变了）；PV 通过推不出每一台合格（抽样只覆盖批次样本，量产每一台落在下线检测那一层）；零失效试验给出的只是可靠度的一个下限，而且只挂在那一个寿命节点上；「跑完 N 小时无失效」换一个样本量结论就变，因为它根本没有声明过射程；判定准则被受控放宽之后，历史上那些「通过」的射程随之改变，⛔ 不再与新判据下的「通过」等价。★ 钉 B 的可操作形式同样是一句问句：这个「通过」的射程边界写在哪一格里？写不出格子来，说明射程从来没被声明过——而没被声明的射程会被默认读成「无限射程」，那正是本课全部翻车形态的共同入口。

两钉的关系：钉 A 管「这一行写完了没有」（结构完整性），钉 B 管「写完之后它到底证明了什么」（结论射程）。⛔ 把两者合成一句「按计划完成验证」，正是本课要拆开的那个结——计划完成的是动作，而 DVP&R 要交付的是证据，两者之间隔着这两根钉子。

先打一针预防针。本课最容易被读反的一句是：「验证是设计的下游——设计定了才知道要验什么、判据是多少。」这句话听起来是常识（没有设计当然没法验），而它会让人在两个方向相反的场合各做错一次。

会做错的第一个具体动作：把判定准则那一格留空，等样件试出来了再填，填的是「本次实测值再留一点余量」。为什么这是读反：判据的正当来源里，「本次实测值」一次都没有出现过；用实测值当判据，判据就被它本该判定的对象定义了，整条链在逻辑上闭不上——这一行于是永远判通过，而它什么也没证明。更坏的是这个数会以「历史判据」的身份被下一代项目继承，从此没有人说得清它当初是从哪来的。⇒ 正确动作是：判据来源在需求侧就要定下来，来源缺位时先补需求侧推导（→B1-04 目标设定：降温速率、冬季续航热损、快充温升），机理与试验方法缺位时先做机理探索试验（→I6-04 可靠性目标、分配与寿命数据统计（TMS 可靠性量化入门） 的入口条件）；实在还定不出来的，那一格写「待定 ＋ 定它的责任人 ＋ 截止节点 ＋ 它依赖哪条上游输入」，⛔ 不许留空，也⛔ 不许写「满足要求」。

会做错的第二个具体动作，方向正好相反：知道「验证要前置」之后，在 VTS 还在拉扯的时候就把整份 DVP&R 的条目与判据一次写死并锁版，此后需求改了矩阵不动。为什么这是读反：验证前置指的是它与需求同步演进——每一条需求出生时就带上「它将怎么被验证」这一问，而不是「早早写完就不动了」。锁版之后需求再改，矩阵与 VTS 脱节，而脱节不会报错：需求覆盖率照样算得出 100%，因为分母用的是旧版本的 VTS。⇒ 两个动作同源：都把 DVP&R 当成在某个时刻产出的一份文件，而它其实是一条与需求同生共死的索引——需求活多久，它就要跟着走多久。所以这条预防针与钉子 A 是同一件事的正反面：钉 A 说一行要闭合，它说这条链在时间上也要闭合。第 1 讲讲覆盖率的分母时会第一次点破它，第 5 讲讲判据来源时第二次点破。

⚠ 还有一条次级的、同样容易读反的话，这里先备个案，第 4 讲正面拆：「样本量是保险系数——不放心就多测几件，档期紧就少测几件、必要时缩短试验时长多测几件补回来。」它把样本量看成一个可以单独调节的旋钮，看不见它其实同时挂在寿命节点、失效判据与试验时长这三件事上。

再把边界划清，因为本课与它周边十几门课贴得很近，不在开篇写死，必然重叠或者整段落空。本课给的是六样：矩阵的列结构与覆盖率口径 · 验证方式与试验层级的选路（含用仿真或低层级替代时的准入担保）· 样件状态阶梯与各自的证明射程 · 怎么把抽样的成立前提写成可判定的矩阵行 · 判据的正当性与完整构成及其受控再评估 · 不合格的处置出口与再验证的触发判定。只给去向的是：各类试验方法（L 板块各课）、Weibull 与寿命数据统计（I6-04 可靠性目标、分配与寿命数据统计（TMS 可靠性量化入门））、加速试验对标（I6-02 密封与接头寿命设计与加速试验对标）、过程能力与 SPC/MSA（M2-01 质量工具：PPAP/8D/SPC/MSA）、批接收抽样的正当用法（M2-03 供应商质量与来料控制）、下线检测（M2-04 整车总装线热管理 EOL 功能检测：项目、判据构造与数据闭环）、在役与保修数据（M2-05 售后保修与在役失效数据分析：从索赔表读出真实故障率并反馈设计）、在环验证（K4-03 MIL/SIL/HIL 验证流程）、仿真—试验相关性（J7-01 仿真—试验相关性验证（Correlation））与可信外推范围（B1-05 基于 V 模型的热管理正向开发流程）、路试结果的有效性判定（L4-04 整车道路试验通则：策划、车载数采与结果有效性判定）、再验证的范围判定（M2-06 量产阶段变更控制：4M 变更申报、再验证范围判定与量产断点切换）与变更点差异分析（I7-05 变更点失效分析（DRBFM）与变更评审）、判据推导的方法论（B1-04 目标设定：降温速率、冬季续航热损、快充温升）、需求分解与追溯（B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件／M1-04 需求管理与追溯（DOORS 等））。不在射程的是：APQP 阶段与门禁（M1-01 汽车研发流程（APQP/IATF16949）与热管理里程碑），以及法规认证申报。⚠ 还有一条口径要先交代：本课引用到的几份标准与手册均未独立核对过原文，故一律只写标准号与去向，⛔ 不写条款内容、不写限值与等级号；版次与年份以现行目录为准，引用前须核。

⇒ 学完这门课，你应当能做到三件事：看着一行 DVP&R，说得出它缺的是六环里的哪一环；看着一句「通过」，说得出它的射程边界写在哪一格里；看着一个不合格结论，说得出它该走哪一支处置出口、以及要不要触发再验证。六讲就按那条链的六环推进：第 1 讲立框（矩阵的列怎么分组、覆盖率的分母取哪一版、以及这个 100% 证明不了什么）；第 2 讲选路（验证方式是五类不是一类、试验层级是两条正交轴不是一条直线、降级替代的准入三问）；第 3 讲样件状态（DV／PV／EOL 各自能证明什么，以及真正的判据是五个变量冻结了没有，不是「第几轮样件」）；第 4 讲抽样（零失效公式怎么读、三条成立前提、耐久判据该写成什么样的统计表达）；第 5 讲判据（从哪来、怎么写死、怎么判、谁能改）；第 6 讲闭环（不合格的六支处置出口、报告的可追溯最小集、再验证的三类触发源）。第 1 讲就从那张表上最容易被跳过的一列开始——需求 ID 那一列。

第 1 讲　DVP&R 是一条双向索引，它的每一行是一条闭合链

一份 DVP&R 提交上来，最难判的从来不是「哪一行写错了」。写错了反而好办——数值不对、层级选错、责任人写了个已经离职的人，这些一眼可指。真正难判的是另一种：每一格都填了字，合起来却什么也没证明。需求那一列写着「座舱降温性能」，试验方法那一列写着「按试验规范执行」，判定准则那一列写着「满足要求」，样件状态那一列写着「工程样件」，责任人那一列写着「试验部」。表是满的，行数很多，评审会上没有人提得出反对意见，因为没有一格是空的。这一行走到最后会得到一个「通过」的结论，而这个结论追不回任何一条需求、说不清它对应哪个量产状态、也没有人能复核它是怎么判出来的。

本讲要建立的第一个判断力，就是把这样一行拆开看，并且给出拆的工具。走法是：先把一行 DVP&R 从需求到证据的六个环立起来，说清每一环空着时「通过」二字具体失去什么，同时把整份矩阵的性质定死为双向索引而不是排期表（1.1）；再把矩阵的列按功能归成四组，让「这一行写完了没有」从一次主观通读变成逐格核对的动作，并顺手把「通过」的射程有哪几项一次列全（1.2）；接着处理最容易被管理侧误用的那个数——需求覆盖率，先钉死它的分母（1.3），再钉死它不能证明什么（1.4）；然后给软件类验证项一个专门的登记格口，说清它的四要素与它的 gate 该挂在哪（1.5、1.6）；最后把本讲的全部内容收成一句可以逐行去问的自检问句（1.7）。

1.1 一行 DVP&R 不是「一个要做的试验」，是一条从需求到证据的六环闭合链

是什么。把一行 DVP&R 读成「一个要做的试验」，是所有后续麻烦的起点。它实际上是一条链，一头接在某一条需求上，另一头接在一份可复核的证据上，中间有六个环，环环相扣：

环	这一环要填的具体格子	这一环空着时，「通过」二字失去什么	展开在
① 需求条目	需求 ID ＋ 需求版本 ＋ 条款原文摘要	追不到需求——不知道它到底服务哪一条要求	第 1 讲
② 验证方式与试验层级	用哪一类证据形态、上哪一级设施、试验规程编号	不知道这个结论的层级射程有多远	第 2 讲
③ 样件状态	这一版样件与量产状态之间还差哪几个变量	不知道它对应的是哪一个量产状态	第 3 讲
④ 抽样与统计口径	样本量／置信度／可靠度／寿命节点／失效判据	结论没有统计含义	第 4 讲
⑤ 判定准则	被测量／数值范围／测量条件／环境窗口／复测规则	判定权交给了读报告的人	第 5 讲
⑥ 证据与闭环	报告编号／原始数据留存／不合格出口／再验证触发	证据不可复核	第 6 讲

⚠ 表的第三列——「这一环空着会失去什么」——是本课归纳的组织方式，⛔ 不是任何标准或任何客户体系模板的既有条款；它的用处是把一个含糊的「这一行不完整」翻译成一句可以当场指认的话。

为什么必须按链读，而不能按动作读。因为链上空掉的那一环，不会以「表格里有个空格」的形式暴露。它几乎总是被一句话填掉——「按标准执行」「见试验规范」「按客户要求」「参照上一代」。这几句话有一个共同的性质：它们在语法上是完整的答案，在工程上是一次转交。填了它们之后，格子不空了，可判定性却没有被建立起来，因为没有人被要求回答那一环真正的问题。⇒ 本讲开头那一行的六环里，实际上只有第 ① 环写了半个（需求名而不是需求 ID），其余五环全是转交句，而它看起来是满的。

这条链是双向的，所以整份 DVP&R 是索引不是计划表。承接需求逐级分解（B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件），DVP&R 把 VTS/SSTS 的每一条需求翻译成一条或多条可判定的验证条目，而它成立的技术条件只有一个：每一行以「需求 ID ＋ 需求版本」为主键，从需求查得到验证项，从验证项也查得到它服务哪一条需求。两侧都查得到，才叫索引。

为什么不能从「我们能做哪些试验」正推。正推列出来的表看起来往往更满——台架有哪几台、往年做过哪几项、供应商惯例交哪几份报告，逐项抄下来就是几十行。但这张表有一个致命的结构性缺陷：它缺需求 ID 那一列，于是需求覆盖率根本算不出来。更要命的是，正推漏掉的需求不会以「表上少了一行」的形式暴露——它是整类不出现：沿着「我们有哪些试验能力」这条线索往下数，凡是不在这条线索上的需求（要靠分析、靠检查、靠沿用已验证构型来证明的那些）会整类消失，而清点表的人看不出少了什么，因为他数的正是那条线索本身。这是本课要反复回到的枚举陷阱，第 2 讲会把验证方式的全集正面画出来。

工程量级与典型值。⛔ 本课不给 DVP&R 的条目数、行数区间与各类验证项的条目占比——它取决于系统复杂度、需求粒度与客户体系模板，须按本项目 VTS/SSTS 的实际条目确定。凡是拿一个「一般多少行」的数去反推自己这份矩阵完不完整的做法，本课明确不支持：行数多寡与覆盖率之间没有稳定关系，一份三百行的矩阵完全可能整类漏掉电气验证项。

易错点（三条）。

① 把 DVP&R 当成试验部门的排期表交出去。一旦它被归档成「试验计划」，需求侧再改就没有人回头看它——这正是本课反复要防的那条脱节，1.3 会给出它的正面写法。

② 需求 ID 那一列写成自由文本描述。写「座舱降温性能」而不写条款编号，追溯就断在这里：同一句描述在 VTS 里可能对应两条需求，也可能一条都不对应。⚠ 追溯工具链本身（需求管理系统怎么建、基线怎么拉、变更怎么传导）归 M1-04 需求管理与追溯（DOORS 等），本课只要求这一列存在且能双向查。

③ 只做单向。从需求能查到验证项，从验证项查不回需求——这种半边索引在项目中期看不出问题，等到需求版本升级、要判「哪些验证项受影响」时，它一条也回答不了。

1.2 矩阵的列按功能分四组，缺哪一组就决定这一行失去哪一种可判定性

是什么。一份 DVP&R 表最起码的五列是：需求条目、试验方法、判定准则、样件状态、责任人。各家模板在此之上加列的方式千差万别，逐列去比对模板是白费力气；按功能归组才能得到一个与模板无关的核对动作。本课把列归成四组，每一组回答一个不同的问题：

列组	这一组包含的列（示意，实际列名以本项目模板为准）	它回答的问题	缺了这一组，这一行失去什么
需求侧	需求 ID／需求版本／条款原文摘要	为什么要验	追溯断掉，覆盖率算不出来
方法侧	验证方式／试验层级与设施／试验规程编号／样件状态	怎么验	不知道结论的层级射程与样件射程
判据侧	被测量与测点／数值范围与方向／测量条件／环境窗口／复测规则／判据版本	凭什么判	判定权落到读报告的人手里
执行与证据侧	样本量与统计口径／责任人／计划与实际时点／结论／报告编号／不合格单号	谁做、证据在哪	结论没有统计含义，事后不可复核

⚠ 这套四组划分与「每组回答一个问题」的读法是本课归纳的，⛔ 不是某个标准既有的格式，也 ⛔ 不是任何客户体系 DVP&R 模板的实际列序。

为什么要归成四组。因为四组与 1.1 的六环一一对应：需求侧＝第 ① 环，方法侧＝第 ②③ 环，判据侧＝第 ⑤ 环，执行与证据侧＝第 ④⑥ 环。归组之后，「这一行写完了没有」就从一次通读变成了一个逐格核对的动作：四组各挑一个代表格子去问，问不出答案的那一组就是空的。这比「你这行写得不够细」有用得多——后者会引来一次辩论，前者只会引来一次补写。

顺手把「通过」的射程一次列全。一个「通过」永远是有射程的：它只对被试的那个样件状态、那个环境窗口、那个统计口径成立。射程写在哪里？就写在上面这几组列里。⚠ 沿「试验报告首页印了什么」这条线索去数射程，必漏后三项——它们通常不在首页上：

1. 样件状态（方法侧）
2. 试验层级与设施（方法侧）
3. 环境窗口：气温／海拔／辐照／路面与载荷区间（判据侧）
4. 测量条件与量具，含量具溯源（判据侧）
5. 统计口径：样本量／置信度／可靠度／寿命节点／失效判据（执行与证据侧）
6. 软件与标定版本——同一台样车换一版标定，热管理结论可能完全不同
7. 判据版本与有效期——判据改过之后，历史「通过」与新「通过」不等价

⚠ 这七项同样是本课归纳的清点方式。前五项各自落在上表的某一组里；第 6 项落不进硬件那套格子，这正是软件类验证项要单开一个登记格口的原因（1.5）；第 7 项落在判据侧的「判据版本」列上，第 5 讲会讲它为什么必须带版本号、谁有权改。第 6 讲把这七项当作试验报告可追溯性的最小集来用。射程七项写不出来，「通过」就会被默认读成无限射程——那是本课全部翻车形态的共同入口。

工程量级与典型值。⛔ 本课不给列数：各家 DVP&R 模板的列数不同，取决于客户体系与内部规程，须按本项目模板确定。本课给的是功能分组而不是列数——分组可以套到任何一份模板上去核对，列数不能。

易错点（三条）。

① 把「试验方法」一列写成一个规程编号就完事，不写样件状态与环境窗口。规程编号回答的是「按什么规矩做」，回答不了「这次做的是哪一版样件、在什么条件下做的」——射程整个丢掉，而表面上这一格填得很专业。

② 把责任人写成部门。写「试验部」而不写具体的人，等于没有责任人：追不到人的行，在进度会上永远处于「在推进中」。

③ 只按模板补列，不按功能核组。模板里有二十列而四组里缺一组，这种情况很常见——最常缺的是判据侧的测量条件与环境窗口，因为模板作者默认它们写在试验规程里。

1.3 需求覆盖率的分母永远取当前版本的 VTS，孤儿验证项必须单独成表

是什么。需求覆盖率是衡量 DVP&R 完整度的核心指标，它的定义是一个纯计数比：

需求覆盖率 ＝ 已追溯到验证项的需求数 ÷ VTS 需求总数

两端各有一条纪律，缺一条这个数就不可信：

• 分母永远取当前版本的 VTS，且只数可验证需求；
• 分子只认「已追溯到验证项」的需求，即需求 ID 与验证项 ID 双向查得到的那些。

除此之外还有一块东西既不进分子也不进分母，必须单独成表：孤儿验证项——表上有行、却挂不到任何一条需求上的那些。孤儿项要逐条判去留，出口只有两个：要么它对应着一条没写进 VTS 的隐含需求（那就回去补需求，把它认领回来），要么它是历史惯性项（上一代平台一直在做，本平台没人问过它为什么做——那就砍掉，它正在占用稀缺的试验窗口）。⚠「分母取当前版本」与「孤儿验证项单独成表」这两条是本课归纳的做法。

为什么分母这一条必须单独钉一次。这里要点破本课最容易被读反的那句话的第二个方向。「验证要前置」是对的，但它指的是验证与需求同步演进——每一条需求出生时就带上「它将怎么被验证」这一问；它不是「趁早把整份 DVP&R 的条目与判据一次写死并锁版，此后需求改了矩阵不动」。读成后者之后的具体动作是：在 VTS 还在拉扯的阶段就把矩阵锁版归档，然后专心执行。

这个动作的危险之处在于它不会报错。需求版本升级之后，矩阵没动，覆盖率照样算得出 100%——因为分母用的是旧版本的 VTS。脱节没有任何征兆，它留下的不是一个可疑的空格，而是一个漂亮的百分比，评审看到它会停止提问。⇒ 正面写法只有一条：覆盖率的分母永远取当前版本，需求版本一变就重算，并把差量逐条列出来——新增的需求有没有验证项？被删的需求，它的验证项该不该撤？被改的需求，原来那条验证项的判据还成不成立？第三问最容易被跳过，因为那一行看起来还在、还挂着，只是它挂的已经是另一条需求了。

工程量级与典型值。覆盖率是纯计数比，定义与算法可给、读者可复算；⛔ 本课不给「覆盖率应达到多少」的门槛——那属于客户体系与项目约定，须按本项目确认。

易错点（三条）。

① 分母用需求文档的条目总数，而不是「可验证需求」总数。说明性条款、参考性条款、术语定义一并混进分母，覆盖率被系统性拉低，然后所有人把这个低值当成噪声忽略——一旦被当成噪声，这个指标就彻底失效了。正确做法是先判定哪些条目是可验证需求（不可验证的怎么处置，第 2 讲给三种出口），把判定结果本身留痕。

② 需求版本升级后只补新增行、不复核被改需求的判据。见上。

③ 把分母悄悄修剪到 100%。把几条暂时想不出怎么验的需求从分母里剔出去，覆盖率立刻好看——⚠ 这与走豁免不是一回事：豁免要写明理由、批准人与有效期，是显式的一行；修剪分母不留任何痕迹。

1.4 覆盖率 100% 不等于没有验证盲区——它只是一个指派关系的完整性指标

是什么。把上一节那个数的射程说死：需求覆盖率只证明「每条需求都被指派了至少一个验证项」。它 ⛔ 不证明那个验证项的试验层级选对了，⛔ 不证明它的判据被写死了，⛔ 不证明它的样本量在统计上成立，⛔ 不证明它的样件状态与要下的结论匹配。这四件事分别由第 2 讲（层级选路）、第 5 讲（判定准则）、第 4 讲（抽样与统计口径）、第 3 讲（样件状态）来管，它们与覆盖率之间没有任何推导关系。

为什么必须在第 1 讲就把它说死。因为覆盖率是本课全部内容里最容易被管理侧误用的一个数：它是绿色的、是百分比、可以逐周对比、可以进汇报页。一个 100% 出现在门禁材料上，评审会往往就此停止提问——而它恰恰是四件真问题都还没被问过时也能达到的状态。⚠ 更坏的一种用法是反过来：因为覆盖率不够而临时新增一批验证项去凑分子。凑出来的行有一个共同特征——判据栏写「满足要求」，因为凑行的人并没有时间去把判据推出来（第 5 讲会把这句话点破，并给出判据的正当来源）。

⚠ 一条硬纪律：覆盖率这个量只用于判「指派关系是否完整」，⛔ 不得拿它反算验证充分性，⛔ 不得拿它反推「还差几项试验」。指派关系的完整性与验证的充分性是两个统计对象，一个数不能同时回答两个问题。

工程量级与典型值。⛔ 不给任何门槛值——包括「覆盖率不到多少不许过门禁」这类内部约定，本课不给。

易错点（两条）。

① 把覆盖率当成 DVP&R 评审的唯一出口判据。正确的出口判据至少还要加上 1.7 那句逐行自检问句的抽查结果，以及四组列的逐组核对结论。

② 用覆盖率的达标去替代对某一行的追问。「整体 100% 了，你这一行就别较真了」——这句话在评审会上出现时，说明覆盖率已经从一个诊断工具变成了一面挡箭牌。

1.5 软件类验证项要有自己的登记格口：层级 ＋ 在环形态 ＋ 覆盖率类型 ＋ 证据清单

是什么。热管理里的软件与标定类验证项（模式切换逻辑、阀路控制策略、热泵切换与除霜判据、故障诊断与降级策略）塞不进硬件那套「试验方法 ＋ 样件状态」的格口——它没有样件批次、没有试验设施、没有环境舱档期。它要登记的是四要素：

• 层级——在哪一级验：单元 / 集成 / 系统；
• 在环形态——MIL / SIL / PIL / HIL / 实车；
• 覆盖率类型——要交哪一类覆盖率证据；
• 证据清单——用例集版本、覆盖率报告、缺陷单关闭记录。

为什么不给它专门的格口就一定出事。没有格口，软件项在矩阵里就只能被写成一行——「软件功能验证——见软件测试报告」。拿 1.1 的六环去量这一行：第 ② 环（哪一级、什么在环形态）空、第 ③ 环（哪一版基线）空、第 ④ 环（用例覆盖到什么程度）空、第 ⑤ 环（什么算通过）空、第 ⑥ 环（缺陷单闭环记录在哪）空——六环里五环是空的，而这一行在表上占据的位置与硬件行一模一样，宽度还更窄，评审时最不容易被停下来看。

射程说死：本课只讲怎么登记、gate 设在哪。⛔ 覆盖率的定义（语句覆盖、分支覆盖、判定条件覆盖各自是什么）、达标判据、以及哪一类功能该要求哪一种覆盖率，一律去 K4-03 MIL/SIL/HIL 验证流程；⛔ 本课不给任何覆盖率百分比门槛、不给测试用例数、不给安全等级号——那些由客户体系与该功能的安全等级确定。本课在这里只交付一件事：矩阵上那一格该长什么样。

易错点（三条）。

① 把 HIL 通过当成整车层结论。在环级回答不了实物公差、装配与老化，它的保真度上限由模型与接口决定（见 K4-03 MIL/SIL/HIL 验证流程）；整车层要确认的是结果，第 2 讲的层级选路会把这条边界画清。

② 软件基线版本不写进矩阵。这是射程七项里第 6 项的典型失守形态：同一份「通过」在换一版标定之后射程已经失效，而矩阵上没有任何一格记录着它当初挂在哪一版，于是没有人知道该重验哪些项（这类「没人改硬件、但原证据不再算数」的情形，第 6 讲会作为再验证触发的一整类来处理）。

③ 把覆盖率报告当成证据清单的全部。四要素里的证据清单是三样：用例集版本、覆盖率报告、缺陷单关闭记录。缺陷单没关完而覆盖率达标，是可以同时成立的。

1.6 软件项的出口判据不止需求覆盖率，它的 gate 挂在「这一版基线撑不撑得住这一节点的验证」上

是什么。软件类验证项的出口判据至少有三层，⛔ 只写需求覆盖率是不够的：需求覆盖率（每条需求都有对应用例）＋ 结构覆盖率（代码结构被用例走到什么程度）＋ 各测试层级的证据件（单元、集成、系统各自的报告与缺陷单状态）。三层的具体判据与达标要求见 K4-03 MIL/SIL/HIL 验证流程，本课要求的是这三层在矩阵上各占一格，而不是合并成一句「软件验证完成」。

gate 该挂在哪。挂在「这一版基线能不能支撑该节点要做的验证」上，而不是「排期到了就交」。这里有一个必须写进矩阵的对齐点：软件的「本版基线锁定」与机械的「不能再改」不是同一回事。对机械件，冻结意味着改动要改模具、改工装，代价阶跃且不可逆；对软件，冻结意味着本版基线锁定、下一版另开，代价是重新验证与重新标定，可逆但绝不免费。两者的判据不同，节奏也不同——而 DVP&R 侧能做的事很具体：把对齐点显式登记在矩阵的计划时点列里，让软硬件的节奏错位在矩阵上就看得见，而不是等到某次整车验证发现「那一版标定还没出来」。

为什么这件事值得单开一节。软硬件节奏错位是项目延期的一大类根因，而它在 DVP&R 上留下的痕迹通常只有一处：某一行的计划时点与实际时点之间出现了一个没人解释的间隔。把对齐点登记下来，这个间隔就有了名字，也就有了责任人。

工程量级与典型值。⛔ 不给覆盖率门槛与等级号（去 K4-03 MIL/SIL/HIL 验证流程）；⛔ 不给基线冻结相对量产启动的周数——那属于项目排期，冻结点谱系见 M1-01 汽车研发流程（APQP/IATF16949）与热管理里程碑。

易错点（两条）。

① 拿一版尚未达到该节点成熟度的基线去交门禁，附一份成熟度声明就算过。后果不在当下：门禁过了之后，硬件就在这版没被真正验证过的构型上继续往下走，而后续必要的软件修改只能以「例外」的名义发生——例外不进正常的再验证判定流程，于是该重验的项没人提。

② 把软件项的时点写成一个日期，不写它依赖哪一版基线。日期会漂，依赖不会；写依赖才追得回责任。

1.7 每写完一行，先自问一句：这一行如果判「通过」，它到底证明了什么

是什么。本讲全部内容可以收成一个动作——逐行问一句：

这一行如果判「通过」，它到底证明了什么？

答得出来（能说清它证明了哪一条需求、在哪一级、用哪一版样件、以什么统计口径、按哪一版判据、证据留在哪），这一行就是闭合的；答不出来，就说明六环里有环是空的。空的那一环去哪找？回到 1.1 那张表逐环对——追不到需求就是第 ① 环空，说不清层级射程就是第 ② 环空，以此类推。

为什么用问句而不是核对表。因为 DVP&R 评审最常见的失效形态不是「有明显错误」，而是每一格都填了字，合起来什么也没证明。核对表能查出空格，查不出转交句；而这个问句能——「按标准执行」回答不了「它到底证明了什么」，「见试验规范」也回答不了。⇒ 它是把结构完整性检查从「通读一遍」变成逐格核对的最小工具，成本只有一句话。

工程量级与典型值。⛔ 本课不给评审时长、不给每次评审该看多少行的配额——那取决于矩阵规模与评审组织方式，须按本项目确定。

易错点（两条）。

① 把它用成质询而不是自检。在评审会上被别人问出来已经太晚——那时这一行往往已经排进了试验计划，改它要动档期。它应当在提交前由写这一行的人自己问一遍，答不出的自己打回。

② 只问「做没做」不问「证明了什么」。「这项试验做了吗」是进度问题，「它证明了什么」是证据问题。计划完成的是动作，而 DVP&R 要交付的是证据——两者之间隔着的正是这六个环。

本讲收口。到这里，一行 DVP&R 的骨架已经立起来：六环、四组列、射程七项，外加一个逐行自检的问句。剩下的五讲各钉一环——第 2 讲钉第 ② 环，把「用什么方式验、上哪一级设施」拆成可选的路，并写清每一格明确不能回答什么；第 3 讲钉第 ③ 环；第 4 讲钉第 ④ 环；第 5 讲钉第 ⑤ 环；第 6 讲钉第 ⑥ 环，并把「原来那份证据不再算数」这一整类情形收口。⇒ 从第 2 讲开始，每一讲末尾都请拿本节这句问句回头量一遍你自己那份矩阵。