高可用系统测试不能只做单元测试单元测试之外还需验证依赖异常和发布回退测试范围应依据真实调用链选择。覆盖率说明哪些代码被测试执行过不能说明 Redis 切换、连接重建或依赖变慢时系统仍可用。高可用是整条调用链的属性需要把限流逻辑、真实依赖、发布回退和基础设施故障分开验证。测试范围来自架构与业务目标。先列出关键请求依赖哪些服务、允许多长时间、失败后是拒绝、降级还是转人工再选择单元、集成、负载和故障演练。没有统一的覆盖率或延迟数字能代替这份定义。第一层单元测试 —— 聚焦算法边界与并发状态机单元测试UT适合验证令牌桶、滑动窗口和状态机等局部逻辑并隔离网络与时钟。测试要快且可重复具体执行时间由项目规模决定。边界值、时钟回拨、窗口切换和并发竞争都应覆盖。下面示例使用实现的默认时钟只展示基本阈值更稳定的测试应注入可控时钟并增加窗口推进后的恢复断言。public class SlidingWindowRateLimiterTest { Test void shouldRefuseRequestWhenExceedingThresholdWithinWindow() { SlidingWindowRateLimiter limiter new SlidingWindowRateLimiter(10, 1000); // 1秒内限流 10 次 // 模拟 10 次成功请求 for (int i 0; i 10; i) { assertTrue(limiter.tryAcquire(), 前 10 次请求必须放行); } // 第 11 次请求必须被精准拒绝 assertFalse(limiter.tryAcquire(), 超过阈值的第 11 次请求必须被拦截); } }第二层集成测试 —— 基于真实依赖与流量仿真的熔断防线验证Resilience4j / Sentinel 的熔断阈值、超时和降级逻辑不能只停留在配置文件应通过集成测试观察状态转换与返回语义。Testcontainers可以启动与生产协议一致的 Redis 或数据库WireMock则模拟第三方 HTTP 的失败、延迟与错误内容。镜像版本、配置和测试数据要固定避免一次升级同时改变多个变量。下方代码说明故障响应与 Fallback 断言。调用次数、固定延迟和熔断状态都依赖测试配置实际用例应显式提供 CircuitBreaker 配置并等待可观察状态而不是假设某一次调用必然打开。捕获异常时也应断言预期类型不能吞掉所有失败。SpringBootTest Testcontainers class CircuitBreakerIntegrationTest { Autowired private PaymentClient paymentClient; Test void shouldTriggerCircuitBreakerWhenDependencyFails() { // WireMock 模拟下游支付接口连续 5 次返回 500 错误 stubFor(post(urlEqualTo(/pay)) .willReturn(aResponse().withStatus(500).withFixedDelay(2000))); // 发起 10 次调用观察熔断器状态转换 for (int i 0; i 5; i) { try { paymentClient.doPay(new PayRequest()); } catch (Exception ignored) {} } // 第 6 次调用时熔断器必须处于 OPEN 状态直接触发 Fast-Fail 并返回 Fallback PayResult result paymentClient.doPay(new PayRequest()); assertTrue(result.isFallback(), 熔断器未开启导致请求卡死); assertEquals(SYSTEM_BUSY, result.getErrorCode()); } }第三层端到端故障演练集成测试无法覆盖完整网络拓扑与编排行为。故障演练先在隔离或预发环境运行明确授权、影响范围、停止条件和恢复负责人。生产环境演练需要单独风险评审不能因为工具支持就直接执行。从可控场景开始网络延迟或丢包用于验证超时、重试与路由停止一个测试 Pod 可以观察服务发现和容量变化数据库切换则检查连接重建、事务结果和读写路由。每次只注入一种主要故障强度从小范围开始并保留自动终止时间。下面 YAML 的 namespace、标签、延迟和持续时间只是演示必须替换为专用测试目标并在执行前核对选择器。为避免示例误指业务默认命名空间这里将 selector 收到e2e-testing。# Chaos Mesh 故障注入配置示例模拟 Redis 节点网络延迟 apiVersion: chaos-mesh.org/v1alpha1 kind: NetworkChaos metadata: name: redis-latency-chaos namespace: e2e-testing spec: action: delay mode: one selector: namespaces: - e2e-testing labelSelectors: app: redis-cluster delay: latency: 1000ms jitter: 200ms direction: to duration: 5m高可用自动化测试卡点与演练 Checkist交付前确认核心限流与重试逻辑有边界测试集成层包含下游拒绝、超时和恢复并且 Fallback 不会伪造成功结果。预发演练核对服务发现、连接恢复、任务状态和旧版本回退性能容差由业务目标与容量基线确定。监控验收同时检查告警内容、路由和恢复通知。告警延迟目标由故障处置预算定义消息中保留服务、版本和请求关联信息不带凭据或完整业务数据。演练结束后确认故障已撤销、指标回到基线并把未通过项保留在发布风险清单中。