4. 兼容性测试概述
说实话，刚入行那会儿，我对兼容性测试的理解特别浅。
总觉得“能跑就行”。直到有一次，我把一个密码SDK集成到某个老牌国产操作系统上。开发环境一切正常，一上客户的信创服务器，整个进程就崩了。查了三天，最后发现是底层OpenSSL版本差异导致的符号冲突。
从那以后，我养成了一个习惯：接手任何一个SDK，第一件事就是搞清楚它的兼容边界。不然后面有你踩的坑。
这章我们就聊聊兼容性测试的那些事儿。目标、分类、层级，把这些搞清楚，后面的测试工作才不会跑偏。
4.1 兼容性测试要解决什么问题
兼容性测试，说白了就是验证你的SDK在目标环境里能不能正常工作。
它的核心目标，我总结三个：
- 功能一致性：同样的接口，在不同平台下返回结果必须一样。比如SM4加密，你在Windows上加密一篇文章，结果在Linux上解不出来，这事儿就大了。
- 接口稳定性：API的签名、行为、异常码不能因为平台变了就跟着变。否则集成方会疯掉。
- 性能可接受：兼容不等于能用就行。有些平台算力弱，同样的算法耗时差几倍，得有个底线。
核心原则：兼容性测试不是为了发现所有不同，而是为了识别并控制不可接受的差异。
你可能问，那什么是不可接受？
举个例子。一个接口，文档上说返回0表示成功，1表示失败。结果在某平台上返回了2。这就不可接受。但如果只是执行时间多了20毫秒，且业务上能接受，那可能就不算问题。
4.2 兼容性测试的分类方式
我习惯把兼容性测试按两个维度来分。
一个按测试对象，一个按测试时机。
4.2.1 按对象分类
| 分类 | 说明 | 我在项目中遇到过的问题 |
|---|---|---|
| 硬件兼容 | 不同CPU架构（x86、ARM、LoongArch）下的指令集差异 | 某ARM平台的SM3指令集加速没生效，纯软实现慢了2倍 |
| 操作系统兼容 | Windows、Linux、macOS，以及各种国产系统 | 统信UOS上动态库加载路径跟CentOS不同，找不对库 |
| 运行时兼容 | JDK版本、.NET Framework版本、C运行时库版本 | JDK 8下AES-GCM的Provider实现有已知bug，不能用 |
| 外部依赖兼容 | OpenSSL、NSS、GnuTLS等底层密码库的版本 | OpenSSL 1.0.2和1.1.1的EVP接口行为不一致 |
| 语言绑定兼容 | C、C++、Java、Python、Go等不同语言包装层 | Python绑定在内存管理上跟C原生层不一致，有泄漏 |
4.2.2 按时机分类
这个很简单，就两种：
- 预发布兼容测试：发版前做，目的是确认SDK在新环境上能跑。
- 回归兼容测试：每次代码变更后，跑一小部分核心用例，确保没把老的兼容性搞坏。
我的习惯：预发布测试我会把全量兼容矩阵跑一遍。回归测试我只看差异部分，比如新增了某个OS支持，就只测那个OS相关的用例。
4.3 兼容性测试的四个层级
嗯，这里要重点说说层级。这是我个人非常喜欢的一个划分方式。
我把兼容性测试分为四个层级：API层级、功能层级、平台层级、版本层级。
为什么这么分？
因为不同层级关注的粒度不同，测试手段也不同。把它们分开，你的测试设计才能做得干净。
4.3.1 API层级
这是最细的粒度。针对每一个对外暴露的接口。
测试内容：
- 函数签名是否一致（参数类型、个数、顺序）
- 返回值类型、错误码定义是否相同
- 多线程下接口行为是否一致（锁机制、线程安全）
你会特别注意什么？
我记得有个项目，C接口里一个函数参数是int，但在Java绑定里被映射成了long。32位平台没事，一到64位就出问题。
所以API层级的兼容测试，我通常会用契约测试的方式来做。
// 一个简单的契约示例：接口签名必须匹配
// C 层
int sm4_encrypt(const unsigned char *key,
const unsigned char *iv,
const unsigned char *input,
size_t input_len,
unsigned char *output,
size_t *output_len);
// Java 绑定签名必须一致
public native int sm4Encrypt(byte[] key, byte[] iv,
byte[] input, byte[] output);
4.3.2 功能层级
这个层级关心的是业务流程对不对。
一个API对，不代表整个功能对。
举个例子。SM4加密在Android和iOS上单个加密接口都正常，但Android的加解密流程里多了个Base64编码，iOS端没有。结果两端互通不了。
功能层级的兼容测试，我建议用端到端的业务场景来驱动。
- 场景1：A平台加密 → B平台解密 → 结果一致
- 场景2：多轮加解密 → 数据不溢出
- 场景3：并发操作密钥 → 状态不紊乱
避坑提醒：我曾经在跨平台场景下吃亏过。A平台加密结果用B平台解密，前几次都成功，结果密钥更新几次后，两边状态没同步，解密直接失败。原因是密钥派生流程没统一。功能层级的测试一定要覆盖完整的生命周期。
4.3.3 平台层级
这是最复杂的一层。因为“平台”是个很大的概念。
我把它拆成了两部分：
- 操作系统平台：Windows / Linux / macOS / Android / iOS / 国产OS
- 硬件平台：x86 / ARM / LoongArch / RISC-V
怎么做？
对于操作系统平台，我一般会准备一个兼容矩阵。把支持的所有OS版本列出来，然后逐一验证核心API和功能。
| 操作系统 | 版本 | 架构 | 测试结果 |
|---|---|---|---|
| CentOS | 7.9 | x86_64 | 通过 |
| Ubuntu | 20.04 | x86_64 | 通过 |
| Ubuntu | 22.04 | ARM64 | 通过 |
| 统信UOS | V20 | LoongArch | 失败（见备注） |
4.3.4 版本层级
这个层级容易被忽略，但实际中特别容易出问题。
你想想看，你的SDK依赖OpenSSL。OpenSSL从1.0.2升级到1.1.1，很多内部结构变了。如果SDK直接用了这些内部结构，那版本一升级就崩。
版本层级测试要做两件事：
- 前向兼容：新版本SDK能否在老版依赖库上运行？
- 后向兼容：老版本SDK能否在新版依赖库上运行？（这个更常见）
我通常会把依赖库的最小版本和最大版本都测一遍。比如：
- OpenSSL 1.1.0 ~ 3.0.0
- JDK 8 ~ JDK 17
- GCC 4.8 ~ GCC 12
为什么要测最小版本？
因为很多集成方的环境不是最新的。他们可能为了稳定性，卡在一个老版本上。你SDK说“支持OpenSSL 1.1.x”，结果人家用1.1.0就报错，这就尴尬了。
4.4 知识体系总览
说了这么多，来张图总结一下。这是我对兼容性测试整个知识体系的梳理。
4.5 最后说两句
兼容性测试不是一锤子买卖。它不是发版前跑一遍就能完事的。
我的建议是：把它嵌入到你的日常测试流程里。
每次有新环境、新依赖版本、新语言绑定，就自动触发一次兼容性检查。自动化能做大部分，但有些场景，比如新架构上的真实部署测试，还得靠人工盯着。
嗯，这一章就到这儿。记住这四个层级，后面我们每一层都会展开细讲。