前阵子和一个做航电系统的老同事吃饭他正被需求验证四个字折腾得够呛项目快走到适航审查阶段了核查证据时发现十几条需求的验证证据要么缺、要么追溯链断裂只能连夜补验证、补记录。这个场景在航电开发里实在太典型了。很多人把需求验证理解成最后跑一遍测试给审查代表看但在真正的工程体系里需求验证是一条贯穿系统需求、软件需求、硬件需求直到整机验证的主线。这篇文章我不打算讲学院派理论就讲我在航电项目里怎么做需求验证先厘清验证到底验证的是什么再看验证方法怎么选接着讲如何把每条需求都有闭环证据管理起来最后聊几个我亲眼见过、也亲手处理过的翻车现场。1. 先在V模型里找对位置需求验证究竟是干什么的1.1 验证与确认一对爱被混淆的兄弟英语里Validation和Verification都经常被翻译成验证但在航电开发里这两个概念的差别足以影响整个项目的工作量。Verification验证回答的问题是我们把需求实现对了吗它是针对实现体开展的证明活动——评审、分析、测试都是为了证明输出的产品确实符合需求规格。Validation确认回答的问题是我们定下的需求本身是对的吗它发生在更早的阶段关注需求的完整性、正确性、一致性和可实现性。举个例子某飞控系统需求写着当空速低于失速速度时触发失速告警。验证要做的是检查最终代码确实实现了空速低于失速速度触发告警而确认要做的是问问气动团队这个失速速度怎么定义在哪些飞行阶段生效迎角限制是否参与其中如果需求本身定义错了验证做得再严谨也是南辕北辙。在日常中文语境里需求验证往往被宽泛使用既包含需求本身的确认也包含对需求实现的验证。我自己的做法是流程上把这两个动作严格分开——需求确认环节要评审需求是否完整、一致、可实现需求验证环节再发起针对实现体的评审、分析、测试。两者经常串在一起执行但证据要能分开审查代表问到哪一根线都接得上。1.2 需求验证挂在V模型的哪些层航电开发里需求验证不是一个孤立的阶段它挂在V模型的每一层右侧。V模型左侧是从上到下的分解过程飞机/系统级需求 → 系统架构设计 → 软件/硬件需求 → 软件详细设计 → 编码右侧是从下到上的验证过程单元测试 → 软件集成测试 → 软硬件集成测试HIL → 系统级验证 → 飞机级验证。每一层左侧的需求都要对应右侧的验证活动这就是所谓每一个需求都有回音。具体到航电开发遵循的标准族系统级ARP4754A民用飞机与系统研制定义系统级需求验证与确认活动。机载软件DO-178C机载系统和设备合格审定中的软件考虑定义软件生命周期里的验证过程。机载电子硬件DO-254机载电子硬件设计保证指南定义硬件需求和验证。这三份标准相互咬合。系统需求下放到软件团队成为软件需求软件团队按DO-178C做软件层面的验证系统团队在HIL台架或铁鸟试验台上做软硬件集成的系统级验证。需求验证的活动不是从编码完成后才开始需求评审本身就是一种验证/确认活动设计评审也是。1.3 为什么航电领域尤其较真很多人不理解航电开发为什么对验证较真到近乎苛刻。因为失效后果不可接受。航电系统的安全等级按DAL设计保证等级从高到低分为A、B、C、D、E五级DAL A对应灾难性失效可能导致飞机失事DAL B对应危险性失效可能严重降低飞机能力或给机组造成过大负担DAL C对应较大影响DAL D对应较小影响DAL E无安全影响。我做过最严格的是一个DAL A模块它的一条简单告警逻辑要求验证团队不仅做需求覆盖还要做MC/DC结构覆盖率且验证人员必须与开发人员独立。适航审定环节里局方审查代表看的就是这些验证证据——需求编号、验证方法、验证环境、执行结果、覆盖报告。他们最常做的动作是随机抽一条需求让你马上给出对应验证证据。你给不出整个包件可能被拒收。2. 验证方法不是拍脑袋选的四类手段的打法与取舍DO-178C明确认可的验证手段主要有评审、分析、测试三类DO-178C还引入形式化方法作为可选手段。除此之外我在实际项目中大量使用建模与仿真作为辅助验证手段。它们各有适用场景不能互相替代。2.1 评审Review入口处的第一道闸口评审是成本最低、应用范围最广的验证手段适用于所有产出物需求规格、设计文档、测试用例、验证结果。需求层面的评审最该盯的是可验证性。我做需求评审时强制要求每一项需求过这条检查有没有可量化的指标有没有明确的输入条件有没有定义容差边界有没有限定验证环境如果一条需求写着系统应在合理时间内完成自检测那就是评审不过关的典型——什么叫合理时间内需求评审的实操做法提前把检查单发给评审人员会上只讨论问题不打太极。评审记录必须留痕评审日期、评审人员、通过的结论或问题清单。这些本身就是验证证据。我的经验是把可验证性作为强制检查项之后需求质量明显提升很多原本要在测试阶段才暴露的问题在评审阶段就被拦下来了。2.2 分析Analysis不跑代码也能出证据分析是通过演绎推理或数学计算来证明需求被满足。它特别适合那些跑测试跑不全的需求。典型场景性能预算验证处理器在最坏情况下的负载率不超过某阈值。这种需求靠测试很难覆盖所有最坏情况组合一般用WCET最坏执行时间分析加少量代表性实测。时序需求系统端到端响应时间不超过50ms分析数据流路径上每一级的处理时间累加并加余量。精度需求航电系统里常见数据链路的精度分析浮点误差传播计算。安全性需求结合FMEA失效模式与影响分析、故障树分析验证安全需求如单点失效不应导致灾难性后果。分析报告的套路要固定引用需求编号、说明分析方法和输入假设、推演过程、给出结论满足/不满足/需修改。写分析报告最忌讳的就是藏着输入假设不写。审查代表特别喜欢问你的分析假设从哪来假设来源说不清整份报告的可信度就塌了。2.3 测试Test最被依赖其实最难做对的方法测试是大家最熟悉、也最容易被做坏的验证方法。DO-178C的核心要求是基于需求的测试Requirements-Based Testing每个测试用例必须对应一条或多条需求测试的目的是判断需求是否被满足而不是单纯追求覆盖率数字。测试分三个层级软件单元测试针对最底层软件需求验证单个函数/模块行为。软件集成测试验证模块之间的接口、时序、数据交互。软硬件集成测试在目标机上验证软件与硬件协同行为通常用HIL台架。单元测试可以在宿主机PC上跑但一旦涉及中断、时序、外设交互就必须在目标机或等效环境验证。很多团队在这个问题上栽过跟头——见后面第4章的翻车现场三。测试用例设计的基本功是正常路径 边界值 异常路径。航电系统坚决不能只测好天气路径。一条需求写着收到传感器无效数据时不应触发告警且应记录故障标志你得专门设计无效数据注入场景让传感器输出超界、全零、乱码、时序错乱看系统行为是否符合需求。只测正常数据等于这条需求没被验证。2.4 建模与仿真Modeling/Simulation航电特有的加速器航电开发里建模与仿真是非常常见的辅助手段按抽象程度从高到低有MIL模型在环、SIL软件在环、HIL硬件在环。MIL需求阶段的逻辑快速验证直接在被仿真模型上跑场景适合验证控制逻辑、状态机、告警逻辑。SIL代码编译运行在PC模拟环境与仿真模型交互可以大批量跑回归。HIL把真实硬件接到台架上用仿真器模拟传感器和执行器信号验证软硬件协同和系统级需求。我的用法总结MIL和SIL主要用于需求确认——当评审会上大家为一个逻辑问题争得面红耳赤时与其吵一小时不如搭个模型跑两个场景答案当场见分晓。HIL则偏向系统级需求验证能在实验室里提供相当接近真实飞机环境的证据。但要注意边界仿真结果不能自动等同于正式验证证据。如果要用SIL结果替代目标机测试必须做测试环境等价性论证必要时涉及工具鉴定。稳妥做法是把仿真用于分析、辅助评审、需求确认把目标机测试用于正式验证证据。哪些证据用仿真、哪些用目标机必须在验证计划里写清楚。2.5 方法选择矩阵不同需求该用哪些手段组合需求类型首选验证手段辅助手段备注逻辑型需求状态机、告警、模式切换测试单元集成评审、MIL/SIL仿真注意边界与异常路径性能需求时序、吞吐、负载分析 代表性测试建模分析假设要写明精度/误差需求分析测试传播误差计算安全性需求失效、容错分析FMEA/故障树 故障注入测试评审高DAL等级几乎必查硬件接口需求目标机测试 / HIL分析宿主环境通常不可信所有需求评审—基线手段不能省略这个矩阵不是死的但至少要保证每条需求都有明确的主验证手段。我见过有些项目不愿意填矩阵总说到时候都测结果到审查阶段发现有些需求根本没法测——比如系统应具备在失去所有外部电源时保存关键数据的能力这种需求不开专项分析靠常规测试根本验不出来。3. 让每条需求都有回音验证闭环的工程化3.1 先用文件把验证什么、怎么验固定下来工程化的第一步是文件化。DO-178C要求先制定软件验证计划和规程Software Verification Plan and Procedure再在项目过程中记录软件验证结果Software Verification Results。验证计划包含验证对象范围、采用的方法矩阵、验证环境宿主机/目标机/HIL、工具清单、人员角色与独立性声明、通过/失败判定准则、交付物清单。验证结果是逐条需求的验证证据记录一般以验证矩阵为核心呈现。我常年在项目里维护一张核心表——行是需求条目列是验证方法、验证用例编号、执行状态、结果结论、证据存放位置。这里有一个血的教训验证矩阵不是最后补的。正确做法是从需求基线确立那天开始建每完成一个验证活动立即往里填一行。最后补出来的矩阵一定会被审查代表问出大量细节漏洞当时用哪个版本代码跑的执行人是谁环境配置记录在哪这些信息当时不记事后根本补不出来。3.2 双向追溯需求链不能被写断需求验证闭环的核心是追溯性。航电开发里要求双向追溯正向追溯Forward Traceability高层需求 → 低层需求 → 设计 → 代码 → 测试。用于保证每条需求都被实现并被验证没有孤儿需求。反向追溯Backward Traceability每个测试用例 → 对应需求每段代码 → 对应需求。用于防止镀金实现了需求之外的无用功能和幽灵测试没有需求支撑的用例。工具方面大项目常用DOORS、Jama Connect、IBM ELM这类需求管理平台中小项目用Excel也能做关键是每条需求必须有唯一ID且每次需求变更后要重跑一次追溯检查。我见过太多项目需求改了设计跟着改了但测试用例和验证矩阵没同步更新审查代表一深挖链条就断在验证这一环。审查代表最爱做的一件事随机抽一条需求让你30秒内给出对应验证证据。你做不到他就有理由质疑整个验证体系的可信度。这不是吓唬人是真实发生过的事。3.3 覆盖率需求覆盖只是及格线结构覆盖才是深水区说到覆盖率很多非航电领域的人只会想到需求覆盖率——每条需求被至少一个用例覆盖。航电开发除了需求覆盖率还要求代码结构覆盖率这是很多人第一次接触DO-178C时被震到的地方。DO-178C对结构覆盖率的最低要求按DAL等级区分DAL等级语句覆盖判定覆盖MC/DC覆盖A要求要求要求B要求要求视目标情况C要求——D视目标情况——MC/DC修正条件判定覆盖是DAL A级别的硬骨头。它的含义可以这样理解每个布尔条件单独翻转时必须独立地影响整个判定的结果。举个实际例子某告警判定是允许告警 传感器有效 AND 超限。MC/DC要求你的测试用例能让A从真变假、B不变时结果从真变假也得能让B从真变假、A不变时结果改变。这样每个条件都被证明自己说了算而不是几个条件抱团糊弄过一个组合用例。结构覆盖率的坑在于覆盖率工具本身可能需要做工具鉴定比如DO-330体系下的TQL等级而且覆盖率数据必须与测试用例版本严格对应。项目后期经常发生的噩梦是代码改了一行你重新跑完全部用例覆盖率报告显示95%但你根本说不清那5%为什么没覆盖——这5%可能就是新增代码里的关键分支。所以我的习惯是每次回归后都重新收集覆盖率数据绝不沿用上一次的报告。3.4 发现问题后怎么关问题报告、回归与变更验证验证不是跑完就绿、记录就完。验证中发现的任何问题都要进入问题报告流程。航电项目的问题报告通常包含缺陷现象、复现步骤、分析过程、根因分类需求问题/设计问题/代码问题/测试用例问题/验证环境问题、影响范围评估、修复措施、回归验证结果。容易被忽视的问题类别是测试用例自己写错了。我在多个项目里发现验证失败里相当一部分不是产品缺陷而是用例设计错误或测试环境配置错误。这类问题同样要走问题报告流程但要正确归类不能糊里糊涂地算成产品缺陷。变更后的回归策略也要讲究。不是把所有用例从头到尾重跑一遍就叫回归而是要基于影响分析确定受影响的模块和相关需求先跑关联用例再决定是否全量回归。高DAL项目的回归范围和理由要写进验证结果不能只写已回归三个字。还有一条心态上的底线验证阶段发现fail是健康的信号。适航文化里隐瞒失败、篡改证据、为了让用例变绿而修改测试期望值的代价远超老老实实返工的代价。哪个环节出问题都有解决路径唯独掩盖问题没有出路。4. 真实项目里的错题集需求验证的典型翻车现场4.1 翻车现场一需求写得很完整但每条都不可验证某航电显示系统项目需求文档厚厚一摞评审时测试工程师却苦不堪言。因为里面充斥着这种条目系统应在合理时间内显示主要飞行参数。什么叫合理时间没有数值没有统计口径没有验证方法。测试工程师拿到这种需求根本没法设计用例——无论测出什么结果开发组都能说这个时间我认为是合理的。修复方案是把这条需求改写成系统收到有效数据帧后应在1000ms内完成主飞行显示器所有动态参数更新在HIL环境下连续测量100次99%样本满足要求。量化指标、限定条件、验证环境和统计标准一步到位测试用例自然就好设计了。这件事给我的教训是需求验证的第一道工序在需求书写阶段就已经开始了。可验证性不是评审时的补充要求而是需求的出生属性。现在我带团队做需求评审第一条检查项永远是这条需求的通过/不通过判据客观吗。4.2 翻车现场二测试用例照抄需求措辞自以为覆盖了某燃油管理软件有一条需求当计算的剩余燃油量低于1000磅时触发低油量警告。开发团队设计的测试用例是设置剩余油量500磅执行任务确认警告被触发。用例执行结果全绿。但审查代表问了三个问题就哑火了剩余油量正好等于1000磅时触发还是不触发边界值有没有验油量传感器信号丢失时应该怎么处理需求里有没有定义警告在油量恢复后应该清除还是保持清除条件是什么这个案例是典型的翻译需求式测试。基于需求测试不是把需求句子换个格式写进用例而是理解需求背后的测试意图再设计出能覆盖正常、边界、异常三种场景的用例。当时我们补的用例包括1005磅不触发、1000磅按需求定义的行为触发、995磅触发、传感器无效数据帧触发故障处理逻辑、警告触发后油量恢复至1200磅时警告状态迁移等。一套补下来才算是真正完成了这条需求的验证。4.3 翻车现场三宿主环境全绿目标机上一跑就花屏某航电显示控制系统的软件在PC模拟环境里所有单元测试和集成测试全部通过测试报告漂亮得很。结果拿到目标机上一做软硬件集成测试字符画面错位、刷新率不足、偶发卡顿。追究根因两条字节序差异和显示缓存对齐方式不同。PC是小端目标机是大端数据格式不对齐导致显示数据错误。目标机CPU定时器精度和中断延迟特性与PC不同导致刷新间隔不稳定。修复方案不是把全部用例都搬到目标机——那样测试成本太高而是做测试分层纯逻辑类需求计算、状态机、数据变换在宿主机充分回归。与硬件强相关的需求中断处理、时序、外设交互、端到端延迟划到目标机测试或HIL台架验证。不同环境之间做等价性论证写明比较维度编译器版本、浮点精度、字节序、存储器布局、定时器来源、外设模拟程度。再抽一条金标准用例在两个环境各跑一遍比对结果。这件事让我养成了一个习惯项目计划阶段就给目标机测试留足时间预算。宿主测试做得再爽真机会教做人。硬件台架排期是稀缺资源早占坑别等代码写完了才发现台架被别的项目借走了。4.4 翻车现场四DAL A的独立性要求差点卡死项目按DO-178CDAL A软件的验证要求具备独立性——验证活动不能由参与开发的人员独立完成。这个要求在纸面上很清楚落地时经常引起组织层面的碰撞。我之前参与的一个DAL A模块团队总共不到十个人既有开发又有验证。要做好独立性人数和分工就捉襟见肘。项目经理一开始拍板说先做完再分人补验证记录被我在评审会上否了——事后补记录存在真实性风险一旦审查代表问了执行细节就露馅。最终方案几经调整验证工程师独立于开发工程师汇报线测试设计和结果分析都由验证方主导。验证团队提前介入需求评审不等到代码完成才突发检查。评审和测试记录全部签字留痕过程数据完整归档。这样做下来进度看着慢了但审查阶段反而顺利。被反复挑战的点恰恰是验证人员你认识开发人员吗你们怎么确保独立判断——有完整的过程记录和决策依据这些问题都不难答。供应链场景里的版本更扎心。给OEM主机厂做Tier1一级供应商交付时对方要求需求验证证据包完整、可追溯。一次交付中被拒收原因是几十条需求的验证矩阵里验证结果一栏空着返工了一个多月才补齐。这种问题最好在项目启动的对齐会上就把验证矩阵模板统一好别等交付前才拉通格式。5. 想少走弯路我的需求验证实操清单做了这么多年航电我把需求验证的实操经验压缩成五条清单供同行参考。需求条目化的第一天就打可验证性标签。每条需求必须能回答怎么判通过——条件是什么、数值是多少、环境是什么、时限是什么。答不出来就不准入库评审。验证矩阵当周建、每周更绝不攒到审查前补。补出来的矩阵会暴露大量细节漏洞当时用的软件版本号是多少执行人是谁环境配置有没有记录这些信息当时不记事后补不出来。测试用例评审时重点看覆盖的是意图还是字面。检查清单里加一项用例是否包含边界值、异常输入、时序变化三个维度的推演。没有这三类用例的需求验证基本是无效验证。给目标机测试留足时间预算。宿主环境能解决大部分逻辑验证但硬件强相关需求必须在目标机或HIL上验。台架和真机资源都是稀缺品从计划第一天就把排期写进去。缺陷流程别图省事。问题报告、根因分类、回归理由、关闭条件都写清楚。审查代表最常挑战的就是验证失败之后你们做了什么这部分的记录质量决定了整个验证体系的可信度。做航电需求验证这些年我的一个朴素体会是验证做得好的项目前期看着慢后面反而快验证做得差的项目前期疯狂赶后期都在还债。需求验证不是一个收尾动作它从需求诞生那天就开始了。你现在给每条需求写下的验证判据越实在后面少加的班就越实在。