企业 AI 项目 Wiki · 测试与验收

验收标准

也常写作Acceptance criteria · 验收条件 · 通过标准

定义

验收标准是项目相关方事先约定、用于判断指定交付物或版本是否可以被接受的一组可验证条件。它要说明验收对象、适用场景、预期结果、允许范围、验证方法、所需证据和确认责任，使“通过”或“不通过”能够依据记录作出，而不是依赖临场感觉。

验收标准到底解决什么问题

需求描述想实现什么，验收标准则把其中需要被确认的结果变成判定条件。它让客户、实施团队和测试人员在开发前就知道什么结果算完成，也让报价、排期、测试范围和问题处理有共同依据。

验收标准应当在实施和正式验收之前确定。项目进行中可以因需求变化而修订，但必须记录修改原因、影响范围、批准人和生效版本，不能在看到测试结果以后临时改变口径。

标准的对象既可以是一项功能，也可以是一批数据、一次系统集成、一个可交付版本或整期项目。对象越大，越需要拆分为能够逐项验证的条件，并说明关键条件是否具有一票否决作用。

一条可执行的验收标准由什么组成

不一定每条都写成八个字段，但下面的信息必须能够从标准或它引用的验收资料中找到。

标准编号与需求来源

为标准提供稳定标识，并关联需求、范围项、业务规则或风险，使变更和测试结果可以追溯。

明确的验收对象

指出功能、接口、数据、文档、模型配置或具体版本，避免测试结果与后来变更的对象混在一起。

前置条件与适用场景

说明用户角色、账号权限、环境、数据状态、外部依赖以及正常、边界、异常或资料不足场景。

可观察的预期结果

直接描述页面、数据、系统动作、业务状态或人工接手应出现什么，不只写内部实现方式。

阈值与允许范围

对时间、数量、误差、成功率或质量等级给出单位、统计口径、样本范围和允许偏差；不能只写“快”“稳定”或“准确”。

验证方法

说明通过测试、演示、检查、分析还是材料审阅确认，以及由人工、自动化程序或双方共同执行。

证据与记录位置

规定保存测试结果、日志、截图、报告、样本版本、问题单或签字记录，使结论能够复查。

确认责任与例外规则

说明谁有权判定通过，关键失败怎样处理，哪些偏差可以带条件接受，例外由谁批准。

项目通常要在哪些维度设置标准

业务与功能结果

角色是否能够完成目标业务流程，规则、状态转换、计算和异常提示是否符合已确认需求。

数据与接口结果

字段、格式、映射、去重、同步、失败重试和对账是否正确，数据差异怎样发现和处理。

性能、容量与可用性

在约定负载和条件下检查响应时间、吞吐、并发、资源使用、稳定运行时间和故障恢复，而不是脱离场景写一个孤立数字。

安全、权限与审计

正确角色能做什么、无权角色必须被阻止什么、敏感操作怎样确认和留下记录，以及已知风险是否完成处置。

运行与可维护性

部署、配置、监控、告警、备份、恢复和故障联系方法是否可用，接手团队能否依据移交资料继续运行。

资料与交付完整性

代码、配置清单、部署说明、操作手册、许可、账号和培训是否按范围交付，并能与正式版本对应。

怎样从需求写成验收标准

确认对象和决定人
先确定本次验收的范围、正式版本和有权作出结论的人，避免标准没有明确归属。
从业务结果和风险出发
列出用户必须完成的工作、不能发生的错误以及失败会造成的业务影响，再决定哪些条件必须验证。
按场景拆分
分别写正常、边界、异常、权限不足、资料不足和外部依赖失败场景，不把完全不同的结果塞进一句话。
确定测量方法和阈值
选定样本、环境、重复次数、统计口径和允许偏差；无法合理量化时，建立清楚的人工评审量表。
定义证据和停止条件
说明每项结果怎样留证，出现安全、数据损坏、越权或其他关键失败时是否立即停止验收。
共同评审并冻结版本
由业务、技术、测试和项目负责人检查可理解性、可执行性和成本，在实施前形成有版本的确认记录。
变更时保持追溯
需求、标准、用例和问题记录同步更新，旧结果不得直接用来证明新标准或新版本已经通过。

模糊写法与可验收写法有什么区别

右侧只用于说明表达结构，具体数字必须来自项目需求、风险和可验证依据。

