4. 兼容性测试策略

兼容性测试，到底测什么？

说白了，就这四样：前向兼容、后向兼容、API兼容性、行为兼容性。光测一个不够，全得覆盖到。我见过太多团队只盯着「新功能能用」，结果老业务崩了，用户骂街。

4.1 前向兼容 vs 后向兼容

这两个概念，刚入行的兄弟容易搞混。我给你捋一捋：

我记得刚入行那会儿，做支付SDK。新版本加了个加密字段，结果老版本根本没这个字段。我没有做降级处理，直接让老SDK的APP调用新接口，崩了。你说冤不冤？前向兼容，就是要你考虑「用户不升级」的情况。

后向兼容呢，更常见。你升级了SDK，老用户不更新你的库，但他调你的API。你不能改响应结构，不能删字段。我有个同事，新版本把返回的 status 字段名改成了 state，结果线上很多老代码直接用 response.status ——全挂了。你说这算不算低级错误？

4.2 API兼容性

API兼容性，是SDK和调用方之间的契约。

一旦对外发布，接口签名就是承诺。举个例子：

// v1.0.0 - 原版
public User getUser(int id)

// v2.0.0 - 改了参数类型，不兼容
public User getUser(String id)

// 调用方按int传参，编译都过不了，更别说运行了

API兼容性需要关注以下几个维度：

• 方法签名不变：方法名、参数类型、返回类型不能变。
• 异常类型不变：新增异常可以，但不能删除已有异常。
• 字段不能删：JSON响应里，之前有 errorMsg，新版本不能去掉。
• 枚举值不能砍：状态码、枚举常量只能增不能减。

怎么测API兼容性？我的习惯是这样的：

1. 把旧版本SDK和调用方代码打包成测试项目。
2. 用新版本SDK替换旧SDK的jar/aar包。
3. 不修改调用方代码，直接运行已有测试用例。
4. 如果编译通过、测试全绿，API兼容性就算过了。

4.3 行为兼容性

行为兼容性，是最容易被忽略的。

你想想看，API没变，返回值格式没变，但——

• 同一个操作，以前返回空字符串，现在返回null
• 以前是同步的，现在改成了异步
• 以前异常是 IOException，现在变成了 RuntimeException

这些都属于行为不兼容。你说接口没坏吧？调用方逻辑完全可能炸。

有一次我们升级了底层图像算法，接口还是 Image process(Image input)，返回的也是 Image。但新版本对某些角度的图片处理耗时从50ms飙到了500ms。调用方没设超时，结果整个APP卡死。你说这是API问题吗？不是。是行为问题。

行为兼容性测试，要盯的是：

测行为兼容性，光靠单元测试不够。我建议你拿老版本的测试用例，直接在线上切换前后对比看差异。或者用diff工具比较两个版本的完整调用日志。我曾经手工跑了一百多个回归用例，就为了确认同一个输入，输出是否完全一致。