很多公司在面测试中高级岗时，都会不同程度地问到“有没有了解过TDD”“你认为TDD可以解决什么问题”或者“说说测试驱动开发的流程”等等，即使公司并不会用到此开发流程，面试官也会通过你对这个相对还比较“陌生”的概念的讲述来了解你对一些测试相关概念的熟知程度以及测试思想的见解。

什么是TDD(测试驱动开发)？

百科中对测试驱动开发的介绍如下，测试驱动开发，英文全称是Test-Driven Development，简称为TDD，它是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写好测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。

测试驱动开发并不是在近几年才发展起来的一种方法，其最早是在极限编程方法论中就开始有了这种思想的实践过程 ，市面上很多《极限编程》、《持续集成》、《测试驱动开发》的书籍中都有不同角度的介绍。

简单来说，测试驱动开发是针对一些小功能点甚至小到一个方法的敏捷开发实践。传统的开发模式是开发人员编写完业务代码后再开始编写单元测试脚本来验证上一步的业务功能代码，而测试驱动开发的中心思想却是先根据需求文档来编写测试代码（即先编写单元测试脚本），并思考怎样对这些要实现的业务功能作验证，等编写了足够的单元测试脚本后，再继续编写业务功能代码，通过测试后，再继续迭代以上的过程一直到编写完成所有的业务需求功能模块。

单元测试

从上引出的一个概念-单元测试，这里简单说明下。单元测试一般是由开发者在编写业务功能代码时， 为了验证自己开发的每个代码单元而编写的一种独立的测试。完成单元测试后，开发人员会出一份单元测试报告以及单元测试覆盖率报告， 测试人员需要以以上报告作为设计功能测试用例的依据。

测试驱动开发的流程

可以从以下测试驱动开发周期图中清晰地看出核心流程节点。测试驱动开发的口号是不可运行/可运行/重构

测试驱动开发与传统开发的区别

传统开发模式下编写的单元测试脚本其实还是为了验证功能，仍属于测试的一种形式。而测试驱动开发已经不再是一种简单的测试行为了，准确地说，它是一种设计行为。测试驱动开发类似于是对一段代码的用法而编写的设计规格说明，可以从编写代码的内聚性、可测性、可复用性以及缺陷密度、接口的简易水平看出。在测试驱动开发中，以需求的剖析、用户业务功能的理解都是层层递进的，是可以逐步细化到代码级别的，而这样的过程也恰恰提高了测试的覆盖率，同时能从根本上解决一些因业务逻辑设计错误而导致的后期大量的缺陷修复工作。

测试驱动开发的优缺点

从以上的TDD周期图中也可以看出，测试驱动开发最大的优点就是重构了，不断迭代，不断地对现有代码进行重构，不断优化代码的内部结构，最终实现对整体代码的改进。以此不断减少一些设计冗余、代码冗余、接口复杂度等等。

另外，对于一些前期需求不明确，甚至需求信息量特别少，且后期又会有大量业务功能修改时，传统的开发模式需要加班加点以此赶工开发，测试，缺陷修复，人工、时间成本且不说，最重要的产品质量也无法得到保证。当然 ，这种模式下也最适合采用原型法、敏捷开发模式了，毕竟拥抱变化是敏捷的宗旨 。而测试驱动开发也是敏捷开发模式的基础，这样无论是来自客户的紧急需求还是项目团队的一次技术改革，都可以通过重构设计、增加测试脚本来实现了。

测试驱动开发的应用领域

以上分析了测试驱动开发的诸多优势，但目前并没有被大量广泛的使用起来，一来这是一种技术或管理方式上的变革需要慢慢被大众所熟知 ； 二来需要足够专业技能、专业素质的人才来保证整个过程的通畅与专业； 第三，前期需要一定的投入，而它产生的输出足以解决目前多数企业中遇到的质量、效率、成本等难题，所以选择是一步，真正能够严格执行下去的很少。

结尾

总之，如果是在面试过程中，可以通过以上几方面分步来讲解自己对测试驱动开发的认识，如果恰巧自己也在敏捷团队里有过工作经历，更可以添砖加瓦，加上自己的亲自经验，一定会给面试官一个思维清晰，测试经验丰富的良好印象。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取