题记
本系列笔记将从测试人员的角度，总结在百度两年来的测试经验，记录一个完整的基于敏捷流程的验收测试全过程，分享在测试过程中的一些知识和经验，以及自己的一些理念。总结自己，也希望对大家有益。
概念
验收测试驱动开发（ATDD）和测试驱动开发（TDD）是完全不同的两个概念。
TDD更偏重自动化case先行，而ATDD更偏重于验收细节、质量标准先行。
在了解ATDD之前，先回顾下TDD：
测试驱动开发（TDD）
极限编程的方法之一，从业务入手，以测试先行的方法来反向推动代码的实现。那什么是TDD呢？
简单的说，就是每当需要添加一个新功能，或修改现有功能时，我们首先思考这部分代码期望达到的输入与输出，先把验证该业务的单元测试用例写出来，再去写最简单的实现代码来通过该测试；不断重复此过程直到完成整个功能。
注意：TDD是开发人员的责任。
典型的TDD开发步骤：
Step 1：分析并确定一个目标测试场景
Step 2：添加一个单元测试来验证该测试场景的输入输出
Step 3：运行该测试，得到失败的测试结果
Step 4：写最简单的功能代码来通过该测试
Step 5：再次运行该测试，看到测试通过
Step 6：进行代码重构，包括功能代码和单元测试代码
Step 7：重复以上步骤，直至开发完成
建议在TDD的开发遵循的最佳实践：
1.简化－保持测试用例尽可能的简单，以验证业务为首要目标
2.业务导向－针对每一个需要验证的业务场景进行测试，而不是对代码的每一个方法进行测试
3.隔离－每一个测试类（TestCase）都可以单独运行，不依赖于其它任何测试；同样很多测试类也可以一起执行，而不会互相干扰
4.重构－开发出来的单元测试和功能代码都需要不断重构，改进代码的可读性，可维护性，减少冗余代码等
5.测试列表－在开始开发之前，先列出所有需要的测试，并在开发中不断维护该列表，避免遗忘一些必要的测试
6.反向工程－在某些开发环境中，如Eclipse，可以使用IDE所提供的反向工程能力从测试代码自动生成必要的类，方法等
7.注释－不需要另外单独的文档，而是在测试类中对每个测试方法对应的业务场景，输入和期望的输出进行详细的描述
TDD的好处：
1.提高代码质量－测试先行，并达到足够的覆盖率，确保代码都经过了测试
2.对系统进行描述－TDD产生的测试就是对系统的一套完整的说明文档，所有的业务，每一个方法的使用在这里都有描述。如果谁想深入了解你的系统，让他去看测试：）
3.自信得重构- TDD能够产生一组完备的测试套件，每当我们重构了代码后，可以方便得通过执行已有的测试来确保新的改进没有影响到代码的逻辑和行为；同样，当每次解决了缺陷后，可以通过执行已有的测试来确保其它功能没有受影响，没有引入新的缺陷。这让团队可以更加自信得去进行代码重构
4.自动回归测试- TDD产生的测试套件可以与自动化的持续进程环境相结合，部分实现回归测试的自动化，大大提高回归测试的频率，同时减少所花费的时间
5.消除浪费- TDD有助于开发团队避免产生冗余的，没有用的代码；避免那些没有任何人能看懂的不知所谓的代码
6.减少Debugging -通过TDD来进行编程，可以大大减少对代码Debugging的需要，节省时间
7.简化设计-在概要设计的指导下，TDD能够替代大部分甚至全部的详细设计（实现类，方法级别的设计）
8.更加模块化-由于TDD需要开发人员将一个功能分解为一个个可以测试的更小单元，然后再集成为一个整体。这样的思维和开发模式将产生更小的，更清晰的，更加责任明确的类，更加松耦合的组件和清晰的接口
TDD的局限性：
1. TDD产生的代码质量取决于测试的质量，即不恰当，不正确的测试会产生错误的代码；业务场景覆盖不充分的测试会产生功能不完整的代码；
2. TDD只适用于输入输出明确的开发项目，不适用于某些探索性的，输出不确定的开发，比如密码系统，人工智能，安全等领域的研发；
3. TDD在某些环境下实施会有一些困难，比如关系型数据库，异步通信等，需要一些额外的辅助工具。
最后，作为一种新的设计和编程方法，在项目中实施TDD对开发人员提出了一些新的挑战：
*职责转变-某些开发人员认为，他的工作就是实现功能，写代码；测试只是测试人员的事情，不在他的职责范围内。这是错误的认识，完备高质量的单元测试也是开发人员的职责！
*思维转变-很多开发人员拿到需求后，喜欢立刻就埋头开始写代码实现。TDD要求测试为先，开发人员首先要思考的不再是功能如何实现，而是应该如何去进行验证，并列出需要的测试场景。这是一个大的逆向思维转变。