集成测试目标与范围
好，这一章我们来聊聊集成测试的目标和范围。说实话，很多团队做集成测试时容易走极端——要么测得太浅，只验证了接口通不通；要么测得太深，把单元测试的活都干了。怎么把握这个度？我这些年踩过不少坑，今天把经验摊开讲。
我们为什么要做集成测试
KMS和国密算法模块，说白了就是两个独立的系统。KMS管密钥的存、取、轮转、销毁；国密管SM2签名验签、SM3摘要、SM4加解密。它们通过API对接，但中间有很多隐性契约——比如密钥格式、异常码定义、性能基线。不搞集成测试，这些契约出了问题，上线后就是事故。
我记得有一次，项目里KMS返回的SM2公钥是未压缩格式，但业务方默认用了压缩格式去验签。前后端各自单元测试都通过，一联调就崩。这就是集成测试没覆盖到格式协议的典型例子。
集成测试的核心目标
目标其实就三个维度：功能正确、性能达标、异常可靠。我们逐个看。
- 功能正确：接口返回的数据结构、状态码、错误信息必须和国密规范一致。好比SM3摘要长度固定32字节，多一个少一个都不行。
- 性能达标：国密算法计算量比国际算法大，尤其SM2验签和SM4多段加密。你要测出吞吐量和延迟的基线，看看你的KMS能不能扛得住业务峰值。
- 异常可靠：密钥过期、算法不匹配、输入数据损坏……这些场景必须有明确的错误返回，不能把异常传成崩溃或者静默失败。
一句话总结：集成测试要验证的是“两个系统拼在一起后，对外提供的服务是否满足预期”。不是单测的重复，也不是端到端的替代。
测试范围的界定
范围这东西，我建议从两个维度切：接口维度和密钥生命周期维度。
| 维度 | 测试项 | 关键点 |
|---|---|---|
| 接口维度 | SM2签名/验签、SM2加密/解密、SM3摘要、SM4 ECB/CBC加解密、国密密钥生成与导入 | 入参格式、出参结构、状态码、超时策略 |
| 密钥生命周期维度 | 密钥创建 → 启用 → 使用 → 轮转 → 禁用 → 销毁 | 每个状态切换时的算法可用性、前后状态一致性 |
| 算法兼容性维度 | SM2曲线参数、SM4填充模式（PKCS7/NoPadding）、SM3的大端小端 | 不同库实现可能有差异，需要交叉验证 |
你可能要问：要测多少种组合？嗯，别贪多。我建议优先覆盖 常用算法 + 边界值 + 异常流，把精力花在刀刃上。
关键测试维度
我再展开说说几个容易遗漏的维度。
- 数据流完整性：比如SM4加密后，KMS返回的密文能不能原样传给另一个模块解密？中间有没有截断或编码转换？我在项目中遇到过base64编码问题，密文丢了最后的等号，解密直接失败。
- 并发与资源隔离：KMS通常被多个业务调用。你需要测多线程并发请求时，国密算法的上下文是否被污染。SM3有上下文对象，线程不安全就会出乱子。
- 混合算法场景：有些业务会先拿SM2加密通信密钥，再用SM4加密数据。集成测试要覆盖这种“套娃”场景，确保中间结果的格式可以衔接。
避坑指南：我曾经在测试SM4 CBC模式时，没注意IV的初始向量长度必须是16字节。KMS的默认IV生成策略和业务方用的库不一样，结果加密出来的密文，对方解密就是乱码。所以，任何非对称密钥的传递细节——IV、填充模式、编码格式——都要在测试用例里显式写出来。
测试环境与数据准备
环境要尽可能贴近生产。我建议至少准备两套：开发联调环境（可以随时重装）和预发环境（和生产的硬件/网络一致）。测试数据要用国密标准的测试向量，别自己瞎编。SM2签名验签可以用GB/T 32918里的示例，SM3用RFC 6979的已知值，SM4用GMT 0002附录里的测试数据。
下面这张图帮你理清集成测试的范围与目标之间的关系——
这张图你应该能看明白：三个目标（功能、性能、异常）驱动三个测试范围（接口、生命周期、兼容性）。范围定了，用例设计才不会跑偏。
个人经验：每次做集成测试前，我会先列一张“接口契约清单”，把每个国密算法的入参、出参、错误码、默认值都写清楚。这份清单既是测试用例的骨架，也是后期排查问题的字典。你试试看，能省很多返工的时间。
最后提醒一句：范围不要贪大。你不可能一次把所有算法、所有模式、所有密钥状态都测全。优先覆盖核心业务链路（比如用户注册时的SM2签名、数据传输时的SM4加密），再按风险等级逐步扩展。集成测试是个迭代过程，不是一锤子买卖。