测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。
TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。 TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。 优点：在任意一个开发节点都可以拿出一个可以使用，含少量bug并具一定功能的产品。 缺点：增加代码量。测试代码是系统代码的两倍或更多。 TDD = TFD + Refactoring (TFD -- Test First Development) 计算机领域： Test Drived Develop 测试驱动开发是一种开发方法，是开发人员参与的活动。 其效果是以可执行的形式文档化你的需求，迫使你分清职责隔离依赖以驱动你的设计，编织安全网以便将Bug扼杀在在摇篮状态，防止其逃逸。可传统测试人员的活动是试图找到已经逃逸的Bug。这两种活动都是必要的，而且毫不冲突，互为补充。 那么测试人员在新的特性还没开发完成之前做什么呢? 除了提前写测试用例，无论是自动化的还是非自动化的，而需要测试人员参加的一项重要活动，就是参与特性验收条件的制定。 之前经常发生开发人员按照自己的理解去编码，测试人员按照自己的理解去测试，直到开发完成，测试过程中才发现理解的不一致，开始产生争执并阻塞等待业务分析人员(如果幸运的话)或者行政主管(如果开发过程混乱的话)的仲裁。 解决办法就是，在开始开发新特性前的一刹那，由业务分析人员，测试人员，开发人员进行一次讨论，就验收条件达成一致并形成记录，然后测试人员和开发人员分头去写测试和实现。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。