回归测试基础：定义、范围、策略与冒烟测试的关系
回归测试是数据库缓存工程中保障质量的核心环节。当缓存逻辑、数据源配置或参数化规则发生变更时，回归测试确保已有功能不被破坏。本节从定义、范围、策略以及与冒烟测试的关系四个维度展开。
2.1 回归测试定义
回归测试（Regression Testing）是指在软件或系统发生代码修改、配置变更、环境升级或数据迁移后，重新执行已有测试用例，以验证变更未引入新的缺陷或导致原有功能失效的测试活动。
核心目标： 检测“回归缺陷”——即因变更而重新暴露的旧缺陷或新引入的副作用。
在数据库缓存工程中，回归测试覆盖以下典型变更场景：
- 缓存策略调整： 如从 LRU 切换为 LFU，或调整过期时间 TTL。
- 数据源参数修改： 如连接池大小、超时阈值、重试次数。
- 缓存键生成规则变更： 如新增维度字段或修改哈希算法。
- 底层依赖升级： 如 Redis 客户端库版本更新或数据库驱动替换。
2.2 回归测试范围
回归测试并非全量重跑所有用例，而是基于变更影响分析（Change Impact Analysis）确定范围。范围划分通常遵循以下层次：
| 范围层级 | 说明 | 适用场景 |
|---|---|---|
| 单元级回归 | 仅重跑与被修改代码直接相关的单元测试 | 缓存键生成函数、序列化/反序列化逻辑 |
| 模块级回归 | 覆盖被修改模块及其直接调用者的测试 | 缓存读写模块、失效通知模块 |
| 集成级回归 | 验证缓存层与数据库、消息队列等外部组件的交互 | 缓存穿透/击穿防护、数据一致性校验 |
| 端到端回归 | 模拟真实用户请求，覆盖完整业务链路 | 缓存预热流程、降级与熔断机制 |
实践建议： 在数据库缓存工程中，优先选择集成级回归作为基线，因为缓存层的大部分缺陷发生在与数据源交互的边界上。
2.3 回归测试策略
回归测试策略决定了“测什么、怎么测、测多少”。常见策略包括：
- 全量回归： 执行所有历史用例，适用于重大版本发布或底层架构重构。成本高，但覆盖最全面。
- 选择性回归： 基于代码变更影响分析，仅执行受影响模块的用例。效率高，但依赖精准的依赖分析工具。
- 风险驱动回归： 按功能风险等级排序，优先覆盖高风险的缓存一致性、数据丢失等场景。
- 参数化回归： 通过数据驱动方式，用多组参数组合（如不同 TTL、连接池大小）执行同一套测试逻辑，验证配置边界。
下表对比了四种策略的适用性与成本：
| 策略 | 覆盖度 | 执行成本 | 推荐频率 |
|---|---|---|---|
| 全量回归 | 高 | 高 | 大版本发布 |
| 选择性回归 | 中 | 中 | 日常迭代 |
| 风险驱动回归 | 中高 | 中 | 紧急修复 |
| 参数化回归 | 高（配置维度） | 低（自动化） | 每次配置变更 |
2.4 冒烟测试与回归测试的关系
冒烟测试（Smoke Testing）是回归测试的前置关卡。两者在目标、执行时机和范围上存在明确差异，但又紧密衔接。
常见误区： 不要将冒烟测试与回归测试混为一谈。冒烟测试是“快速检查”，回归测试是“全面验证”。在数据库缓存工程中，冒烟测试通常只验证缓存能否正常读写、连接是否建立；而回归测试需要验证缓存一致性、过期策略、并发安全等深层行为。
2.5 数据库缓存工程中的实践要点
结合数据库缓存场景，回归测试与冒烟测试的协作流程如下：
- 变更提交后，自动触发冒烟测试： 执行 3~5 个核心用例（如缓存连接、基本读写、过期失效）。
- 冒烟通过后，进入回归测试阶段： 根据变更类型选择对应回归策略（推荐参数化回归 + 选择性回归组合）。
- 回归测试执行中，重点关注缓存与数据库的数据一致性： 使用数据驱动方式，覆盖不同 TTL、不同并发数、不同缓存键模式。
- 回归测试报告生成后，自动比对基线结果： 标记新增失败用例，关联变更代码，辅助快速定位。
效率提升技巧： 在回归测试中引入“参数配置矩阵”，将缓存参数（如 maxmemory、eviction-policy、timeout）作为测试数据源，用同一套测试逻辑验证不同配置组合下的行为。这既能提升回归覆盖率，又能降低用例维护成本。