Qa Ci Cd Testing

SKILL.md

---
name: qa-ci-cd-testing
version: 1.6.0
description: >-
  当需要把测试集成到 CI/CD 流水线中、或者现有流水线的测试环节跑起来效率低不可靠时使用此技能。覆盖流水线各阶段的分层测试卡点设计（提交检查→单元测试→接口测试→UI 测试→回归测试）、工具集成策略和质量门禁配置。不要在 CI 里堆满慢的 UI 测试——而是构建测试金字塔：提交阶段跑最快的（<5min），合码阶段跑核心的（<15min），夜间跑全量的。

when_to_use: 用户说"CI/CD"、"持续测试"、"流水线测试"、"质量门禁"、"自动化回归"、"提交即测试"、需要设计CI/CD测试流程、构建流水线需要加入测试环节时
allowed-tools: Read Grep Glob Bash
related_skills:
  upstream:
    - qa-tech-selection          # 输入：技术选型确定工具栈
    - qa-test-strategy-design    # 输入：测试策略确定自动化范围
  downstream:
    - qa-release-risk-governance # 输出：CI/CD流程支持发布
    - qa-shift-right
input_format:
  required:
    - name: 测试策略
      type: object
      description: 来自qa-test-strategy-design的测试策略
    - name: 自动化架构
      type: object
      description: 来自qa-test-automation-arch的自动化架构
  optional:
    - name: 流水线配置
      type: string
      description: CI/CD流水线配置信息
output_format:
  traceability:
    - 每条流水线带唯一ID（PIPE-XXXX）
  structure:
    - pipeline_design: CI/CD流水线设计
    - test_stages: 各阶段测试配置
    - quality_gates: 质量门禁设置
    - feedback_loops: 反馈循环机制
categories: ['Development','Testing','DevOps']
depth_requirement_quantification:
  reference_value: "根据流水线复杂度调整设计深度：简单×1/中等×2/复杂×3"
  minimum: "至少覆盖提交检查、接口测试、回归测试3个卡点"
error_recovery_guidance:
  on_failure: "流水线测试卡点失败时回退到测试策略调整范围"
  retry_behavior: "调整测试范围或工具后重新配置卡点"
---
> **⚠️ 安全警告**：本技能的示例可能涉及 CI/CD 流水线配置、发布操作和部署环境。
> 实际使用时请勿在未授权的生产环境执行发布或部署，先确认灰度策略和回滚方案。
> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

# 持续测试实践

## 核心原则

测试左移（提前测试）、测试右移（线上验证）、快速反馈。

## 深度要求（参考值）

**关键指标**：根据项目复杂度设计质量门禁策略

| 复杂度 | 流水线阶段 | 质量门禁阈值 | 说明 |
|--------|-----------|-------------|------|
| 简单项目 | 2-3个阶段 | 单元测试通过率≥80% | 标准CI流程 |
| 中等项目 | 4-5个阶段 | 单元≥90%+接口通过率≥95% | 含集成测试 |
| 复杂项目 | 6-8个阶段 | 全链路≥95%+性能阈值 | 含全量自动化+安全扫描 |

## 测试左移

### 左移策略

```text
需求阶段：
├─ 需求评审：测试参与需求评审
├─ 验收标准：明确验收条件
├─ 可测试性：评估可测试性
└─ 测试计划：制定测试计划

开发阶段：
├─ 代码评审：测试视角的CR
├─ 单元测试：开发编写单元测试
├─ 接口测试：测试编写接口测试
└─ 冒烟测试：开发自测通过

集成阶段：
├─ 接口自动化：自动执行接口测试
├─ 集成测试：自动执行集成测试
└─ 冒烟测试：自动执行冒烟测试
```

### 左移实践

```text
实践1：需求可测试性评估
├─ 验收条件是否明确？
├─ 是否可自动化验证？
├─ 测试数据是否可准备？
└─ 测试环境是否可搭建？

实践2：代码评审检查点
├─ 业务逻辑是否正确？
├─ 异常处理是否完善？
├─ 日志记录是否完整？
└─ 测试代码是否同步？

实践3：单元测试覆盖
├─ 核心逻辑单元测试
├─ 分支覆盖
├─ 边界覆盖
└─ 异常覆盖
```

