验收标准的目的、格式和最佳实践

任何项目的成功都取决于开发团队满足客户需求的能力。客户和开发团队之间的沟通对于提供符合产品和市场需求的解决方案起着至关重要的作用。如果客户对自己的需求解释的太过模糊，而团队又无法理解清晰的需求，最终无法理解需求背后的业务问题，那么问题就会出现。想象一下，你要求你的团队能够让用户在网上书店按类别搜索产品。你期望有一个清晰的界面，上面有类别链接，可以点击这些链接（比如奇幻、非虚构、历史等）经过两周的开发，你收到了一个搜索栏功能，用户必须输入他们感兴趣的类别，而不是浏览预先列出的类别。虽然这也可以，但你的最初目标是暴露所有可用的类别，让用户进一步探索。

这时，高质量的软件文档可以帮助避免这个问题。用户故事和验收标准（AC）作为记录需求的主要格式。用户故事是对一个功能的自然语言描述。它通常伴随着验收标准。

验收标准（Acceptance criteria，AC）是软件产品被用户、客户或其他系统接受所必须满足的条件。它们对于每个用户故事来说都是独一无二的，并从最终用户的角度定义了功能行为。写得好的验收标准有助于避免在开发阶段结束时出现意想不到的结果，并确保所有利益相关者和用户对他们得到的东西感到满意。

验收标准是最低层次的功能要求

验收标准主要目的

明确利益相关人的要求是一个高层次的目标。为了让AC的目的更加明确，我们来分解一下：

特性范围细化：AC定义了用户故事的边界。它们提供了关于功能的精确细节，帮助团队了解故事是否完成并按预期工作。

描述负面场景：你的AC可能要求系统识别不安全的密码输入，并阻止用户继续进行。无效的密码格式是所谓的消极场景的一个例子，当用户做无效的输入或行为出乎意料。AC定义了这些场景，并解释了系统必须如何对这些场景做出反应。

建立沟通：验收标准使客户和开发团队的愿景同步。确保他们每个人对需求有一个共同的理解。开发人员确切地知道功能必须表现出什么样的行为，而利益相关人和客户则了解对功能的期望。

简化验收测试。AC是用户故事验收测试的基础。每个验收标准必须是独立的可测试的，从而有明确的通过或失败的方案。它们也可以通过自动化测试来验证故事。

特性估算。验收标准规定了团队到底必须开发什么。一旦团队有了精确的需求，他们就可以将用户故事拆分成可以准确估算的任务。

验收标准的类型和结构

AC可以用不同的格式来写。最常见的有两种，第三种选择是设计自己的格式。

• 情景导向(Given/When/Then)

• 规则导向

• 自定义格式

由于第一种和第二种格式有非常特殊的结构，我们将主要关注它们。但是，你可能会发现其他格式更适合你的产品，所以我们也会简单的介绍一下。

场景导向的验收标准

面向场景写AC的格式称为Given/When/Then（GWT）类型。

• 给定一些前提条件

• 当我做一些动作时

• 那么我希望有一些结果

这种方法是从行为驱动开发（BDD）中继承过来的，它提供了一个一致的结构，帮助测试人员定义何时开始和结束测试某个特定功能。它还减少了编写测试用例所花费的时间，因为系统的行为在前期已经被描述了。

以这种格式编写的每个验收标准都有以下语句。

1. 1. 场景——将被描述的行为的名称。

2. 2. Given——情景的开始状态

3. 3. When——用户做出的具体操作

4. 4. Then——"When"的行动结果。

5. 5. And——用于接续前面三种说法中的任何一种。

当这些语句组合在一起时，涵盖了用户为完成任务和体验结果所采取的所有行动。

我们来看看一些例子：

例1

用户故事 作为一个用户，我希望能够找回我的账户密码，这样我就可以在忘记密码的情况下访问我的账户。

场景：我忘记了密码，希望能够找回我的账户密码。

Given：用户已浏览到登录页面。

When：用户选择了忘记密码选项

And：输入有效的电子邮件，以接收密码恢复的链接。

Then：系统将链接发送到输入的邮箱

Given：用户通过电子邮件收到了链接

When：用户通过邮件中的链接进行浏览。

Then：系统允许用户设置新的密码。

例二

用户故事 作为一名用户，我希望能够在ATM机上从我的信用卡账户里取出现金，这样我就可以在不同的地方快速取出账户里的钱。

验收标准 1:

Given：该账户是有信用额度的

And：该卡是有效的

And：ATM里有现金

When：客户要求取出现金

Then：确保账户被扣款

And：确保发放现金

And：确保卡的归还

验收标准2:

Given：该账户已透支

And：该卡是有效的

When：客户要求取出现金

Then：确保显示拒绝信息

And：确保不发放现金

规则导向的验收标准

