UAT 与验收

• UAT 与 Beta 测试的定义与目的
• 测试对象、环境、参与者、阶段的不同
• 两者的衔接关系

UAT（用户验收测试）是开发完成、进生产前，由业务用户/客户代表在准生产环境按验收标准验证系统是否满足业务需求与合同约定，是"验证交付物是否符合约定"的正式验收环节，通常在严格受控的环境下、按预先定义的验收用例与退出准则执行，参与者为代表业务角色的用户。Beta 测试是面向真实用户/公开小范围人群的测试，在真实生产环境或接近真实的环境下让大量真实用户使用，收集真实场景下的反馈、问题与性能数据，用于发布前验证与收集改进意见，参与者广泛不控。边界：UAT 是"按标准验证验收"、受控、收尾性质；Beta 是"真实环境试运行"、开放、探索性质。两者常衔接：UAT 通过后进入 Beta 或直接上线，Beta 反馈作为发布决策与后续迭代输入。

边界在于"受控与开放"和"验收与探索"：UAT 用验收标准做正式判定，Beta 用真实使用做风险收集。UAT 是质量门禁，Beta 是发布前的真实环境验证。

• UAT 通过与上线决策的关系
• Go/No-Go 决策的补充评估维度
• 上线决策的多维度把关

UAT 通过不等于可以直接上线。UAT 验证的是"业务功能与验收标准符合"，但上线决策（Go/No-Go）还需补充评估：非功能与风险——性能、容量、稳定性、安全、可用性是否达标（UAT 往往侧重功能）；生产就绪度——部署方案、回滚方案、监控告警、备份恢复、数据迁移是否就绪；运营与支持——运维文档、客服培训、应急预案是否到位；合规与法务——数据合规、隐私、合同义务是否满足；遗留缺陷——已确认缺陷的严重度与影响是否可接受，是否有规避方案。Go/No-Go 是综合评审，需要业务、技术、运维、安全、法务多方共同决策，UAT 通过只是其中一个前提条件。

UAT 通过回答"业务是否满意"，Go/No-Go 回答"是否安全、就绪、可发布"。上线决策是多维度的综合评估，UAT 只是必要条件而非充分条件。

• UAT 用户筛选的代表性
• 覆盖典型业务角色与关键流程
• 参与度管理的策略

UAT 用户的筛选应保证"代表性"：覆盖系统的典型业务角色（如销售、客服、财务、管理员等不同职能用户）、关键业务流程的负责人、不同使用水平（新手/熟练）与不同业务单元/地区的用户，确保各角色对与他们相关的功能都有验收代表。同时要选择"懂业务、有决策权或能代表使用者"的用户，避免只选"关系好的"或"技术强的"。参与度管理：建立用户名录与分工（谁负责哪些场景），提前沟通时间与任务，提供清晰的任务清单与验收指引，设置里程碑与提醒，及时反馈缺陷处理进度以维持积极性，并安排关键用户（离岸/关键角色）作为验收负责人担纲签署。对参与度低的用户要及时跟进，必要时轮换或补充代表。

代表性决定"验收结论是否可信"——若关键角色未覆盖，其相关功能等于未验收。参与度管理是让代表真正执行并负责，而非挂名。

• 功能正确与用户满意（可用性/体验）的区别
• 弥补差距的测试策略
• 从"技术正确"到"体验满意"的验证

"功能正确"指系统按规格实现了功能（技术层面），"用户满意"指用户实际使用时觉得好用、符合预期（体验层面）。两者之间的差距来源于：可用性不佳（操作繁琐、流程难懂）、性能体感差、与用户真实工作流不匹配、需求理解偏差。弥补策略：将可用性测试纳入测试计划——在功能测试之外，进行任务型可用性测试与专家评审，验证"用户能否顺畅完成任务"；引入用户视角的验收用例——按真实业务场景设计，而非仅按技术规格；进行端到端与真实环境验证——在接近生产的条件下测试完整流程；收集用户反馈（Beta、反馈渠道）闭环改进；把"用户满意"指标（任务完成率、满意度）纳入验收标准。

