holistic-testing-pact

以 PACTS 原则构建整体测试模型

<default_to_action> 设计测试策略或在团队中构建质量保障时：

1. 应用 PACTS 原则：主动（在缺陷出现前测试）、自主（团队负责质量）、协作（全团队共同负责）、有针对性（聚焦风险）、结构化（对 Agent 行为进行治理、观察和解释）
2. 确定象限重点：面向技术（单元、集成、性能）或面向业务（验收、探索、可用性）
3. 根据 PACTS 维度和测试象限选择 Agent
4. 建立反馈闭环，在几分钟内而非几天内发现问题
5. 衡量结果（缺陷逃逸率、发布信心、Agent 信心），而非活动（测试数量）

快速应用 PACTS：

• 主动 → 在架构设计中融入可测试性，在细化阶段进行风险分析
• 自主 → 开发人员在本地运行测试，CI 流水线不设人工关卡
• 协作 → 三剑客评审，QE 与开发人员结对，共同拥有测试
• 有针对性 → 基于风险进行规划，聚焦关键流程，淘汰无价值的测试
• 结构化 → 对 Agent 行为进行治理、观察和解释；衡量信心，而非信任

关键成功因素：

• 质量是全团队的责任，而非 QA 阶段的职责
• QA 应发挥赋能作用（构建基础设施、提供指导），而非充当把关人
• 在开发期间快速反馈，而不是开发完成后再反馈 </default_to_action>

速查卡

适用场景

• 设计全面的测试策略
• 在团队中营造质量文化
• 为新项目选择测试方法
• 从串行 QA 转向并行质量保障

PACTS 原则

原则	重点	反模式
主动	在编写代码前测试，设计可测试性	等着缺陷找上门
自主	团队准备就绪后即可部署	QA 充当人工把关人
协作	全团队共同思考质量	QA 独立开展工作
有针对性	基于风险，开展高价值测试	穷尽式清单测试
结构化	对 Agent 行为进行治理、观察和解释	在混乱中强行加入 Agentic AI

整体测试象限

象限	目的	示例
技术 + 支持	快速反馈	单元、组件、集成测试
技术 + 批判	发现极限	性能、安全、混沌测试
业务 + 支持	建立共同理解	BDD、验收测试
业务 + 批判	探索未知问题	探索性测试、可用性测试、A/B 测试

按 PACTS + 象限选择 Agent

PACTS 维度	Agent
主动 + 技术	qe-test-generator、qe-requirements-validator
自主 + 技术	qe-test-executor、qe-coverage-analyzer
协作	qe-fleet-commander（编排）
有针对性	qe-regression-risk-analyzer、qe-quality-gate
结构化	qe-fleet-commander、qe-quality-gate（治理、观察、解释）

---

实践 PACTS

主动：在缺陷出现前测试

// During API design, ask: "How will we know if this times out under load?"
// Build observability from start
await Task("Risk Analysis", {
  phase: 'refinement',
  question: 'What could go wrong and how will we know?'
}, "qe-requirements-validator");

自主：团队负责质量

• 开发人员在本地运行完整测试套件
• CI 快速失败并提供清晰的诊断信息
• 无需人工批准即可部署
• 自助式测试环境

协作：全团队共同思考

• QE 参加规划和细化会议
• 为每个用户故事开展三剑客评审
• 共同负责测试代码
• 针对复杂场景开展集体测试

有针对性：测试重要的内容

// E-commerce checkout? Test thoroughly.
// Admin panel used twice a month? Lighter touch.
await Task("Risk-Based Planning", {
  critical: ['checkout', 'payment'],
  light: ['admin-panel', 'settings']
}, "qe-regression-risk-analyzer");

结构化：治理、可观测性、可解释性

这是 Agent 系统的第 5 项原则。随着 Agent 承担起质量工作，你需要治理（边界和防护措施）、可观测性（Agent 做了什么以及原因）和可解释性（可供审计的决策）。这对受监管行业尤为重要。

• 我们衡量的是 信心，而非信任——信任是一种人的感受；信心则可以用数学方式解释。
• 随附一份操作手册和就绪度评估指南。
• 反模式：在混乱的基础上强行加入 Agent 式 AI。先建立结构，再实现自动化。

// Make agent behavior auditable and explainable, not a black box
await Task("Agent Governance Review", {
  guardrails: ['scope-boundaries', 'approval-gates'],
  observability: ['decision-traces', 'confidence-scores'],
  explainability: 'every-decision-auditable'
}, "qe-fleet-commander");

---

从 PACT 到 PACTS

PACT 源自 Reuven Cohen（Agentics Foundation），后由 Dragan Spiridonov 改编用于质量工程。PACTS 增加了第五项原则——结构化——灵感来自 DORA 关于 AI 辅助交付和平台工程质量度量的研究。这一新增原则反映出，要让自主的 Agent 式质量工作能够在大规模应用时值得信赖，就需要治理、可观测性和可解释性。

---

从传统方式演进

旧方式（顺序执行）	整体式 + PACTS（并行执行）
开发人员编写 → QA 测试 → 发现 Bug → 修复	团队共同讨论构建什么以及如何测试
反馈缓慢，互相推诿	反馈迅速，共同负责
将质量作为把关手段	将质量作为赋能手段
QA 处于关键路径上	QA 构建基础设施、提供指导

---

成功信号

• 每天多次部署功能
• Bug 逃逸率呈下降趋势
• 团队会自然地讨论质量
• 开发人员无需提醒就会编写测试
• 发布过程平稳（这是好事）

---

Agent 协作提示

记忆命名空间

aqe/holistic-testing/
├── pacts-assessment/*    - PACTS maturity analysis
├── quadrant-coverage/*   - Coverage per quadrant
├── team-metrics/*        - Quality ownership metrics
└── feedback-loops/*      - Cycle time data

Agent 群协调

const holisticFleet = await FleetManager.coordinate({
  strategy: 'holistic-testing',
  pacts: { proactive: true, autonomous: true, collaborative: true, targeted: true, structured: true },
  agents: [
    'qe-fleet-commander',       // Orchestration
    'qe-test-generator',        // Tech quadrant
    'qe-requirements-validator', // Business quadrant
    'qe-quality-analyzer'       // Metrics
  ],
  topology: 'mesh'
});

---

相关技能

• agentic-quality-engineering - Agent 协作
• context-driven-testing - 根据上下文调整
• shift-left-testing - 主动测试
• risk-based-testing - 针对性测试

---

请记住

PACTS = 主动 + 自主 + 协作 + 有针对性 + 结构化

质量是构建出来的，不是测试出来的。团队共同负责质量。QA 负责赋能，而非把关。测试重要的内容，跳过不重要的内容。通过可观测性和可解释性治理 Agent 行为——衡量信心，而非信任。衡量结果，而非活动。

使用 Agent： Agent 会分析 PACTS 成熟度、推荐象限覆盖范围，并协调全团队质量工作。使用 Agent 扩展整体思维，同时保留人类判断。