PMI PMP: 质量管理与验收 — 学习指南

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

属于 PMP — 学习指南. 使用经过验证的答案练习： PMI 考试中心, 或参加限时模拟考试： ExamRoll.io.

质量规划与质量管理计划

质量管理始于一份书面且经各方同意的质量管理计划 (QMP)，该计划为特定项目定义了“好”的标准。一份健全的 QMP 绝不是样板文件——它必须将客户需求和法规约束转化为可衡量的特性。它至少包含：与相关方需求挂钩的质量目标和度量指标、适用的标准和法规、测试规范（单元、集成、系统、性能、可靠性、安全性、可用性）、每个可交付成果的验收标准、角色和职责（谁编写测试、谁执行、谁签核）、工具和环境、缺陷分类和上报阈值、审计频率以及可追溯性方法。

测试规范尤其值得强调。每一项需求——无论是功能性还是非功能性需求——都应指向一个或多个测试用例，并最终指向执行证据。这就是需求-测试-结果可追溯性矩阵，它是一种工件，用于在后期客观地证明所交付的产品满足范围要求。

• 需求 ID
  • 来源：需求文档 / 待办事项列表
  • 目的：锚定范围
• 验收标准
  • 来源：与产品负责人 / 客户共同阐述
  • 目的：定义“完成”
• 测试用例 ID
  • 来源：测试计划
  • 目的：验证标准
• 测试结果与证据
  • 来源：测试执行报告
  • 目的：证明合规性
• 已交付的功能 / 构建版本
  • 来源：发布说明
  • 目的：链接回范围

当一个组件（例如原型）未能通过计划中从未提及的可靠性测试时——这在硬件和复杂系统中是常见情况——正确的响应不是悄悄地打补丁然后继续前进。这说明计划本身存在缺陷。项目经理应通过整体变更控制更新 QMP，添加缺失的测试规范，将此差距记录为经验教训，对故障进行根本原因分析，然后才重新设定基线。如果跳过更新计划这一步，就会为下一个组件留下同样的盲点。

持续验证与早期测试

将质量视为阶段关口检查点的预测型进度计划会累积隐藏的技术债务。在设计阶段引入的缺陷会在系统测试时才暴露出来，而此时的返工成本呈指数级增长，并且常常与进度压力相冲突。解决之道是持续验证：测试左移、自动化回归测试、子系统的早期集成，以及向客户或产品负责人频繁进行演示。

在混合和适应性环境中，这通过以下方式实现：产生可演示增量的短迭代、在测试失败时阻止合并的持续集成流水线，以及包含测试工件的“就绪/完成”定义。预测型项目也可以采用相同的原则，方法是在阶段关口之间插入集成里程碑，对高不确定性的组件尽早进行基于风险的测试，并要求供应商的交付物附带测试证据而非仅有保证。

仅在阶段关口评估质量的陷阱之所以危险，恰恰因为它给人一种纪律严明的感觉。关口评审将缺陷的发现压缩到项目已投入成本和时间的某个时刻；此时发现的问题要么导致隐瞒（为了通过关口的压力），要么导致成本高昂的返工循环。持续验证则将发现过程分布在整个生命周期中，此时进行纠正的成本很低。

“完成”的定义与验收测试

“完成”的定义 (DoD) 是一份契约，它规定了一个工作项是真正地完成了，而不仅仅是编码或制造完毕。一个成熟的 DoD 包括：代码/组件已评审、单元测试已编写并通过、集成测试已通过、已向产品负责人演示验收标准、文档已更新、非功能性标准（性能、安全）在适用时已验证，以及所需的法规证据已捕获。

当变更请求被批准时，与该变更相关的验收测试必须被纳入范围。仅仅更新需求和代码是不够的；还必须添加或修改相应的测试用例，并对其进行执行和追溯。变更控制委员会应拒绝那些缺少明确验证方法的变更。这就是 DoD 如何防止范围蔓延悄无声息地降低质量。

在没有可证明的测试证据的情况下就假定产品质量合格——这是一种非常常见的失效模式——是错误的，因为对质量的信任必须通过工件赢得：测试报告、缺陷度量、审计发现、签核。如果没有证据，当发生退货后，项目经理告诉客户“质量流程已得到遵守”时，他将拿不出任何凭证。正确的姿态是进行基于证据的沟通：分享可追溯性矩阵、测试执行日志、审计结果以及已采取的纠正措施。保障是透明化的结果，而非其替代品。

审计、根本原因分析与持续改进

质量审计是预先计划的、独立的检查，旨在评估流程是否得到遵守以及是否有效。它们有两个目的：合规性（我们是否言行一致）和改进（我们的实践是否真正产出高质量）。审计应在质量管理计划 (QMP) 中进行规划，并明确其频率、范围和汇报路径。

当发生质量故障时——例如交付的产品出现重大问题、客户退回组件、发布在生产环境中中断——项目经理的责任不是直接启动返工。严谨的应对顺序是：

1. 控制直接影响（停止发货、回滚发布、隔离受影响的单元）。
2. 分析根本原因，使用结构化技术：5 Whys、鱼骨图（石川图）、故障树分析、缺陷类别帕累托分析。
3. 定义纠正措施以解决真正的原因而非表象，并定义预防措施以消除再次发生。
4. 更新 QMP、流程、测试和 DoD，以融入改进措施。
5. 在组织过程资产中记录经验教训，以便其他项目受益。
6. 向受影响的干系人沟通，提供事件经过和已做变更的证据。

未能将口头约定的规范形成文档，会导致一类特定的返工：各方后来对承诺的内容产生分歧，质量纠纷演变为合同纠纷。每一项商定的规范、变更和验收标准都必须书面化并进行版本控制。

运维就绪性、培训与交接

质量并非在交付时就结束——它必须在交接后得以延续。运维和 QA 团队应从最早的规划阶段就参与进来，而不是在上线时才感到意外。具体的实践包括邀请运维代表参加 Sprint 演示和设计评审，与支持和运维人员共同编写验收标准，在开发产品的同时编写运行手册 (runbook) 和已知问题列表，以及在切换前执行运维就绪性审查。

应为最终用户、支持人员和管理员制定培训计划，并在交接前制作好材料并进行演练。一个有用的交接清单涵盖：生产环境已配置并测试，监控和警报已就位，运行手册和上报路径已文档化，支持人员已培训并认证，保修和缺陷报告机制已定义，以及经验教训已转移。

一个不易察觉的质量杀手是让测试人员承担过多的支持工作——要求 QA 人员回答生产工单、分类客户问题或填补分析师的空缺。这会降低测试覆盖率，延迟缺陷发现，并耗尽负责保障质量的人员。当出现能力压力时，项目经理应上报以获取额外资源或协商范围，而不是蚕食测试职能。保护 QA 的工作能力是领导层的责任。

何时上报以及更新计划

当质量故障对范围、进度、成本或合规性的威胁超出了项目经理的容忍度时；当所需的纠正措施超出了可用的应急储备时；或者当发现影响其他项目的系统性流程缺陷时，应向发起人或指导委员会上报。每当需要一类新的测试、审计揭示了差距、变更请求修改了验收标准，或经验教训确定了更优的实践时，都应更新 QMP。可追溯性、证据和持续验证是三大支柱——每一个质量决策都应至少强化其中之一。

← 风险与问题管理 · 所有领域 · 采购与合同管理 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →