2017-07-18 22:58:30 lanchunhui 阅读数 2802

测试驱动开发 TDD(Test-Driven Development)是敏捷开发的一项核心实践,同时也是一种设计技术和方法。

  • 既然是测试驱动,便是测试,测试用例先行;
    • 首先编写好测试用例,期待值,实际值;
  • 开发的目的是让测试运行通过;
  • 开发围绕测试展开;

0. 常见测试方法

  • 功能测试、单元测试、系统测试和负荷测试等;

1. 基本思想

在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践,但不只适用于XP(Extreme Programming),同样可以适用于其他开发方法和过程。

2012-02-19 16:54:19 Ant_Yan 阅读数 4054

敏捷开发有许多种方法,但不管采用任何一种,测试都是实施敏捷的基础,及时的验证代码的正确性,系统功能的健全与否,及时的反馈,及时的叫停……都是保证敏捷的基础。所以大量的快速的自动化测试,才能保证敏捷开发在快速迭代中仍然不怎么丢失软件的质量。

所以,在敏捷开发里一直都有一种说法叫“代码即文档”,而且测试代码也成了功能代码的使用文档。敏捷里强调的TDD(Test-driven developmenet, 测试驱动开发),就主要体现了这种思想:根据设计编写测试-> 实现设计的功能 -> 用测试代码验证 -> 重构实现代码 -> 改善设计 -> 再次回到根据改善的设计编写测试。反复循环下去,就是TDD所倡导的流程。

TDD的好处:1. 能驱使系统最终的实现代码,都可以被测试代码所覆盖到,也即“每一行代码都可测”。2. 测试代码作为实现代码的正确导向,最终演变为正确系统的行为,能让整个开发过程更加高效。TDD的不足之处或者说还不够完善的地方,是对设计和测试的编写没有一个明确的方针。作为整个循环中的向导部分,如何保证根据设计编写的测试就是最终用户所期望的系统行为?如果这一部分模糊了,那么后续所有环节几乎都要受到影响。所以,再次基础上,敏捷社区又有人提出了BDD的概念,即“行为驱动开发”。

BDD(Behavior-driven development)把TDD中模糊的那一部分给明确了,强调开发、测试、BA、客户等所有项目相关人员都用自然语言来描述系统的行为。大家看到的描述一致,读到的内容一致,于是最终测试驱动开发产出的结果也应该是最符合用户期望的。所以在BDD的倡导下,介绍了一种简洁的类似自然语言叫Gherkin Language。下面看一个用Gherkin Language描述系统行为的例子:

As a xxx [Role]
I want to xxx [Feature]
So that I can xxx[Benefit]

Scenario 1: create user
Given a admin log into the system
when he create a user with name 'mike'
then mike should be able to log into the system

随着BDD的出现和发展,使用大家都能轻易理解和认知的语言来描述系统的行为并创建User Story,TDD的反复循环的流程也就能更顺利的进行下去了。BDD的核心价值是体现在正确的对系统行为进行设计,所以它并非一种行之有效的测试方法。它强调的是系统最终的实现与用户期望的行为是一致的、验证代码实现是否符合设计目标。但是它本身并不强调对系统功能、性能以及边界值等的健全性做保证,无法像完整的测试一样发现系统的各种问题。

有种说法是BDD是TDD的进化,其实笔者看来,没有孰优孰劣,它们的本质和目标都是一致的。只是在实施方法上,进行了不同的探讨来完善整个敏捷开发的体系。如果BDD书写的User Story或者叫测试用例,不能作为开发、测试和客户等人共同参与和看到的一致性内容的话,那么它的价值也几乎得不到体现。另外一点,由于BDD不能代替完整的测试,旨在描述系统的行为,所以就像Gherkin Language的例子所体现的那样,关键是“简洁”,切忌啰嗦的想把每一步操作和任何情况都说得很清楚。