功能正确是可证明的，用户满意是需感知的。弥补差距靠"从用户视角设计测试"，把可用性、体验、真实场景纳入验证体系，而非只验证技术规格。

• UAT 与系统测试的定位差异
• 业务用户视角、真实环境、验收标准的区别
• 两者的衔接

系统测试（System Test）由测试团队在测试环境执行，面向"系统整体是否符合规格"的技术验证，测试人员用系统化用例覆盖功能、性能、接口、安全等，验收标准是"规格/需求符合度"；UAT 由业务用户/客户代表在准生产环境执行，面向"业务是否可用、是否满足业务需求"，用真实业务场景验证，验收标准是"业务验收 Acceptable Criteria"（含签署判定）。差异体现在：视角——系统测试是技术/规格视角，UAT 是业务用户视角；环境——系统测试用测试环境，UAT 用与生产一致或准生产环境；验收标准——系统测试有明确规格，UAT 用业务验收标准并可含主观的"业务上是否可接受"。两者衔接：系统测试通过后进入 UAT，UAT 是最终的业务把关。

差异核心是"验证主体、视角与标准"：系统测试由测试团队按规格验证，UAT 由业务用户按业务标准验收。UAT 是系统测试之后、生产之前的业务把关。

• UAT 失败后的缺陷分类与处理
• 延期（Go-live 延期）的判定
• 验收签字的口径与条件

UAT 失败后的决策流程：先对缺陷分类——按严重度（阻塞/严重/一般/轻微）与业务影响（是否阻断关键流程、有无变通方案）分级，区分"阻断性缺陷"（必须修复才能验收）与"可接受缺陷"（有变通或可后置）。延期判定——若存在阻断性缺陷影响关键业务或合同义务，或修复成本高、风险大，则判定延期上线，并给出修复计划与重新验收时间；若有条件通过（有可接受缺陷+明确规避方案+修复计划），可"有条件通过"并及时跟进。验收签字口径——只有满足"验收标准+无阻断性缺陷+关键流程通过"才正式签署；对缺陷需列明清单、责任人、修复期限与验收复核方式，签字代表接受当前状态并承诺后续处理。整个过程要文档化，作为决策依据。

UAT 失败不是"全盘否定"，而是按"缺陷分类→影响评估→延期/有条件通过→签字口径"的流程决策。签字意味着"接受当前状态并明确后续处理"，而非"无缺陷"。

• 模糊需求到验收条件的转化
• 可验证、可量化的验收标准设计
• Given/When/Then 与场景化

把模糊需求转化为可度量验收条件（AC）的方法：与需求方澄清真实意图，用"给定/当/那么"（Given/When/Then）的场景化描述把模糊表述变成可验证的行为，如"用户能快速下单"转化为"当用户加入购物车并提交，订单在 2 秒内创建成功且返回订单号"；把"快速""好用"等模糊词量化成可测指标（时间、数量、成功率、比例）；明确前置条件、触发动作与可观察结果，使每个 AC 都能被"执行→断言"验证；对每个 AC 定义判定标准（通过/失败），并让需求方确认。可量化维度包括：时间（响应时间）、数量（并发数、数据量）、正确性（返回结果）、边界（最大/最小）。最终 AC 应写成"可执行、可断言、可复核"的清单。

转化模糊需求的关键是"动词化 + 量化 + 场景化"：把形容词变成可测的行为与指标，用 Given/When/Then 让每个 AC 可执行断言。AC 的可验证性决定了它能否作为验收依据。

• UAT 环境与生产的一致性
• 业务数据样本的准备
• 只读与隔离约束

