敏捷质量实践中提倡测试左移，测试人员要尽早介入需求阶段，越早越好。测试人员需要关注需求的有效性，以及在需求产生和传递的过程中，交付价值是否被准确的描述、理解和对齐。在这个过程中很容易遇到一个常见问题：验收标准是验收测试要测的吗？验收标准到底是不是测试用例？这两者之间有什么区别和联系？本文主要想解决的就是这个具体的困惑。

验收标准是确保需求实现的最小集合

验收标准是什么

回顾一下需求由厚厚的《软件需求规格说明书》演化为一张用户故事卡片的过程，在这个过程中我们舍弃了大量的细节描述，突出了需求需要交付的客户/用户价值。在需求交付的过程中，我们会一直关注价值，在保证价值的前提下，实现方式和技术细节都是可以讨论的。

那么问题来了，既然很多内容都是可以讨论的，我们怎样确定一个用户故事被实现完成了呢？验收标准就是用户故事实现完成的试金石。可以这样说，一个用户故事能否被标记为开发完成并进入测试阶段，很大程度上取决于验收标准是否全部通过。

通常来说，验收标准就是一系列可以接受的条件或者业务规则，且与功能或特性相互匹配和满足，同时也能被产品负责人和相关干系人接受。

敏捷实践中，推荐使用行为驱动开发（Behavior-driven development，缩写BDD）的方式来写验收标准，即使用GWT格式。

• Given （在什么样的情景或条件下）

• When （采取了什么行动）

• Then （得到什么结果）

举个例子：

• Given （假设） 我在搜索界面

• When （当） 我填写入住城市，选择住宿时间

• Then （于是） 我可以浏览该城市和该时间段内空闲酒店的名字和价格

在编写验收标准时，应重点关注可以验证需求实现的用户场景上，更多的是正向验证用户需求实现完成，切忌将验收标准写成测试用例或者测试点。

验收标准在什么时候用

故事启动（Story Kickoff）

在故事启动时，需求涉及的全部角色：需求分析师、开发、测试、体验设计师，大家需要坐在一起进行需求澄清，确保所有人对需求的理解一致，并约定好故事验收时的验收标准都有哪些。在这个过程中，任何人都可以针对验收标准进行提问，或者补充更多的验收场景。

故事验收（Desk Check）

当开发人员完成代码实现后，做一些基本的自测工作，并准备好验收场景和数据，就可以约大家进行故事验收了。验收时，也需要需求设计的全部角色，大家坐在一起，听开发讲解实现细节，并逐一演示验收场景。如果验收标准全部验证通过，大家也没有其他问题，这个用户故事就可以被标记为开发完成，准备进入测试阶段了。

用户验收测试（User Acceptance Test）

除了研发团队的测试外，迭代的交付还需要一定的用户验收测试。用户验收测试的设计和执行者有时是PO、或是提出需求的客户及相关干系人，有时是小范围内测或公测的真实用户。在用户验收测试时，执行者也会在一定程度上参考验收标准，检验验收标准是否完备，是否都能满足用户预期的验证通过。

验收标准不是验收测试

从上文的讨论中，可以得出结论：验收标准是定义用户故事完成的标准。而验收测试分为两部分，一部分发生在用户故事开发完成后，是研发团队内部的验收，另一部分是在测试完成后上线前，由客户或真实用户进行验收。由此可见，验收标准并不等于验收测试，验收标准是验收的最小集，而验收测试的范围要更广。

测试用例验证了软件功能的有效性

测试用例是什么

测试用例是指为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。简单来说，测试用例就是用文字来描述以怎样的步骤测试一个测试点，以及期望的测试结果是什么。

测试用例通常会包括：描述、优先级、前提条件、执行步骤、期望结果、实际结果和备注等信息。根据项目各自的特点，测试用例包含的信息不尽相同。

测试用例在什么时候使用

用例设计和评审

在测试设计阶段，测试人员根据需求，采用多种设计思路来编写测试用例，并提交至测试组或项目组进行用例评审。此时，测试用例承载了业务需求的测试点，以及测试人员基于专业经验识别出的非业务需求类的验证点。

测试执行

在测试执行阶段，测试人员（有时也是用例编写者）按照用例的详细描述执行测试用例，并根据实际执行结果与预期结果是否一致，来判定该测试用例是否通过测试。不通过的用例需要分析原因，报缺陷或以其他方式进行跟进。

回归测试

开发对用例相关的功能进行改进，或者修复了相关缺陷，就需要对指定用例进行回归，确保功能没有被改坏，或者缺陷确实被修复了。另外，有时在重大上线前，也需要按优先级选取一定量的测试用例来进行回归测试，以确定主线业务流程功能正常。

沟通测试点

测试用例还有个很重要的作用，记录具体的实现细节以及框定需求的测试范围。多个迭代过去，大家在需要翻看历史需求时，可能故事卡不足以还原全部的实现细节，测试用例集在这个时候就能够完整的告诉大家：软件是怎么实现的，当执行某些操作时，程序有什么表现，以及当时这个需求的测试范围是什么。尤其在团队成员上下文不足时，良好设计并编写的用例集可以完美补齐这些知识。

验收标准不是测试用例

以上我们讨论了验收标准和测试用例分别是什么，以及在什么阶段使用。容易得出，验收标准与测试用例是完全不同的两件事，两者的相同点在于它们都是可判定的用户使用场景，可以根据预期来判断是否通过，而两者的区别体现在下表中的各个维度上。

本文我们还讨论了验收标准不是验收测试。仅从覆盖范围来看，验收标准、验收测试、测试用例的关系可以参考下图：

• 测试用例：覆盖范围最大，应该是确保软件功能正常、满足用户预期的测试全集

• 验收测试：覆盖范围比测试用例小，只覆盖验收需要的测试用例

• 验收标准：覆盖范围比验收测试小，只覆盖验证需求实现完成的测试用例

当然，验收标准和测试用例除了使用时机外，两者的区别也体现在不同的责任人和使用范围。验收标准的责任人是需求分析师，在团队协作过程中使用，是多角色合作的基础；而测试用例的责任人是测试人员，属于测试专业上下文的内容。但在不同的组织结构下，对角色的定义会存在一定模糊的界限，因此，“全团队为需求的验收和质量负责”是比较推荐的理念。

相信经过本文的澄清，我们已经搞懂了验收标准和测试用例到底是怎么回事。随着行业的发展，为了测试左移，将有越来越多的测试人员需要懂需求；相应的，为了高效产出高质量的需求，也有越来越多的需求分析人员需要懂测试。需求分析人员与测试人员一起打造高质量的需求，将为交付高质量高价值的软件奠定坚实的基础。

作者：于晓南 

原文链接：https://insights.thoughtworks.cn/acceptance-criteria-testcases/