AC（Acceptance Criteria，验收准则）和TC（Test Cases，测试用例）两者既有区别，又有联系。在实际应用中，我们常常混淆两者的概念，下面笔者将根据自己的理解来说说两者间的关系。
1、什么是AC？
AC全称Acceptance Criteria，又名“验收准则”，是敏捷测试中user story（用户故事）的重要组成部分。AC是针对user story内容的说明和解释，是根据user story的阐述制定的验收标准。AC初稿由BA（Business Analyst，业务分析师）根据客户的需求来编写，需user（用户）、BA、QA（Quality Analyst，质量分析师）和DEV（Developer，开发人员）共同review。每一条AC都应体现出业务价值，是story的功能集，是story交付时必须满足的一组条件。
2、什么是TC？
TC是Test Cases（测试用例）的缩写。与AC不同的时，TC主要由测试人员根据AC来编写，BA、QA和测试人员一起review。从开发流程来讲，TC应该是story交付前必须执行的测试；从内容上来说，TC是AC的具体实现，应该比AC更将详细，必须包括AC的所有内容。此外，TC还应包括很多异常测试用例，以确保系统对异常能正确的处理。
总结所述，AC和TC的包含关系主要如下图所示：
通常，AC（Acceptance Criteria，验收准则）的编写会使用Given-（and）-When-（and）-Then的格式。Given表示前置条件，When描述测试步骤，Then表示执行结果。
比如编写某个邮箱aaa发送邮件功能的AC1：作为一个aaa邮箱普通用户，我想要编写邮件发送给我的朋友Jerry，邮件发送成功。转换为Given-（and）-When-（and）-Then的描述方式如下：
Scenario 1：收件人地址正确，邮件发送成功
Given 普通用户userA登录aaa邮箱成功
When 用户userA编写邮件，邮件内容不为空
and 在“收件人”输入Jerry邮箱地址，邮箱地址存在
and 点击“发送”
Then 提示“邮件发送成功”
如上例所示，使用Given-（and）-When-（and）-Then格式后，对于测试场景的输入和输出一目了然，可以有助于用户和测试人员快速理解，便于测试人员将AC转化为TC执行。
2、编写AC时应该关注些什么？
1）AC不是TC（Test Cases，测试用例）
AC只是为了确保用户故事完整并使用此验收的标准。当团队据此验收标准创建了一套TC，并测试成功通过后，我们可以声明用户故事是完整的，系统可以根据客户的期望而发挥作用。 因此，AC是根据敏捷的用户故事定义高水准的接受标准，TC是使用这些标准来定义与接受标准相比非常详细的实际测试用例。 从某种程度而言，TC可以看作是AC的详细步骤解析。
如将上述Scenario 1的AC1转换为TC，TC描述如下表所示：
2）用户和场景
AC是为story验收准备的，在编写AC时，我们需着重关注点应该用户和用户使用场景，即：什么用户在什么场景下使用该系统（功能）。我们应该认知到，及时在比较清楚某个story的情况下，我们也不能捕获所有的场景。因此，只有清楚地了解用户和用户使用场景之后，我们才能对用户场景进行由高到低的使用频率排序。在编写AC的过程中，我们应该首要保证使用频率高的用户场景有足够的测试执行并完全通过。
例如，依然针对上述Scenario 1用户aaa发送邮件给jerry的用户故事举例，我们依然可以延伸出更多的AC：
AC2：
Given 普通用户userA登录aaa邮箱成功
When 用户userA编写邮件，邮件内容为空
and 在“收件人”输入Jerry邮箱地址，邮箱地址存在
and 点击“发送”
Then 提示“邮件发送成功”
相较AC2而言，AC1邮件内容不为空场景更具有用户使用价值，使用频率高于AC2。因此在AC编写时，我们标注出场景使用频率，不仅可以使团队成员更深刻理解用户场景使用价值，也可以使测试人员在进行验收测试时更加注意测试重点。
