3. 安全关键软件测试标准与INTEGRITY合规要求

INTEGRITY 作为面向安全关键领域的实时操作系统，其测试活动并不是“把功能跑通”即可结束，而是必须回答一个更严格的问题：在什么标准下、以什么目标、用什么证据，证明这套内核及其上的应用满足适航、工业或汽车安全完整性要求。 DO-178C、IEC 61508 与 ISO 26262 分别面向航空、通用工业与道路车辆，它们对 INTEGRITY 测试的约束方式不同，但底层逻辑高度一致：先确定软件的安全等级或完整性等级，再据此确定测试的独立性、覆盖目标、验证深度和证据形式。

三个标准对 INTEGRITY 测试的约束差异

DO-178C 以“软件等级”驱动一切。机载软件按失效后果分为 A 至 E 级，A 级要求最严：不仅要求语句覆盖，还要求判定覆盖、修正条件/判定覆盖（MC/DC），并要求验证活动具备独立性。对 INTEGRITY 而言，若它作为 A 级机载软件的驻留操作系统，其内核服务、分区调度、时间与空间隔离机制都必须纳入验证范围，且不能仅靠“供应商已认证”一句话带过，需要形成面向具体项目的证据包。

IEC 61508 以“安全完整性等级”SIL 1～SIL 4 划分，强调安全生命周期与系统性失效控制。它更关注功能安全整体框架：安全需求分配、硬件与软件协同、诊断覆盖率、失效模式与影响分析。对 INTEGRITY 测试来说，SIL 3 及以上通常要求更严格的测试独立性、更完整的追溯关系，以及对内核配置项（如分区数量、调度周期、内存保护单元配置）的逐项验证。

ISO 26262 面向汽车电子电气系统，以 ASIL A～D 分级。它强调“安全目标—功能安全概念—技术安全需求—软硬件实现—验证确认”的追溯链。INTEGRITY 在汽车场景中常作为安全岛或域控制器的操作系统，其测试重点包括：启动自检、运行时监控、内存保护、任务超时监控、以及与应用层安全机制的接口一致性。ASIL D 对测试方法的要求接近 DO-178C A 级，但更强调硬件与软件的协同失效分析。

INTEGRITY 测试的合规目标与证据要求

无论依据哪个标准，INTEGRITY 测试的合规目标都可以归纳为四类：需求追溯、覆盖充分、独立性达标、证据可审计。需求追溯要求每一条安全需求都能向下追溯到测试用例，向上追溯到系统安全目标；覆盖充分要求根据等级选择语句、判定、MC/DC 或等价方法；独立性要求验证人员不参与被验证对象的开发；证据可审计要求测试计划、用例、结果、缺陷记录、配置管理记录形成闭环。

以 DO-178C A 级为例，INTEGRITY 内核测试通常需要提供：软件需求标准、软件设计标准、测试计划、测试用例与规程、测试结果、覆盖分析报告、结构覆盖分析、可追溯性矩阵、配置索引、问题报告与纠正记录。IEC 61508 SIL 3 则更强调安全需求规格、验证计划、FMEDA 与诊断覆盖率证据。ISO 26262 ASIL D 需要安全计划、安全案例、验证报告与确认措施记录。

从标准条款到 INTEGRITY 测试活动的映射

实际执行时，建议先把标准条款翻译成可测试的约束。例如 DO-178C 表 A-7 对 A 级要求“验证过程独立于开发过程”，对应到 INTEGRITY 项目就是：内核配置验证、分区隔离测试、时间窗口测试必须由独立验证组执行，且测试环境与被测目标环境一致或经过等效性论证。IEC 61508 对 SIL 3 要求“诊断覆盖率≥90%”（示例目标，具体以项目安全计划为准），对应到 INTEGRITY 就是：内存保护异常注入、任务超时注入、非法系统调用注入等故障注入测试必须覆盖诊断机制。

ISO 26262 ASIL D 要求“安全机制应被验证”，对应到 INTEGRITY 就是：看门狗、内存保护单元、分区调度器、健康监控等机制需要逐项设计测试用例，并记录通过/失败判据。下面这张图把三个标准的核心约束、INTEGRITY 测试对象与证据输出放在同一张关系图中，便于对照理解。

实际执行中的关键操作与判断依据

把标准要求落到 INTEGRITY 测试上，通常按以下顺序推进。第一步是确定适用等级：航空项目查 DO-178C 软件等级，工业项目查 SIL，汽车项目查 ASIL。等级决定覆盖方法和独立性要求，不能先做测试再补等级论证。第二步是建立需求追溯矩阵：左侧列安全需求，右侧列测试用例，中间标注覆盖方法。例如一条“分区 A 不得访问分区 B 内存”的需求，对应测试用例应包含正常访问、越界访问、非法指针访问三类，并记录 MPU 异常触发结果。

第三步是设计覆盖充分的测试用例。以 DO-178C A 级 MC/DC 为例，若内核调度判断条件为 if (task_ready && time_slot_valid && !partition_fault)，则需要设计用例使每个条件独立影响判定结果。示例参数可设为：任务就绪=1、时间片有效=1、分区无故障=1 时调度执行；任务就绪=0 时调度跳过；时间片无效时调度跳过；分区故障时调度跳过。每个用例记录实际输出与预期输出，并标注覆盖的条件组合。

第四步是执行独立性验证。验证人员应独立于开发人员，测试环境应尽量接近目标环境。若使用仿真环境，需要提供等效性论证，说明仿真环境与目标环境在时序、内存保护、中断响应等方面的差异不影响验证结论。第五步是形成证据包：测试计划、用例、结果、覆盖报告、缺陷记录、配置索引按标准要求归档，并确保版本一致。

常见合规误区与排障思路

第一个误区是“内核已认证，项目无需再测”。实际上，供应商认证覆盖的是内核基线，项目对内核的配置（如分区数量、调度表、内存映射）和应用接口仍需验证。第二个误区是“覆盖率达到 100% 就合规”。覆盖率只是必要条件，不是充分条件；需求追溯、独立性、缺陷闭环同样关键。第三个误区是“测试环境可以随意替代”。若仿真环境与目标环境差异较大，必须提供等效性分析，否则验证结论不成立。

排障时可按“标准条款—测试活动—证据—缺口”四步检查。例如发现 MC/DC 覆盖不足，先检查用例是否覆盖每个条件的独立影响，再检查判定表达式是否被简化或重构，最后检查覆盖工具配置是否正确。若发现追溯断裂，先检查需求是否被正确分解，再检查测试用例是否与需求一一对应，最后检查矩阵版本是否与测试结果一致。

综合来看，DO-178C、IEC 61508 与 ISO 26262 对 INTEGRITY 测试的约束虽然表述不同，但都指向同一套工程动作：先定级、再追溯、后覆盖、验独立、留证据。项目只需把标准条款翻译成具体的测试对象、测试用例和判据，就能把“合规”从一句口号变成可执行、可审计、可复现的测试活动。