📚 课程目录第4章测试范围与目标定义

4. 测试范围与目标定义

4.1 为什么范围定义这么重要？

很多人一上来就开测，测到一半发现「诶，这个接口还没联调」，「那个模块没包含国产算法」。说白了，测试范围不清晰，后面全是补丁。我经历过一个银行核心系统改造项目，一开始没定义清楚范围，结果测试团队把整个外围系统都覆盖了，白白浪费三周人力。嗯，从那以后我每次启动测试，第一件事就是跟产品、研发坐在一起，把范围敲死。

我的经验：
范围定义不是一次性的。随着改造深入，会发现一些边界模块也需要测。所以我习惯用「增量迭代」的方式做范围确认——先定核心，再逐步扩展。

4.2 测试范围的核心维度

测试范围通常从下面四个维度去切。我一般用一个表格让团队填，一目了然。

维度	说明	优先级
系统边界	哪些子系统/模块涉及国密改造？比如签名验签服务、密钥管理、TLS协议栈。	高
接口类型	内部API、外部接口、硬件接口、文件交换接口。每个接口的密码算法调用点都要列出来。	高
数据流	哪些业务数据的生成、传输、存储经过了密码操作？比如交易报文、认证令牌、日志。	中
版本基线	是否只测最新版本？还是需要回测旧版本的兼容性？注意：有些系统升级后旧国密算法可能失效。	中

曾经踩过的坑：
有一次我们忽略了「硬件接口」这个维度。对方用的密码卡是USB直连，改造后换了新的密码卡驱动，结果原接口的负载均衡策略完全失效。测试时没覆盖到硬件信号层面，上线第一天就宕机了。

4.3 测试目标的拆解

范围定好之后，得把目标说清楚。我不喜欢写那种「验证系统功能正确」的废话。我习惯把目标拆成三层：

基础通过性——密码算法替换后，原有业务流程能跑通。这是底线。
互操作性——A系统用SM2签名，B系统用SM2验签，能成功交互。这是核心。
异常容错性——算法协商失败、密钥过期、证书链断裂等场景下，系统能优雅降级或报错，而不是直接崩溃。

你想想看，如果目标只写到「通过性」，那互操作测试就变成简单的冒烟测试了。我建议每个目标后面附带一个量化指标，比如「SM4加密解密延迟增加不超过10ms」。

4.4 我的个人经验：怎么避免范围失控

范围失控是国密改造项目最常见的问题。我分享三个实用方法：

画一张依赖图——把参与互操作的系统和组件画成节点，连线表示接口调用。只测图中灰色（已改造）与白色（未改造但需要交互）的连线。纯白色节点之间不用测。
搞一个「范围确认清单」——每次新增测试用例前，必须回答三个问题：这个用例属于哪个维度？优先级是多少？有没有对应的业务场景？不回答就不加。
设一个「范围冻结点」——集成测试开始前一周，所有人签字确认范围。之后要加，走变更流程。这个办法能倒逼前期想清楚。

关键判断：

测试范围不是越全越好。一个系统有100个接口，如果只有5个用到了国密算法，那其他95个接口只需要做回归，不需要做互操作测试。把精力放在那5个上。

4.5 范围定义决策流程

下面是我自己用的一个流程。它帮我在多个项目中理清了测试范围与目标。你看完应该能直接用。

4.6 几个常见坑

坑1：「所有系统都要测」的陷阱
有人觉得国密改造是全量替换，所以所有系统都要测互操作。其实很多边缘系统只改了个配置文件，核心算法根本没动。我遇到过一家公司把几十个微服务全列进范围，结果发现其中40%根本没用到密码功能。浪费了大量时间。

坑2：忽略第三方依赖
你的系统可能调用云服务商的国密API，或者使用了开源的密码库。这些依赖的版本、算法支持的细节往往不在你控制范围内。我在一个项目中没测「云签名服务」的SM2签名，结果对方改版后签名格式不兼容，回滚了一整个版本。

避坑提示：
把第三方依赖单独列一个「外部接口范围」子清单，提前获取对方的测试环境或仿真桩。如果没有，至少要到最新的接口文档和算法参数配置。

范围与目标定义到位，测试就成功了一半。剩下的一半，靠的是执行过程中的变通和复盘。我个人习惯每两天看一眼范围清单，确认有没有漏项或者过度覆盖。记住：宁缺毋滥，精准打击。