不能直接判定的写法	可以继续形成用例的写法
系统响应要快	在约定测试环境和并发负载下，指定核心操作的响应时间按双方确认的统计口径达到目标值，并保存测试报告。
AI 回答准确	在冻结版本的分层样本集上，分别检查事实、引用、资料不足、敏感场景和高风险操作；每类使用自己的指标、阈值和关键失败规则。
权限功能正常	列明每个角色允许和禁止的操作；无权访问必须被阻止并留下审计记录，授权角色完成操作后业务状态正确更新。
接口对接完成	对约定字段和状态执行成功、重复、超时、无效数据和依赖失败测试；结果、重试、幂等和告警行为符合接口约定。
项目资料已交付	按交付清单逐项核对文件名称、版本、可打开性、必要权限和接收人；部署说明能由指定接手人员完成一次受控验证。

怎样根据标准作出验收结论

逐项记录，不只给总分

每项标准保留通过、不通过、阻塞或不适用状态，并附实际结果和证据。总分不能掩盖单个安全、数据或核心业务失败。

关键标准单独设门槛

对越权、数据损坏、错误业务操作、无法恢复等高影响结果，可规定出现一次即停止或不通过，而不是与低风险项目平均。

问题需要完成闭环

失败项记录等级、影响、负责人和修复版本；复测应在可识别对象上执行，并同时覆盖可能受影响的回归范围。

带条件接受要明确责任

如果在遗留问题未关闭时接受，应列出已知偏差、风险、临时措施、责任人、完成期限和批准人，不能把沉默当作默认接受。

最终结论对应具体版本

验收记录应标明版本、环境、样本、标准版本、执行日期和确认人。之后发生实质变更，需要重新判断受影响范围。

企业 AI 项目的验收标准还要增加什么

样本是否代表实际使用和高风险场景？
样本需要按业务类型、用户角色、资料质量和风险分层，并记录来源、版本和适用边界。
核对：样本清单、标签分布、抽样方法、业务复核记录。
是否避免用一个平均准确率包办全部结果？
事实正确、引用、完整性、拒答、工具调用和人工接手属于不同结果，应分别测量并设置门槛。
核对：分场景指标、人工评分量表、关键失败清单。
资料不足时的行为是否可验收？
系统应在知识不足、资料冲突或超出权限时采取约定的澄清、拒答或人工接手动作，不能靠编造补齐。
核对：资料不足样本、预期动作、引用或拒答记录。
会产生业务副作用的操作是否单独设门槛？
修改订单、发送消息、写入系统、审批或付款等动作应验证参数、权限、确认、幂等、审计和失败恢复。
核对：工具权限表、操作日志、重复和失败场景结果。
非确定性和版本变化怎样处理？
必要时重复运行以观察波动，记录模型、提示词、知识库和参数版本，并规定哪些变化触发重新评估。
核对：运行配置、重复结果、版本差异和再验收规则。
是否保留人工判断与申诉路径？
高风险或主观质量场景需要指定业务人员评审，并说明用户怎样纠错、申诉或转人工。
核对：评审人、评分说明、人工接手记录和反馈闭环。

验收标准容易与什么混淆

相关概念	与验收标准的区别
需求	需求说明系统应提供什么能力或满足什么约束；验收标准说明怎样判断指定结果已经满足需求。
验收方案	验收方案组织对象、人员、环境、时间、样本、流程和结论方式；验收标准是方案用来作出判定的条件。
测试用例	测试用例包含具体前置条件、输入和执行步骤。一条验收标准可以由多个用例验证，一个用例也可能提供多项标准的证据。
完成定义（Definition of Done）	完成定义通常是团队对每个增量普遍适用的质量要求；验收标准针对具体功能、交付物或项目结果。
验收测试	验收测试是执行验证的活动；验收标准是测试结果要对照的判定依据。
服务水平目标	服务水平目标描述持续运行期间的服务表现；项目验收标准可以引用它，但一次验收不能自动证明长期表现。

依据与适用边界

本文解释企业软件和 AI 项目中用于判断交付结果能否被接受的验收标准，不替代合同、采购制度、行业监管或法律意见。标准的数量、阈值、优先级、签字方式和例外处理必须结合具体项目确认；本文也不把单条用户故事的验收条件等同于整个项目的最终验收。