1. INTEGRITY安全关键软件测试工程导入
在航空、轨道交通、医疗、核电与汽车电子等领域，软件一旦失效可能直接危及人身安全，这类软件被称为安全关键软件。INTEGRITY RTOS 是 Green Hills Software 面向高保障场景推出的实时操作系统，其设计目标不是"功能尽可能多"，而是"在最坏情况下仍可预测、可证明、可隔离"。本课程围绕 INTEGRITY 平台，讲解如何建立一套可落地、可追溯、可复现的安全关键软件测试工程体系。
一、课程目标：从"会测"到"测得可证明"
普通软件测试关注"功能是否正确"，而安全关键软件测试还要回答三个额外问题：是否覆盖了所有安全需求？是否在异常与边界条件下仍然安全？测试证据能否被第三方审查？因此本课程的目标可以归纳为四条主线：
- 理解平台：掌握 INTEGRITY RTOS 的分离内核、分区、内存保护、时间分区等机制，理解它们如何影响测试设计。
- 掌握方法：能够依据 DO-178C、IEC 61508、ISO 26262 等标准的思路，把需求分解为可验证的测试项，并选择结构覆盖、边界值、故障注入等合适手段。
- 落地工具：能够使用 MULTI IDE、INTEGRITY 目标调试、覆盖率统计、静态分析等工具链完成测试执行与证据采集。
- 形成证据：能够输出需求—用例—结果—缺陷可双向追溯的测试记录，支撑适航或认证审查。
需要强调的是，安全关键测试不是"多跑几遍"，而是用有限的时间和用例，证明系统在定义的安全边界内不会产生不可接受的失效。这决定了本课程后续所有内容都围绕"需求可追溯、覆盖可度量、结果可复现"展开。
二、INTEGRITY RTOS 在安全关键领域的定位
INTEGRITY 的核心是分离内核（Separation Kernel）：内核只提供最少的必要服务，把操作系统功能、驱动、应用分别放入相互隔离的分区中。每个分区拥有独立的地址空间和资源配额，一个分区崩溃不会直接破坏其他分区。这一特性对测试工程有直接影响——测试对象不再只是"一个程序"，而是"一组分区及其通信关系"。
从认证角度看，INTEGRITY 通常已具备较高的安全等级证据（如 DO-178C A 级、IEC 61508 SIL 3 等适用性材料），但平台已认证不等于应用已认证。应用层代码、分区配置、分区间通信（如通过 Channel 或共享内存）仍需独立测试。因此测试工程师必须同时理解"平台提供了什么保证"和"应用必须自己证明什么"。
三、测试工程的整体框架
安全关键软件测试工程可以组织为一条从需求到证据的链路：需求分析 → 测试计划 → 用例设计 → 环境搭建 → 执行与监控 → 结果判定 → 缺陷与回归 → 证据归档。下图给出该框架与 INTEGRITY 平台关键对象的对应关系，帮助建立整体认知。
四、学习路径与关键能力
本课程后续内容按"认知—设计—执行—证据"四层推进。建议的学习顺序是：先建立 INTEGRITY 分区与内核的基本认知，再学习如何把安全需求拆成可测项，然后进入用例设计、环境搭建与执行，最后学习覆盖率统计、缺陷管理与认证证据组织。
下面给出一份可直接参考的测试项设计示例表，用于说明"需求如何变成可执行用例"。示例假设某分区需在 10 ms 周期内完成传感器数据校验，若校验失败则向监控分区发送告警。
| 需求编号 | 需求描述 | 测试项 | 输入/条件 | 预期结果 | 覆盖类型 |
|---|---|---|---|---|---|
| REQ-001 | 周期任务应在 10 ms 内完成 | 周期时间测量 | 正常负载，连续 1000 周期 | 最大执行时间 ≤ 10 ms | 时序/边界 |
| REQ-002 | 校验失败应发送告警 | 故障注入 | 注入 1 位翻转错误 | 监控分区收到告警消息 | 功能/异常 |
| REQ-003 | 分区越权访问应被阻止 | 权限测试 | 尝试写入其他分区内存 | 触发保护异常，系统不崩溃 | 安全/隔离 |
| REQ-004 | 告警消息不得丢失 | 通信压力测试 | 连续发送 500 条告警 | 接收计数 = 发送计数 | 通信/边界 |
这张表体现了安全关键测试的三个要点：每条用例都能追溯到需求；输入条件明确、可复现；预期结果可量化判定。在实际项目中，还应补充前置条件、测试环境版本、目标板编号、执行日期与执行人，使结果具备审查价值。
五、本课程的学习方法建议
建议边学边做：每学完一个测试方法，就在自己的 INTEGRITY 工程中找一个分区或一条通信路径，写出对应的需求—用例—判定条件三行记录。遇到覆盖率不足时，先分析是需求遗漏、用例不足还是代码存在不可达分支，再决定补用例还是提缺陷。只有把"测试设计"和"证据意识"同时建立起来，后续的认证审查才不会变成临时补材料。