什么是验收测试驱动开发

在准备实施一个功能或特性之前，首先团队需要定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员的TDD实践和测试人员的测试脚本开发。

   注意：测试人员必须是团队的一部分，并在ATDD的过程中扮演关键和掌控性的角色。

   典型的ATDD开发过程是：

    Step 1：产品负责人向测试人员和开发人员讲解用户故事，澄清他们提出的问题；

    Step 2：
     a.测试人员列出验收该功能所需要验证的所有测试场景，每个测试场景通常是概要，清晰的一句话；
     b.同时，开发人员查找和分析现有的相关设计，代码和单元测试，明确开发策略；

    Step 3：测试人员和开发人员共同评审和调整测试场景列表，达成共识；必要时寻求产品负责人的参与和确认；并且明确那些场景应该有单元测试；

    Step 4：
     a.基于通过评审和认可的测试场景列表，测试人员开始为每个测试场景创建详细的验收测试用例，准备测试脚本和测试数据；
     b.同时，基于同样的的测试场景列表，开发人员开始添加单元测试用例，并以TDD方式驱动业务实现；

    Step 5：在开发人员将完成的功能部署并交付测试人员执行测试之前，进行代码评审和根据测试场景列表快速验证自己完成的功能，甚至邀请测试人员来观摩；

    Step 6：一旦完成的功能通过构建并部署到测试环境，测试人员立刻开始执行测试脚本；

    Step 7：任何测试人员的测试中发现的缺陷都要纪录到工具，并跟踪，立刻反馈给开发人员解决，或进行其它恰当处理；

    Step 8：最后，在迭代结束，团队成员向产品负责人和客户演示完成的功能。具体演示那些场景，可以在Step 3的阶段就确定。

   由此可见，ATDD和基于单元测试的TDD一样，也充分体现了敏捷开发“业务驱动”的特点，始终从用户的业务价值出发；对开发团队来说，ATDD是由外向内，多方介入的，基于拉动策略的，并行开发测试方法；确保所有交付的产品都经过了充分的测试。

    ATDD的好处：

    1.提高交付产品的质量－因为测试人员早期介入所发挥的驱动作用，确保所有交付的功能都经过了测试，并且提高了测试的覆盖和准确性；
    2.提高TDD质量－测试人员和开发人员共同定义测试场景列表，并且经过评审和修订，可以帮助开发人员书写高质量的，覆盖完整的单元测试用例。有助于解决上面提到的TDD方法的第一个局限性；
    3.回归测试－良好定义和覆盖完整的单元测试和验收测试脚本有助于未来进行回归测试；
    4.消除浪费－以ATDD的方式，满足和通过所有的验收测试场景是开发的首要目标，可以避免团队进行一些对客户没有价值的工作，减少浪费

   在ATDD的实施中，最主要的变化和挑战在于测试人员的工作方式和流程，对测试人员提出了这些挑战：

   *角色转变－传统的很多项目中，测试人员通常都是一个独立的QA团队，与开发团队彼此协作较少，测试人员的工作以开发人员完成开发和部署为起点；在敏捷开发中，尤其是ATDD的团队中，测试人员必然是开发团队的成员，而且是处于支配作用的重要成员。测试人员不能继续是被动的，而是以自己的成果来带动开发实现；

   *沟通能力－传统项目的测试通常基于完备详细的需求文档；然而在敏捷开发中，需求都是以用户故事的简化形式定义的，测试人员要列出准确完备的测试场景，他需要更多地和产品负责人，开发人员沟通，每天紧密工作在一起，有任何问题或变化都能立刻反馈到团队其他成员；

   *探索性测试－由于敏捷用户故事地简单性，而ATDD基于预定义的测试场景列表开发测试脚本，并且部分测试场景有了自动化的单元测试，不再需要重复的手动测试脚本，因此ATDD中的测试脚本不一定能覆盖到所有的逻辑和质量标准，于是“探索性测试”成为一个新的热门话题。即在既定的测试脚本以外，对当前和相关功能进行探索性的测试，尝试去发现一些隐藏的，未知的错误，或者一些不完美的地方。这应该成为测试人员的一种工作习惯。探索性测试看似随意，也有一些可遵循的方法，比如卖点测试、破坏测试、极限测试、深巷测试等。