测试驱动开发测试驱动实际上与自动化测试没有直接关系，或者直接关系很小。 测试驱动属于单元测试的范畴，如果需要建立一些关系，可以通过其中编写的测试代码，放入自动化测试工具中执行。
1、何为测试驱动？
测试驱动开发(注意是开发而不是设计) (全名Test-Driven Development，简称TDD )是一种与传统软件开发过程不同的新开发方法。 要求在编写某个功能的代码之前先写测试代码，然后只写能通过测试的功能代码，通过测试推动整个开发。
2、测试驱动的好处
与传统的结构化开发流程方法相比，具有以下优点：
1) 促使设计更符合开发的需求，也可以更快地适应变化。
TDD根据客户的需求编写了测试用例，设计了功能的流程和接口。 此外，这种从用户角度设计代码通常符合后期开发的需要。 因为通过关注用户的反馈，可以及时应对需求的变化，同时由于从用户的角度进行了简单的设计，所以也可以更快地应对变化。
2)使设计松耦合，提高系统的扩展性和抗变性，容易获得反馈。
由于测试和测试独立性的要求，实现了松散耦合的设计，更多地依赖于接口而不是特定的类，从而提高了系统的可扩展性和抗变性。 此外，TDD还可以大大缩短设计决策的反馈周期，并在几秒或几分钟内获得反馈。
3) 尽早发现错误，极大降低测试及修复成本，提高产品质量
通过将测试工作提到编码之前并频繁运行所有测试，可以尽可能地避免和尽早发现错误，大大降低后续测试和修复的成本，提高代码质量。 在测试的保护下，不断重构代码，消除了重复设计，优化了设计结构，提高了代码的复用性，提高了软件产品的质量。
4)利于重构
TDD提供了持续的回归测试，给了我们重构的勇气。 如果代码更改导致系统的其他部分出现任何异常，测试会立即通知我们。 全面的测试有助于持续跟踪整个系统的状态，因此不必担心出现意外的副作用。
5) 提供了开发者文档
TDD生成的单元测试代码是最好的开发人员文档，它展示了所有API的使用方式和工作方式。 另外，它们与作业代码同步，总是最新的。
6) TDD可以减轻压力、降低忧虑、提高我们对代码的信心，给我们重建的勇气，是快乐工作的重要前提。
7)快速的提高了开发效率？
总的来说，长期使用TDD的实践可以改变人的编程习惯和思维方式。 因为TDD追求在编写实现代码之前编写测试用例。 从界面使用者的角度来考虑，有助于引出设计良好的界面。 当编写代码的人脑子里想着“想要什么”，而不再是具体细节的“怎么办”时，TDD的目的也就实现了。
3、测试驱动适用场景
测试驱动是敏捷开发方法之一的极限编程(XP )中的最佳实践。 理论上，适合应用敏捷开发方法的项目都适用测试驱动开发。 敏捷开发适用于中小型项目，但大型项目可以划分为几个小项目。 因此，敏捷开发可以处理任何项目，因此也不能进行TDD。
4、相关讨论
关于TDD，有正负两面的评价。
正面评价
可以有效地避免因过度设计而造成的浪费。 但是，也有人强调，开发前需要完整的设计。 可以有效地避免重建造成的浪费。
开发者可以在开发中具有更全面的观点。
负面评价
开发人员可能只完成满足测试的代码，而忽略了实际需求的实现。 实践者认为用结对编程的方式可以有效地避免这个问题。
实际代码的开发速度变慢，特别是不利于要求开发速度的原型开发。 这里必须考虑开发速度，必须同时包括功能和质量，简单的代码速度可能不能完全代表开发速度。
对于GUI、数据库和web APP应用程序。 因为构建单元测试很难，所以强行构建单元测试反而会在维护上增加额外的工作量。 有些开发者认为这是由于设计方法而不是开发方法造成的困难。 例如，MVC、MVP架构可用于分离UI和逻辑，以利于测试。
开发关注的是用例和测试用例，而不是设计本身。 目前，对这个观点有很多争论。
测试驱动开发可能会导致单元测试覆盖度不足，包括边界测试可能不足。 在实际运行中，与非测试驱动开发一样，代码完成后仍需对单元测试进行补充，提高测试覆盖度。
个人总结
功能没有实现，先写测试，这种做法与我们平时常见的开发模式相反，但也不是绝对没有。 在设计接口、编写集成规范时，首先要确定接口，在实现接口时，包括API地址、参数、访问方法、返回结果等，必须牢牢抓住该规范。 在平时的开发中，经常一边开发一边思考，随时调整
。TDD，就是先想好要实现什么样的结果，然后再进行开发。然后开发完成后，还可以立即进行验证，无疑代码的严谨和质量都会有所提升。不过，这也对开发者，设计者提出了比较高的要求。有些东西，一开始并不是那么容易看清楚，边做边想可能效率更高一些。面向对象开发方法区别于结构化开发方法的自顶向下，是自底向上的，先构造一个最基本的雏形，然后再慢慢丰满，增量、迭代、原型倾向，更利于体现敏捷的思路。你功能都没确定，吭哧吭哧地，一本正经地写测试用例，很可能是一种浪费。所以我认为，一般情况下，用不上这个TDD，只有在SOA架构，实现服务接口时，或者需求非常明确的情况系啊，才适用这种所谓的TDD。 V模型1、什么是V模型
开发模型里面，V模型与测试驱动开发思想有点类似。
即需求分析、概要设计、详细设计、编码都有一个相应的测试阶段。如下图
具体对应关系是这样子的：
单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来；
集成测试对应概要设计，在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；
系统测试，就是根据需求分析而来，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试作准备。
2、优缺点
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。也就是说，虽然从需求分析到编码，都有一个相应的测试阶段与之对应，但这只体现在测试用例的编写等准备工作上，只有开发完毕，才进行测试。那么其优缺点也很明显：
优点
1）既有底层测试又有高层测试。底层：单元测试。高层：系统测试。
2）将开发阶段清楚的表现出来，便于控制开发的过程。当所有阶段都结束时，软件开发就结束了。
缺点
1）容易让人误解为测试是在开发完成之后的一个阶段。
2）由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，并且代码修改起来很困难。
3）实际中，由于需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。
3、适用场景
V模式是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。
测试驱动开发
谈谈自动化测试中的测试驱动、测试桩
TDD（测试驱动开发）的意义在哪？