第3章：兼容性测试基础

说实话，很多刚入行的朋友问我：兼容性测试到底测什么？
我的回答很简单——测的是新版本会不会把老用户搞崩了。

我记得几年前接手过一个支付SDK的升级，版本号从v2.3跳到v3.0。团队里面有人拍胸脯说「改动不大，直接发吧」。结果呢？上线后大批老用户闪退。查到最后，是接口返回字段类型变了，老App直接解析崩溃。从那以后，我每次升级都要老老实实把兼容性测试走一遍。

这一章我们就来聊聊兼容性测试的定义和两个核心类型：向前兼容和向后兼容。搞懂这些，你至少能避免我当年的坑。

什么是兼容性测试

兼容性测试，说白了就是验证新版本SDK能否在既有环境中正常工作。
它不是功能测试，也不是性能测试，它关注的是版本之间的契约。

我在实际工作中把它拆成三个维度：

• 接口兼容——API签名、参数、返回值是否改变
• 行为兼容——同样的输入，输出是否一致
• 数据兼容——旧配置、旧缓存、旧数据库能否正常读写

你想想看，如果这三个维度任何一个出了问题，用户升级SDK就会出事故。嗯，这不是开玩笑。

向后兼容（Backward Compatibility）

向后兼容是最常见的要求。意思是：
新版本的SDK，要能正确处理旧版本产生的数据，也要能被旧版本的调用方正常使用。

举个例子，你的SDK v2.0有个配置文件是JSON格式，v3.0改成Protobuf了。
如果你不兼容旧格式，那所有没有升级配置文件的App就全部没法跑了。我见过一个团队在升级日志库的时候，直接把日志文件格式换了，结果监控系统三天没收到任何日志——全挂了。

维度	向后兼容要求
API签名	已有方法参数表、返回值类型不可变
序列化格式	旧版本序列化的数据必须能被新版本反序列化
行为语义	相同输入下，新版本输出与原版本一致
资源路径	配置、缓存、文件路径不能删除或移动

向前兼容（Forward Compatibility）

向前兼容比向后兼容少有人提，但同样重要——尤其在做分布式系统和长期运行的SDK时。

向前兼容的意思是：
老版本的SDK，要能正确处理新版本产生的数据。

我项目中遇到过真事：服务端先升级了SDK，客户端还是旧版。新SDK发消息时多加了一个字段，老版客户端反序列化直接报错——因为它不认识这个字段。后来我们统一要求：所有序列化协议必须支持「忽略未知字段」。这就是向前兼容的典型策略。

维度	向前兼容要求
序列化格式	新版本增加字段时，旧版本能跳过并保留其余字段
接口	新版本扩展的方法，旧版本调用方可以选择不调用
数据	旧版本写入的数据，新版本保存后，旧版本仍能读取

向前兼容的实现思路不复杂：

• 序列化用Protobuf/Thrift的「ignore unknown fields」模式
• 消息体中用Map/字典替代固定字段
• 接口设计时预留扩展点，比如ext字段

兼容性类型对比

为了方便记忆，我画了个表：

类型	方向	核心意思	常见破坏场景
向后兼容	新 ← 旧	新版本能处理旧版本数据	删除方法、改参数、改序列化格式
向前兼容	旧 ← 新	旧版本能处理新版本数据	新增必填字段、扩展枚举不提示

你可能注意到了，向后兼容是防守，向前兼容是主动。两者结合，才能形成一个完整的版本升级保护网。

知识体系结构

下面这张图把本章的核心逻辑串起来了。你保存下来，以后做兼容性测试方案时可以直接照着看：

实操建议

说了这么多理论，实际工作中怎么落地？
我个人的做法是三步走：

1. 列影响清单——每次升级前，把变更点写下来：删了哪些接口？改了什么字段？序列化格式变了吗？
2. 写兼容性用例——针对每个变更点写两个方向的测试：
   用旧数据调新SDK、用新数据调旧SDK。
3. 自动化回归——把这些用例塞进CI，每次提交都能自动跑。