最后总结:TDD的迭代反复验证是敏捷开发的保障,但没有明确如何根据设计产生测试,并保障测试用例的质量,而BDD倡导大家都用简洁的自然语言描述系统行为的理念,恰好弥补了测试用例(即系统行为)的准确性。(不管以上理念是否先进,切忌盲从和滥用)
 

 

2018-11-21 00:56:50 OliverZang 阅读数 608

“你有了解哪些开发模式?” “你了解的这几种模式有哪些不同” “测试方法与目的是什么?”
带着这些问题,我们来看看Agile 中的Scrum 与 TDD

Agile
敏捷开发模式,实质是一种以人为本的开发理念,重视团队沟通,重视客户反馈,重视产品迭代。
根据Agile的思想,我们主要有Scrum和XP两种开发实践,XP中又以TDD较为流行。

Scrum

项目经理从客户(产品经理)获取初步的需求,建立需求列表;
项目经理(可以分为PO与ScrumMaster)定一个sprint的周期(4周例如),按需求列表分配优先级,以此为前提,与开发小组讨论工作量backlog;
技术总监按backlog分配任务;开发小组集中速度开发。
项目经理每个sprint向客户递交可视化产品,评审并讨论迭代需求。
循环迭代,直至递交完整需求的产品。

优点:有效提升用户满意度,产品成功率;量化,透明的开发任务,增加效率;不同开发岗位之间的互动,培养了团队凝聚力,减少技术代沟产生的摩擦。

缺点:项目经理要求极高,对外部客户的需求更变所带来的backlog,经费以及质量控制要有明确的量化能力。对产品迭代需求的优先级划分要合理。对内部开发人员/QA的信息互换要即时。
对开发人员有更高的要求,没有完善的设计文档(UI/原型)约束,容易产生理解误差,不能解决反复修改需求带来的工作量积压问题,即递交产品前的开发工程量不变甚至更多。

Scrum小结“敏捷”实质上是对产品需求完善的速率,不是加快工程速度,而是产品后续打入市场的速度!
正如微信等产品,通过用户反馈后迭代部分业务功能并及时更新即是agile的思想。

由上可知,Scrum对开发人员个人也提出了更高的要求,尤其是对需求的认识。

此时我们需要引入TDD的开发模式了,即先写测试后写业务代码。

T实际上能映射现实业务的需求,在“莽”代码前,开发人员先分析需求,完善测试,再按照测试要求完成代码书写。这样的功能模块跑起来才是有效的,这样的集成系统跑起来才是有质量,少返工,真前进的工程。

经过一些网络资源的阅读与大佬经验谈,TDD给我的第一印象是前期引入较为困难,测试例的推导不全,后期补测试例的情况较多。如若在Scrum中引入TDD,开发人员Sprint工作量积聚上升,抱怨与抵触声随着backlog增加而来。

可以推断,TDD对技术总监的要求更高,需要对开发成员进行思想的指导与实践的论证,团队熟练掌握后,后期对于产品的质量的确会有进一步的保证。

总结:Scrum与TDD近几年的普及与实践都顺应了互联网瞬息万变的节奏,这两种开发模式都对开发人员个人,提出了更高的要求。

OK~屁文写完,继续补技术知识去了。

2018-11-02 08:59:41 weixin_36904212 阅读数 373

通过昨天对老师的提问,也算是对一直以来的困惑和思考做了个总结。

敏捷开发是一种内涵非常丰富的思想,面向用户,面向需求,而不是面向模块。而TDD则是一种卓有成效地提高工作效率的办法,与敏捷相辅相成。

接下来,结合本人最近项目上的一些经验和教训,来做一个深入的总结和反思吧~

关于敏捷,面向需求和面向模块究竟有什么区别呢?