在某些情况下，很难将接受标准融入到Given/When/Then结构中。例如，GWT对于以下情况几乎没有用处。

• 你正在处理描述系统级功能的用户故事，而这些功能需要其他的质量保证方法。

• 验收标准的目标受众不需要测试场景的精确细节。

• GWT场景不适合描述功能的设计和用户体验约束。开发人员可能会错过一些关键的细节。

你可以用面向规则的AC形式来解决这些情况。

面向规则的形式需要有一套规则来描述系统的行为。根据这些规则，你可以得出具体的方案。

通常，使用这种形式组成的标准看起来像一个简单的子弹列表。让我们来看一个例子。

比如：

用户故事 作为用户，我想通过搜索栏输入城市、名称或街道，这样就可以找到匹配的可供选择的酒店。

基本搜索界面验收标准

• 搜索栏放在顶部栏上

• 当用户点击 "搜索 "时，搜索就开始了。

• 该字段包含一个带有灰色文字的占位符。"你要去哪里？"

• 一旦用户开始输入，占位符就消失了

• 如果用户输入城市、酒店名称、街道或所有组合，则进行搜索。

• 搜索有英文、法文、德文和乌克兰文。

• 用户输入的符号不能超过200个。

• 搜索不支持特殊符号（字符）。如果用户输入了特殊符号，显示警告信息。"搜索输入不能包含特殊符号"。

其他格式

大多数用户故事都可以用上面提到的两种格式来涵盖。不过，你可以发明自己的验收标准，只要它们能达到目的，用纯英文（中文）写清楚，并且不会被误解。（有些团队甚至使用纯文本）

有时，你的标准可能被指定为系统行为的例子：

马克-莱维森为agilepainpareief.com编写的一套简单的强密码AC。

该方法为密码功能测试提供了明确的指导方针。

负责的角色和如何创建验收标准

有些标准是由产品负责人（PO）在创建Product Backlog时定义和编写的。而其他的标准可以由团队在Sprint计划会后的用户故事讨论中进一步制定。选择负责撰写标准的人并没有严格的建议。如果客户有丰富的技术和产品文档知识，可以将其记录下来。在这种情况下，客户与团队协商标准，以避免相互误解。否则，标准由 产品负责人、业务分析师、需求分析师或项目经理来创建。

这个过程从用户故事优先级的确定开始，到与整个团队协商细节结束

撰写验收标准的主要挑战和最佳做法

验收标准看起来好像很容易写。尽管它们的格式很简单，但写作对许多团队来说是一个挑战。让我们深入了解一下有助于避免常见错误的最佳实践。

在开发前记录标准。验收标准必须在实际开发开始之前记录下来。这样，团队就有可能提前捕捉到所有的客户需求。在开始的时候，为少量的用户故事设定标准就足够了，以填补两个Sprint的Backlog（如果你实践Scrum或类似的方法）。这些标准必须得到双方的同意。然后，开发人员使用文档化的验收标准来规划技术流程。

不要把AC做得太窄。 验收标准可能太过具体，几乎没有给开发人员提供任何机动的选择。为了避免这种情况，请记住，验收标准必须传达意图而不是最终的解决方案。此外，狭隘的AC可能会遗漏多个没有被覆盖的用户行为。

保持你的标准是可以实现的。这一点与上一点密切交集。有效的验收标准定义了你能够提供的合理的最小功能块。但万一你屈从于描述所有的小细节，你的团队就有可能被数百个小任务卡住。

保持AC的可衡量性，不要太宽泛。宽泛的验收标准会使用户故事变得模糊不清。有效的验收标准必须勾勒出工作范围，这样开发人员才能正确地计划和估计他们的工作。

避免技术细节。正如我们所提到的，验收标准必须用简单的英语（汉语）书写。这将使它们对每个人来说都是清晰易懂的，毕竟你的利益相关人或经理可能没有技术背景。

达成共识。同样的问题，根据团队和利益相关人的不同观点，可能会有不同的解决方法。确保你已经向利益相关人传达了你的AC，并达成了双方的共识。这同样适用于团队成员。每个人都必须审查AC，并确认他们理解并同意每一行。

编写可测试的AC。这将使测试人员能够验证是否满足了所有需求。否则，开发人员就不会明白用户故事是否已经完成。

结语

不要忽视验收标准，因为它们——简单易行——可以同时解决多个问题。它们记录了客户的期望，提供了最终用户的观点，澄清了需求并防止了歧义，最终帮助质量保证验证是否达到了开发目标。无论你是否使用敏捷方法，一定要选择最好的格式或试验自己的格式。不同类型的用户故事和最终的功能可能需要不同的格式，测试适合你的新格式是一种很好的做法。

原文：https://www.altexsoft.com/blog/business/acceptance-criteria-purposes-formats-and-best-practices/

译者：Joanna Li