您正在为网站开发功能。 这是一个简单的登录表格。 由于您是个精通软件的超人，因此您决定先进行一些基本计划，然后再进行开发。 至少，您要确定要构建的功能的某些方面。
这就是你的想法； 你需要：-
· 用户名和密码的输入框
· 提交按钮
· 一种通知用户是否输入了错误的详细信息的方法
· 某种方法来恢复被遗忘的细节
· 如果他们还没有帐户，可以通过某种方式注册
即使简单的功能也可能难以设计。 您已经列出了要跟踪的五件事。 也许它不止于此。 没有适当的规划就着急开发功能很疯狂，但是您知道这一点，并且已经在上面编写了清单。
那么，够了吗？
好吧，如果您想编写某种行为测试该怎么办？ 您如何将以上内容转化为用户步骤？ 这样的"简短标语"方法是否可以告诉您有关用户实际如何执行这些操作的足够信息？ 您是否考虑过用户成功登录后会发生什么？ 这种方法是否鼓励这种想法？
我们知道我们需要什么，但是这如何转化为精心设计的功能？
您可能猜到了答案：验收标准。
什么是验收标准？
接受标准是一组步骤的不必要的模糊名称，这些步骤可绘制出用户可能如何与特定功能交互的信息。 它们以使用"给定"，"何时"和"然后"步骤的格式编写，并映射到用户操作。 因此，它们很容易转换为行为测试。 以这种方式设计功能也是识别使该功能正常工作可能需要的其他好方法。
您的登录表单的接受条件示例如下所示：
Given I have an account registered with
给定标识了该操作的某种先决条件。 什么时候指定动作。 然后定义动作的结果。 我们还可以使用And通过添加额外条件来补充任何阶段。 这种方法是逻辑，清晰和简单的。 这些步骤中的每一个都准确解释了该场景中预期发生的情况。
我们也可以轻松地为此编写行为测试，因为我们确切知道涉及的设置，动作和结果。 我们有测试的前提条件：用户必须拥有一个帐户。 我们有一个动作：用户单击登录按钮。 我们得到的结果是：用户已登录并查看主页。
该AC还为我们提供了一些额外的信息。 在编写它时，我意识到我不知道用户成功登录后会怎样。格式化这样的要求迫使我不得不思考，从而推动了产品设计和用户体验。
最后，借助格式，AC鼓励您采用更合乎逻辑的思维方式，并且由于使用了"然后"，因此可以确保您仔细考虑用户操作的结果。 它使您关心的是用户可能会如何体验您的应用程序，而不只是关注您想制作的所有有趣的东西。
我如何写好的交流电？
因此，您在编写这些东西时大受欢迎，但是您如何正确地做呢？ 上面的登录功能非常简单，但是更复杂的概念可能会导致AC混乱，因此请务必牢记以下几点：
· 从用户角度撰写
这是规则编号。 接受标准与您作为开发人员如何与某些事物进行交互无关。 这与您如何希望某人与某物进行交互无关。 您必须假装自己是地球上最无助和最令人讨厌的事物：用户。 因为那将是谁来处理您宝贵的登录表单。
2.简单性
AC应该很容易理解。 尝试将每行映射到特定的用户操作或先决条件，例如输入正确的用户详细信息或已在应用程序中注册。 试图包含多个事物的冗长的AC可能会影响清晰度，从而否定上述许多好处。
3.朴素的语言
这一点与第2点有关，并直接影响它。 用简单的语言写AC。 这种方法的主要优点之一是非技术人员可以理解它。 能够向任何人描述功能并同时推动实施/测试的工具非常宝贵。 复杂的语言会妥协。
4.避免实施细节
AC应该描述用户如何与功能交互； 它不应描述该功能的外观或其在幕后的操作方式。 您实现某些事情的方式会并且会比想法本身更频繁地发展。 登录是很常见的，但是提交按钮的颜色或它使用的身份验证提供程序的颜色与放屁一样具体。
5.不要技术
同样，这一点与上述内容有点相关。 不要提及算法或机器学习，也不要说线粒体是细胞的强大力量。 没关系
交流本身是否足够？
不，这只是起点。 它可以驱动您的设计，可以传达您的愿景并可以帮助您进行测试，但这不是万能的。 您仍然应该编写子任务，以更好地定义功能的更多技术方面，创建模型并编写具体示例。 所有这些东西都是有效且有价值的，应该使用，但是写得很好的接受标准是一个坚实的起点，并且如果正确完成，将始终会带来质量更高的软件。
除非您是Adobe，否则无论您做什么都不重要，它仍然会变得很糟糕。
(本文翻译自Lee McGowan的文章《Software Design: What is Acceptance Criteria and why do you need it?》，参考：https://medium.com/javascript-in-plain-english/software-design-how-to-write-good-acceptance-criteria-b4aed47b4ad7)
閱讀更多 聞數起舞 的文章
