目录标题
- 1. 集成测试的定位：验证 AP Core 的“系统级契约”
- 1.1 单元测试 vs 集成测试：关注点不同
- 1.2 集成测试的三类“真实边界”
- 2. 用例设计的核心目标：围绕不变量构建测试矩阵
- 2.1 目标一：错误模型的身份一致性与可比较性
- 2.2 目标二：生命周期门控的全局一致性
- 2.3 目标三：并发与异步语义的可预期性
- 2.4 目标四：时间与内存等“基础语义”的稳定支撑
- 2.5 难点对比：为什么“跨库边界一致性”最容易被忽略
- 3. 落地方法：把目标转成可执行的测试工程与最小清单
- 3.1 测试工程结构建议
- 3.2 断言方法建议
- 3.3 最小可交付（MVP）集成测试清单
- 3.4 常见反模式（建议在集成测试里主动“打破它”）
- 结语
1. 集成测试的定位：验证 AP Core 的“系统级契约”
AUTOSAR Adaptive Platform 的 Core（通常对应 ara::core 语义集合）是平台的通用基座：它提供统一的错误模型、初始化/反初始化生命周期、异步/并发基础能力，以及时间与内存等基础语义。集成测试的价值在于验证这些能力在真实组合与真实边界下仍保持一致，而不仅是单个 API 在理想条件下“能跑”。软件工程里常见的认知偏差是“局部正确即整体正确”，但在平台基础库上更接近心理学中的“系统一因子错误”：某个底层契约一旦不稳，会被上层无限放大。
1.1 单元测试 vs 集成测试：关注点不同
- 单元测试：验证单一类/函数的局部行为（例如某个错误码到 message 的映射）。
- 集成测试：验证跨模块、跨编译单元、跨库边界后的全局不变量是否成立（例如同一错误域在进程内的身份是否一致、初始化门控是否能约束所有依赖点）。
1.2 集成测试的三类“真实边界”
- 编译与链接边界：跨编译单元、跨静态库/
