公众号专注分享跟IT相关的各种知识,关注我,一起升职加薪!
今天我这次分享的目的,就是和你聊聊软件测试领域中的另一个很热门的话题:测试驱动开发,也就是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. 重复以上步骤直到所有测试通过。
网友评论