以目前的经验为例,作为一个用户量巨大的后台,按照模块来分,有测试模块,面向数据库的模块,面向缓存的模块和面向前端的模块。如果按照模块来分工合作的话,会出现的问题是,接口的负责人很难提供其他模块所需要的特定功能,很难知道自己的接口在其他模块究竟是怎样运行的,发挥着什么样的作用。倘若尝试解决这些问题,沟通的成本是昂贵的,需要给出的API文档的工作量和需要的时间成本同样很高,但是需要更新甚至返工的概率是很大的。那么按照需求来分工的话,则是功能的开发者对所需要的模块接口进行全局的设计和实现,在已有的可扩展性较高的接口基础之上,为需求进行专属的扩展。事实上有经验的对业务进展十分清楚的程序员会能够在最初设计接口是就考虑接口的通用性,为后来的接口扩展提供便利,但多数情况下还是按照功能,定制地去拓展接口。

这种情况下对程序员的挑战是大于以往的,一方面,前期的结构对于后期功能的拓展可能会是一种阻碍,很可能需要全部重来。如果接口的可拓展性极差,或者架构对后期的功能的添加会产生大量负面影响而需要重新设计,推翻重来是不可避免的。所以这是十分需要经验的,现代软件开发流程的科学化使得很多公司有专门的架构师,这类人所承担的责任通常是巨大的,就我现在的感受而言,架构师应该不仅仅是面向开发团队的,同时也是面向用户的。在我们这次实践中,SM便是这样的一种角色,而PO更像是用户和SM之间的桥梁。如果SM缺乏面向用户的意识,整个团队的代价是无法真正实现敏捷的,开发过程中遇到的阻碍也可能会变多。另一方面,是对编程技能的要求更高,需要更加全面的编程知识。譬如,一个后台程序员,除了要对前端有所了解,对于算法,数据库,数据库底层,操作系统性能等方面都比较熟悉,否则同样是无法敏捷的。也就是说,对于一个整体的功能,任何拿到部分功能的程序员,都应当具备实现全局功能的编程能力,同时也意味着不同的人是需要操作相同的模块的。

关于测试,什么样的测试才是系统测试呢?

还是结合自身经历来思考。对于一个面向前端的登录接口,我们获得前端的输入,返回其想要的结果,我们不需要关心用户信息是否写入了数据库或缓存,不需要关心返回值是如何计算的,这个过程中可能出现的错误等。我们的测试是不依赖于实现的。那么单元测试呢?我的理解是,单元测试时关注实现的,譬如我的需求,a+b+c,实现者利用了函数sum(a,b,c,),过程需要函数add(x,y),系统只关心初值和终值,单元却还会关心过程中的两次add,他需要知道实现,才能确认实现,进而测试实现来保证最终结果。

那么,TDD是什么,又如何应用呢?

TDD,所谓测试驱动开发,那么一定是测试现行。TDD的过程中,我们需要的是专注于一个需求的开发,直到测试通过。这里我说针对一个需求,我想强调的,这里的测试,应当是不依赖于实现的系统测试,而不是单元测试。否则,TDD将难以展开。

大多数情况下,开发者会先开发再测试,很可能出现的一种情况是,过程中一系列的单元测试都是通过的,但最终的功能依旧无法保证,这时再开展系统测试,可以说是比较耗费时间的,毕竟,原本你的目标可以变成:通过眼前这一项测试。

先这么多吧~期待后面会有更多不一样的感受。

2010-06-01 17:59:28 hanwesley 阅读数 16

最近关注敏捷开发,看了几本敏捷开发方面的书籍。也有点体会,做个总结。

 

敏捷开发的核心就是迭代开发,快速发布,加上TDD

 

最合适的团队做最合适的事情

 

但是这个方式适用于新系统的开发,像一些遗留系统的迭代就比较费劲了。

 

注重测试可能会好点。

 

<!--StartFragment -->

敏捷开发--TDD

阅读数 1157

敏捷质疑: TDD

阅读数 8918

TDD实践和思考

阅读数 142

敏捷开发 tdd 单元测试

博文 来自: a15089415104
没有更多推荐了,返回首页