第 18 章 —— 多层测试证据的适用范围

本章目标： 本章完成后，开发者能够为领域端口、真实 Runtime、多节点协议和网络黑盒分别选择证据，并拒绝用较低层绿灯替代较高层验收。

学习目标

1. 建立 E1—E4 测试证据阶梯。
2. 为每层写出环境、固定 revision、已证明与未证明事项。
3. 区分真实集合实现、受控 fake membership 和真实网络端口。
4. 为三类集合安排最小但不失真的验证组合。

前置条件

• 已完成第 15 章书籍案例与第 16—17 章装配/隔离。
• 已运行第 14 章 chaos 测试。
• 不把 test count 当作生产就绪分数。

案例进度

履约团队已有领域测试、单 Runtime 测试和 chaos 测试。发布评审追问：「这些绿灯是否证明真实端口、客户端协议与进程隔离？」团队不再回答笼统的「测试覆盖了」，而是按证据层逐项陈述。

证据强度是适用范围，不是积分

E4 比 E3 更接近部署现实，但依然不是生产就绪分数。生产网络拓扑、容量、权限、告警与运维流程仍要单独验收。

三类集合的最小证据组合

Register

• E1：业务把 route hint 当可重建提示，不当订单事实。
• E2：put/get/remove、resolver、ChangeStream overflow。
• E3：双节点 delta、tombstone、schema mismatch、repair。
• E4：第 23 章 Redis-shaped lab 通过真实 TCP 端口观察复制窗口。

Lease

• E1：领域结果保留 uncertain、reason 与 fencing token。
• E2：acquire/transfer 后旧 token 被 guard 拒绝。
• E3：autonomous dual holder 与 quorum fail closed。
• E4：外部受保护资源实际校验 token；本书只提供边界，不冒充现成业务系统。

CRDT

• E1：计数只用于运行观察，不作为计费事实。
• E2：单 Runtime merge 与代数性质样例。
• E3：多节点本地更新、重复/乱序与 repair 收敛。
• E4：客户端协议是否暴露该状态，取决于具体应用，不由 CRDT 单元测试证明。

证据卡需要固定四类信息

每次记录至少包含：

1. 环境与 revision：运行在哪个源码与 JDK/Maven 环境。
2. 输入/故障：实际注入了什么，不用「模拟异常」含糊带过。
3. 观察结果：test 数、失败、错误、跳过及关键行为。
4. 未证明事项：下一层仍要回答什么。

Skipped 和 Tests run: 0 不是通过；只编译成功也不是行为证据。

反例与故障注入

• 给 Maven 指定不存在的 test，并关闭 failIfNoSpecifiedTests 门禁，观察「构建成功但 0 test」的假绿。
• 用 fake port 的 E1 结果宣称网络 repair 通过，指出缺少的执行面。
• 用受控多节点 E3 结果宣称真实 TCP 客户端协议兼容，指出进程/端口证据缺口。
• 只写「全部通过」但不记录 revision，观察结论如何无法复现。

实验

先运行书籍自有 E1/E2：

cd examples/order-fulfillment-control-plane
mvn clean test

再运行固定源码 E2/E3：

cd submodule/dsm
mvn -q -pl dsm-integration-test -am \
  -Dtest=RuntimeIntegrationTest,TwoNodeIntegrationTest,ChaosIntegrationTest \
  -Dsurefire.failIfNoSpecifiedTests=false test

用 evidence-ladder.json 核对每一层的 proves 与 doesNotProve 都非空。

实验验收卡

回顾

• 测试等级描述执行面，不是质量积分。
• 每层都需要写已证明和未证明事项。
• fake、单 Runtime、多节点 chaos、真实端口不能互相替代。
• 先固定 revision 和失败输入，再谈绿色结果。

下一步

第五篇进入运行责任：第 19 章先建立 diagnostics、metrics 和 trace 观察面，让分布式差异可以被定位。

证据链接

• DSM examples：Spring Boot 应用测试
• RuntimeIntegrationTest
• TwoNodeIntegrationTest
• ChaosIntegrationTest