第3章 多平台PKI SDK兼容性测试框架设计：分层、模块化、可扩展

做SDK测试这么多年，我最深的体会是：没有框架的测试就是一团乱麻。尤其是PKI SDK，要面对Windows、Linux、macOS、iOS、Android这些差异巨大的平台，再加上OpenSSL、Bouncy Castle、硬件安全模块等各种底层引擎……如果每次换平台都重新写一遍用例，那离离职就不远了。

这一章我就把实战中打磨出来的框架思路拆给你看。核心就三个词：分层测试、模块化、可扩展。你想想看，一套框架如果能同时满足这三条，不管以后冒出什么新平台、新协议版本，你都只需要改一小块代码，甚至不改——直接插上适配器就跑。

3.1 为什么一定要分层？

我曾经接手过一个项目，测试代码和业务逻辑搅在一起。换一个平台，测试代码要重写60%。为什么？因为把平台API调用直接硬编码在用例里了。说白了，分层就是把“做什么”和“怎么做”拆开。

我习惯把框架切为三层（见下方架构图）：

• 测试用例层：只描述业务场景，比如“签发一张RSA 2048证书并验证链”。它不关心底层是哪个库。
• 测试适配层：把平台差异封装成统一接口。比如 PlatformKeyStore::loadCertificate(path)，在不同平台下调用不同的API。
• 底层PKI核心：真实的密码学实现，可能是OpenSSL、NSS、BC等。这一层我们不直接测，而是通过适配层间接覆盖。

3.2 模块化：每个适配器就是一个插件

分层的下一步就是把适配器做成插件。我见过很多团队虽然分了层，但适配器代码全写在同一个目录里，ifdef 满天飞。那是假分层。

真正的模块化要做到：每个平台或每个PKI库是一个独立的模块，拥有自己的注册入口。比如：

adapters/
├── openssl/
│   ├── OpenSSLAdapter.cs
│   ├── OpenSSLKeyStore.cs
│   └── module.json
├── bouncycastle/
│   ├── BCAdapter.java
│   ├── BCKeyStore.java
│   └── module.json
└── mbedtls/
    ├── MbedTlsAdapter.c
    ├── MbedTlsKeyStore.c
    └── module.json

每个模块里的 module.json 声明它支持的平台、版本、依赖。框架在启动时扫描目录，自动加载能用的适配器。这样做的好处很明显：

场景	传统方案	模块化方案
新增一个平台	修改测试框架核心代码，加一堆 #ifdef	丢一个新模块文件夹，配置 module.json，重启即用
更新底层库版本	全局替换，可能引起连锁回归	只升级对应模块，兼容性测试只需跑该模块的用例
禁用某个引擎	注释/删除代码，容易出错	删掉模块文件夹或修改 module.json 中 "enabled": false

3.3 可扩展：预留热插拔与版本兼容钩子

框架设计不能只满足今天。PKI行业协议在变——从X.509 v3到国标SM2，从CRL到OCSP，从RSA到后量子算法。如果框架写死了，三年后就要重写。

我一般预留三个扩展点：

1. 适配器工厂：根据运行时平台自动选择适配器。比如检测到系统是Windows且安装了CNG，就加载CNG适配器；否则回退到OpenSSL。
2. 协议版本兼容层：当新版本TLS或PKCS#12格式变化时，不用改适配器，而是在兼容层做版本路由。
3. 回调机制：允许测试用例注入自定义验证逻辑。比如某些客户的CA有自己的吊销规则，通过回调我们可以不改框架就支持。

// 伪代码：扩展点示例
public interface ICertValidator
{
    bool Validate(X509Certificate cert, ValidationOptions options);
}

// 默认实现
public class DefaultValidator : ICertValidator { ... }

// 可插拔：框架允许外部注册
ValidatorFactory.Register("SM2WithSM3", new SM2CertValidator());

你看，有了这三个扩展点，新算法、新平台、新业务逻辑都能在不改动框架骨架的情况下加入。说白了，好的框架像乐高——底座固定，上面的积木随你拼。

3.4 我在项目中踩过的坑

第一个平台跑通容易，第二个平台开始痛苦，第三个平台翻车。这是我做跨平台PKI测试的真实体会。

• 坑1：时间戳依赖。Windows的 CertCreateSelfSignCertificate 直接返回带时间戳的证书，而Android的 KeyStore 不帮你处理时间。适配器必须统一在抽象层补足时间参数。
• 坑2：私钥格式。OpenSSL喜欢PEM，Windows CNG用 NCryptKeyHandle，macOS用 SecKeyRef。适配层如果不做统一的私钥生命周期管理，测试用例里会频繁出现资源泄漏。
• 坑3：并发安全。某次我在Linux上用OpenSSL多线程签名，没加锁，结果段错误。模块化的适配器需要明确声明线程安全级别。

这些坑其实都可以通过框架设计来规避。比如私钥统一用 IKeyHandle 封装，内部使用引用计数；平台相关资源在适配器析构时自动释放。你想想看，如果这些逻辑分散在用例层，排查起来得多痛苦。