qa-testing-strategy
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseQA Testing Strategy (Jan 2026)
QA测试策略（2026年1月）
Risk-based quality engineering strategy for modern software delivery.
Core references: curated links in (SLOs/error budgets, contracts, E2E, OpenTelemetry). Start with for a compact, navigable overview.
data/sources.jsonreferences/operational-playbook.md面向现代软件交付的基于风险的质量工程策略。
核心参考资料：中整理的链接（SLO/错误预算、契约、E2E、OpenTelemetry）。可先查看获取简洁的导航式概述。
data/sources.jsonreferences/operational-playbook.mdScope
适用范围
- Create or update a risk-based test strategy (what to test, where, and why)
- Define quality gates and release criteria (merge vs deploy)
- Select the smallest effective layer (unit → integration → contract → E2E)
- Make failures diagnosable (artifacts, logs/traces, ownership)
- Operationalize reliability (flake SLO, quarantines, suite budgets)
- 创建或更新基于风险的测试策略（测试内容、测试场景及原因）
- 定义质量门禁和发布标准（合并代码 vs 部署上线的要求）
- 选择最有效的测试层级（单元→集成→契约→E2E）
- 确保故障可诊断（提供制品、日志/链路追踪、明确责任人）
- 落地可靠性管理（不稳定测试SLO、隔离机制、测试套件预算）
Use Instead
替代方案
| Need | Skill |
|---|---|
| Debug failing tests or incidents | qa-debugging |
| Test LLM agents/personas | qa-agent-testing |
| Perform security audit/threat model | software-security-appsec |
| Design CI/CD pipelines and infra | ops-devops-platform |
| 需求场景 | 对应技能 |
|---|---|
| 调试失败的测试或事件 | qa-debugging |
| 测试LLM Agent/角色 | qa-agent-testing |
| 执行安全审计/威胁建模 | software-security-appsec |
| 设计CI/CD流水线和基础设施 | ops-devops-platform |
Quick Reference
速查参考
| Test Type | Goal | Typical Use |
|---|---|---|
| Unit | Prove logic and invariants fast | Pure functions, core business rules |
| Component | Validate UI behavior in isolation | UI components and state transitions |
| Integration | Validate boundaries with real deps | API + DB, queues, external adapters |
| Contract | Prevent breaking changes cross-team | OpenAPI/AsyncAPI/JSON Schema/Protobuf |
| E2E | Validate critical user journeys | 1–2 “money paths” per product area |
| Performance | Enforce budgets and capacity | Load, stress, soak, regression trends |
| Visual | Catch UI regressions | Layout/visual diffs on stable pages |
| Accessibility | Automate WCAG checks | axe smoke + targeted manual audits |
| Security | Catch common web vulns early | DAST smoke + critical checks in CI |
| 测试类型 | 目标 | 典型场景 |
|---|---|---|
| 单元测试 | 快速验证逻辑和不变量 | 纯函数、核心业务规则 |
| 组件测试 | 隔离验证UI行为 | UI组件和状态转换 |
| 集成测试 | 验证与真实依赖的边界交互 | API+数据库、消息队列、外部适配器 |
| 契约测试 | 跨团队防止破坏性变更 | OpenAPI/AsyncAPI/JSON Schema/Protobuf |
| E2E测试 | 验证关键用户路径 | 每个产品域1-2条“核心业务路径” |
| 性能测试 | 执行预算和容量验证 | 负载、压力、稳定性、回归趋势测试 |
| 视觉测试 | 捕获UI回归问题 | 稳定页面的布局/视觉差异对比 |
| 可访问性测试 | 自动化WCAG合规检查 | axe工具快速扫描+针对性人工审计 |
| 安全测试 | 尽早发现常见Web漏洞 | DAST快速扫描+CI中执行关键检查 |
Default Workflow
默认工作流
- Clarify scope and risk: critical journeys, failure modes, and non-functional risks (latency, data loss, auth).
- Define quality signals: SLOs/error budgets, contract/schema checks, and what blocks merge vs blocks deploy.
- Choose the smallest effective layer (unit → integration → contract → E2E).
- Make failures diagnosable: artifacts + correlation IDs (logs/traces/screenshots), clear ownership, deflake runbook.
- Operationalize: flake SLO, quarantine with expiry, suite budgets (PR gate vs scheduled), dashboards.
- 明确范围和风险：关键用户路径、故障模式、非功能性风险（延迟、数据丢失、认证）。
- 定义质量信号：SLO/错误预算、契约/ schema检查，区分代码合并和部署上线的阻塞条件。
- 选择最有效的测试层级（单元→集成→契约→E2E）。
- 确保故障可诊断：提供制品+关联ID（日志/链路追踪/截图）、明确责任人、不稳定测试排查手册。
- 落地执行：不稳定测试SLO、带过期时间的隔离机制、测试套件预算（PR门禁 vs 定时执行）、监控仪表盘。
Test Pyramid
测试金字塔
text
/\
/E2E\ 5-10% - Critical journeys
/------\
/Integr. \ 15-25% - API, DB, queues
/----------\
/Component \ 20-30% - UI modules
/------------\
/ Unit \ 40-60% - Logic and invariants
/--------------\text
/\
/E2E\ 5-10% - 关键用户路径
/------\
/Integr. \ 15-25% - API、数据库、消息队列
/----------\
/Component \ 20-30% - UI模块
/------------\
/ Unit \ 40-60% - 逻辑和不变量
/--------------\Decision Tree: Test Strategy
测试策略决策树
text
Need to test: [Feature Type]
│
├─ Pure business logic/invariants? → Unit tests (mock boundaries)
│
├─ UI component/state transitions? → Component tests
│ └─ Cross-page user journey? → E2E tests
│
├─ API Endpoint?
│ ├─ Single service boundary? → Integration tests (real DB/deps)
│ └─ Cross-service compatibility? → Contract tests (schema/versioning)
│
├─ Event-driven/API schema evolution? → Contract + backward-compat tests
│
└─ Performance-critical? → k6 load testingtext
需要测试：[功能类型]
│
├─ 纯业务逻辑/不变量？→ 单元测试（模拟依赖边界）
│
├─ UI组件/状态转换？→ 组件测试
│ └─ 跨页面用户路径？→ E2E测试
│
├─ API接口？
│ ├─ 单一服务边界？→ 集成测试（真实数据库/依赖）
│ └─ 跨服务兼容性？→ 契约测试（Schema/版本管理）
│
├─ 事件驱动/API Schema演进？→ 契约测试+向后兼容测试
│
└─ 性能关键型功能？→ k6负载测试Core QA Principles
核心QA原则
Definition of Done
完成定义
- Strategy is risk-based: critical journeys + failure modes explicit
- Test portfolio is layered: fast checks catch most defects
- CI is economical: fast pre-merge gates, heavy suites scheduled
- Failures are diagnosable: actionable artifacts (logs/trace/screenshots)
- Flakes managed with SLO and deflake runbook
- 策略基于风险：明确关键用户路径和故障模式
- 测试组合分层：快速检查捕获大多数缺陷
- CI执行高效：预合并阶段快速门禁，重量级测试套件定时执行
- 故障可诊断：提供可操作的制品（日志/链路追踪/截图）
- 通过SLO和排查手册管理不稳定测试
Shift-Left Gates (Pre-Merge)
左移门禁（预合并阶段）
- Contracts: OpenAPI/AsyncAPI/JSON Schema validation
- Static checks: lint, typecheck, secret scanning
- Fast tests: unit + key integration (avoid full E2E as PR gate)
- 契约检查：OpenAPI/AsyncAPI/JSON Schema验证
- 静态检查：代码规范、类型检查、敏感信息扫描
- 快速测试：单元测试+核心集成测试（避免将完整E2E作为PR门禁）
Shift-Right (Post-Deploy)
右移验证（部署后阶段）
- Synthetic checks for critical paths (monitoring-as-tests)
- Canary analysis: compare SLO signals and key metrics before ramping
- Feature flags for safe rollouts and fast rollback
- Convert incidents into regression tests (prefer lower layers first)
- 核心路径的合成监控（以监控为测试）
- 金丝雀发布分析：扩容前对比SLO信号和关键指标
- 功能灰度发布：安全上线与快速回滚
- 将事件转化为回归测试（优先选择低层测试）
CI Economics
CI成本优化
| Budget | Target |
|---|---|
| PR gate | p50 ≤ 10 min, p95 ≤ 20 min |
| Mainline health | ≥ 99% green builds/day |
| 预算指标 | 目标值 |
|---|---|
| PR门禁 | p50 ≤ 10分钟，p95 ≤ 20分钟 |
| 主干分支健康度 | 每日构建成功率 ≥ 99% |
Flake Management
不稳定测试管理
- Define: test fails without product change, passes on rerun
- Track weekly: (where
flaky_failures / total_test_executions)flaky_failure = fail_then_pass_on_rerun - SLO: Suite flake rate ≤ 1% weekly
- Quarantine policy with owner and expiry
- Use the deflake runbook: template-flaky-test-triage-deflake-runbook.md
- 定义：无产品代码变更时测试失败，重新执行则通过
- 每周追踪：（其中
不稳定测试失败数 / 总测试执行数=失败后重新执行通过的次数）不稳定测试失败数 - SLO：测试套件每周不稳定率 ≤ 1%
- 带责任人与过期时间的隔离机制
- 使用排查手册：template-flaky-test-triage-deflake-runbook.md
Common Patterns
常见模式
AAA Pattern
AAA模式
javascript
it('should apply discount', () => {
// Arrange
const order = { total: 150 };
// Act
const result = calculateDiscount(order);
// Assert
expect(result.discount).toBe(15);
});javascript
it('should apply discount', () => {
// Arrange
const order = { total: 150 };
// Act
const result = calculateDiscount(order);
// Assert
expect(result.discount).toBe(15);
});Page Object Model (E2E)
页面对象模型（E2E）
typescript
class LoginPage {
async login(email: string, password: string) {
await this.page.fill('[data-testid="email"]', email);
await this.page.fill('[data-testid="password"]', password);
await this.page.click('[data-testid="submit"]');
}
}typescript
class LoginPage {
async login(email: string, password: string) {
await this.page.fill('[data-testid="email"]', email);
await this.page.fill('[data-testid="password"]', password);
await this.page.click('[data-testid="submit"]');
}
}Anti-Patterns
反模式
| Anti-Pattern | Problem | Solution |
|---|---|---|
| Testing implementation | Breaks on refactor | Test behavior |
| Shared mutable state | Flaky tests | Isolate test data |
| sleep() in tests | Slow, unreliable | Use proper waits |
| Everything E2E | Slow, expensive | Use test pyramid |
| Ignoring flaky tests | False confidence | Fix or quarantine |
| 反模式 | 问题 | 解决方案 |
|---|---|---|
| 测试实现细节 | 重构时易失效 | 测试行为而非实现 |
| 共享可变状态 | 导致测试不稳定 | 隔离测试数据 |
| 测试中使用sleep() | 缓慢且不可靠 | 使用事件驱动的等待机制 |
| 所有测试都用E2E | 缓慢且成本高 | 遵循测试金字塔原则 |
| 忽略不稳定测试 | 导致虚假的信心 | 修复或隔离不稳定测试 |
Do / Avoid
建议/禁忌
Do
建议
- Write tests against stable contracts and user-visible behavior
- Treat flaky tests as P1 reliability work
- Make "how to debug this failure" part of every suite
- 针对稳定契约和用户可见行为编写测试
- 将不稳定测试视为P1可靠性任务
- 为每个测试套件添加“如何调试此故障”的说明
Avoid
禁忌
- "Everything E2E" as default
- Sleeps/time-based waits (use event-based)
- Coverage % as primary quality KPI
- 默认使用“全E2E测试”
- 使用sleep()/基于时间的等待（改用事件驱动等待）
- 将覆盖率作为主要质量KPI
Resources
资源
| Resource | Purpose |
|---|---|
| comprehensive-testing-guide.md | End-to-end playbook across layers |
| operational-playbook.md | Testing pyramid, BDD, CI gates |
| shift-left-testing.md | Contract-first, BDD, continuous testing |
| test-automation-patterns.md | Reliable patterns and anti-patterns |
| playwright-webapp-testing.md | Playwright patterns |
| chaos-resilience-testing.md | Chaos engineering |
| observability-driven-testing.md | OpenTelemetry, trace-based |
| contract-testing-2026.md | Pact, Specmatic |
| synthetic-test-data.md | Privacy-safe, ephemeral test data |
| 资源 | 用途 |
|---|---|
| comprehensive-testing-guide.md | 跨测试层级的完整操作手册 |
| operational-playbook.md | 测试金字塔、BDD、CI门禁 |
| shift-left-testing.md | 契约优先、BDD、持续测试 |
| test-automation-patterns.md | 可靠模式与反模式 |
| playwright-webapp-testing.md | Playwright使用模式 |
| chaos-resilience-testing.md | 混沌工程 |
| observability-driven-testing.md | OpenTelemetry、基于链路追踪的测试 |
| contract-testing-2026.md | Pact、Specmatic契约测试 |
| synthetic-test-data.md | 隐私安全的临时测试数据 |
Templates
模板
| Template | Purpose |
|---|---|
| template-test-case-design.md | Given/When/Then and test oracles |
| test-strategy-template.md | Risk-based strategy |
| template-flaky-test-triage.md | Flake triage runbook |
| template-jest-vitest.md | Unit test patterns |
| template-api-integration.md | API + DB integration tests |
| template-playwright.md | Playwright E2E |
| template-visual-testing.md | Visual regression testing |
| template-k6-load-testing.md | k6 performance |
| automation-pipeline-template.md | CI stages, budgets, gates |
| template-cucumber-gherkin.md | BDD feature files and steps |
| 模板 | 用途 |
|---|---|
| template-test-case-design.md | Given/When/Then测试用例设计和测试断言 |
| test-strategy-template.md | 基于风险的测试策略模板 |
| template-flaky-test-triage.md | 不稳定测试排查手册模板 |
| template-jest-vitest.md | 单元测试模式模板 |
| template-api-integration.md | API+数据库集成测试模板 |
| template-playwright.md | Playwright E2E测试模板 |
| template-visual-testing.md | 视觉回归测试模板 |
| template-k6-load-testing.md | k6性能测试模板 |
| automation-pipeline-template.md | CI阶段、预算、门禁模板 |
| template-cucumber-gherkin.md | BDD特性文件和步骤模板 |
Data
数据文件
| File | Purpose |
|---|---|
| sources.json | External references |
| 文件 | 用途 |
|---|---|
| sources.json | 外部参考链接集合 |
Related Skills
相关技能
- qa-debugging — Debugging failing tests
- qa-agent-testing — Testing AI agents
- software-backend — API patterns to test
- ops-devops-platform — CI/CD pipelines
- qa-debugging — 调试失败的测试
- qa-agent-testing — 测试AI Agent
- software-backend — 待测试的API模式
- ops-devops-platform — CI/CD流水线