关于敏捷测试中AC和TC的那些事儿（二）

       在上节《关于敏捷测试中AC和TC的那些事儿（一）》中，我们了解了AC和TC之间的关系。这节开始，我们将一起讨论下如何编写AC，以及如何分析AC使得其能够最大化覆盖story的功能点。

       1、AC的编写格式？

      通常，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编写时，我们标注出场景使用频率，不仅可以使团队成员更深刻理解用户场景使用价值，也可以使测试人员在进行验收测试时更加注意测试重点。