## 测试右移

### 右移策略

```text
发布阶段：
├─ 灰度发布：按比例放量
├─ 监控告警：实时监控
├─ 快速回滚：问题时快速回滚
└─ 线上验证：验证发布效果

线上阶段：
├─ 业务监控：业务指标监控
├─ 技术监控：技术指标监控
├─ 用户反馈：用户问题收集
└─ 混沌工程：主动注入故障
```

### 右移实践

```text
实践1：灰度发布
├─ 用户灰度：按用户比例
├─ 流量灰度：按流量比例
├─ 地域灰度：按地域
└─ 监控验证：实时监控

实践2：线上监控
├─ 业务监控：订单量、成功率
├─ 技术监控：错误率、响应时间
├─ 资源监控：CPU、内存、磁盘
└─ 告警通知：异常告警

实践3：混沌工程
├─ 故障注入：模拟故障
├─ 韧性验证：验证系统韧性
├─ 恢复测试：验证恢复能力
└─ 改进优化：持续改进
```

## CI/CD 流水线设计

### 流水线阶段

```text
代码提交 → 代码检查 → 单元测试 → 接口测试 → 集成测试 → 部署 → 冒烟测试 → 灰度发布 → 全量发布

各阶段职责：
├─ 代码提交：提交代码
├─ 代码检查：静态代码分析
├─ 单元测试：执行单元测试
├─ 接口测试：执行接口测试
├─ 集成测试：执行集成测试
├─ 部署：部署到测试环境
├─ 冒烟测试：执行冒烟测试
├─ 灰度发布：按比例发布
└─ 全量发布：全量发布
```

### 质量门禁

```text
门禁标准：
├─ 代码检查
│   ├─ 代码规范：无严重违规
│   ├─ 代码重复：< 5%
│   └─ 圈复杂度：< 10
│
├─ 单元测试
│   ├─ 覆盖率：≥ 80%
│   ├─ 通过率：100%
│   └─ 执行时间：< 5分钟
│
├─ 接口测试
│   ├─ 覆盖率：≥ 90%
│   ├─ 通过率：100%
│   └─ 执行时间：< 10分钟
│
├─ 集成测试
│   ├─ 通过率：100%
│   └─ 执行时间：< 30分钟
│
└─ 冒烟测试
    ├─ 通过率：100%
    └─ 核心功能：全部通过
```

### 工具选型

```text
├─ 代码管理
│   ├─ Git：版本控制
│   └─ GitLab/GitHub：代码托管
│
├─ CI/CD工具
│   ├─ Jenkins：开源、灵活
│   ├─ GitLab CI：集成度高
│   ├─ GitHub Actions：云端友好
│   └─ CircleCI：云端CI
│
├─ 测试工具
│   ├─ JUnit/TestNG：单元测试
│   ├─ Pytest：Python测试
│   ├─ Postman/Newman：接口测试
│   └─ Selenium/Playwright：UI测试
│
└─ 报告工具
    ├─ Allure：测试报告
    ├─ SonarQube：代码质量
    └─ Grafana：监控可视化
```

## 输出示例

**团队需要将测试接入CI/CD流水线**
→ 设计流水线阶段：提交触发→单元测试→接口测试→UI测试→质量门禁→报告
→ 左移：需求阶段定义验收标准，开发阶段推动单元测试
→ 右移：灰度发布监控指标，线上质量监控告警

**现有CI/CD测试效率低下（跑一次1小时）**
→ 优化策略：分层并行执行、增量测试、智能用例筛选

## 检查清单

持续测试实践完成后检查：
- [ ] 测试左移是否实施？
- [ ] 测试右移是否规划？
- [ ] CI/CD流水线是否设计？
- [ ] 质量门禁是否定义？
- [ ] 工具选型是否完成？
- [ ] 监控告警是否配置？