测试要求

2. 测试规范（Testing Requirements）

2.1 测试的核心理念

在本项目中，测试被视为工程核心资产，而不是开发完成后的附加步骤。

测试设计遵循以下原则：

• 不追求“数字好看”的覆盖率
• 以真实用户使用路径为中心
• 对不同模块设定不同强度的测试要求
• 明确哪些错误是可以被容忍的，哪些是不可以的

2.2 核心训练链路的定义

以下内容被定义为核心训练链路（Core Training Pipeline）：

• 底层内存分配与管理
• 数值计算过程
• 计算任务的分发与调度
• 自动微分（Autograd）
• 优化器逻辑
• 模型（Model）执行相关代码

这些部分共同构成了一条完整的训练流程，一旦出现不能正确处理的错误，整个训练过程即失去意义。

因此，这些模块必须接受最严格的测试要求。

2.3 Tensor 维度覆盖策略（0D–3D）

基于对用户使用场景的分析，项目做出如下判断：

• 用户极少在高维（>3D）Tensor 上进行复杂操作
• 实际使用中最常见的是：
  • 0D（标量）
  • 1D（向量）
  • 2D（矩阵）
  • 3D（常见批量张量）

测试要求

• 对于每一种可支持的操作类型：
  • 即使某个逻辑分支已经被覆盖
  • 仍必须通过 0D–3D 的额外测试
• 测试目标：
  • 消除内部实现不确定性
  • 确保在用户最常用维度范围内行为一致、正确

2.4 数据类型覆盖要求

在 core/include/definitions 中，项目明确列出了：

• 所有支持的可操作数据类型

测试中要求：

• 对每一种支持的数据类型
• 在所有有效维度（0D–3D）下
• 对应操作必须被明确测试并验证正确性

2.5 测试框架

项目统一使用以下测试工具：

• Google Test（gtest）

主要用于：

• 单元测试
• 参数化测试
• 维度 × 数据类型 组合测试
• 回归测试

2.6 非核心模块的测试要求

对于非核心模块，例如：

• 日志系统
• 工具类
• 辅助组件

不要求复杂的维度与数学验证，但仍需保证整体质量。

当前阶段要求：

• 行覆盖率 ≥ 80%
• 分支覆盖率 ≥ 35%
• 在此基础上，覆盖率应尽可能继续提高

2.7 分阶段取舍策略

• 一些可能在未来才显现的复杂问题：
  • 当前阶段暂不强制覆盖
• 避免过度设计导致：
  • 开发成本失控
  • 测试负担过重

2.8 面向未来功能的测试规范

对于后续新增功能或插件：

• 项目会为每一个功能单独制定测试要求
• 开发者需：
  • 按要求编写足量测试