在 Agile 中，需求被定义为用户故事，即以用户为中心的系统功能表达。虽然这样做的好处是将用户置于对话的中心，并最终开发出一款能为最终用户带来真正价值的产品，但这也为需求的模糊性和不明确性创造了空间。

产品所有者（在开发团队的参与下）的职责之一是分解和细化用户故事，以提出具体的需求，这些需求以更符合其所需的工程工作的语言来表述。在此过程中，还应为用户故事定义一组特定的验收标准（如果用户尚未明确定义）。然而，成功做到这一点的一个关键方面是确保所有需求都是可测试的，即它们使得开发测试成为可能，从而明确确定是否满足验收标准。

本指南将演示如何在 Agile 中处理需求以确保它们是可测试的。

为便于测试，需求必须清晰、可衡量且完整。本指南将分别探讨这些特质。

要求不应包含歧义或模糊的术语，这些术语可能存在误解。不明确的要求示例如下：

注册表格应该直观

“直观”取决于解释，并且容易产生歧义。以下是针对相同要求的更明确表述：

注册表单应要求输入用户名、电子邮件地址和密码，并在每个字段中提供输入提示

这更清楚地定义了注册表单将包含的内容：指定的内容不会减少，也不会增加。这当然是朝着直观的方向发展（考虑到添加输入提示的额外细节），但它使需求确实得到满足时更加明显。

要求应具有可衡量性，即每个可量化的特征都应具有实际数量或范围，而不是包含诸如“快”、“多”或“高”等限定术语。以下是不可衡量要求的示例：

即使有大量用户访问，API 也应该快速响应请求

这是一个更好的版本：

对于预期的最大并发用户数，API 的响应时间应小于三秒，对于单个用户的响应时间应小于一秒

现在，对于速度应该有多快以及大量用户意味着什么，有了明确的衡量标准。用户或产品所有者可能不知道最大预期并发用户数，但它仍然是一个可以衡量和规定的明确定义的数量。

需求应该包含其捕获的核心功能的所有相关信息，并且不应包含多个功能。不完整性的示例如下：

用户个人资料应该包含用户的图片，点击图片将打开图片编辑页面，用户可以在其中替换图片或重新定位图片。

首先，此要求可以使用一些附加信息，例如：

用户资料应显示用户存储的缩略图，单击图片上的任意位置将打开图片编辑页面，用户可以在其中替换图片和/或重新定位图片。

现在它在信息方面看起来更完整了，但它仍然不满足完整性属性，因为它包含多个功能。最好将其分解为三个单独的要求：

• 用户资料应该显示用户存储的缩略图。
• 点击图片任意位置将打开图片编辑页面。
• 图片编辑页面应允许用户替换图片和/或重新定位图片。

最后，需要注意的是，需求不应包含实施细节。它应该与功能有关，而不是必须设计的具体方式（除非它与用户体验和功能的整体感知密切相关）。

用户故事通常表述为“作为 [角色]，我想要 [功能] 以实现 [目标]”，并且大多数情况下来自最终用户自己，而不是产品团队。这几乎意味着用户故事并不完全清晰、可衡量或完整。但是，如果正确执行上一篇关于完善用户故事和验收标准的指南中所述的流程，应该可以得到完善的用户故事，这些故事会重新编写，以便更加清晰，并分解为更精细的工作单元，其中包含一系列可独立测试的验收标准。

因此，精炼工艺应确保：

• 用户故事足够短，可以适合一个冲刺或积压迭代，并包含单一功能（完整需求）。
• 用户故事或至少验收标准是明确的，即任何模糊的陈述都会被重新捕获为更精确的陈述。
• 用户故事或至少验收标准是可衡量的，即应通过测量和量化的工程视角重写诸如“很多”、“很多”、“更好”或“更容易”等限定词。
• 用户故事的验收标准决定了用户验收的具体、可测试的条件。

验收标准决定了用户故事的可测试性，因此它是确保需求可测试的最重要组成部分。当用户故事本身遵循可测试需求的原则时，验收标准可以更容易地定义。但是，用户故事在捕获需求方面具有一定的灵活性；毕竟，它们是用户故事，即使在细化之后也是如此。话虽如此，细化过程的主要目标之一是得出每个用户故事的验收标准，因为从陈述方式来看，可能无法立即清楚它们是什么。验收标准实际上是将可测试性融入故事的因素。此外，通过强制执行诸如“给定 [前提条件]，当我 [执行某些操作] 时，我期望 [结果]”的结构，验收标准通过对预先存在的状态/情况和执行某些操作后的预期结果状态施加上下文信息来促进清晰度。

以下是之前指南中一个精致的用户故事示例：

作为注册用户，我希望使用我的用户名和密码登录，以便系统可以对我进行身份验证，并且我可以信任它。

验收标准如下：

假设我是一个注册用户并且已注销，如果我转到登录页面并输入我的用户名和密码并单击登录，那么与我的用户相关的数据应该是可访问的。

请注意，除了不包含前面讨论过的一些模糊术语之外，通过建立非常具体的上下文和操作，此验收标准清晰明确。它的功能特异性也很完整。用户故事通常不止一个验收标准，而是有几个验收标准，因此从可测试性的角度来看，不需要一个验收标准来完整地捕获需求（用户故事），这意味着在标准级别上没有完整性。但是，重要的是，所有验收标准结合起来涵盖用户故事的所有可测试组件，并且每个标准都与一个功能相关。

最后，考虑一下可衡量的验收标准的重要性。事实上，上述标准是可衡量的（行动定义明确，结果是二元的：数据可访问，或不可访问）。

ATDD 是一种从测试驱动开发 (TDD) 衍生而来的开发方法，以适应敏捷模型。该方法的主要目标是通过在编码活动开始之前编写验收测试来提高代码质量。而且，由于验收标准与最终用户的期望更紧密相关（与传统的开发人员驱动的软件测试相反），这有助于从一开始就引导用户故事的实施朝着可接受的最终产品的方向发展。此外，在根据验收标准编写具体测试用例和场景的过程中，可能会出现一些问题，这些问题会暴露出模糊之处，需要进一步澄清需求。

当编写代码的主要目标是通过测试，而编写代码的主要目标是向最终用户提供预期价值（因为它们是验收标准）时，敏捷团队更有可能成功交付高质量的软件。

在敏捷中，用户故事可能带有关于系统功能或行为的模糊、不明确的陈述。完善用户故事和确定验收标准是团队的两项关键工作，它们将带来更好的需求。然而，确保它们是可测试的仍然很重要，为此我们制定了一些指导原则，即需求必须清晰、可衡量和完整。通过将其与敏捷的用户故事和验收标准框架联系起来，我们有一个思维框架来帮助我们确保能够测试所有需求。

最后，如果您想让您的团队获得成功，那么 ATDD 方法论是值得借鉴的，因为它为软件开发工作的开始带来了可测试性，这可以帮助您从一开始就发现不明确的需求，并以积极的方式影响整体代码质量。

要进一步了解，请查看以下相关指南：

• 完善用户故事和验收标准
• 将敏捷用户故事分解为任务并估算工作量
• 使用 Agile 阅读并理解建筑设计规范