UAT 环境应在接近生产的基础上准备：环境配置、版本、集成依赖与生产一致，数据用与生产特征一致的真实业务样本（如脱敏的真实订单、用户、库存数据），保证验收反映真实业务场景。数据准备：从生产抽取样本并脱敏，覆盖关键业务类型、边界数据与历史数据，同时要注意数据之间的关系（订单↔用户↔库存）完整。只读与隔离约束：UAT 环境通常只读或受控，避免污染生产数据；UAT 与生产数据物理隔离，UAT 数据变更不影响生产；对需要写操作的功能，用隔离的测试数据（独立业务标识）并限制影响范围；对某些外部依赖（如真实支付）用 mock 或沙箱，明确数据边界。同时要建立 UAT 数据刷新与回滚机制，防止 UAT 数据被污染。

UAT 的真实性依赖"环境与数据与生产一致"，而安全性依赖"只读与隔离"。两者需平衡：用真实样本保真实性，用脱敏、隔离、只读约束保安全。

• UAT 退出准则的定义
• 三种结论（通过/有条件通过/不通过）的判定标准
• 签署流程与文档输出

UAT 退出准则（Exit Criteria）定义何时可以结束 UAT 并给出结论，通常包括：验收用例全部执行完成、关键业务场景通过、无阻断性/严重缺陷、缺陷已按优先级处理或达成一致、业务覆盖率达到目标。判定标准：验收通过——所有验收用例通过、无严重缺陷、验收标准全部满足；有条件通过——存在非阻断性缺陷（有变通方案或影响有限），但业务同意接受并附修复计划与期限，可在修复后复核；不通过——存在阻断性/严重缺陷、关键业务无法完成、或验收标准未满足，需返工修复后重新验收。文档输出：验收报告（测试范围、用例执行结果、缺陷清单、结论）、验收签字单（各业务代表签署）、缺陷跟踪记录、遗留问题与修复计划。签署流程需各方（业务、提供方、必要时第三方）确认，作为正式交付依据。

三种结论的判定核心是"缺陷对业务的影响程度"：无阻断则通过，有可接受缺陷则有条件通过，有阻断则不通。文档输出保证结论可追溯、可审计、可责任界定。

• UAT 与生产环境的差异及风险
• 上线首日核心链路冒烟的设计
• 生产监控与回滚预案

"验收环境健康、生产翻车"的根因是环境差异（配置、数据、依赖、流量）与真实负载。为衔接 UAT 与生产，上线首日应设计核心链路冒烟：上线前规划一套"生产冒烟清单"——覆盖核心业务链路（登录、下单、支付、查询、关键回写）的关键操作，上线后立即用生产真实数据（或最小化测试数据）执行一遍，验证功能在真实生产环境可用；同时开启生产监控（业务指标、错误率、响应时间、日志告警），观察真实流量下的表现；准备回滚预案与灰度策略，若冒烟或监控发现异常可快速回滚或降级。冒烟应选择"对业务最关键、最容易因环境差异而失败"的链路，并设置明确的可接受阈值与责任人。

生产翻车主要来自"环境差异+真实负载"。衔接的关键是"上线即验证"——用生产冒烟清单在上线后立即核实核心链路，配合监控与回滚预案，把 UAT 的信任延伸到生产。

• 用户视角与技术评估的冲突来源
• 严重度与优先级的维度
• 建立双方认可的优先级规则

用户视角的严重度关注"业务影响"——这个缺陷是否阻断了我完成工作、是否影响业务结果、是否频繁遇到；技术评估关注"技术影响"——修复复杂度、影响范围、风险、是否易复现。两者冲突的来源：用户认为"体验差但功能可完成"的缺陷很严重，技术认为"修复成本低但影响面小"的缺陷优先级不高；或用户不感知的底层缺陷（如数据一致性风险）技术评估为高但用户认为不重要。建立双方认可的优先级规则：用统一的"严重度×优先级"矩阵，把用户视角（业务影响、频率、阻断性）与技术视角（修复成本、风险、影响范围）分开打分再综合；明确"严重度=P0/P1/P2/P3"（对业务影响）与"优先级"（综合修复时机）的区分；建立评审机制（业务+技术共同评审），对争议缺陷按既定规则裁定并记录依据。

