qa-ci-cd-testing
Skill31 starsChanged 48 days agoMITView on GitHub
当需要把测试集成到 CI/CD 流水线中、或者现有流水线的测试环节跑起来效率低不可靠时使用此技能。覆盖流水线各阶段的分层测试卡点设计(提交检查→单元测试→接口测试→UI 测试→回归测试)、工具集成策略和质量门禁配置。不要在 CI 里堆满慢的 UI 测试——而是构建测试金字塔:提交阶段跑最快的(<5min),合码阶段跑核心的(<15min),夜间跑全量的。 触发场景:CI/CD、持续测试、流水线测试、质量门禁、自动化回归、提交即测试、构建流水线需要加入测试环节时。 Use when the user asks about: integrating tests into a CI/CD pipeline — layered quality gates, fast commit-stage tests, and release blocking criteria.
In this repository50 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- qa-agent-testingSkill
- qa-ai-blindspot-compensationSkill
- qa-ai-context-engineeringSkill
- qa-ai-output-critiqueSkill
- qa-ai-prompt-strategySkill
- qa-api-testingSkill
- qa-boundary-deep-diveSkill
- qa-bug-lifecycleSkill
- qa-bug-reportingSkill
- qa-bug-root-cause-analysisSkill
- qa-code-review-for-testSkill
- qa-combination-strategySkill
- qa-critical-thinkingSkill
- qa-domain-modelingSkill
- qa-execution-observationSkill
- qa-expert-reviewSkill
- qa-exploratory-testingSkill
- qa-heuristic-checklistSkill
- qa-input-validationSkill
- qa-mobile-testingSkill
- qa-output-validationSkill
- qa-quality-metricsSkill
- qa-question-frameworkSkill
- qa-regression-testingSkill
- qa-release-risk-governanceSkill
- qa-req-deconstructionSkill
- qa-requirement-reviewSkill
- qa-retrospectiveSkill
- qa-risk-intuitionSkill
- qa-scenario-treeSkill
- qa-shift-leftSkill
- qa-shift-rightSkill
- qa-specialized-testingSkill
- qa-stakeholder-communicationSkill
- qa-state-transitionSkill
- qa-team-coachingSkill
- qa-tech-debt-managementSkill
- qa-tech-selectionSkill
- qa-testability-advocacySkill
- qa-test-automation-archSkill
- qa-test-case-designSkill
- qa-test-data-engineeringSkill
- qa-test-env-dataSkill
- qa-test-estimationSkill
- qa-test-leadershipSkill
- qa-test-reportingSkill
- qa-test-skillsSkill
- qa-test-strategy-designSkill
The file
Files
⚠️ 本技能单独使用效果有限,建议配合完整技能集(12 步工作流)使用。安装:npx skills add Kokxi/qa-test-skills
⚠️ 安全警告:本技能的示例可能涉及 CI/CD 流水线配置、发布操作和部署环境。 实际使用时请勿在未授权的生产环境执行发布或部署,先确认灰度策略和回滚方案。 本技能仅在 workspace/ 输出评估文件,不持久化、不外传、不跨会话复用。
持续测试实践
核心原则
测试左移(提前测试)、测试右移(线上验证)、快速反馈。
深度要求(参考值)
关键指标:根据项目复杂度设计质量门禁策略
| 复杂度 | 流水线阶段 | 质量门禁阈值 | 说明 |
| 简单项目 | 2-3个阶段 | 单元测试通过率≥80% | 标准CI流程 |
| 中等项目 | 4-5个阶段 | 单元≥90%+接口通过率≥95% | 含集成测试 |
| 复杂项目 | 6-8个阶段 | 全链路≥95%+性能阈值 | 含全量自动化+安全扫描 |
测试左移
左移策略
需求阶段:
├─ 需求评审:测试参与需求评审
├─ 验收标准:明确验收条件
├─ 可测试性:评估可测试性
└─ 测试计划:制定测试计划
开发阶段:
├─ 代码评审:测试视角的CR
├─ 单元测试:开发编写单元测试
├─ 接口测试:测试编写接口测试
└─ 冒烟测试:开发自测通过
集成阶段:
├─ 接口自动化:自动执行接口测试
├─ 集成测试:自动执行集成测试
└─ 冒烟测试:自动执行冒烟测试左移实践
实践1:需求可测试性评估
├─ 验收条件是否明确?
├─ 是否可自动化验证?
├─ 测试数据是否可准备?
└─ 测试环境是否可搭建?
实践2:代码评审检查点
├─ 业务逻辑是否正确?
├─ 异常处理是否完善?
├─ 日志记录是否完整?
└─ 测试代码是否同步?
实践3:单元测试覆盖
├─ 核心逻辑单元测试
├─ 分支覆盖
├─ 边界覆盖
└─ 异常覆盖测试右移
右移策略
发布阶段:
├─ 灰度发布:按比例放量
├─ 监控告警:实时监控
├─ 快速回滚:问题时快速回滚
└─ 线上验证:验证发布效果
线上阶段:
├─ 业务监控:业务指标监控
├─ 技术监控:技术指标监控
├─ 用户反馈:用户问题收集
└─ 混沌工程:主动注入故障右移实践
实践1:灰度发布
├─ 用户灰度:按用户比例
├─ 流量灰度:按流量比例
├─ 地域灰度:按地域
└─ 监控验证:实时监控
实践2:线上监控
├─ 业务监控:订单量、成功率
├─ 技术监控:错误率、响应时间
├─ 资源监控:CPU、内存、磁盘
└─ 告警通知:异常告警
实践3:混沌工程
├─ 故障注入:模拟故障
├─ 韧性验证:验证系统韧性
├─ 恢复测试:验证恢复能力
└─ 改进优化:持续改进加载时机
| 什么时候读 | 读哪个 |
| 设计流水线分层卡点时 | references/pipeline-design.md |
CI/CD 流水线设计的完整内容已下沉至references/pipeline-design.md,避免每次触发都占用上下文。
输出示例
团队需要将测试接入CI/CD流水线 → 设计流水线阶段:提交触发→单元测试→接口测试→UI测试→质量门禁→报告 → 左移:需求阶段定义验收标准,开发阶段推动单元测试 → 右移:灰度发布监控指标,线上质量监控告警
现有CI/CD测试效率低下(跑一次1小时) → 优化策略:分层并行执行、增量测试、智能用例筛选
检查清单
持续测试实践完成后检查:
- 测试左移是否实施?
- 测试右移是否规划?
- CI/CD流水线是否设计?
- 质量门禁是否定义?
- 工具选型是否完成?
- 监控告警是否配置?
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

