比如营销活动的服务器的部署规格：
部署规格
CPU：0.001~4 (Core)
内存：16384~16384(Mb)
6个POD
测试要点：单个pod的性能指标摸底，6Pod 集群峰值容量测试，6Pod 集群 72 小时稳定性测试，6Pod 集群容灾测试（Pod 故障场景）
用例 1：单 Pod 极限性能摸底测试
- 用例编号：PT-MARKET-001
- 测试目的：确认单 Pod 性能天花板，验证单 Pod 4 核 CPU/16GB 内存规格是否满足基础业务需求
- 前置条件：1. 仅启动 1 个营销服务 Pod（暂停其余 5 个）；2. Pod 资源限制生效（CPU≤4Core、内存 = 16GB）；3. 依赖服务（MQ/DB）正常运行；4. 清空测试环境历史数据
- 测试步骤：
- 启动监控工具，实时采集单 Pod CPU、内存使用率，接口 QPS、响应时间、错误率
- 按梯度加压：初始并发用户数 [填写，如 50]，每 5 分钟递增 [填写，如 20]，直至触发资源上限（CPU 达 4Core 或内存达 16GB）或接口错误率超标
- 每个梯度稳定运行 3 分钟，记录对应指标数据
- 达到极限后，维持极限压力运行 5 分钟，观察是否崩溃、报错
- 停止加压，恢复空载运行 3 分钟，观察资源是否回落
- 预期结果：
- 单 Pod 极限 QPS、响应时间达到业务预期值
- 极限压力下 CPU≤90%、内存≤80%，无触达上限，无 OOM/CPU 节流
- 极限压力下接口错误率≤0.1%，服务不崩溃、不重启
- 空载后 CPU、内存快速回落至初始水平（波动≤5%）
- 实际结果：[测试后填写]
- 测试结论：[通过 / 不通过]
用例 2：6Pod 集群峰值容量测试（核心业务场景）
- 用例编号：PT-MARKET-002
- 测试目的：验证 6 个 Pod 集群能否承接业务峰值流量，资源利用率合理且负载均匀
- 前置条件：1. 启动 6 个营销服务 Pod，负载均衡生效；2. 所有 Pod 资源限制正常；3. 依赖服务按生产规格部署；4. 准备业务峰值流量对应的测试数据
- 测试步骤：
- 启动监控工具，采集 6 个 Pod 的 CPU、内存，集群整体 QPS、响应时间、错误率
- 加压策略：分 3 阶段加压，每阶段稳定运行 10 分钟
- 阶段 1：业务日常流量（预期 QPS 的 50%）
- 阶段 2：业务高峰流量（预期 QPS 的 80%）
- 阶段 3：业务峰值流量（100% 预期 QPS），额外预留 10% 峰值冗余加压
- 每个阶段记录集群指标 + 单个 Pod 指标，重点核对负载均匀性
- 峰值压力下维持 15 分钟，观察指标稳定性
- 预期结果：
- 集群峰值 QPS、响应时间、错误率均达标（符合基准指标）
- 所有 Pod CPU 使用率：日常≤70%、峰值≤90%，无触达 4Core 上限
- 所有 Pod 内存使用率全程≤80%，无波动超标
- 6 个 Pod CPU / 内存使用率偏差≤20%，负载均衡有效
- 集群性能损耗率≤15%（6Pod 总 QPS ≥ 单 Pod 极限 QPS×6×85%）
- 全程服务无崩溃、无重启，依赖服务无异常
- 实际结果：[测试后填写]
- 测试结论：[通过 / 不通过]
用例 3：6Pod 集群 72 小时稳定性测试
- 用例编号：PT-MARKET-003
- 测试目的：验证集群在长时间高负载下的稳定性，排查内存泄露、资源耗尽等隐性问题
- 前置条件：1. 6 个 Pod 正常运行，负载均衡生效；2. 监控工具支持长时间采集（如 Prometheus+Grafana）；3. 压力维持业务高峰流量（预期 QPS 的 80%）
- 测试步骤：
- 启动监控，开启全量指标采集（每 1 分钟记录 1 次数据）
- 施加业务高峰压力，持续运行 72 小时（可按需求调整为 24/48 小时）
- 期间每 12 小时巡检 1 次：记录集群指标、单个 Pod 资源使用、服务是否重启、错误率是否超标
- 72 小时后停止加压，观察资源是否正常回落
- 预期结果：
- 72 小时内集群 QPS、响应时间、错误率稳定，无大幅波动（波动≤10%）
- 所有 Pod CPU 使用率稳定≤75%，无持续上涨
- 所有 Pod 内存使用率稳定≤80%，无持续上涨（无内存泄露），波动≤5%
- 期间无 Pod 崩溃、无服务重启，依赖服务无异常
- 停止加压后，CPU、内存快速回落至空载水平
- 实际结果：[测试后填写]
- 测试结论：[通过 / 不通过]
用例 4：6Pod 集群容灾测试（Pod 故障场景）
- 用例编号：PT-MARKET-004
- 测试目的：验证集群在部分 Pod 故障时，剩余 Pod 能否承接流量，保障服务高可用
- 前置条件：1. 6 个 Pod 正常运行，施加业务高峰压力（预期 QPS 的 80%）；2. 集群指标稳定达标；3. 支持手动删除 Pod（kubectl delete pod）
- 测试步骤：
- 施加业务高峰压力，待集群指标稳定（运行 5 分钟），记录基准数据
- 故障场景 1（轻度故障）：手动删除 1 个 Pod，观察集群自愈（K8s 自动重建）及指标变化，稳定运行 10 分钟
- 故障场景 2（中度故障）：自愈完成后，再手动删除 2 个 Pod（剩余 3 个），稳定运行 10 分钟
- 故障场景 3（极限故障）：自愈完成后，再删除 1 个 Pod（剩余 2 个），稳定运行 10 分钟
- 每个场景记录：集群 QPS、响应时间、错误率，剩余 Pod 资源使用率
- 测试结束后，恢复 6 个 Pod，验证集群指标是否回归正常
- 预期结果：
- 轻度故障（剩 5Pod）：集群 QPS 不下降，响应时间、错误率达标；剩余 Pod CPU≤90%、内存≤80%，负载均匀
- 中度故障（剩 3Pod）：集群 QPS 不低于峰值的 80%，响应时间≤预期 1.2 倍，错误率≤0.3%；剩余 Pod CPU≤95%、内存≤85%，无崩溃
- 极限故障（剩 2Pod）：服务不中断，核心接口正常响应，错误率≤1%（非核心接口可放宽）
- Pod 故障后，K8s 自动重建，重建后 Pod 快速接入集群，指标恢复正常
- 恢复 6Pod 后，集群指标回归基准水平
- 实际结果：[测试后填写]
- 测试结论：[通过 / 不通过]