冲突的根源是"严重度（业务影响）"与"优先级（综合修复时机）"的混淆。用统一矩阵把两者分开量化并共同评审，才能让双方在同一套规则下达成一致。

• 验收证据链的组成
• 验收记录、缺陷清单、签字授权的组织
• 合规审计与责任追溯

验收证据链要支撑"谁在何时基于什么依据验收了什么、结论如何"的可追溯。组织方式：验收记录——记录每个验收用例的执行人、时间、环境、数据、执行结果与证据（截图/日志/数据快照），形成可复核的测试记录；缺陷清单——记录缺陷的描述、发现时间、严重度、状态、处理人与结论，形成完整的缺陷生命周期；签字授权——明确各业务角色的授权范围与签字权限，验收签字单记录各方签署意见、日期与结论，作为正式交付依据。同时要建立版本对应关系（验收的软件版本、环境、数据），并妥善归档，保证从"验收依据（AC）→执行记录→缺陷→签字"能完整追溯。这样合规审计时能还原验收全过程，责任归属清晰。

证据链的核心是"可追溯"与"可归责"。把验收依据、执行记录、缺陷、签字按版本和角色串起来，才能支撑审计与责任界定，避免"验收无凭"。

• 需求漂移的识别与分类
• 验收时发现不一致的处理方式
• 变更管理与影响评估

需求漂移是需求随项目推进逐渐偏离原始约定，验收时发现"系统按需求实现，但用户期望已变"。处理流程：先识别漂移——区分"需求已变（用户期望改了）"与"需求理解偏差（实现与需求不符）"；对已变的需求，进入变更管理流程——评估变更的影响（范围、成本、时间、风险），与用户协商是否纳入本次验收还是作为后续迭代；对理解偏差，澄清需求并确认是否需修复。不能简单"按旧需求验收"或"按新期望全盘重做"，而应：重大漂移走正式变更（评审、重新定验收标准、影响交付计划），轻微漂移记录并纳入版本计划，同时更新验收标准与 AC，让验收与实际需求对齐。整个过程要文档化并让业务确认。

需求漂移的本质是"需求与期望随时间脱节"。处理的关键是"识别→变更管理→对齐验收标准"，而非单方面接受或拒绝，在"守约"与"顺应新需求"之间找平衡。

• 业务场景驱动的 UAT 用例设计
• 用例的可执行性
• 用户参与管理

可执行的 UAT 用例应"业务场景驱动"而非"技术功能驱动"：按真实业务流程组织用例，用业务语言描述（如"销售员录单并提交折扣审批"），明确前置条件、操作步骤、预期业务结果与验收标准，让业务用户能直接理解并执行。用例设计要点：覆盖核心业务场景与关键路径、包含边界与异常场景、步骤可操作（如"点击某按钮→填写某字段"而非抽象描述）、预期结果可验证（有明确业务判定）。用户参与管理：把用例按业务角色分配，让用户执行自己负责的场景；提供清晰的执行指引与数据说明；建立执行进度跟踪与问题反馈渠道；及时处理 UAT 中发现的缺陷并反馈，维持用户参与积极性；对参与度低的用户安排提醒与支持。

可执行性的关键是"用业务语言、按真实场景、可操作可验证"。用户参与管理是保证用例被执行、执行有结果、结果被跟进，从而让 UAT 真正有效。

• 可执行规格（Executable Specification）的概念
• 自动化验收与 BDD 的结合
• 自动化在 UAT 中的角色与边界

可执行规格（Executable Specification）是把需求/验收标准写成可被自动化执行的格式（如 BDD 的 Given/When/Then、行为测试），让"规格即测试"，需求的验收条件直接由测试代码验证，从而弥合"需求文档"与"测试执行"的鸿沟。在 UAT 中结合自动化：把关键业务场景的验收条件写成自动化测试（如 Cucumber、SpecFlow），在 UAT 前由测试团队自动执行验证"业务行为是否符合 AC"，UAT 用户再基于真实业务判断做最终确认；自动化验收适合可回归、可量化的核心链路，而 UAT 的人工部分负责无法自动化的主观体验与真实业务判断。自动化验收能提升效率与可重复性，但不能替代业务用户对"业务可接受性"的把关。

