回归测试基础理论
聊回归测试之前，我想先问一个问题：你改了一行代码，怎么保证整个加密SDK没崩？
很多时候，改动看起来很小——修了一个边界条件、换了一个算法参数。但加密库的依赖链特别深，一个底层函数变了，上层几十个调用方都可能出事。我见过一位同事，只改了一个密钥派生函数的入参类型，结果证书验证模块全部报错。嗯，这就是回归测试要解决的问题。
回归测试的定义
回归测试，说白了就是「改完之后，再跑一遍」。目的是确认新代码没有破坏已有的正确功能。
在我参与的加密SDK项目里，回归测试覆盖的范围通常包括：
- 被修改的模块本身
- 依赖该模块的其他模块
- 与加密功能相关的集成场景（如TLS握手、签名验签）
你可能会问：那和普通的功能测试有什么区别？其实核心差异在于时机——功能测试是「第一次验证」，回归测试是「变更后验证」。加密SDK的回归测试更敏感，因为很多缺陷不是功能错了，而是性能下降或兼容性断裂。
回归测试的分类
根据变更范围和风险等级，我把回归测试分成三类。下面用一个表格快速对比：
| 类型 | 覆盖范围 | 执行耗时 | 典型场景 |
|---|---|---|---|
| 全量回归 | 整个加密SDK所有测试用例 | 长（数小时） | 大版本发布、核心算法重构 |
| 增量回归 | 仅受影响模块及依赖链 | 中（30分钟左右） | 日常Bug修复、参数调整 |
| 冒烟回归 | 最核心的10~20个验证点 | 短（5分钟内） | 代码提交前快速检查 |
我个人习惯把这三类放在同一个CI流水线里：提交代码先跑冒烟回归，过了再跑增量回归，合并前跑全量回归。为什么不一步到位？因为时间就是成本。全量回归一次跑两三个小时，如果前面就挂了，后面全白费。
💡 小经验：我在项目中遇到过一位同事，每次提交都只跑增量回归，结果合并时全量回归没通过——原因是他的改动影响了另一个完全不相关的模块（加密SDK的共享内存管理）。从那以后，我要求团队在合并前必须执行一次全量回归。增量回归的「影响分析」可能存在盲区。
全量回归
全量回归就是把整个测试集重跑一遍。听起来笨，但最可靠。在加密SDK中，全量回归通常包括：
- 所有对称/非对称加密算法测试（AES、RSA、ECC等）
- 密钥生成、导入导出、生命周期管理
- 证书链验证、CRL/OCSP检查
- 与外部HSM或安全芯片的接口兼容性
- 异常场景（内存不足、密钥损坏、超时等）
我记得有一次重构RSA签名模块，改了底层的大数运算库。全量回归跑了4个小时，最后发现一个边缘用例：当模数长度正好是2048位时，签名结果高位少了一个字节。增量回归根本覆盖不到这个场景，因为增量分析认为「大数运算库改的是内部函数，对外接口不变」。你说坑不坑？
增量回归
增量回归的关键是「变更加影响分析」。我们先找出所有受影响的接口和模块，然后只跑相关的测试用例。怎么做呢？
- 依赖图分析：建立模块之间的调用关系图。我常用工具扫描头文件和函数符号，自动生成依赖。
- 变更集合提取：对比Git diff，识别修改了哪些文件、函数、数据结构。
- 测试用例筛选：根据依赖图，选择所有「直接或间接依赖」被修改项的测试用例。
⚠️ 注意：我曾经用增量回归跳过了一个「看似无关」的全局变量改动。那个全局变量在密钥池管理器里，我改的是它的初始化顺序。增量回归只跑了密钥生成和加解密用例，结果证书验证模块因为全局变量状态不对，全部失败。所以增量回归的依赖分析一定要做到「传递闭包」——不光看直接调用，还要看共享状态、静态变量、配置参数。
冒烟回归
冒烟回归是「进门前先看门开了没」。在加密SDK里，我定义的冒烟回归清单大概是这样：
- 初始化/销毁接口能否正常返回（不崩溃、不超时）
- 一次完整的对称加解密（AES-256-GCM）
- 一次完整的非对称签名/验签（RSA-2048 SHA256）
- 密钥生成（随机数是否可用）
- 内存泄漏快检（跑3次基础操作后检查内存）
冒烟回归跑得特别快——我见过最快的是32秒。它不是为了找bug，而是为了「别让测都测不下去」。一个很常见的例子：编译环境变了，链接库路径不对，全量回归跑10分钟才报错，但冒烟回归第一秒就能发现「初始化函数返回NULL」。
测试策略如何选择
策略选择不能靠感觉，得看两个东西：变更风险 和 测试时间窗口。
我通常用下面这个决策模型：
如果变更涉及加密核心算法（如RSA、ECC、哈希），或者影响全局状态（如密钥池、会话管理），优先做全量回归。如果只是修了一个告警日志格式、改了一个注释，冒烟+增量就够了。
还有一个平衡点：CI阶段和发布阶段。CI阶段我跑增量+冒烟，发布前必须全量。但全量回归耗时太长怎么办？解决办法是并行化——把测试集按功能域拆成多个独立job，同时跑。我在一个项目里把全量回归从3小时压缩到了45分钟。
你想想看，如果不做策略选择，每次都全量回归，开发效率会大幅降低；如果只做增量，风险又不可控。所以我建议团队里至少两个人一起评审「影响范围评估结果」——一个人容易漏，两个人可以互补。
🔧 实用技巧：我习惯在每个模块的测试用例里打上标签（@AES、@RSA、@证书、@密钥管理）。增量回归时，通过标签自动筛选。这样即使依赖分析不完美，也能靠标签兜底。比如你改了密钥管理，可以直接选所有@密钥管理标签的用例，顺便带上@证书（因为证书依赖密钥管理）。效果不错。
这张图的核心逻辑就是：先评估影响范围，再选策略。别跳过评估直接拍脑袋。我曾有一次「觉得改动很小」就直接冒烟+增量，结果CI通过了，上线后证书过期却没及时更新——因为改了一个时间戳相关的判断逻辑，但增量回归没覆盖到证书过期检查的测试用例。后来我把这个决策图贴在了团队Wiki首页，每次变更前都必须回答「影响范围属于小还是大」。