测试右移

当功能已经上线了但还担心线上质量、或者需要设计灰度发布后的验证方案时使用此技能。通过生产监控（APM/日志/用户反馈）、线上巡检拨测、A/B 验证和混沌工程将测试延伸到生产环境。不要把上线当成终点——用户在生产环境的使用方式是永远测不全的。输出右移验证方案（灰度监控指标 + 拨测用例 + 告警阈值 + 回滚触发条件）。本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills

kokxi@kokxi

Install

openclaw skills install @kokxi/qa-shift-right

⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

测试右移实践

核心原则

测试右移——在生产环境验证质量，持续监控和改进。

⚠️ 安全警告：使用本技能前必须确认以下条件

生产环境操作: 本技能涉及灰度发布、线上监控、混沌工程等生产环境操作。执行前必须获得团队/组织的明确书面授权。

用户隐私: 涉及用户行为分析、埋点数据收集时，必须确保已获得用户知情同意，并符合数据保护法规（如GDPR/PIPL）要求。

爆炸半径控制: 混沌工程实验必须先在小范围（非生产/影子环境）验证，逐步扩大。必须设置熔断机制和自动回滚，确保故障影响在可控范围内。

回滚预案: 任何灰度发布必须预先准备回滚方案，定义明确的回滚触发条件（错误率、业务指标异常阈值），并确保回滚流程经过演练。

禁止场景: 禁止在生产环境直接执行未经审批的混沌实验、禁止在未告知用户的情况下收集行为数据、禁止在无回滚方案的情况下全量发布。

右移阶段

阶段1：灰度发布

📌 本节与 qa-release-risk-governance「灰度策略设计」内容同步，修改时请同步更新两处。

text

灰度策略：
├─ 用户灰度
│   ├─ 内部员工 → 白名单用户 → 10% → 50% → 100%
│   ├─ 适用：新功能、高风险功能
│   └─ 监控：业务指标、错误率、用户反馈
│
├─ 流量灰度
│   ├─ 1% → 10% → 30% → 50% → 100%
│   ├─ 适用：性能优化、算法变更
│   └─ 监控：性能指标、资源使用
│
├─ 地域灰度
│   ├─ 某城市 → 某省份 → 全国
│   ├─ 适用：地域性功能
│   └─ 监控：地域指标、用户反馈
│
└─ 时间灰度
    ├─ 低峰期 → 高峰期
    ├─ 适用：定时任务、批处理
    └─ 监控：执行结果、资源使用

灰度监控

text

监控指标：
├─ 业务指标
│   ├─ 订单量/交易量
│   ├─ 转化率/成功率
│   └─ 用户活跃度
│
├─ 技术指标
│   ├─ 错误率/异常率
│   ├─ 响应时间/吞吐量
│   └─ 资源使用率
│
└─ 用户反馈
    ├─ 投诉量
    ├─ 客服咨询量
    └─ 社交媒体反馈

灰度回滚

text

回滚条件：
├─ 业务指标异常
│   ├─ 订单量下降 > 20%
│   ├─ 成功率下降 > 5%
│   └─ 用户投诉增加 > 50%
│
├─ 技术指标异常
│   ├─ 错误率 > 1%
│   ├─ 响应时间增加 > 50%
│   └─ CPU/内存使用率 > 80%
│
└─ 用户反馈异常
    ├─ 投诉量激增
    └─ 负面舆情

阶段2：线上监控

text

监控体系：
├─ 业务监控
│   ├─ 核心业务指标
│   ├─ 业务流程监控
│   └─ 业务异常告警
│
├─ 技术监控
│   ├─ 应用性能监控（APM）
│   ├─ 基础设施监控
│   ├─ 日志监控
│   └─ 链路追踪
│
└─ 用户体验监控
    ├─ 前端性能监控
    ├─ 用户行为分析
    └─ 用户反馈收集

监控工具

text

├─ APM工具
│   ├─ SkyWalking
│   ├─ Pinpoint
│   ├─ Jaeger
│   └─ Zipkin
│
├─ 日志工具
│   ├─ ELK Stack
│   ├─ Loki
│   └─ Splunk
│
├─ 告警工具
│   ├─ Prometheus + Alertmanager
│   ├─ Grafana
│   └─ PagerDuty
│
└─ 用户体验工具
    ├─ 前端监控：Sentry
    ├─ 用户行为：Mixpanel
    └─ 用户反馈：Hotjar

阶段3：混沌工程

text

混沌工程原则：
├─ 稳态假设：系统在故障下应保持稳态
├─ 爆炸半径：控制故障影响范围
├─ 持续实验：持续验证系统韧性
└─ 自动化：自动化故障注入和恢复

故障类型：
├─ 基础设施故障
│   ├─ 网络延迟/丢包
│   ├─ 节点宕机
│   ├─ 磁盘故障
│   └─ CPU/内存压力
│
├─ 应用层故障
│   ├─ 服务不可用
│   ├─ 接口超时
│   ├─ 数据库故障
│   └─ 缓存故障
│
└─ 业务层故障
    ├─ 第三方服务故障
    ├─ 数据不一致
    └─ 流量突增

混沌工程工具

text

├─ Chaos Monkey
│   ├─ 用途：随机终止实例
│   ├─ 适用：AWS环境
│   └─ 特点：Netflix开源
│
├─ Chaos Mesh
│   ├─ 用途：Kubernetes故障注入
│   ├─ 适用：K8s环境
│   └─ 特点：功能全面
│
├─ Litmus
│   ├─ 用途：云原生混沌工程
│   ├─ 适用：K8s环境
│   └─ 特点：CNCF项目
│
└─ Gremlin
    ├─ 用途：商业混沌工程平台
    ├─ 适用：多云环境
    └─ 特点：企业级支持

输出示例

功能发布后需要验证线上质量 → 右移实践：

灰度发布：5%用户→24小时→逐步全量
线上监控：接口错误率、页面性能、用户行为埋点
混沌工程：模拟支付服务故障，验证降级策略

用户说"上线后出了问题怎么办" → 启动测试右移：灰度策略+监控+混沌工程+回滚方案全套方案

检查清单

测试右移实施后检查：