datai/datai-scenes/datai-scene-salesforce/docs/decisions/2026-02-03-002-04-ADR-代码覆盖率技术选型.md

ADR-002-04: 代码覆盖率技术选型

状态

已接受

日期

2026-02-03

背景

代码覆盖率功能需要选择合适的技术方案，满足以下要求：

1. 支持查询和统计 Apex 类与触发器的测试覆盖率数据
2. 支持按类、触发器、命名空间等多维度查询
3. 提供覆盖率统计和聚合分析能力
4. 与 002-03（测试执行）功能的数据模型兼容
5. 确保查询性能和数据一致性

需求约束

1. 支持分页查询，避免大数据量查询导致性能问题
2. 支持多条件筛选（testResultId、name、type、namespace、coverage范围）
3. 提供总体覆盖率统计功能
4. 提供按类型（Class/Trigger）统计功能
5. 与现有技术栈保持一致

决策

决策 1：数据库表策略

选择方案 1：复用现有表

• 复用 002-03 的 datai_apex_code_coverage 表
• 不复用 datai_apex_code_location 表（本功能不需要代码位置详情）

理由：

1. 数据一致性：datai_apex_code_coverage 表在 002-03 中已经定义，复用可避免数据冗余和不一致
2. 维护成本低：不需要创建新的数据库表，降低维护复杂度
3. 功能完整性：002-03 的测试执行功能会写入覆盖率数据，本功能只需要查询和统计
4. 查询性能：表结构已经优化，包含必要的索引

决策 2：Service 层设计策略

选择方案 1：独立 Service 层

• 创建独立的 IApexCodeCoverageService 接口和 ApexCodeCoverageServiceImpl 实现
• 与 ApexTestService 分离，职责更清晰

理由：

1. 单一职责原则：代码覆盖率功能以查询和统计为主，与测试执行（写入操作）职责不同
2. 可维护性：独立的 Service 层便于维护和扩展
3. 可测试性：独立的 Service 层便于单元测试
4. 代码清晰度：避免一个 Service 类过于庞大，职责混乱

放弃方案 2（合并到 ApexTestService）的理由：

1. ApexTestService 已经包含测试执行逻辑，再添加查询逻辑会导致类过于庞大
2. 代码覆盖率查询与测试执行是不同的业务领域，应该分离
3. 不利于后续的独立扩展和维护

决策 3：查询性能优化策略

选择方案 1：数据库索引 + 分页查询

• 使用现有的数据库索引（test_result_id、name、type、namespace）
• 使用 PageHelper 进行物理分页
• 对覆盖率范围筛选在内存中进行（数据量可控）

理由：

1. 查询性能：数据库索引确保查询性能
2. 内存友好：物理分页避免加载大量数据到内存
3. 灵活性：覆盖率范围筛选在内存中进行，避免复杂的 SQL 条件
4. 简单性：实现简单，不需要额外的缓存或搜索引擎

放弃方案 2（使用 Redis 缓存）的理由：

1. 代码覆盖率数据相对稳定，但查询条件多样，缓存命中率可能不高
2. 增加系统复杂度，需要维护缓存一致性
3. 当前数据量下，数据库查询性能已经足够
4. 可以后续根据实际性能需求再考虑添加缓存

决策 4：权限控制策略

选择方案 1：独立权限标识

• 使用独立的权限标识 apex:coverage:query
• 与测试执行权限分离

理由：

1. 细粒度控制：支持对代码覆盖率查询和测试执行分别授权
2. 安全性：某些用户可能只需要查看覆盖率，不需要执行测试
3. 灵活性：便于后续的权限管理扩展
4. 符合规范：与若依的权限管理规范一致

放弃方案 2（复用测试执行权限）的理由：

1. 权限粒度太粗，无法满足细粒度控制需求
2. 不符合最小权限原则
3. 不利于后续的权限管理

后果

正面影响

1. 开发效率高：复用现有数据库表，减少开发工作量
2. 维护成本低：独立的 Service 层，职责清晰，便于维护
3. 查询性能好：数据库索引 + 分页查询，确保查询性能
4. 权限控制灵活：独立的权限标识，支持细粒度控制
5. 代码质量高：遵循单一职责原则，代码结构清晰

负面影响

1. Service 类数量增加：独立的 Service 层会增加类数量
2. 覆盖率范围筛选在内存中进行：如果数据量很大，可能会影响性能（但当前场景下数据量可控）
3. 无缓存支持：首次查询可能需要访问数据库（可以后续根据需求添加缓存）

替代方案

数据库表策略 - 方案 2：新建表

• 描述：创建新的数据库表专门用于代码覆盖率查询
• 优点：
  • 表结构可以完全按照查询需求设计
  • 不影响 002-03 的表结构
• 缺点：
  • 数据冗余，需要同步维护两份数据
  • 增加存储成本
  • 增加维护复杂度
• 适用场景：查询需求与存储需求差异很大，需要不同的表结构

Service 层设计策略 - 方案 2：合并到 ApexTestService

• 描述：将代码覆盖率查询功能合并到 ApexTestService 中
• 优点：
  • 减少 Service 类数量
  • 测试执行和覆盖率查询在同一个类中，便于关联操作
• 缺点：
  • 违反单一职责原则
  • Service 类过于庞大，职责混乱
  • 不利于维护和测试
• 适用场景：功能简单，查询逻辑很少的场景

查询性能优化策略 - 方案 2：使用 Redis 缓存

• 描述：使用 Redis 缓存覆盖率统计结果
• 优点：
  • 减少数据库访问，提高查询性能
  • 支持高并发查询
• 缺点：
  • 增加系统复杂度
  • 需要维护缓存一致性
  • 增加运维成本
• 适用场景：查询频率很高，数据相对稳定的场景

权限控制策略 - 方案 2：复用测试执行权限

• 描述：复用测试执行的权限标识 apex:test:execute 和 apex:test:query
• 优点：
  • 减少权限标识数量
  • 简化权限配置
• 缺点：
  • 权限粒度太粗
  • 无法满足细粒度控制需求
• 适用场景：权限控制要求不高的场景

相关文档

• 需求文档
• 设计文档
• 测试执行决策记录
• Apex 代码编译和执行决策记录