# 验收测试 Acceptance Tests
## 定义
验收测试是对软件产品行为的正式描述，通常表示为示例或使用场景。对于这样的示例或场景，已经提出了许多不同的符号和方法。在许多情况下，目标是应该有可能通过软件工具自动执行此类测试，这些软件工具可以是开发团队的临时工具，也可以是现成的工具。
验收测试应该由业务方负责说明需求的规格说明。从本质上讲，规格说明是一种测试。例如：当用户输入有效的用户名和密码，然后点击“登录”按钮，系统将显示“欢迎”页面。很明显，这是一个规格说明，同时它也是一个测试。类似于单元测试，验收测试通常具有二进制结果（通过或失败）。失败表明（尽管不能证明）产品中存在缺陷。
团队在敏捷使用接受测试的实践中日趋成熟，这是功能规范的主要形式和业务需求的唯一正式表达。其他团队使用验收测试作为对包含用例或更多叙述性文字的规范文档的补充。
## 也称为
术语“功能测试”，“验收测试”和“客户测试”或多或少地互换使用。还使用了更具体的术语“故事测试”，指的是用户故事，例如短语“故事测试驱动的开发”。
## 预期收益
验收测试具有以下好处，是对可以从单元测试中获得的好处的补充：
一方面鼓励开发人员与客户，用户或领域专家进行更紧密的合作，因为这需要表达业务需求
在客户和开发人员之间提供清晰明确的“合同”；通过验收测试的产品将被认为是足够的（尽管客户和开发人员可能会改进现有测试或根据需要建议新的测试）
减少新缺陷和回归的机会和严重性（缺陷削弱了先前审查并宣布可接受的功能）
业务方编写形式化的测试来描述每个用户故事的行为，开发人员负责将这些测试自动化。
这些测试由业务分析师和QA编写，他们要在迭代前半部分之前把测试写好。在迭代的前半部分中，他们测试的故事将被开发。开发人员将这些测试集成到持续构建中，这些测试成为迭代中故事的完成定义。如果没有写好验收测试，或者验收测试没有通过，一个故事就不能算完成。
## 常见陷阱
**以过分的技术方式表达验收测试**
客户和领域专家是验收测试的主要对象，他们发现验收测试包含难以查看和理解的实施细节。为防止验收测试过分关注技术实施，请让客户和/或领域专家参与验收测试的创建和讨论。有关更多信息，请参见行为驱动开发。
过分侧重于技术实施的验收测试还可能会因细微或外观上的更改而导致失败的风险，实际上这些更改不会对产品的行为产生任何影响。例如，如果验收测试引用了文本字段的标签，并且该标签发生了变化，那么即使产品的实际功能没有受到影响，验收测试也会失败。
## 潜在成本
与自动化单元测试不同，自动化验收测试并未普遍视为净收益，在吉姆·肖尔（Jim Shore）或布莱恩·马里克（Brian Marick）等专家质疑以下成本是否被实践的好处所抵消之后，引起了一些争议：
- 许多团队报告说，创建自动验收测试需要大量的精力
- 有时由于“脆弱”的测试问题，团队发现维护自动验收测试很麻烦
- Fit / FitNesse传统的第一代工具导致了客户或领域专家无法理解的验收测试。
BDD方法可以为此争议的解决带来了希望。
## 起源
- 1996年：自动化测试被确定为“ 极限编程”的一种实践，没有过多地强调单元测试和验收测试之间的区别，并且没有推荐任何特殊的符号或工具
- 2002年：极限编程的发明者之一Ward Cunningham发布了Fit，这是一种基于表格的，类似于Excel的表示法的验收测试工具
- 2003年：鲍勃·马丁（Bob Martin）将Fit与Wikis（坎宁安的另一项发明）相结合，创建了FitNesse
- 2003-2006年：Fit / FitNesse组合使大多数其他工具黯然失色，成为敏捷验收测试的主流模型
点击看敏捷名词地铁线路全图