敏捷开发的tdd思想_tdd开发 和敏捷开发 - CSDN
  • 敏捷开发模式,实质是一种以人为本的开发理念,重视团队沟通,重视客户反馈,重视产品迭代。 根据Agile的思想,我们主要有Scrum和XP两种开发实践,XP中又以TDD较为流行。 Scrum 项目经理从客户(产品经理)获取...

    “你有了解哪些开发模式?” “你了解的这几种模式有哪些不同” “测试方法与目的是什么?”
    带着这些问题,我们来看看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~屁文写完,继续补技术知识去了。

    展开全文
  • 测试驱动开发 TDD(Test-Driven Development)是敏捷开发的一项核心实践,同时也是一种设计技术和方法。 既然是测试驱动,便是测试,测试用例先行; 首先编写好测试用例,期待值,实际值; 开发的目的是让测试...

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

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

    0. 常见测试方法

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

    1. 基本思想

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

    转载于:https://www.cnblogs.com/mtcnn/p/9421310.html

    展开全文
  • 敏捷开发的核心思想

    千次阅读 2015-10-12 10:39:08
    敏捷开发的核心思想主要是迭代式开发,将整个项目分解为数个短期的迭代周期,快速相应需求进行增量开发。 结合我们公司的开发经验来看,我个人觉得敏捷开发主要包括几个步骤: 需求制定——》需求分析——》设计...
    敏捷开发的核心思想主要是迭代式开发,将整个项目分解为数个短期的迭代周期,快速相应需求进行增量开发。
    结合我们公司的开发经验来看,我个人觉得敏捷开发主要包括几个步骤:
    需求制定——》需求分析——》设计编码——》测试、功能验证——》发布版本——》下一个周期

    1、需求制定:需求方根据上一个版本,提出的新开发需求或调整等。
    2、需求分析:开发及测试人员,与需求方讨论并分析新需求,并验证需求的可行性。
    3、涉及编码:根据确认后的需求,设计实现方式并进行编码。
    4、测试、功能验证:对软件稳定性进行各种测试,并由配合需求方进行功能验证。
    5、发布版本:将这个版本发布给需求方。
    6、下一个周期:重复1到5步骤。

    实际开发中不可能情况非常顺利,一般都会有新的需求或修改在开发过程中被发现或提出,
    这时候并非不能调整原有的开发计划,可以视具体情况而定决定是否加入开发计划中,
    如果涉及到大规模的改动则一般需要作为下一个版本的开发任务。

    由于敏捷开发是使用增量式的开发,开发周期短响应快,一般不会出现致命的缺陷,整个开发过程较为流畅。


    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。
    
    敏捷开发宣言——
    个体和交互 胜过 过程和工具
    可以工作的软件 胜过 面面俱到的文档
    客户合作 胜过 合同谈判
    响应变化 胜过 遵循计划
    虽然右项也有价值,但是我们认为左项具有更大的价值。

    以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:
    Iteration
    迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
    IterationPlanningMeeting
    迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
    Story Card/Story Wall/Feature List
    在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
    敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
    在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
    Standup Meeting
    站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
    Pair Programming
    结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
    CI/Daily Build
    持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
    可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
    Retrospect
    总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
    ShowCase
    演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
    Refactoring
    重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
    TDD
    测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。
    

    敏捷方法反思:
    自己参与的敏捷开发项目总的来说不是很成功,这可能也是业界遇到的通病:
    1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
    2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
    3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚本也多流于形式,测不出深层次的问题。
    4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
    5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
    6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
    7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

    展开全文
  • 敏捷开发是一种内涵非常丰富的思想,面向用户,面向需求,而不是面向模块。而TDD则是一种卓有成效地提高工作效率的办法,与敏捷相辅相成。 接下来,结合本人最近项目上的一些经验和教训,来做一个深入的总结和反思...

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

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

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

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

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

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

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

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

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

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

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

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

    展开全文
  • 敏捷开发基本思想

    2011-01-29 11:26:30
    本文主要总结一下敏捷开发模式的基本思想   1、测试驱动开发(TDD):敏捷开发中,测试是在功能实现之前。就是要实现一个功能,首先根据业务需求,写出相应的测试,然后再写功能代码使得每个测试都可以通过。可以...
  • 敏捷杂谈之TDD与BDD

    千次阅读 2012-02-19 16:56:54
    敏捷开发有许多种方法,但不管采用任何一种,测试都是实施敏捷的基础,及时的验证代码的正确性,系统功能的健全与否,及时的反馈,及时的叫停……都是保证敏捷的基础。所以大量的快速的自动化测试,才能保证敏捷开发...
  • 敏捷开发 宣言 思想 认识误区

    千次阅读 2014-12-11 14:16:54
    一个是敏捷开发的宣言 另一篇是稍微具体的方法
  • 浅谈对TDD的看法

    千次阅读 热门讨论 2014-05-28 07:55:08
    程序员对TDD这个词一定不陌生,近几年比较火。英文全称Test-Driven Development,测试驱动开发。它要求在编写某个功能的代码之前先编写测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个开发的进行。 ...
  • 测试之谈TDD、BDD和ATDD

    千次阅读 2018-04-15 16:32:35
    敏捷开发技术中比较高频的两个概念,但实际自己并不能说出其中的区别和联系,刚好借此机会学习了解,通过CSDN记录学习的疑问正文:一、概念:TDD:Test-Driven Development(TDD)即测试驱动开发,它是一种测试先于...
  • 项目概要  多线程下载要求的技术点比较多,其中主要...接下来,我们运用TDD思想,具体解决我们所需要实现的方法类。 链接网络资源模块 首先要考虑链接网络,我们必须先要考虑我们设计的方法能发实现,因此首先写
  • 敏捷开发方法学及应用

    千次阅读 多人点赞 2013-12-13 00:20:54
    敏捷开发,瀑布式开发,XP,TDD,SCRUM,Lean,FDD,DSDM你了解多少?本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也...
  • 一个实例搞懂TDD(测试驱动开发

    千次阅读 2019-06-12 18:11:07
    TDD(Test-Driven Development)是敏捷开发中的一项核心实践和技术,也是一种设计方法论,其基本思想是:在明确要开发某个功能后,在开发功能代码之前,先编写测试代码,然后编写功能代码并用测试代码进行验证,如此...
  • TDD的一些想法

    2014-06-16 09:41:40
    3.如何测试驱动开发 感觉这类实践比较适合写底层代码,如api,应用框架等等,如果只是写业务逻辑的话,只要保证单元测试覆盖率就OK了。 4.mock对象(同样需要测试减少危险) 5.提交前保证所有测试运行通过 6.如何看待伪...
  • 敏捷开发知识体系笔记

    万次阅读 2015-11-06 10:08:55
    敏捷开发知识体系整体框架敏捷开发工程实践项目管理 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽图 需求管理 需求订单 业务流程草图 用例驱动开发 用户故事 架构 演进的架构 演进的...
  • 测试驱动开发(Test-Driven Development):是敏捷开发中的一项核心实践和技术,也是一种设计方法论。是极限编程的一个重要组成部分,它的基本思想就是在开发功能代码之前,先编写测试代码。2.TDD的原理:在开发功能...
  • 敏捷开发实践总结

    千次阅读 2017-12-03 20:21:15
    敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP...
  • Python测试驱动开发(TDD)

    千次阅读 2018-08-16 22:56:02
    前言:TDD是一种敏捷开发模式,而不是测试方法。 目录 Python测试驱动开发(TDD) 目录 单元测试与功能测试的区别 “单元测试/编写代码“循环 遵守不测试常量规则 有用的TDD概念 不要预先做大量的设计 确保...
  • TDD实践

    2019-02-24 15:17:42
    TDD(Test-Driven Development)测试驱动开发,是敏捷开发中的一项核心实践和技术,也是软件开发过程中的应用方法。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,由测试代码确定需要编写什么产品代码。 ...
  • 学习TDDTDD的好处

    万次阅读 2011-11-24 10:27:36
    TDD的全称是Test Driver Development,测试驱动开发。就是开发要以测试为驱动。编码之前,测试先行。代码都没有,我如何测试,我连要测的对象都没有啊?这好像是个问题。 TDD的哲学为我们解答了这个问题:先编写...
1 2 3 4 5 ... 20
收藏数 3,668
精华内容 1,467
关键字:

敏捷开发的tdd思想