文章总结： GJB/Z141-2004《军用软件测试指南》是国家军用标准，规范军用软件全生命周期测试方法与过程。标准建立6大维度21个质量子特性模型，定义单元测试、部件测试、配置项测试、系统测试四级体系，涵盖静态与动态测试方法，明确测试文档要求及安全性关键分级策略，为军用软件质量保障提供完整技术框架。
综合评分： 83
文章分类： 技术标准,安全建设,应用安全,安全开发
GJB/Z 141-2004 标准内容总结及21个子特性说明
苏州华克斯
苏州华克斯
华克斯
2026年3月17日 14:10
江苏
#
1 标准基本信息与适用范围
GJB/Z 141-2004 的全称为《军用软件测试指南》（Military software testing guide）。该标准是由中国人民解放军总装备部批准发布的指导性技术文件，属于国家军用标准体系中的推荐性标准。
从适用范围来看，该标准主要适用于军用软件的测试组织和测试人员，规定了军用嵌入式软件在其生存周期内各阶段测试的方法、过程和准则。标准明确指出，其目的是 “规范军用软件在其生命周期内各阶段的测试方法、过程和准则，确保软件质量满足军事要求”。值得注意的是，该标准仅适用于军用软件，需满足军事环境下的抗干扰、保密性、极端条件适应性等特殊要求。
在技术领域方面，GJB/Z 141-2004 覆盖了军用软件测试的各个方面，包括测试策略、测试方法、测试工具、测试环境、测试数据管理等。标准特别强调了对涉密军用软件的支持，涵盖了软件全生命周期各个阶段，从需求分析、设计、编码、测试到部署和维护。
1.1 标准章节结构与主要条款
GJB/Z 141-2004 采用了层次清晰的章节结构，共分为 9 个主要章节和 4 个附录。根据标准的目次，其结构如下：
| | | |
| — | — | — |
| 章节号 | 章节名称 | 主要内容 |
| 1 | 范围 | 明确标准的适用范围和不适用范围 |
| 2 | 引用文件 | 列出标准中引用的其他标准和文件 |
| 3 | 术语和定义 | 定义标准中使用的关键术语 |
| 4 | 一般要求 | 包括测试目的、测试级别、测试内容、测试过程、测试方法、测试用例、测试管理、文档编写、测试工具、软件安全性关键等级与测试的关系等 10 个小节 |
| 5 | 单元测试 | 详细规定单元测试的各项要求 |
| 6 | 部件测试 | 详细规定部件测试的各项要求 |
| 7 | 配置项测试 | 详细规定配置项测试的各项要求 |
| 8 | 系统测试 | 详细规定系统测试的各项要求 |
| 9 | 回归测试 | 详细规定回归测试的要求 |
| 附录 A | 软件测试方法 | 资料性附录，包括静态测试方法和动态测试方法 |
| 附录 B | 软件可靠性的推荐模型 | 资料性附录，包括斯奈德蕴德模型等 4 个模型 |
| 附录 C | 软件测试常用模板 | 资料性附录，包括测试用例、测试记录、问题报告单等模板 |
| 附录 D | 软件测试内容的对应关系 | 资料性附录，说明质量子特性与传统测试内容的对应关系 |
1.2 软件质量模型与测试内容
GJB/Z 141-2004 建立了完整的软件质量模型，该模型定义了 21 个软件质量子特性，源自 ISO/IEC 9126 国际标准，覆盖功能性、可靠性、易用性、效率、可维护性、可移植性六大维度。这 21 个质量子特性包括：
功能性维度：
•适合性：软件提供的功能是否能够满足用户指定的用途和目标
•准确性：软件能否在计算和数据处理方面达到所需的精确度
•互操作性：软件与其他系统交换信息和相互工作的能力
•安全保密性：软件保护信息和数据的能力，防止未授权访问
•依从性：软件是否符合相关标准、约定或法规
可靠性维度：
•成熟性：软件避免因错误而发生故障的能力
•容错性：软件在错误条件下仍能保持正常运行的能力
•易恢复性：软件在发生故障后恢复到正常状态的能力
易用性维度：
•易理解性：用户能否容易地理解软件的使用方式
•易学性：用户能否快速掌握软件的使用方法
•易操作性：软件的操作是否方便、高效
•吸引性：软件的界面设计是否具有吸引力
效率维度：
•时间特性：软件执行其功能时的时间特性
•资源利用性：软件使用资源的效率
可维护性维度：
•易改变性：软件进行修改的难易程度
•稳定性：软件在修改过程中保持其功能的能力
•易测试性：软件进行测试的难易程度
•易分析性：软件进行分析的难易程度
可移植性维度：
•适应性：软件适应不同环境的能力
•易安装性：软件安装的难易程度
•易替换性：软件被替换的难易程度
•共存性：软件与其他软件共存的能力
标准要求从这 21 个质量子特性的角度确定软件部件测试、软件配置项测试和系统测试的测试内容。这种基于质量模型的测试内容确定方法，确保了测试活动能够全面覆盖软件质量的各个方面。
1.3 测试级别与方法体系
GJB/Z 141-2004 从整体上将测试的等级分为了单元测试、部件测试、配置项测试、系统测试四个级别。每个级别都有其特定的测试对象和目的，技术要求，以及详细的测试内容和方法。
1.3.1 单元测试
单元测试是最低级别的测试，其测试对象是软件的最小可测试单元，通常是单个函数或方法。单元测试一般采用白盒测试方法为主，辅助以黑盒测试方法。
根据标准要求，单元测试需要：
•明确代码行 / 分支覆盖率要求（军用核心软件≥90%）
•关注代码逻辑、边界、内存、异常处理
•理解代码逻辑，进行详细的代码审查和静态分析
1.3.2 部件测试
部件测试的对象是多个单元组装后的部件，旨在验证接口兼容性和整体功能。部件测试一般主要采用黑盒测试方法，辅助以白盒测试方法。
部件测试的重点包括：
•验证模块间接口与集成行为
•覆盖所有接口的功能性、容错性测试
•依据概要设计说明，检查模块之间的衔接
1.3.3 配置项测试
配置项测试的对象是软件配置项，即以独立配置管理的软件配置项为对象，验证其与需求规格说明的一致性。配置项测试一般采用黑盒测试方法。
配置项测试的核心要求包括：
•检验软件配置项与软件需求规格说明的一致性
•验证功能、性能、可靠性、兼容性、易用性、维护性、信息安全、可移植性等
•对照软件需求规格说明验证功能是否符合设计
1.3.4 系统测试
系统测试的对象是完整的、集成的计算机系统，重点是新开发的软件配置项的集合。系统测试同样采用黑盒测试方法。
系统测试的特点包括：
•针对完整集成的系统，验证系统在真实环境下的功能和性能
•基于系统 / 子系统设计文档，覆盖所有质量子特性
•需贴合军用作战使用场景验证环境适应性、可靠性
•参考用户需求相关文档，确保软件整体满足实际使用需求
1.4 测试过程与管理要求
GJB/Z 141-2004 将军用软件测试过程分为测试策划、测试设计和实现、测试执行、测试总结四个阶段。部分资料也将其描述为测试需求分析、测试设计、测试实施、测试评估和测试报告编写五个阶段。
1.4.1 测试策划阶段
在测试策划阶段，需要确定以下内容：
•测试的内容或质量特性：根据质量子特性确定测试内容
•测试的充分性要求：确定测试应覆盖的范围及覆盖程度
•测试方法：确定采用静态测试方法和动态测试方法
•测试资源和技术需求：包括软件、硬件、人员数量、人员技能等
•测试资源计划和测试进度计划：制定详细的资源配置和进度安排
1.4.2 测试设计与实现阶段
测试设计与实现阶段的主要活动包括：
•分析测试用例集的层次结构，选取和设计测试用例
•获取并验证测试数据
•根据测试资源、风险等约束条件，确定测试用例执行顺序
•获取测试资源，开发测试软件
•建立并校准测试环境
•进行测试就绪审查
1.4.3 测试执行阶段
测试执行阶段需要：
•执行测试用例，获取测试结果
•分析并判定测试结果，根据不同的判定结果采取相应的措施
•对测试过程的正常或异常终止情况进行核对
1.4.4 测试总结阶段
测试总结阶段的工作包括：
•评估测试效果和被测软件项，描述测试状态
•描述被测软件项的状态，如被测软件与需求的差异，发现的软件错误等
•完成软件测试报告，并通过测试评审
1.5 测试方法体系
GJB/Z 141-2004 建立了完整的测试方法体系，包括静态测试方法和动态测试方法两大类。
1.5.1 静态测试方法
静态测试方法包括检查单和静态分析方法。对文档的静态测试方法主要是以检查单的形式进行，而对代码的静态测试方法一般采用：
代码审查技术：
•人工审查流程：准备阶段依据《软件设计说明书》制定审查清单，重点关注寄存器操作、内存分配等硬件相关代码；执行阶段采用 “双人交叉审查” 模式，记录不符合项
•工具辅助审查：使用 Checkstyle（Java）、PVS-Studio（C/C++）等工具，强制约束 MISRA-C/C++ 等军用编码规范；通过 Fortify 检测未定义变量、空指针解引用等内存安全问题
静态分析技术：
•控制流分析：构建函数调用图，识别不可达代码，验证分支覆盖率（MC/DC≥95%）
•数据流分析：追踪变量定义到使用路径，检测未初始化变量
•接口分析：协议一致性验证使用 SCAP 工具检查 ARINC 653 分区接口是否符合时间触发调度规范
1.5.2 动态测试方法
动态测试方法一般采用白盒测试方法和黑盒测试方法：
黑盒测试方法包括：
•功能分解、边界值分析、判定表、因果图、随机测试、猜错法和正交试验法等
•等价类划分：针对导弹制导系统输入参数（如弹道倾角 – 90°~+90°），划分有效 / 无效等价类，重点测试边界值（0°、±90°）
•因果图法：处理多条件组合场景（如雷达信号处理中的多目标跟踪逻辑），生成决策表驱动测试用例
白盒测试方法包括：
•控制流测试：语句覆盖测试、分支覆盖测试、条件覆盖测试、条件组合覆盖测试、路径覆盖测试
•数据流测试、程序变异、程序插桩、域测试和符号求值等
•路径覆盖：基本路径覆盖针对循环结构（如 PID 控制算法），设计测试用例覆盖循环 0 次、1 次、最大次数场景
1.6 测试工具与文档要求
1.6.1 测试工具分类与要求
GJB/Z 141-2004 将测试工具分为静态、动态、支持三类。标准明确指出：”软件测试应尽量采用测试工具，避免或减少人工工作”。选择软件测试工具应考虑软件测试工具的需求及确认等因素。
根据标准要求，工具需要经过评估验证其适用性。在实际应用中，常用的测试工具包括：
•静态测试工具：Coverity、Fortify、Testbed 等，用于检测内存泄漏、并发缺陷
•动态测试工具：自动化测试框架如 Robot Framework、PyTest，用于回归测试用例自动化执行
•性能测试工具：LoadRunner、JMeter 等，用于指挥控制系统负载压力测试
•专项测试工具：故障注入框架（FIF）用于硬件在环（HIL）环境故障模拟；形式化验证工具 UPPAAL、TLA + 用于实时调度算法正确性证明
1.6.2 文档要求
GJB/Z 141-2004 对测试文档有严格要求，第 8 章明确要求六类文档齐全：
•STP（Software Test Plan）：软件测试计划
•STS（Software Test Specification）：软件测试说明
•STC（Software Test Case）：软件测试用例
•STR（记录）（Software Test Record）：软件测试记录
•SPR（Software Problem Report）：软件问题报告单
•STR（报告）（Software Test Report）：软件测试报告
标准还提供了软件测试用例、软件测试记录、软件问题报告单等的参考模板，软件测试实验室可以参考标准中给出的模板，快速建立起规范、标准的原始记录。
1.7 软件安全性关键等级与测试的关系
GJB/Z 141-2004 在第 4.10 节专门规定了 “软件安全性关键等级与测试的关系”。标准根据软件的安全性关键等级确定相应的测试要求，体现了风险导向的测试策略。
软件安全性关键等级通常分为 A、B、C 三类，不同等级对应不同的测试要求：
•A 类（高安全关键等级）：如数据加密模块等，需要进行最严格的测试，包括 100% 的路径覆盖、形式化验证等
•B 类（中等安全关键等级）：需要进行较为全面的测试，包括较高的代码覆盖率和严格的功能测试
•C 类（低安全关键等级）：可以适当简化测试要求，但仍需满足基本的测试覆盖要求
这种分级测试策略的目的是确保在有限的资源下，将测试重点放在对安全影响最大的软件模块上，实现测试资源的优化配置。
1.8 回归测试要求
GJB/Z 141-2004 在第 9 章专门规定了回归测试的要求。回归测试是测试活动的重要组成部分，因为它可出现在上述每个测试级别中，并贯穿于整个软件生存周期。
回归测试的对象是修改后的软件单元、部件、配置项或系统，目的是确保修改未引入新缺陷、原有功能未受损。触发条件包括代码变更、需求变更等。
标准规定了详细的回归测试策略：
•单元回归测试：针对代码修改进行的回归测试
•部件回归测试：针对部件修改进行的回归测试
•配置项回归测试：针对配置项修改进行的回归测试
•系统回归测试：针对系统修改进行的回归测试
回归测试要求在代码修改、需求变更、缺陷修复后必须执行，并区分了不同层级的回归范围。这种全面的回归测试策略确保了软件质量在整个生命周期中的稳定性。
1.9 测试方法选择与实施
在选择和实施测试方法时，面临以下困难：
方法复杂度高：GJB/Z 141-2004 要求的测试方法体系复杂，包括静态测试、动态测试、专项测试等多种方法，需要根据软件特点选择合适的组合。
覆盖率要求严格：军用核心软件要求代码行 / 分支覆盖率≥90%，某些关键模块甚至要求 100% 覆盖，这对测试用例设计提出了极高要求。
时间压力：在任务紧迫时，为了满足指标，工程师可能被迫编写缺乏断言深度的测试代码，导致测试效果打折。代码变更了，相关的设计文档、接口定义、用户手册往往因为时间紧迫而未能同步更新。
解决方案：
•采用基于风险的测试策略，根据软件安全性关键等级确定测试覆盖度要求
•建立测试用例库，实现测试用例的复用和标准化
•使用自动化测试技术，提高测试执行效率
•建立持续测试机制，将测试活动融入软件开发全过程
2、21个质量子特性
根据 GJB/Z 141-2004《军用软件测试指南》（该标准依据 GJB 5236-2004《军用软件质量模型》制定），军用软件的测试内容被划分为6 个质量特性，下分 21 个质量子特性。
以下是这 21 个测试项的详细分类、定义及核心测试关注点：
一、功能性 (Functionality)
指软件在指定条件下使用时，满足明确和隐含需求的能力。包含 5个子特性：
| | | |
| — | — | — |
| 序号 | 子特性名称 | 定义与核心测试内容 |
| 1 | 适合性 (Suitability) | 定义：软件是否为指定的任务提供了适当的功能集。 测试点：功能清单核对、任务覆盖度、功能完备性（无多余或缺失功能）。 |
| 2 | 准确性 (Accuracy) | 定义：软件提供正确或相符结果的能力。 测试点：计算精度、数据处理误差、时间控制精度、测量结果的偏差范围。 |
| 3 | 互操作性 (Interoperability) | 定义：软件与一个或多个规定系统进行交互的能力。 测试点：接口协议一致性、数据格式转换、硬件/外设驱动兼容性、网络通信协同。 |
| 4 | 安全保密性 (Security) | 定义：软件保护信息和数据的能力，防止未授权访问。 测试点：身份鉴别、访问控制、数据加密/解密、防篡改、审计日志、抗攻击能力。 |
| 5 | 依从性 (Compliance) | 定义：软件依附于与功能性相关的标准、约定或法规的能力。 测试点：是否符合国军标、行业标准、合同规定的特定规范。 |
二、可靠性 (Reliability)
指软件在指定条件下使用时，维持规定性能级别的能力。包含 3个子特性：
| | | |
| — | — | — |
| 序号 | 子特性名称 | 定义与核心测试内容 |
| 6 | 成熟性 (Maturity) | 定义：软件因故障导致失效的频率。 测试点：平均无故障时间 (MTBF)、随机输入测试下的稳定性、长期运行无崩溃。 |
| 7 | 容错性 (Fault Tolerance) | 定义：在软件故障或其接口违规时，维持规定性能级别的能力。 测试点：错误输入处理、异常中断恢复、降级运行模式、故障隔离能力。 |
| 8 | 易恢复性 (Recoverability) | 定义：在失效发生后，重建其性能级别并恢复受直接影响的数据的能力。 测试点：自动重启时间、平均恢复时间 (MTTR)、数据备份与还原、断点续传。 |
三、易用性 (Usability)
指软件在指定条件下使用时，被理解、学习、使用和吸引用户的能力。包含 4个子特性：
| | | |
| — | — | — |
| 序号 | 子特性名称 | 定义与核心测试内容 |
| 9 | 易理解性 (Understandability) | 定义：用户能判断软件是否适合其任务及如何使用的容易程度。 测试点：功能标识清晰度、菜单逻辑、帮助文档的对应性。 |
| 10 | 易学性(Learnability) | 定义：用户学习使用软件的容易程度。 测试点：新手上手时间、演示教程有效性、操作引导提示。 |
| 11 | 易操作性 (Operability) | 定义：用户操作和控制软件的容易程度。 测试点：输入校验、快捷键支持、错误提示友好度、参数设置便捷性、中断与撤销功能。 |
| 12 | 吸引性 (Attractiveness) | 定义：软件吸引用户的能力。 测试点：界面美观度、布局合理性、色彩搭配、可定制化程度（如皮肤、布局调整）。 |
四、效率 (Efficiency)
指软件在规定条件下，相对于所用资源数量，提供适当性能的能力。包含 2个子特性：
| | | |
| — | — | — |
| 序号 | 子特性名称 | 定义与核心测试内容 |
| 13 | 时间特性 (Time Behaviour) | 定义：软件执行功能时的响应时间和处理时间。 测试点：平均响应时间、最大响应时间、吞吐量、事务周转时间、并发处理能力。 |
| 14 | 资源利用性 (Resource Utilization) | 定义：软件执行功能时占用资源（内存、CPU、I/O等）的数量和持续时间。 测试点：内存泄漏检测、CPU 占用率、磁盘 I/O 效率、网络带宽占用、最大负载下的资源表现。 |
五、维护性 (Maintainability)
指软件可被修改的能力，包括修正、改进或适应环境变化。包含 5个子特性：
| | | |
| — | — | — |
| 序号 | 子特性名称 | 定义与核心测试内容 |
| 15 | 易分析性 (Analyzability) | 定义：诊断缺陷或失效原因，以及识别待修改部分的容易程度。 测试点：日志记录的详细度、错误代码的可追溯性、模块化程度。 |
| 16 | 易改变性 (Changeability) | 定义：使指定的修改可能实现的容易程度。 测试点：代码耦合度、参数化配置能力、局部修改对整体的影响范围。 |
| 17 | 稳定性 (Stability) | 定义：避免由于修改导致意外后果的能力。 测试点：回归测试通过率、修改后的副作用检测、版本控制的稳定性。 |
| 18 | 易测试性 (Testability) | 定义：使已修改的软件能被确认的容易程度。 测试点：是否预留测试接口、桩模块支持、自动化测试脚本的编写难度。 |
| 19 | 依从性 (Compliance) | 定义：软件依附于与维护性相关的标准或约定的能力。 测试点：代码注释规范、文档更新同步性、遵循软件工程标准的情况。 |
六、可移植性 (Portability)
指软件从一种环境迁移到另一种环境的能力。包含 2个子特性：
| | | |
| — | — | — |
| 序号 | 子特性名称 | 定义与核心测试内容 |
| 20 | 适应性 (Adaptability) | 定义：软件无需采用有别于为该软件准备的活动或手段就可能适应不同规定环境的能力。 测试点：跨硬件平台运行、跨操作系统运行、不同分辨率适配、参数化环境配置。 |
| 21 | 易安装性 (Installability) | 定义：在指定环境下安装软件的容易程度。 测试点：安装向导友好度、安装失败回滚机制、卸载彻底性、升级/补丁安装的平滑性。 |
| (注：部分版本或解读中，第21项也可能包含“易替换性”，指软件在相同环境中替代另一指定软件产品的能力，通常与易安装性合并考察或作为独立子项，但在GJB 5236模型中通常归为上述分类，总数严格对应21项) | | |
总结与应用
在 GJB/Z 141-2004的实际测试执行中：
1.裁剪原则：并非所有项目都必须测试全部 21 项。需根据软件的安全性关键等级（A/B/C/D级）、规模和任务需求进行裁剪。
1. 例如：嵌入式底层驱动可能重点测“功能性”、“效率”和“可靠性”；而指挥控制系统的人机界面则重点测“易用性”。
2.测试映射：测试人员需将这 21 个子特性转化为具体的测试用例。
1. 例如：针对“资源利用性”，需设计满载压力测试用例；针对“安全保密性”，需设计渗透测试和权限绕过测试用例。
3.评价依据：测试报告必须对照这 21 项给出定性或定量的评价结论，作为软件验收的关键依据。
相关内容：
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：华克斯 苏州华克斯
苏州华克斯《GJB/Z 141-2004 标准内容总结及21个子特性说明》