测什么、怎么测、测到什么程度：把型号软件测试要求说明白

AI与代码安全

2026年10月14日 21:34
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

编者荐语：

型号软件测试相关技术及商务合作请联系13381155803【微信同步】

以下文章来源于航天质量那点事儿
，作者航天质量那点事儿

航天质量那点事儿
.

商业航天质量人的碎碎念

点击上方

蓝字

带你起飞

做型号软件的同行大概都有同感：软件写出来不难，难的是怎么证明它靠得住。代码跑通了、功能对上了，不等于它真的可以装进产品里交付。真正决定一款型号软件能不能放心用的，恰恰是测试这一关。测试是软件上天之前，地面上最后几道关口之一。也正因如此，型号软件测试要求这类文件条目不算多，分量却不轻：过程怎么走、管理怎么抓、改了代码怎么办、测哪些项目、测到什么程度算够，每一条背后都对应着具体的做法。

01

测试过程：先有铺垫，后有执行

测试过程遵循QJ 3027 的相关要求展开：先策划测试计划，再制定测试需求，然后建立测试环境、设计测试用例、编制《测试说明》，按测试规程把各阶段测试逐项做下去，过程留好记录，最后编制各阶段的《测试报告》。

测试过程主要工作与输出

说明：过程文档与记录均需按测试规程形成，作为各阶段测试结论的依据。

这条链上，真正动手执行只占一小段。环境要先搭起来，用例要从需求里推出来，《测试说明》要在执行前定稿。把测试理解成“跑一遍出结果”，是对这件事最大的误会——在这套要求里，执行只是水到渠成的一步，前面的计划和文档才是骨架。

02

测试管理：独立、受控、可重复

管理要求可以概括成三个词：独立、受控、可重复。

测试管理的三项要求

说明：测试组织形式随软件规模、安全关键等级、测试级别浮动，等级越高，组织要求越严。

测试由相对独立的人员进行，这是老规矩。自己写的代码自己测，问题容易顺着同一个思路漏过去。项目规模、安全关键等级、测试级别不同，组织实施的团队也随之不同，等级越高的软件，测试组织的门槛越严。

测试过程中产生的工作产品和文档要纳入配置管理，用例改到哪一版、依据哪份需求、用了哪个工具，都要能对上号；重要阶段要过评审；测试工具和环境要专门管理。这一切指向同一个目标：可重复。报告里的结果，换个人、换个日子，按同样条件能再复现出来，这份报告才站得住。

03

回归测试：更动从来不是局部的

研制过程中改代码是常态，改完之后测什么，要求里有三条，条条有针对性。

第一条，对更动进行影响域分析，更动部分和受影响部分都要重新开展相应级别的测试。改一行代码，受牵连的可能是一大片，影响域分析就是先把这一片找出来。

第二条最容易被忽略：软件运行的硬件环境、用来生成软件的工具，只要更新，就必须分析是否需要回归测试以及开展其他软件确认。环境一变，此前跑通的结论未必仍然成立。

第三条，重新测试的情况下，《测试说明》《测试报告》等所有测试相关文档必须重新编写。文档不是测试的副产品。重测不留新文档，这次测试等于没有发生过。

回归测试三项要求

说明：环境一变，此前跑通的结论未必仍然成立；重测不留新文档，等于没有发生过。

04

测试裁剪：等级不同，动作不同

型号软件按安全关键等级分为A、B、C、D 四级，失效后果越严重，等级越高。不同等级的软件，测试活动按一张裁剪表执行：单元测试、组装测试、配置项测试、分系统联试（软件验收测试）四大类，往下再分静态分析、代码审查、功能、性能、接口、余量、边界、安全性等具体类型。

这张表的规律很清楚。功能测试从单元、组装、配置项到分系统联试，四个等级一路必选，是整张表里唯一贯穿到底的类型；静态分析在单元测试阶段同样不分等级，全部必选；接口测试在组装、配置项、分系统联试三个层面全等级必选。等级越低，放开的越多。以配置项测试为例，A 级必选项有 13 项，从静态分析到逻辑测试一项不落；到 D 级，必选项收拢为功能、性能、接口、余量、边界 5 项。强度、恢复性、安装性这类测试，只有高等级软件才必须做。

分系统联试这一层，功能、性能、接口三项测试四个等级全部必选。验收这道门，底线是同一条。

裁剪不等于随意。必选项原则上要做，确需裁剪必须说明理由；微、小、中等规模的软件可以裁掉组装测试，这也是写在注释里的明规矩，不是口头默许。

软件测试活动裁剪要求

注：△ 表示必选项，○ 表示可选项；对必选项进行的裁剪必须说明理由；微、小、中等规模的软件，组装测试可以裁剪。

把这张表横向数一遍，等级差异就出来了。

各阶段必选项数量对比

说明：功能测试在四个阶段、四个等级全程必选，是整张表里唯一贯穿到底的类型。

05

覆盖率：测没测够，拿数字说话

测试做得充分不充分，要求里给了硬指标。各安全关键等级软件应达到的覆盖率见下表。

软件测试充分性（覆盖率）要求

注：AM 指由软件交办方和软件承制方协商确定，但应与软件产品的质量要求相一致。

这张表里有两处值得多看一眼。一是第三方测试的尺子比开发方更细：A 级软件交第三方测试，需求、语句、分支、目标码覆盖都要到 100%。道理不复杂，独立的一双眼，本就该看得更清。二是 AM 不是没有要求，而是把具体指标交给交办方和承制方协商，但必须与软件产品的质量要求相一致。协商，不等于商量着打折。

几条注释别漏看。MC/DC（修正的条件/判定覆盖）只针对高级语言编写的程序代码；目标码覆盖只针对高级语言编写的嵌入式软件；覆盖率没有达标，不能含糊带过，必须分析说明，必要时用分析、审查、评审等方法补充说明情况和影响；A、B 级软件即使覆盖率达标，开发方的配置项测试也还要对语句覆盖和分支覆盖情况进行分析——数字之外，还要说清数字是怎么来的。

覆盖率要求中的几条注释

06

写在最后

从头读到尾，这份要求的逻辑其实很朴素：过程要留痕，组织要独立，更动要追溯，项目按等级裁剪，充分性拿覆盖率衡量。没有一条是玄学，每一条都在回答同一个问题：怎么让一块看不见摸不着的软件，在上天之前被尽可能彻底地看清。

对于测试的人来说，这些要求是底线，不是天花板。裁剪留理由，达标说来路，回归不走过场。要求写得这么细，是因为教训都发生过；把要求当回事，是这条路最省事的走法。