代码合并进主干 ≠ 可以交付。
PM 在测试阶段的核心职责：组织测什么、何时内部关，不负责替测试写用例、手动点测过关。
一、常见默认场面 & 翻车点
常规团队配置：7～8人、产品对外、项目对内，PM兼任项目组长。
本阶段高频翻车问题：
-
只测 Demo 流程，简单点点就收尾
-
测试用例数量多，但和 AC（验收标准）对不上
-
内部自测宣称“通过”，需求人员未到场确认
-
P0 严重缺陷遗留，靠口头放行直接进入预发布
二、核心名词定义（本篇口径）
内部验收 = 完整测试验证 + 需求按 V1/AC 确认本期迭代可内部闭环
✅ 包含：测试全覆盖、业务合规确认、遗留项定级锁死
❌ 不包含：客户 UAT 签字（该环节统一放在第8篇）
P0/P1：严重缺陷 / 高优缺陷，定级严格遵循团队统一质量规范
三、关键灵魂拷问：你测的是 AC 还是 Demo？
1）测 AC（正确做法）
每条验收标准独立编号、逐条验证、结果可追溯、证据可留存：
-
有 AC# 编号
-
有明确测试结果
-
有截图/数据/用例记录佐证
特点：闭环可查、责任可溯、UAT 不翻车。
2）测 Demo（高危做法）
只保证主流程能演示、页面能点开，边界场景、权限场景、异常场景、生产隐性风险全部遗留。
后果：UAT 集中爆雷、上线后批量出问题。
四、阶段分工（PM 定位）
-
测试：落地测试执行、结果判定、缺陷闭环
-
需求：确认功能、业务逻辑符合 V1 版本设计预期
-
PM：定测试范围、组织内部验收会、锁发布拦截口径
五、PM 本阶段必须交付的产出
|
《测试范围表》 |
逐条对齐本期所有 AC，标注是否测试、结果、证据、内部/UAT 归属 |
|
《内部验收结论》 |
半页精简文档：明确本期闭环 AC、遗留项、责任人、各方确认记录 |
|
压测/容量记录（按需） |
按章程执行，可引用任务表；不测必须出具书面豁免 |
重要边界：内部闭环仅用于支撑 M2「AC-xx 内部关」；客户 UAT 签字统一归第8篇，不混签、不提前闭环。
六、可直接复用：测试范围表模板
制表原则：对照 V1 验收标准，而非原型按钮、页面外观。
【项目】xxx ｜【版本/Build】xxx ｜【环境】测试/预发 ｜【日期】xxx
|
AC-01 |
订单导出功能合规校验 |
Y |
通过 |
用例#xxx；1万条数据5min导出记录完整 |
内部关；UAT 见08篇 |
|
AC-02 |
…… |
补充测试范围（非AC字面，但必测）
-
探索/边界场景：权限校验、SQL性能、接口兼容性、异常输入
-
变更回归范围：关联任务# / PR#
-
压测/容量：☑️ 完成 ｜ ☐ 书面豁免（需写清理由）
PM 自检三问
本期所有 AC 是否全部入表，无遗漏？
是否全覆盖 AC，而非只测 Demo 主路径？
AI 参与开发模块，是否留存边界/探索测试记录？
七、测试组织流程（PM 协调，不写用例、不点测）
|
范围冻结 |
以 V1.x + 变更表为唯一依据，禁止口头加测、改范围 |
PM |
|
用例+探索测试 |
对准 AC“通过标准”设计用例，覆盖边界、权限、SQL、异常 |
测试 |
|
测试执行 |
按任务表完成常规/探索/回归测试，达成 DoD 标准 |
测试 |
|
缺陷管理 |
P0/P1 门禁管控，所有缺陷入库闭环追踪 |
测试 |
|
回归验证 |
迭代变更后同步更新回归范围，与变更流程联动 |
测试 |
禁止操作：不允许「AI写过用例就免测」；不允许接收无 PR、无 AC 对应的大包代码直接合入测试。
八、P0/P1 缺陷发布门禁 & 豁免规则
适用阶段：08发布清单、正式上线前
|
P0 严重缺陷 |
默认拦截发布，无豁免 |
必须：缩范围 / 修完 / 延期。严禁口头放行上线 |
|
P1 高优缺陷 |
拦截发布 或 书面豁免 |
豁免必须留痕：审批人、修复日、补测计划、抄送发起人；遗留项入08清单，禁止常态“上线后再说” |
本条与《质量与管理链》口头放行管控一致，热修复流程参照06/08篇。
九、内部验收会议（标准 30～45 分钟）
参会人员
测试（主评）、需求（必到）、PM、开发/技术（答疑）、发起人（旁听可选）
会议固定流程
过测试范围表：逐条确认 AC 通过/不通过/阻塞
需求业务确认：是否符合 V1 业务设计（不看 Demo 像不像）
锁定遗留项：定级别、定责任人、定修复截止日
输出验收结论：明确内部闭环 AC、待 UAT 验证内容
十、可复用：内部验收结论（半页模板）
【项目】xxx ｜【Build/版本】xxx ｜【日期】xxx
内部关闭 AC：AC-01、AC-02……（对应 M2 闭环）
未关闭/遗留项：
|
P1 |
需求确认：xxx（签字/邮件留痕）
测试确认：xxx
PM 结论：xxx
内部验收 ≠ UAT 验收！客户正式签字统一在08发布与UAT篇。
未通过处置：禁止标记 M2/模块闭合，必须修复缺陷、走变更缩范围或申请延期。
十一、PM 可为 / 不可为（避坑清单）
|
测试范围强绑定 AC |
替测试手动点通过、判结果 |
|
拉需求到场做业务确认 |
用 Demo 演示替代 AC 验收 |
|
P0/P1 刚性门禁、书面豁免 |
口头放行“今晚先上” |
|
压测要么完成、要么书面豁免 |
因 AI 用例多，擅自缩减探索测试 |
十二、常见空子 & 标准对策
|
口头需求随意改测试范围 |
所有范围变更走05变更流程，统一留痕 |
|
内部验收无需求在场 |
验收结果无效，必须补业务确认 |
|
合并主干=测过了 |
以 AC 逐条测试闭环为唯一依据 |
|
只测 Happy Path 主流程 |
权限/SQL/边界单独记录、强制覆盖 |
|
内部关=UAT通过 |
UAT 单独在08篇闭环、客户单独签字 |
十三、省略本环节的直接后果
|
不测 AC、只测 Demo |
UAT 等于重做一遍需求验收 |
质量与管理链-测试规范 |
|
无正式内部验收 |
问题全部暴露在客户面前，引发投诉 |
同上 |
|
P0 口头放行 |
直接引发线上生产事故 |
发布门禁规范 |
|
应压测未压测、无豁免 |
线上容量瓶颈、卡顿、雪崩 |
环境与发布管控 |
十四、与往期体系联动
|
测试范围、内部验收闭环 |
《执行骨架》质量、验收标准 |
|
发布前门禁清单 |
《AI 审查与门禁》（08篇勾选核验） |
|
AC落地、M2里程碑闭合 |
《锁范围与验收》《排里程碑与缓冲》 |
|
摒弃纯 Demo 验收 |
《质量与管理链》 |
|
变更回归联动 |
《执行监管与变更》 |
十五、实操落地建议
联调完成后3日内：测试定稿《测试范围表》，PM敲定内部验收时间。
M2 里程碑前必自查：所有 AC 内部关是否有表、有结论、可追溯。
结语
组织测试与内部验收的核心公式：对着 AC 逐条测 + 需求在场确认业务 + P0/P1 刚性门禁留痕。
把内部验收做扎实，08篇的生产发布、客户UAT才不会变成「第一次正式验收」，从源头降低上线风险与验收返工。
下一篇预告：《发布与 UAT》
讲解发布清单完整留痕、生产上线与合同验收的严格边界，彻底分清「上线可用」≠「客户验收通过」。
