测试驱动开发(TDD)

今天我这次分享的目的,就是和你聊聊软件测试领域中的另一个很热门的话题:测试驱动开发,也就是Test-Driven Development ,通常简称为TDD。

听上去有些迷惑是不是?测试怎么可能驱动开发呢?在传统软件的开发流程中,软件开发人员先开发好功能代码,再针对这些功能设计测试用例、实现测试脚本,以此保证开发的这些功能的正确性和稳定性。那么,TDD从字面上理解就是要让测试先行,这又是怎么一回事呢?

确切地说,TDD并不是一门技术,而是一种开发理念。它的核心思想,是在开发人员实现功能代码前,先设计好测试用例的代码,然后再根据测试用例的代码编写产品的功能代码,最终目的是让开发前设计的测试用例代码都能够顺利执行通过。

这样对于开发人员来说,他就需要参与到这个功能的完整设计过程中,而不是凭自己想象去开发一个功能。他有一个非常明确的目标,就是要让提前设计的测试用例都可以顺利通过,为此,他先实现测试用例要求的功能,再通过不断修改和完善,让产品代码可以满足测试用例,可以说是“小而美”的开发过程。

所以,从本质上来讲,TDD并不属于测试技术的范畴。那么,我为什么还要单独用一篇文章和你分享这个主题呢?因为,TDD中通常会用到很多常见的自动化测试技术,使得测试在整个软件生命周期中的重要性和地位得到了大幅提升。

可以说,TDD的思想和理念给软件研发流程带来了颠覆性的变化,使得测试工作从原本软件研发生命周期的最后端走向了最前端。也就是说,原本测试工作是软件研发生命周期最后的一个环节,而现在TDD相当于把测试提到了需求定义的高度,跑到了软件研发生命周期最前面。

那么,接下来我们就一起看看TDD的优势有哪些,以及TDD的具体实施过程。

TDD的优势

TDD的优势,可以概括为以下五个方面:

1. 保证开发的功能一定是符合实际需求的。

用户需求才应该是软件开发的源头,但在实际的软件开发过程中,往往会在不知情的情况下,或者自己的主观判断下,开发出一个完全没有实际应用场景的功能。而这些没有实际应用场景的功能,却因为产品验证和测试工作介入的时机都在项目后期,所以往往在集成测试中或者产品上线后才会被发现。

比如,开发人员在实现用户注册的功能时,认为需要提供使用手机号注册的功能。但是,这个功能开发完成后,测试人员却告知开发人员这个功能用不上,或者产品上线后才发现这个功能在实际场景中完全不是必须的,因为用户可以使用邮箱注册,然后再通过绑定手机号实现手机号登陆。所以,直接用手机号注册这个功能是不需要的,真正需要的是绑定邮箱和手机号的功能。

试想一下,如果是测试驱动开发,即先根据用户的实际需求编写测试用例,再根据测试用例来完成功能代码,就不会出现这种既浪费时间、精力,又没有必要的功能了。

2. 更加灵活的迭代方式。

传统的需求文档,往往会从比较高的层次去描述功能。开发人员面对这种抽象的需求文档,往往会感觉无从下手。但是,在TDD的流程里,需求是以测试用例描述的,非常具体。那么,开发人员拿到这样的需求时,就可以先开发一个很明确的、针对用户某一个小需求的功能代码。

在开发过程中,开发人员可以不断的调试这个功能,通过测试->失败-修改/重构->测试->成功的过程,使开发的代码符合预期,而不是等所有功能开发完成后,再将一个笨重的产品交给测试人员进行一个长周期的测试,发现缺陷后再整个打回来修改,然后由此又可能会引入新的缺陷。另外,如果用户需求有变化,我们能够很快地定位到要修改的功能,从而实现快速修改。

3. 保证系统的可扩展性。

为了满足测试先行的灵活迭代方式,我们会要求开发人员设计更松耦合的系统,以保证它的可扩展性和易修改性。这就要求,开发人员在设计系统时,要考虑它的整体架构,搭建系统的骨架,提供规范的接口定义而非具体的功能类。

这样,当用户需求有变化时,或者有新增测试用例时,能够通过设计的接口快速实现新功能,满足新的测试场景。

4. 更好的质量保证。

