干验证这一行十几年踩过最大的坑往往不是代码写不出来而是项目开工前没把“要验什么”想清楚。SoC 模块验证尤其如此——今天手机、汽车、IoT 设备里的芯片几乎全是 SoC模块数量动辄几十上百每个模块挂在总线上中断、时钟、复位、寄存器配置、低功耗状态转换全都要照顾到。如果上来就闷头写 UVM 环境大概率要走弯路。这篇想认真聊聊一份真正能落地的 SoC 模块验证规格说明Verification Specification Template该怎么写它到底解决什么问题、包含哪些硬性模块、怎么写才不流于形式以及适合哪些人来参考。文中的模板骨架和踩坑记录都是我在真实项目里反复迭代过的。1. 为什么说模块验证规格说明是整个验证流程的“地基”1.1 那些“裸奔”的验证项目最后都怎么了我见过不少验证团队拿到模块设计文档就开始写 testbench甚至还有人连设计文档都懒得细读直接对着 RTL 端口猜功能。表面上看效率很高——别人还在写文档你已经跑起了仿真。但等你进入覆盖率分析阶段问题就全冒出来了功能覆盖点东一个西一个没有和测试用例对应某个边界条件可能测了十遍另一个关键场景从来没触发过设计改了一版接口验证环境跟着大改却没人记得当初哪些用例是针对旧接口写的。我从前接手过一个 DMA 控制器的模块验证前一位同事搭了一套完整的 UVM 环境跑得挺顺回归也一直是绿的。但交付前 QA 问了一句AXI 总线的 outstanding 传输和 DMA 描述符异常这两个场景的组合你们验证过吗现场一片安静。翻遍环境发现场景列表确实是凭感觉写的没有任何一份文档能证明“这个模块的功能都被覆盖到了”。最后加班补测试项目延期两周。所以我现在定了个规矩动手搭环境之前先写验证规格说明验证规格没说清楚的部分测试用例里不许出现。SoC 的模块验证比普通 IP 验证更尴尬。模块本身只是 SoC 里的一个零件真正的风险往往发生在模块之间的交互上。你的模块对中断、时钟门控、低功耗状态的处理方式决定了它挂到子系统里会不会成为“拖后腿”的那个。没有规格说明这些交互场景非常容易被遗忘而一旦遗忘代价往往要等到 SoC 集成阶段才集中爆发那时候定位和修改的成本已经高得吓人。1.2 验证规格说明到底在解决什么问题验证规格说明不是“计划文档”它是验证团队和设计团队、架构团队之间的一份契约。它回答四个核心问题验什么scope、怎么验approach、验到什么程度算完criteria以及谁对验证结论负责ownership。这四个问题说不清楚后面所有投入都可能白费。第一它强制你把模块功能点拆成可验证的清单。人的大脑不适合记住几十上百个功能点但一张表格可以。第二它让验证环境的设计有了依据。UVM 环境里每个 agent、每个 scoreboard 该验什么、该长什么样都是从规格说明的功能点推导出来的而不是拍脑袋想出来的。第三它是交接的核心资产。SoC 项目动辄几百人协作模块验证工程师中途换人是常态一份写清楚的规格说明能让新人三天上手否则三周都未必能进入状态。我经常跟团队说一句话验证规格说明写得越细后面的代码反而写得越少。因为你在文档阶段已经把场景、边界、优先级都过滤了一遍写测试用例基本就是填空。反过来规格写得含糊代码阶段一定会反复返工省在文档上的时间最后都会加倍还给调试和补测。1.3 这份模板适合谁、在哪个阶段介入如果你是刚入行的验证工程师可以从这份模板学习“验证思维”——不是急着调仿真器而是先学会把“验什么”翻译成“怎么写用例”。如果你是有经验的 DV 工程师这份模板能帮你躲开文档盲区版本管理、评审记录、范围豁免这些细节决定了文档在项目末期还能不能当证据用。如果你是验证负责人或项目 leader这份模板就是你组织评审、分配任务、确认签核标准的抓手。从阶段上看理想的介入点是模块设计规格Module Design Specification冻结前后最晚不要晚于 testbench 开始搭建之前。太早写模块功能都没定写了也是废纸太晚写规格说明就失去了指导作用只能沦为项目末期补的“形式文档”。我自己的经验是设计 specs 一到手先花一两天把功能树和验证范围的初稿拉出来等 RTL 接口稳定后再细化。这样既能赶上工程节奏又不会让文档从一开始就脱离实际两头都不耽误。2. 核心结构一份能直接落地的模板骨架2.1 文档头与版本管理——别小看这一页先说最容易被忽视的部分。我见过太多规格说明正文写得不错但文档头只有一句话加一个作者名。等到项目后期设计改了三轮评审意见撒了一地谁也说不清当前这版到底对应哪个 RTL 版本。所以文档头必须包含文档编号、项目名称、模块名称、作者、评审人、批准人、版本号、修订日期和修订内容。这些信息看起来琐碎但每一栏都在将来的某个评审节点上救过我的命。修订历史尤其重要。哪怕是你一个人维护的文档两个月后回来看如果没有修订记录你根本不知道上一版改了哪些内容、为什么改、是否已经同步给设计团队。这在设计变更频繁的 SoC 项目里几乎是致命伤所以我一直要求团队把修订记录当成核心内容来维护而不是顺手写两笔了事。下面是我常用的版本记录表格样式版本日期作者修订内容评审人V0.12024-03-10张三初始草稿功能树初版李四V0.22024-03-18张三根据设计规格 V0.9 更新接口表新增 P1 用例李四V1.02024-03-25张三评审通过进入测试用例开发阶段设计/验证组长这个表里的关键是“修订内容”一定要具体比如“更新接口表”“新增 P1 用例”而不是写“修改格式”“更新排版”。否则这个表就没有追溯价值填得再勤也只是一堆没有信息量的流水账。2.2 模块概述、接口与时钟复位——先讲清楚 DUT模块概述这一节不是抄设计文档的摘要而是站在验证视角来描述这个模块负责什么、行为边界在哪里、有哪些关键接口和配置项。举个例子如果你验的是一颗 GPIO 控制器概述里要写清楚支持多少路 IO、每个 IO 可配置的方向、上下拉、中断模式以及它挂在哪个总线上、由哪个时钟域驱动。这些信息决定了验证环境的规模和复杂度也直接影响测试用例的裁剪。接口信息建议用一张表列全接口名、方向、协议类型、时钟域、位宽以及和 SoC 互联的关键信号别名。SoC 里的模块几乎都挂在 AXI、AHB 或 APB 上还有自己的控制信号和中断输出。接口没列清楚后面写 agent 基本就是猜猜出来的 agent 协议行为跟真实总线不完全一致后续集成阶段肯定出幺蛾子。接口名方向协议时钟域位宽说明apb_slave输入APBpclk32寄存器访问通道axi_master输入/输出AXI4aclk128数据搬运通道dma_irq输出电平触发aclk1中断输出ctrl_rst_n输入异步复位-1低有效全局复位时钟和复位是 SoC 模块验证里最容易出事故的环节。规格说明需要明确模块有哪几个时钟域、时钟频率和来源PLL 分频还是外部直供、是否有门控时钟、复位源有几路、复位释放后的行为顺序是什么。很多同学只惦记功能验证忘了验证复位行为和时钟域交叉CDC结果模块在 SoC 集成时因为复位或跨时钟域问题翻车。这些内容必须在规格里留足位置宁可多写也不要漏写因为在芯片级联调阶段这些问题一旦暴露就是大改。寄存器列表也一样不要复制整页寄存器表格进来只列出和验证强相关的配置项控制寄存器每个 bit 的作用、状态寄存器的置位和清除机制、中断使能与状态。这些信息对写寄存器模型RAL和断言都至关重要缺一个后面补起来都很痛苦。而且记录这些配置项的价值不仅在于实现寄存器模型更重要的是让验证工程师在评审时能确认“我对寄存器的理解跟设计一致”。2.3 验证范围划分测什么、不测什么很多规格说明死在“范围不清”上。范围写得模棱两可最终结论一定被挑战你说验证完了凭什么所以我的做法是分成 In Scope 和 Out of Scope 两栏。In Scope 写明本模块验证会覆盖的功能域比如接口协议符合性、数据通路功能、寄存器读写、中断产生与清除、错误处理与恢复、可配置参数覆盖、复位与低功耗相关行为。Out of Scope 则要写得非常具体模拟和混合信号行为由 AMS 团队负责、DFT 逻辑、时序收敛与功耗分析、系统级软件交互属于 SoC 集成验证阶段。如果是和芯片启动相关的模块比如 boot ROM 控制器还要特别写清楚启动序列的验证责任边界——本模块验证到哪一步哪些留给 SoC 级软件验证这一步不写清后面扯皮是必然的。Out of Scope 写清楚还有一个额外的好处防止验证范围无限膨胀。做验证的人都有体会项目后期总有人提“顺便把这个也验一下”。如果规格说明里已经明确写了哪些内容不在范围你可以有理有据地说“这个需要在 SoC 顶层验证模块级环境覆盖不到”。这不是推卸责任而是保护验证边界避免模块级验证变成什么都想管、什么都管不透的四不像最终丢了真正的重点。2.4 验证环境架构说明——给后续评审留一张地图环境架构这一节强烈建议用一张框图加一段文字描述。框图不要求画得多精美但一定要表达清楚DUT 周围有哪些 agent比如 AXI master agent、APB slave agent、时钟和复位 agent哪些是主动激励driver/sequencer哪些只做被动监听monitor参考模型reference model和记分板scoreboard怎么和 DUT 做数据比对。这样的一份描述相当于给整个验证环境画了一张“地图”评审时大家才能对着同一个图说话。然后逐个组件写清楚职责。比如参考模型它是用行为级代码模拟 DUT 的预期行为还是用一个简化的响应模型比对策略是逐周期对齐cycle-accurate还是逐事务比较transaction compare这两种方式的适用场景完全不同写清楚就能避免实现阶段大量返工。还有寄存器模型RAL的使用方式、虚序列virtual sequence的调度策略、覆盖率在哪里采集都应该在这一节说明。不要觉得这些细节“到时候再说”环境搭起来之后再说成本差十倍。这些内容会让规格说明比“标准模板”长出一截但正是这一截决定了你的验证环境是不是真正可复用的。在 SoC 项目里模块级验证环境最好能通过层级化复用hierarchical reuse直接挂到 SoC 级别环境里。如果架构说明里没有提前规划后面想复用基本没戏等于整个模块验证环境重新写一遍这不光是浪费人力还会因为两套环境不一致带来额外的对齐成本。3. 从功能点到测试用例验证计划怎么写得有可执行性3.1 功能点拆解从一个功能树开始写测试计划之前强烈建议先做一件事把模块功能拆成功能树。根节点是模块下一层是功能大类再下一层是具体的功能点和边界条件。这一步做好了后面所有测试用例和覆盖点都是树的叶子逻辑关系清清楚楚评审的时候也能顺着树从头到尾捋一遍看有没有漏分支。以 UART 模块为例功能大类包括发送通路、接收通路、波特率配置、FIFO 管理、中断管理、错误检测。每个大类再往下拆发送通路里有起始位、数据位、校验位、停止位的组合不同数据位宽5 到 8 bitFIFO 空和满时的暂停行为接收通路的边界条件包括溢出错误overrun、奇偶校验错误、帧错误、断线检测。这些叶子节点就是后续测试用例的原型。功能点拆解的颗粒度我的经验是两个标准拆到能写出唯一的测试用例为止拆到能对应唯一的覆盖点为止。如果发现一个功能点下面还要写三个测试用例才能覆盖不同场景那说明拆得还不够细需要继续往下拆。反过来如果两颗“功能点”其实只能写同一个测试用例它们就是重复的合并掉别让功能树里堆一堆没区分度的名字。3.2 测试用例表优先级、场景、预期结果的组合测试用例不是“写一个发送数据的 test”这么简单而是把每个功能点翻译成具体场景激励怎么产生、配置怎么设置、预期行为是什么。表格列建议这样设计用例 ID、关联功能点 ID、用例名称、场景描述、激励要点、配置项、预期结果、优先级、覆盖点映射。实际填表的时候前面几列花不了多少时间真正费时间的是“场景描述”和“预期结果”这两列它们才是测试用例的灵魂。下表是精简后的样式实际使用时可继续扩展激励要点、配置项、预期结果、覆盖点映射等列用例 ID关联功能点用例名称场景描述优先级TC_UART_010FEAT_UART_TX_0018N1 发送正常数据配置 8 数据位、无校验、1 停止位连续发送 256 字节P0TC_UART_020FEAT_UART_TX_002发送 FIFO 满暂停FIFO 阈值设为 16发送速率大于采样速率检查停等行为P1TC_UART_030FEAT_UART_RX_003接收溢出错误连续灌入数据超过 FIFO 深度检查 overrun 中断与状态位P1优先级尤其重要。P0 是冒烟测试和主干功能必须最先跑P1 是主要功能回归必跑P2 是边界和异常场景资源够就该都跑P3 是 corner case 和压力场景按资源斟酌。如果不把优先级定义写清楚最后必然出现所有人把每个用例都当 P0 对待的尴尬局面——回归时间失控谁也不敢删用例每天被漫长的回归跑批拖死正经的调试时间反而被挤占。3.3 覆盖率计划功能覆盖点与交叉覆盖的定义覆盖率计划是验证规格说明里最有含金量的部分。很多团队的覆盖率是测试写完之后“顺便”加的结果就是覆盖率报告很漂亮但证明不了什么——点加了一堆跟功能点完全对不上。我的做法是在写测试用例的同时就把功能覆盖点Functional Coverage Point定义出来每个覆盖点绑定一个或多个功能点保证“测了什么一定有对应的覆盖点覆盖到了什么一定有理有据”。还应该设计交叉覆盖cross coverage。还是用 UART 举例波特率9600、115200、921600× 数据位宽5、6、7、8× 校验模式无、奇、偶就是一个典型的 cross 定义。它保证你不只是在一个默认配置下测功能而是真正覆盖了配置组合空间。这类 cross 定义数量不用贪多挑真正影响行为的组合维度就好否则覆盖率收集和报告分析的时间会成倍增长跑完根本来不及仔细看。这一节也可以把代码覆盖率的收集需求写进去跑哪些用例需要开启行、分支、条件、FSM 覆盖率收集哪些模块内部的冗余分支可以申请排除exclusion。提前和设计团队协商 exclusion 清单比事后解释快得多。覆盖率收集本身不是目的它是验证完整度的度量手段收集开关开得越晚越容易发现关键场景没跑到到时候补测的窗口已经所剩无几。3.4 断言与形式化验证计划断言SVA的规划也应该在规格阶段完成而不是等 RTL 写完了再临时加。先想清楚协议里哪些规则必须用断言盯着握手信号不能乱拉、状态机不允许跑进非法状态、FIFO 的读写指针不能越界、中断产生后必须保持到被清除等等。把这些规则列成一张断言清单标注预计位置是内联在 RTL 里、用 bind 方式挂到模块上还是在接口 agent 里用协议检查器protocol checker实现。原先没规划过的断言基本都会在加的时候跟原有代码纠缠不清。这里要提醒一句断言不是装饰品它最大的价值是帮你定位 bug 发生的精确时间点。一条放对位置的断言可以把调试时间从几天压缩到几小时。我见过一条断言在回归里抓住一个只会在特定 burst 长度下出现的时序错误要是没有它那个 bug 可能要等 SoC 集成后才会被下游模块暴露出来到了那一步定位范围是整个芯片想死的心都有。形式化验证FPV适合验证那些状态空间小但逻辑关系严格的控制逻辑仲裁器、状态机、FIFO 控制、总线接口的时序规则。规格说明里可以标出哪些功能点计划用形式化方式覆盖哪些用动态仿真。提前写清楚后面选择验证方法时就不会瞎折腾也能更合理地分配人力——形式化工程师和仿真工程师各自领任务而不是等到半路才互相扯皮“这个该你验”。4. 实操过程从模块需求到一份可评审的验证规格4.1 第一步通读设计文档建立功能树拿到模块设计文档后第一件事不是读代码而是用思维导图或表格把模块功能树画出来。边读边记看到任何一个“支持某种模式”“产生某种中断”“在某种条件下表现某行为”的表述都丢进功能树。认真读完一整份设计文档功能树基本就有影了。这个习惯我坚持了很多年几乎没有一次白费功夫。这里有个细节设计文档里经常出现“该模块与 DPRAM 交互实现数据缓存”这类描述。不要照抄你要追问的是验证这个交互需要模拟 DPRAM 的哪些行为是真实时序还是简化模型这些决策属于验证策略不属于设计文档范畴要靠你自己判断并写进规格说明。我记得第一次处理这类问题时我照搬了完整 DPRAM 时序模型结果仿真速度慢得难以接受后来改成行为级简化模型速度和精度都达到了理想平衡。如果设计文档还不完整怎么办我建议主动约设计工程师聊半小时把疑问点列出来。验证工程师经常犯的错是闷头猜猜对了算运气猜错了整个环境白搭。问清楚一句话胜过回来改三天代码。别不好意思问验证阶段不问清楚到了项目末期才暴露问题那才叫真正的尴尬。4.2 第二步画验证环境框图明确组件职责功能树有了下一步画验证环境框图。这个图可以先画在纸上或白板上边画边想这个功能点谁来激励谁来检测结果参考模型需要模型化哪些行为覆盖点放在哪个组件里采集这些问题在画图的过程中会自然浮现比闷头写代码时发现缺组件再补效率高太多了。拿一个挂在 APB 总线上、内含配置寄存器和数据通路的模块举例APB agent 负责时序激励和协议检查配置寄存器统一由 RAL 模型管理DUT 的输出通过 monitor 送到 scoreboard参考模型读 RAL 里的配置值生成预期响应。这张图画完之后环境的可复用性一眼就能看出来。如果一个组件职责过多别硬塞拆成两个更小的组件后续代码实现会轻松得多调试时定位问题也更直接。框图画好之后建议顺手把环境组件清单和职责列表写进规格文档。这一步只花半小时但能让你在代码评审时少费很多口舌——别人不用追着问“这个 agent 是干嘛的”。评审过太多环境代码最大的痛点就是组件职责边界模糊谁都能改一下、谁都不清楚改动的副作用有了一份职责清单至少能收敛住这种混乱。4.3 第三步逐点填写测试计划表环境框图确认后回到功能树开始逐点填写测试计划表。这一步别图快一天填不完就分两天。填的过程中你会自然发现很多功能点之间的组合关系这些组合往往就是 cross coverage 的来源。很多人把测试计划当成写完了代码之后补的表这个顺序反了——先有计划再有代码代码才不会变成一团乱麻。填表时我有个习惯把每个用例的“预期结果”写得特别具体。比如“发送 100 字节校验正确产生发送完成中断状态寄存器里的 FIFO 计数归零”。预期结果写得含糊scoreboard 就写得含糊覆盖率也就会含糊。从规格层面把预期结果定清楚代码实现的顺畅程度会超出你预期。这句话我跟团队复述过很多次每个把预期结果写满的人在实现阶段都回来谢过我。填完测试计划建议顺手做一次自查每个功能树叶子是否都至少对应一个用例每个 P0 用例是否都有对应的覆盖点有没有两个用例实际上测的是同一个场景这三问跑一遍测试计划的主体框架就立住了后面再怎么细化都是锦上添花。4.4 第四步评审与迭代——规格说明不是一次性文档验证规格说明写出来不是给柜子看的一定要设计评审。评审至少要拉三类人设计工程师、验证同事、以及一个没有参与本模块验证的“第三方验证专家”。设计工程师帮你确认功能理解没有偏差验证同事帮你找用例漏洞第三方专家负责提“如果发生这个情况你测过吗”这类发散性问题。评审会上被问倒不可怕可怕的是没人问、没人提意见那才是最大的风险信号。评审之后规格说明进入受控迭代设计文档每更新一版第一件事就是同步检查验证规格说明里哪些内容要跟着更新。很多团队的规格说明 V1.0 之后就没动过这是最危险的。文档和代码不一致比没有文档更糟因为它制造了虚假的安全感。我自己的习惯是在文档里标注“本文档对应设计规格 V0.9 / RTL tag r20240315”每次回归前都核对一次防止规格说明和实际验证对象悄悄脱钩。5. 常见问题与坑我踩过的那些雷5.1 把验证规格写成了设计文档的复述最常见的失败模式。开篇就是模块架构、内部寄存器逐字段解释、电路原理……写了十几页看不到一条测试用例。记住验证规格的读者是验证工程师要写的是 DUT 对外可观察的行为以及你打算如何验证这些行为的计划不是 RTL 实现细节。内部细枝末节的逻辑属于设计文档的职责验证规格写多了只会稀释重点。判断自己有没有写偏标准很简单把你的验证规格文档发给设计工程师如果他们读完之后觉得“没有任何新信息”那你一定是写偏了。如果他们读完之后能说出“原来你是这么理解这个模块的”那才是切题。验证规格说明的价值在于暴露验证视角的思考而不是复读设计视角的内容这个区别决定了文档是“工具”还是“废纸”。5.2 覆盖率计划与测试用例脱节另一个大坑覆盖点定义在规格里但跑完覆盖率之后没人去核对哪些覆盖点对应哪些测试。到签核评审覆盖率报告显示 98%经理一问“这个 98% 是靠哪些测试达成的是否覆盖了所有配置组合”答不上来那这份报告就失去了信任。覆盖率数字本身没有意义它能追溯回具体的激励场景才有意义。我建议每个覆盖点都绑定用例 ID 列并且每周回归后导出一份覆盖-用例映射报告贴在验证周报里。这样做一方面督促测试用例和覆盖点同步补齐另一方面也让签核评审有据可查。覆盖率不是用来刷数字的是拿来证明“验证声称的完整性”的。如果覆盖率报告说不清来源那这份报告反而会成为评审的质疑焦点得不偿失。5.3 签核标准含糊什么叫验证完成我见过最烂的答案是“测试都通过了回归绿了”。这不算标准。一份合格的验证规格要写清楚量化标准比如说代码覆盖率语句、分支、条件、FSM达到 95% 以上且未覆盖部分有明确、合理的排除理由功能覆盖点 100% 命中所有 P0/P1 用例通过无未关闭的 CR或者所有 CR 都有明确 waive 理由断言无违反或已逐条记录 waive。把这些标准写进规格签核评审才有章可循。这里有个经验标准不要定得太激进。功能覆盖点 100% 是有意义的但代码覆盖率非要 99% 可能让团队把时间耗在几个不可达的 corner 上。合理设定目标值并且明确豁免流程比追求好看的数字重要得多。签核标准的意义在于“大家事先约定好什么算完成”而不是事后跟评审委员会讨价还价那场面我见过太多次谁都不舒服。5.4 文档不维护、不更新前面提过这里单独拎出来再强调一次验证规格的生命周期应该延续到模块验证结束而不是只在项目开始的时候写一次。RTL 每改一版、新增一个 feature文档都要有对应的修订。我自己的做法是在修订记录里写明“本版基于 RTL tag X 验证对应设计规格版本 V0.9”这样一旦出问题回溯起来特别快。这个“关键版本对齐”的习惯能省下大量返工排查时间。我见过一个项目模块在 RTL freeze 前改了三次接口验证规格却一直停留在最早那版。最后的直接后果是验证环境里的 agent 已经按新接口改了测试用例也加了但规格文档里写的还是旧的接口协议。交付评审时别人照着文档去检查代码发现处处对不上质疑声一片。这种低级错误完全可以通过定期维护来避免付出的只是一点维护时间换来的却是文档的可信度。下面把常见问题整理成速查表方便团队内部快速对照问题典型表现根因解决办法规格写成设计复述设计师看完觉得没新信息没站在验证视角强制要求写出测试用例和覆盖点覆盖率和用例脱节覆盖率数字高但无法回答测试来源覆盖点与用例未绑定覆盖点绑定用例 ID周报附映射报告签核标准模糊交付评审无法量化没约定量化目标写清覆盖率、用例、CR 关闭标准文档不更新文档和代码不一致缺少同步机制设计变更时同步修订规格并记录版本6. 模板之外验证规格的思维方式不会过时6.1 新模块类型带来的验证规格扩展这几年 SoC 里越来越多的人开始关注开源验证资源和验证方法学的变化。开源的仿真工具、UVM 的参考实现、各类协议 VIP 的开源替代品都在降低验证入门的门槛。同时像 AI 加速器、安全子系统这类新模块逐渐成为 SoC 的主角它们的验证往往还要额外关注算子数值精度、安全隔离、性能指标等验证规格需要扩展的内容也更多了单一的功能树模型已经不足以覆盖所有维度。以 AI 加速器为例除了传统的数据通路和寄存器验证你还要在规格里定义精度比对策略参考模型用什么数据格式、容差范围是多少、多精度模式如何切换。性能验证也要写清楚目标吞吐率、时延上限、在哪种负载下测量。这些内容放到老一套验证规格模板里没有现成位置需要你主动扩展。我的做法是在原有模板上加一个“专项验证计划”小节专门容纳这些跨功能树的验证需求。6.2 一点个人建议不管工具怎么变、模块怎么换验证规格说明的思维方式不会过时先拆功能再定范围后写用例用覆盖率度量完整度。这本质上是一种把“我要保证质量”这个抽象目标拆解成“可执行、可度量、可追溯”的具体动作的方法。拿到任何陌生模块第一反应仍然应该是先写验证规格把功能和策略讲清楚再谈下一步。我个人在实际项目里的习惯是每开一个模块验证先把这份规格说明模板复制出来哪怕只花半天填完初稿哪怕接下来又要改也一定要把这件事放在写代码之前。每当项目进入尾声、面对交付评审的时候我都庆幸当初有这份文档——它让我面对“你验证得怎么样”这个问题时能清楚地拿出证据而不是支支吾吾说“应该都验过了”。验证这一行讲证据靠细节这份规格说明就是证据本身。