可执行规格的精髓是"用可执行的形式表达需求"，让验收标准自动验证。但 UAT 的"业务可接受性"仍需人工判断，自动化是加速器而非替代者，二者结合。

• 缺陷、需求变更、使用习惯差异的区分
• 各自的处理流程
• 边界判定与沟通

UAT 中用户提出的问题需要区分三类并走对应流程：缺陷（Defect）——系统行为与已确认需求/规格不符，属于"实现错了"，走缺陷修复流程，修复后回归验证；需求变更（Change Request）——系统按需求实现了，但用户希望新增或改变功能，超出原需求，走变更管理流程（评估影响、成本、时间，决定本期或后续版本）；使用习惯差异——系统按需求实现了，但用户期望的使用方式与习惯不同，属于"认知/习惯差异"，需澄清说明（培训、文档、沟通），而非改代码，除非体现为真实需求。边界判定方法：先对照需求/AC 确认"系统是否按约定实现"——是则按需求处理（缺陷或习惯），非则按变更处理；对争议项与业务共同评审，明确归类和去向，避免需求蔓延。

边界管理的核心是"对照约定的需求/AC 划分问题性质"。只有明确"实现是否符合约定"，才能区分缺陷（不符）、变更（超出约定）与习惯差异（符合但用户不习惯），并走对应流程。

• 用例执行率与业务覆盖度的区别
• 核心业务流程覆盖率的度量
• 用覆盖度评估 UAT 充分性

用例执行率只反映"执行了多少用例"，无法反映"业务是否被充分覆盖"——可能执行了很多但核心流程漏测。业务覆盖度应基于"核心业务流程"衡量：先梳理系统的核心业务流程清单（如用户注册、下单支付、对账、退款等关键业务链条），再统计每个核心流程的关键场景与分支是否被 UAT 用例覆盖、是否被执行并验证通过。度量方法：核心流程覆盖率 = 已覆盖且通过验证的核心流程数 / 核心流程总数，并进一步核查每个流程的变体（正常、异常、边界）覆盖。同时关注"业务角色覆盖"（每类角色的关键操作是否被验收）与"业务风险覆盖"（高风险业务点是否验证）。评估 UAT 充分性应结合覆盖率与质量（缺陷关闭情况），而非只看执行率。

执行率是"过程指标"，覆盖度是"结果指标"。UAT 充分性要看核心业务是否被真实验证，因此要按业务流程（而非用例数）度量覆盖，并辅以角色与风险覆盖。

• UAT 使用真实数据的安全合规要求
• 脱敏、最小化、授权
• UAT 与系统测试数据使用的差异

UAT 需使用与生产一致的数据以保证真实性，但使用真实业务数据涉及合规：脱敏（Data Masking）——对个人敏感数据（姓名、身份证、手机号、地址等）进行脱敏/匿名化，在保证业务特征（格式、分布、关联）的同时保护隐私；最小化——只抽取满足验收所需的最小数据集，避免全量复制；授权——明确数据的获取、使用、存储与销毁的授权与合规依据（如隐私政策、数据使用协议），并限制访问范围。与系统测试相比的差异：系统测试多用合成/测试数据，UAT 因需真实业务特征而倾向使用脱敏的真实样本；UAT 数据更接近生产、合规要求更高（涉及真实个人信息），需更严格的脱敏、授权与审计；系统测试数据量大但合规要求相对低，UAT 数据量小但合规与真实性要求高。

差异的本质是"真实性与合规性的权衡"：UAT 用真实数据换取业务真实性，同时必须满足脱敏、最小化、授权等合规要求，且比系统测试更严格，因为涉及真实个人数据。