本文共 2958 字，大约阅读时间需要 9 分钟。

测试驱动开发

测试驱动其实跟自动化测试并没有什么直接的关系，或者说直接关系很小。因为测试驱动是单元测试的范畴，如果非要扯上一点关系，那就是其中编写的测试代码，可以放到自动化测试工具里运行。

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应用而言。构造单元测试比较困难，如果强行构造单元测试，反而给维护带来额外的工作量。有开发者认为这个是由于设计方法，而不是开发方法造成的困难。比如可以使用MVC、MVP架构，将UI与逻辑分离，利于测试。

使得开发更为关注用例和测试案例，而不是设计本身。当前对于这个观点有较多的争议。

测试驱动开发会导致单元测试的覆盖度不够，比如可能缺乏边界测试。在实际的操作中，和非测试驱动开发一样，当代码完成以后还是需要补充单元测试，提高测试的覆盖度。

个人总结

功能未实现，先写测试，这种做法，是我们平时一般的开发模式是相反的，但也不是绝对没有。在接口设计，制订集成规范的时候，就是先定好接口，包括API地址，参数，访问方式，返回结果等等，然后实现接口时，就要紧扣这个规范。而平时开发的话，多半是边开发边想，随时调整。TDD，就是先想好要实现什么样的结果，然后再进行开发。然后开发完成后，还可以立即进行验证，无疑代码的严谨和质量都会有所提升。不过，这也对开发者，设计者提出了比较高的要求。有些东西，一开始并不是那么容易看清楚，边做边想可能效率更高一些。面向对象开发方法区别于结构化开发方法的自顶向下，是自底向上的，先构造一个最基本的雏形，然后再慢慢丰满，增量、迭代、原型倾向，更利于体现敏捷的思路。你功能都没确定，吭哧吭哧地，一本正经地写测试用例，很可能是一种浪费。所以我认为，一般情况下，用不上这个TDD，只有在SOA架构，实现服务接口时，或者需求非常明确的情况系啊，才适用这种所谓的TDD。

V模型

1、什么是V模型

开发模型里面，V模型与测试驱动开发思想有点类似。

即需求分析、概要设计、详细设计、编码都有一个相应的测试阶段。如下图

具体对应关系是这样子的： 单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来；

集成测试对应概要设计，在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；

系统测试，就是根据需求分析而来，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试作准备。

2、优缺点

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。也就是说，虽然从需求分析到编码，都有一个相应的测试阶段与之对应，但这只体现在测试用例的编写等准备工作上，只有开发完毕，才进行测试。那么其优缺点也很明显：

优点

1）既有底层测试又有高层测试。底层：单元测试。高层：系统测试。 2）将开发阶段清楚的表现出来，便于控制开发的过程。当所有阶段都结束时，软件开发就结束了。

缺点

1）容易让人误解为测试是在开发完成之后的一个阶段。 2）由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，并且代码修改起来很困难。 3）实际中，由于需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。

3、适用场景

V模式是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。

转载地址：https://leftfist.blog.csdn.net/article/details/115606974 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！