名称: qa-testing-strategy
描述: 基于风险的质量工程测试策略，用于软件交付。在定义或更新测试策略、选择单元/集成/合同/端到端/性能/安全覆盖、设置CI质量门控和测试预算、管理不稳定测试和测试数据，以及操作可观察性优先的调试和发布标准时使用。
QA测试策略（2026年1月）
基于风险的质量工程策略，适用于现代软件交付。
核心参考: 在data/sources.json中整理的链接（SLOs/错误预算、合同、端到端、OpenTelemetry）。从references/operational-playbook.md开始，获取简洁、可导航的概览。
范围
- 创建或更新基于风险的测试策略（测试什么、在哪里测试、为什么测试）
- 定义质量门控和发布标准（合并 vs 部署）
- 选择最小有效的层级（单元 → 集成 → 合同 → 端到端）
- 使故障可诊断（工件、日志/跟踪、所有权）
- 操作可靠性（不稳定测试SLO、隔离、测试预算）
替代使用
快速参考
| 测试类型 |
目标 |
典型用途 |
| 单元 |
快速证明逻辑和不变性 |
纯函数、核心业务规则 |
| 组件 |
隔离验证UI行为 |
UI组件和状态转换 |
| 集成 |
验证与真实依赖的边界 |
API + 数据库、队列、外部适配器 |
| 合同 |
防止跨团队破坏性变更 |
OpenAPI/AsyncAPI/JSON Schema/Protobuf |
| 端到端 |
验证关键用户旅程 |
每个产品领域的1-2个“金钱路径” |
| 性能 |
强制预算和容量 |
负载、压力、浸泡、回归趋势 |
| 视觉 |
捕获UI回归 |
稳定页面的布局/视觉差异 |
| 可访问性 |
自动化WCAG检查 |
axe烟雾测试 + 针对性手动审计 |
| 安全 |
早期捕获常见Web漏洞 |
DAST烟雾测试 + CI中的关键检查 |
默认工作流
- 明确范围和风险：关键旅程、故障模式和非功能风险（延迟、数据丢失、认证）。
- 定义质量信号：SLOs/错误预算、合同/模式检查，以及什么阻止合并 vs 阻止部署。
- 选择最小有效的层级（单元 → 集成 → 合同 → 端到端）。
- 使故障可诊断：工件 + 关联ID（日志/跟踪/截图）、清晰的所有权、不稳定测试修复手册。
- 操作化：不稳定测试SLO、带过期的隔离、测试预算（PR门控 vs 计划），仪表板。
测试金字塔
/\
/端到端\ 5-10% - 关键旅程
/------\
/集成 \ 15-25% - API、数据库、队列
/----------\
/组件 \ 20-30% - UI模块
/------------\
/ 单元 \ 40-60% - 逻辑和不变性
/--------------\
决策树：测试策略
需要测试: [功能类型]
│
├─ 纯业务逻辑/不变性？ → 单元测试（模拟边界）
│
├─ UI组件/状态转换？ → 组件测试
│ └─ 跨页面用户旅程？ → 端到端测试
│
├─ API端点？
│ ├─ 单服务边界？ → 集成测试（真实数据库/依赖）
│ └─ 跨服务兼容性？ → 合同测试（模式/版本控制）
│
├─ 事件驱动/API模式演变？ → 合同 + 向后兼容测试
│
└─ 性能关键？ → k6负载测试
核心QA原则
完成定义
- 策略基于风险：明确关键旅程 + 故障模式
- 测试组合分层：快速检查捕获大多数缺陷
- CI经济：快速预合并门控、重型套件计划执行
- 故障可诊断：可操作的工件（日志/跟踪/截图）
- 不稳定测试通过SLO和修复手册管理
左移门控（预合并）
- 合同：OpenAPI/AsyncAPI/JSON Schema验证
- 静态检查：lint、类型检查、秘密扫描
- 快速测试：单元 + 关键集成（避免完整端到端作为PR门控）
右移（部署后）
- 关键路径的合成检查（监控即测试）
- Canary分析：在扩展前比较SLO信号和关键指标
- 功能标志，用于安全发布和快速回滚
- 将事件转换为回归测试（优先选择较低层级）
CI经济
| 预算 |
目标 |
| PR门控 |
p50 ≤ 10分钟, p95 ≤ 20分钟 |
| 主线健康 |
≥ 99%绿色构建/天 |
不稳定测试管理
常见模式
AAA模式
it('should apply discount', () => {
// 安排
const order = { total: 150 };
// 行动
const result = calculateDiscount(order);
// 断言
expect(result.discount).toBe(15);
});
页面对象模型（端到端）
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"]');
}
}
反模式
| 反模式 |
问题 |
解决方案 |
| 测试实现 |
重构时破坏 |
测试行为 |
| 共享可变状态 |
不稳定测试 |
隔离测试数据 |
| sleep()在测试中 |
慢、不可靠 |
使用适当的等待 |
| 一切端到端 |
慢、昂贵 |
使用测试金字塔 |
| 忽略不稳定测试 |
虚假信心 |
修复或隔离 |
做 / 避免
做
- 针对稳定合同和用户可见行为编写测试
- 将不稳定测试视为P1可靠性工作
- 使“如何调试此失败”成为每个套件的一部分
避免
- 默认“一切端到端”
- 睡眠/基于时间的等待（使用基于事件的等待）
- 覆盖率百分比作为主要质量KPI
资源
模板
数据
相关技能