确认测试 验收测试_验收测试作为规格

确认测试 验收测试

在我以前的关于验收测试的文章中，我写了关于FitNesse和Cucumber之类的工具如何专注于开发人员和测试人员之间的协作。 当然，并不是所有这些工具都能帮助我们。 在这篇文章中，我们将更深入地了解验收测试作为一种实践，并了解这些工具能为我们带来什么。

验收测试是一种敏捷实践，是指对用户故事进行功能测试。 有时，它被称为敏捷验收测试或示例规范。 验收测试解决了软件开发中最重要的问题之一：需求。

要求

通常，需求不会像业务人员预期的那样传达给团队成员。 发生这种情况的原因很多。 通常，这些原因可以归结为与业务人员具有不同背景的团队。 因为团队通常只对业务领域有基本的了解，所以团队很容易误解模棱两可的要求。

这个问题不仅限于敏捷方法论。 这个问题已经持续了几十年了。 还记得那些经典的瀑布项目吗？ 当然，没有像用户案例那样简短地传达要求。 但是，它们是从商人的角度写的，常常在生产链的下游被误解。 到业务人员可以看到该系统并验证它与他们的想法不符时，已经为时已晚。 结果许多这些项目被取消，结果浪费了很多钱。 其中一些项目甚至导致破产。

敏捷计划游戏（今天称为Scrum）有助于减少此问题的影响。 其简短的反馈循环可确保业务人员在早期阶段就可以在构建世界时意识到他们的世界与系统之间的差异。 万一团队弄错了，只会浪费一次工作。 现在，这仍然非常昂贵。 没有人会仅仅因为需求沟通不畅而放弃整个sprint的工作。 但从积极的一面来看，大多数项目都会在这样的冲刺中幸存下来。

解决需求问题的另一种方法是减少需求中的歧义程度。 我们可以使用正式的语言来编写需求规范。 在您告诉我那行不通或根本不可行之前，让我解释一下。 我们不需要数学精度。 我们需要充分降低歧义的程度，以使人类能够理解。 在大多数项目中，已经足够方便地创建了这样的正式规范。 这就是测试计划 。

测试计划

测试计划以相当正式的方式定义了系统的输入，系统上的动作以及预期的输出。 从而充分降低歧义的程度，以使人类能够理解。

通过针对系统执行测试计划，质量检查人员可以获得有关系统行为（开发人员的解释）与其自己的解释之间的任何差距的反馈。 敏捷通过将开发人员和测试人员置于同一个团队中来减少差异的数量，但是在开发人员实施功能时，质量检查人员仍会编写测试计划。 在最好的球队中找到解释，同时实施一定的差异。

与业务人员发现团队在冲刺之后没有执行“正确的事情”相比，让团队在冲刺中找到自己是一件好事。 但这仍然导致返工，并且占用了我们宝贵的时间。

如果我们可以在实现功能之前了解这些差距怎么办？ 这样可以进一步减少返工，并从一开始就使该功能更加接近正确。 请注意，我绝对不是在声称团队不应犯任何错误，他们会这么做。 但是如果有机会通过早期学习来预防某些错误，我们应该抓住它。

举例说明

因此，商务人士写了一堆故事。 团队会对每个故事的大小进行某种形式的估算，并在冲刺中获取一些故事。 目前，团队尚不了解所有详细信息。 为了找出答案，他们可以组织与业务专家的会议，并询问她任何问题以了解这些详细信息。 团队在这里讨论例如复杂的业务算法或有关UI的详细信息。 团队与业务专家一起创建了一组示例和验收标准。

[请注意，如果所有团队成员都参加这些会议以达成对该功能的共同理解，将会很有帮助。

如果没有，请确保至少由一名开发人员和一名测试人员组成代表团。]

团队将示例和验收标准记录为测试方案。 优选地，业务专家随后审查场景，以断言他们的会议结果。 这就是工具弹出的地方。诸如FitNesse和Cucumber之类的工具使用一种简单而正式的语言来定义测试方案和示例表。 在此阶段，使用工具的好处是您不必自己发明这种语言。

现在，整个团队都可以阅读该功能的预期功能并且在同一页面上。 在编写场景之后，开发人员（有时是测试人员）要做的第一件事是创建一些粘合代码。 此代码将方案绑定（粘合）到系统，以允许测试工具针对系统运行方案并验证输出。

工具的力量

这使这些测试工具真正强大。 测试场景可以在我们希望的任何时间高速执行。 编写测试方案和胶粘代码通常是人类的任务，但是人类在不断重复执行相同任务时非常糟糕，这使它们的测试执行平台效率极低。 另一方面，计算机在持续重复执行任务方面非常有效，这使它们非常适合作为我们测试场景的执行平台。

不仅测试场景有助于在实施之前建立对功能的共识。 每个团队成员都可以（并且应该）阅读方案，业务利益相关者也可以。 在所有方案通过之前，团队尚未完成实施。

由于方案可以由计算机执行，因此它们构成了出色的回归套件。 我们可以让计算机在每个版本中或至少每天运行几次我们的方案。 当团队在更改某些内容后Swift从测试套件中获得反馈时，他们可以在早期阶段发现回归错误。

这听起来似乎太理论化了。 因此，我将继续进行验收测试，并提供有关在开发过程中使用这些实践的更实际的文章。

参考： Software Craft博客上的JCG合作伙伴 Bart Bakker提供的参考： 验收测试作为规范 。

翻译自: https://www.javacodegeeks.com/2013/12/acceptance-tests-as-specifications.html

确认测试 验收测试