每年评审季我都会遇到类似的场面测试负责人把覆盖率100%的报告往桌上一放说“底层模块测得很充分了可以进入下个阶段”。但只要你翻到异常分支和中断场景那一栏基本是空的。这种时候评审会讨论的就不再是“测没测”的问题而是底层软件测试规范有没有真正发挥作用的问题。我在嵌入式行业跑了十几年从驱动、BSP到协议栈都测过也被QA评审过后来自己也坐到评审席上评别人。今天想把这些年关于底层软件测试规范和QA评审底层测试的实操经验整理出来尤其是热搜里那个高频问题——“正常是不是走查然后评审”——会专门用一章来讲清楚。这篇内容适合刚入行的测试工程师、带团队的测试负责人以及发愁“不知道怎么评底层测试”的QA同学。1. 底层软件测试规范到底在规范什么很多人一听“测试规范”就觉得是写文档、走流程、盖公章实际上底层软件的测试规范不是在应付审核它是在给“什么算测完了”这件事划定一条底线。1.1 先说清楚“底层软件”的范围底层软件在不同团队里叫法不太一样。做消费电子的叫BSP、驱动、固件做通信设备的叫协议栈、内核模块做汽车电子的叫MCU底层软件、Autosar基础软件做控制器的叫板级支持包和中间件。共同特点是直接跟硬件打交道运行在资源受限环境里用C或汇编居多出了问题往往表现为系统级崩溃、死机、通信异常这类难定位的问题。这个范围决定了测试规范和通用软件测试规范有本质区别。你不能拿测互联网后端那套思路来套底层软件——没有那么多容器和Mock环境硬件在环测试、中断风暴、寄存器读写时序才是常态。1.2 规范的核心战斗力不是流程文档是准入门槛我在评审时最常看到的规范文档长这样测试计划模板、用例编号规则、缺陷单流转流程、周报格式。这些算不算规范算但只是表层的。真正有约束力的测试规范回答的是这几个问题单元测试最低覆盖率是多少语句覆盖、分支覆盖、MC/DC各自卡多少门槛哪些测试类型在哪个阶段是强制的哪些是“有条件才做”什么级别的缺陷出现时必须中止测试并回退代码测试报告里的哪些数据必须附带原始记录不允许只写结论什么情况下允许申请豁免豁免由谁批准、有效期多久说白了一句话规范的价值不在页面数量而在缺失内容时的“一票否决权”。比如规范里明确写“本阶段分支覆盖率低于80%的模块禁止进入集成测试”那评审时QA就有据可依可以直接拦截而不是跟开发组扯皮说“我觉得覆盖不够”。1.3 底层测试规范有别于上层测试的三条硬约束第一硬件依赖性强。底层代码大部分逻辑依赖真实硬件外设单元测试不可能全在PC上完成。所以规范里要定义清楚什么算Host测试、什么算Target测试、什么算HIL测试三者各占多大比重。第二非功能性测试占比极高。底层软件的性能问题往往不是“慢”而是“时序不满足”。你测一个中断响应时间差几个微秒就可能导致协议超时。规范里必须把时序测试、压力测试、长时间稳定性测试的时长和负载要求写死。第三覆盖率要求更严。上层业务代码测一个80%语句覆盖大家觉得挺好了底层软件不行——它出Bug的往往就在那20%没覆盖到的边界分支里。很多功能安全标准比如汽车行业的ISO 26262对不同安全等级的软件覆盖率有明确要求落地到测试规范里就是要量化到具体数字。2. QA评审底层测试比评上层测试“费劲”在哪我做过被测方也做过评审方最大的感受是评底层测试比评业务测试累得多。原因不是工作量而是“看不懂”和“看不出问题”的界限太模糊。2.1 评审对象只看测试报告的人会漏掉七成问题评审对象清单要摆清楚。光是测试报告本身不足以支撑一次有效的评审。我的经验是完整的评审输入应该包含测试计划与分工表。看谁负责什么模块有没有一个人同时干开发和独立测试的冲突需求追踪矩阵。每个测试用例是否都追溯到了来源需求或设计用例清单及分类统计。正常用例多少、异常用例多少、边界用例多少覆盖率报告。不止看总数字要看每个模块、每个文件的覆盖率缺陷清单及趋势数据。按严重级别分类的未关闭缺陷原始测试记录抽查。至少抽查10%的测试日志确认不是事后补的风险清单与豁免申请。哪些已知问题打算带病上线只看最终报告的话你没法判断覆盖率数据是怎么统计出来的、用例是不是真的在目标机上都跑过了。所以我的原则很简单数据永远要能追到原始记录追不到的一律视为无效。2.2 底层用例设计里QA需要盯住的四个要素评底层测试用例时我习惯按四个维度来审第一个是状态与状态迁移。底层软件很多Bug出在状态切换上比如驱动从初始化到运行、从休眠到唤醒这个迁移路径上有没有用例覆盖。光测稳态是不够的。第二个是中断与时序。中断嵌套、中断屏蔽、临界区保护这类场景用例是真的在硬件上跑了还是只是在代码里看了一遍然后写个“经代码审查确认安全”。如果是后者评审时就要打问号。第三个是异常注入。寄存器读回来全FF算不算有数据、DMA传输到一半被取消会怎样、看门狗超时之前系统有没有正确喂狗。没有异常注入用例的测试报告深度基本堪忧。第四个是资源边界。栈深度有没有实测过堆碎片在长时间跑后有没有分析通信缓冲区满时的背压行为是否符合设计。这些用例是验证性质的不是开发自证清白的简单打印。2.3 QA的知识门槛不懂硬件的QA做不了底层评审这话说出来可能有人不爱听但事实就是如此。一个没接触过寄存器和中断的QA去评审底层测试只能做流程合规性审查——格式对不对、模板规不规范、有没有签字。这有价值但远远不够。我见过比较理想的组合是一个有底层开发经验的QA搭配一个懂流程的QA共同评审。前者看技术深度后者看流程完整度。如果团队里实在没有硬件背景的QA评审时必须拉一个资深开发人员当技术评审组成员否则QA评审容易流于形式。接下来可以提一句最近行业里开始讨论利用AI辅助测试评审的趋势有些工具能自动比对需求追踪矩阵和用例清单之间的缺口。但就目前实践看AI能帮人发现“用例缺了什么”还替代不了人判断“为什么没测”以及这个缺陷背后的风险等级。3. 走查和评审的正确关系别把两个动作搞反了热搜里有个问题问得很实在“正常是不是走查然后评审”。我的答案是但很多人把两个概念混着用最后会议变成一团浆糊。3.1 走查是“作者请人看”评审是“组织做裁决”走查英文Walkthrough本质上是作者自己组织的一个非正式活动。你把模块的代码或者用例设计讲给同事听请他们提意见、找漏洞。走查更偏向“集思广益”和“知识传递”没有正式的裁决结论不产生“通过/不通过”的结论。评审英文Review正式得多。它要有主持人、评审员、记录员明确的角色分工有事先分发材料、有评审标准、有决议记录。评审的产出不是意见而是“通过”、“有条件通过”或“不通过”这三种决策之一。有条件通过还带bai必改项必须有人跟踪闭环。3.2 实际流程建议自检、走查、评审的三段式我建议把这个过程拆成三个有明确入口条件的阶段而不是一次性丢一个大会里第一段作者自检。按团队检查单过一遍补充需求追踪矩阵和覆盖率数据确认自己解决不了的问题列出清单。第二段同行走查。找一个或两个对这块代码不熟悉的同事花半小时到一小时过一遍实现和用例重点找逻辑遗漏和可测性问题。这一阶段发现问题修复成本最低副作用是可能会否定掉一些设计但无所谓早期推翻比后期返工省太多。第三段正式评审。走查问题解决后才把材料提交给QA和评审组。正式评审时材料要是“自己已经查过两遍”的状态而不是拿一堆半成品让评审组帮你检查。3.3 什么时候可以只走查不评审有一点容易被忽略不是所有测试材料都需要走正式评审。低风险模块、内部工具代码、一次性脚本的测试走查组长确认就够了。规格书或者高危模块的测试用例才需要正式评审。我见过有的团队“逢测必评”一个简单的GPIO测试用例都要召集七八个人开两小时评审会人力资源浪费很大。反过来也有团队所有东西都不评全靠代码写得“自觉”。这两种都不对。合理的做法是给模块按风险等级分类高危电源管理、通信协议、安全相关逻辑走完整评审中低危走简化评审或仅走查。4. 评审会上QA必须追问的六个问题评审不是看完材料点点头就结束。我每次坐评审席心里有一张固定的追问清单不管被测方报告写得多漂亮这几个问题必须问透。4.1 需求追踪每个测试用例连到哪条需求第一个问题永远是这条用例对应哪条需求或设计决策被测方如果说不上来或者用例是凭着“经验”补的那基本可以判定测试缺乏目标性。反向再问一遍哪些需求没有被任何测试用例覆盖被覆盖不到的大都是隐含需求或异常约束恰巧是底层软件最脆弱的地方。4.2 覆盖率数据数字可能是假的覆盖率不是测出来的是算出来的。如何插桩、用哪个工具、目标代码优化级别是多少都会影响最终数字。同一个模块O0编译下测出的覆盖率可能比O2高出一截但O2才是真实运行形态。评审时我会要求被测方说明三点插桩方式是什么、覆盖统计口径是什么、有没有排除掉死代码。老手都知道100%语句覆盖不等于没Bug但一听说你覆盖率只有60%就敢说“测试充分”的人一定是想蒙混过关的。覆盖率有水分不算稀奇全部是100%、一个例外的都没有你反而要警惕99%都是后补的数据。4.3 异常和逆向场景没有异常用例等于没测底层软件的生命力一半在异常处理里。拨掉连接器、电源瞬断、通信超时、非法参数、意外唤醒这些场景不来一遍光测happy path只能证明“正常情况能用”证明不了“异常情况不炸”。我在评审时会让被测方做一件很直接的事把异常类用例单独列一张表统计异常用例数占总用例数的比例。低于30%的直接打回补充。这不是拍脑袋定的线异常处理程序的执行路径往往比主流程还长但很多团队愿意花10倍时间铺满正常流程用例却不肯写5个异常用例。4.4 环境一致性台架和实机的差异很多底层测试是在开发板或者HIL台架上跑的这没问题。但台架和真实设备的差异必须写清楚。比如台架上没有接实际的传感器、没有真实的电磁干扰环境、负载状态跟现场也不同这些差异会直接影响测试结论的有效性。我遇到过的情况是这样所有通信压力测试都在台架上把误码率压到0结果部署到现场第一天就出现偶发丢包因为台架没模拟现场的长线缆干扰环境。评审时如果环境差异不审计这个责任QA也得背一半。4.5 缺陷收敛趋势测出100个bug不代表快好了一份好看的报告上缺陷曲线是持续下降的。如果缺陷趋势还在上升或者横盘哪怕测试用例全通过也不能说项目健康。另一个关键点已关闭缺陷和重新打开的比率。同一个模块的同一个Bug反复被打开又关闭说明修复质量存疑。QA评审时建议把这个指标挖出来别光看“关闭XX个缺陷”这种总量数据。缺陷级别也要看阻断级和严重级的缺陷不能靠“后续优化”带进下一个阶段。4.6 风险接受依据谁签字、签了意味着什么底层软件没有绝对零风险这一说总有些已知问题会被带进下一阶段。评审最后要确认的不是“还有没有风险”而是“这个风险是谁决策接受的、依据是什么、有没有记录”。如果接受方只是口头说“出了问题我们负责”没有评估影响范围和应急预案这样的风险接受是不合格。我习惯让被测方把已知风险做成清单每一项包括可能的触发条件、最坏后果是否会导致设备停机、数据损坏、安全风险、发生概率、缓解措施。评审会只讨论这个清单是否合理决议通过后才能签字。5. 一套能直接套用的底层测试评审检查单追了这么多问题实际操作时需要一份工具化的检查单。下面这份是我这些年迭代出来的版本适合底层软件测试计划和测试报告的评审场景可以直接复制去用。评审项详细检查内容判定标准测试范围是否覆盖所有新增/修改模块是否明确排除项排除项必须有理由和风险说明需求追踪用例与需求/设计条目一一对应无未追溯用例存在孤儿用例或未覆盖需求必须说明环境真实性是否说明测试环境与目标环境的差异关键差异必须有影响评估用例结构正常用例/异常用例/边界用例分类统计异常用例占比建议不低于30%中断与并发是否有中断嵌套、临界区、竞态相关用例涉及中断的模块必须有覆盖率门槛语句/分支/MC/DC覆盖率是否达到规范要求未达标必须给出豁免审批记录静态分析是否执行静态分析告警清零或逐个说明高风险告警不允许带病关闭缺陷管理未关闭缺陷是否与风险清单一致缺陷状态和风险清单矛盾视为不合格原始记录能否抽样追到日志、截图、测试时间记录不可追溯的用例判为无效评审决议是否明确通过/有条件通过/不通过有条件通过必须列出闭环责任人评审之前建议提前把这三类材料发给评审组成员不要在会场上才让大家“现场看材料”。第一类是需求追踪矩阵第二类是覆盖率报告的分模块明细第三类是未关闭缺陷清单。提前一天发出去会上讨论质量会高一大截。我见过效率最高的评审会是这样安排的会议开始前作者花十分钟演示关键用例的实际测试过程而不是念PPT。因为底层测试的很多结论是“过程性”的光看结果数据判断不了。看到步骤和现场反应评审员的质疑会更有针对性。6. 这些年踩过的坑写出来省得你再踩最后说几个实际操作中反复踩过的坑。这些都是从评审会现场总结出来的每一条都用真金白银的返工换过。第一个坑是评审会开成“宣讲会”。作者在上面讲了一个小时用例设计思路下面听得云里雾里到最后也没有哪个环节真正围绕风险做决策。后来我强制规定会议材料必须提前发会上只讨论审查结果和争议点不做宣讲。开过一次之后会议时间直接砍半。第二个坑是QA不懂硬件细节导致误判。曾经有个QA盯着一份覆盖率报告质问为什么某个外设寄存器的读写路径没覆盖到事实上那个外设在目标硬件上根本没有引出代码是条件编译的。这个问题的根子在于QA配方不齐。后来我们建立了评审组必须有技术专家参与的机制避免非技术原因卡住正常进度。第三个坑是对“走查过了”和“评审通过了”的混淆。有一段时间团队内部流传“这个代码走查过了不算评审”导致管理层认为质量有把门实际上根本没有正式的裁决记录。后来规范里明确这两者不能互相替代走查结论不能作为准入依据评审必须产生可追踪的决议记录。第四个坑是测试报告和原始记录脱节。我发现过一份覆盖率90%的报告抽查测试日志时发现对应模块根本无法在目标机上运行测试是在模拟器上跑的。模拟器结果不是没有价值但不注明环境就拿出来当硬件测试结果性质就不一样。现在所有报告都要求标注每项测试的执行环境跑在哪个平台、什么工具版本、什么编译选项少一个参数我都不接受。最后一个建议送给刚带QA团队的同行评审底层测试时永远不要只关心“通过了没有”要关心“怎么算通过”。验收标准如果只在评审会现场靠人脑临时判断这次规范了下次一定又乱回去。把度量项量化到规范里把评审结论落到可追踪的记录里比什么都重要。