TDD要求测试先于开发,也就是说在每次新增功能时,都需要先用测试用例去验证功能是否运行正常,并运行所有的测试来保证整个系统的质量。在这个测试先行的过程中,开发人员会不断调试功能模块、优化设计、重构代码,使其能够满足所有测试场景。所以,很多的代码实现缺陷和系统设计漏洞,都会在这个不断调优的过程中暴露出来。也就是说,TDD可以保证更好的产品质量。

5. 测试用例即文档。

因为在TDD过程中编写的测试用例,首先一定是贴合用户实际需求的,然后又在开发调试的过程中经过了千锤百炼,即一定是符合系统的业务逻辑的,所以我们直接将测试用例生成需求文档。

这里,直接将测试用例生成需求文档的方法有很多、很简单的方法,比如JavaDoc。这样,我们就无须再花费额外的精力,去撰写需求文档了。

你看,TDD真的是优势多多吧。那么,接下来我们就一起来看看实施TDD的具体过程。

测试驱动开发的实施过程

站在全局的角度来看,TDD的整个过程遵循以下流程:

1. 为需要实现的新功能添加一批测试;

2. 运行所有测试,看看新添加的测试是否失败;

3. 编写实现软件新功能的实现代码;

4. 再次运行所有的测试,看是否有测试失败;

5. 重构代码;

6. 重复以上步骤直到所有测试通过。

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

在这里插入图片描述

软件测试面试小程序

被百万人刷爆的软件测试题库!!!谁用谁知道!!!全网最全面试刷题小程序,手机就可以刷题,地铁上公交上,卷起来!

涵盖以下这些面试题板块:

1、软件测试基础理论 ,2、web,app,接口功能测试 ,3、网络 ,4、数据库 ,5、linux

6、web,app,接口自动化 ,7、性能测试 ,8、编程基础,9、hr面试题 ,10、开放性测试题,11、安全测试,12、计算机基础

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!  

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
测试驱动的编程是 XP 困扰程序员的一个方面。对于测试驱动的编程意味着什么以及如何去做,大多数人都做出了不正确的假设。这个月,XP 方面的讲师兼 Java 开发人员 Roy Miller 谈论了测试驱动的编程是什么,它为什么可以使程序员的生产力和质量发生巨大变化,以及编写测试的原理。请在与本文相随的 论坛中提出您就本文的想法,以飨笔者和其他读者。(您也可以单击本文顶部或底部的“讨论”来访问该论坛。) 最近 50 年来,测试一直被视为项目结束时要做的事。当然,可以在项目进行之中结合测试测试通常并不是在 所有编码工作结束后才开始,而是一般在稍后阶段进行测试。然而,XP 的提倡者建议完全逆转这个模型。作为一名程序员,应该在编写代码 之前编写测试,然后只编写足以让测试通过的代码即可。这样做将有助于使您的系统尽可能的简单。 先编写测试 XP 涉及两种测试: 程序员测试和 客户测试测试驱动的编程(也称为 测试为先编程)最常指第一种测试,至少我使用这个术语时是这样。测试驱动的编程是让 程序员测试(即单元测试 ― 重申一下,只是换用一个术语)决定您所编写的代码。这意味着您必须在编写代码之前进行测试测试指出您 需要编写的代码,从而也 决定了您要编写的代码。您只需编写足够通过测试的代码即可 ― 不用多,也不用少。XP 规则很简单:如果不进行程序员测试,则您不知道要编写什么代码,所以您不会去编写任何代码。 测试驱动开发(TDD)是极限编程的重要特点,它以不断的测试推动代码的开发,既简化了代码,又保证了软件质量。本文从开发人员使用的角度,介绍了 TDD 优势、原理、过程、原则、测试技术、Tips 等方面。 背景 一个高效的软件开发过程对软件开发人员来说是至关重要的,决定着开发是痛苦的挣扎,还是不断进步的喜悦。国人对软件蓝领的不屑,对繁琐冗长的传统开发过程的不耐,使大多数开发人员无所适从。最近兴起的一些软件开发过程相关的技术,提供一些比较高效、实用的软件过程开发方法。其中比较基础、关键的一个技术就是测试驱动开发(Test-Driven Development)。虽然TDD光大于极限编程,但测试驱动开发完全可以单独应用。下面就从开发人员使用的角度进行介绍,使开发人员用最少的代价尽快理解、掌握、应用这种技术。下面分优势,原理,过程,原则,测试技术,Tips等方面进行讨论。 1. 优势 TDD的基本思路就是通过测试来推动整个开发的进行。而测试驱动开发技术并不只是单纯的测试工作。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值