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

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

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

0. 常见测试方法

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

1. 基本思想

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

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

“你有了解哪些开发模式?” “你了解的这几种模式有哪些不同” “测试方法与目的是什么?”
带着这些问题,我们来看看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 阅读数 374

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

敏捷开发是一种内涵非常丰富的思想,面向用户,面向需求,而不是面向模块。而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 liner19891104 阅读数 57

本文主要总结一下敏捷开发模式的基本思想

 

1、测试驱动开发(TDD):敏捷开发中,测试是在功能实现之前。就是要实现一个功能,首先根据业务需求,写出相应的测试,然后再写功能代码使得每个测试都可以通过。可以将每个功能做成一个Story,然后针对每个Story编写测试。

 

2、小版本发布(Frequent Releases):敏捷开发中,最重要的思想之一就是,尽可能短的时间内,发布可以运行的版本。这种思想的好处是,软件本身成为了客户和开发人员之间沟通的工具,这样,在用户使用发布的产品时,发现问题,及时反馈到开发人员,开发人员及时做出修改。同时,这样周期性的发布产品,也可以极大地提高开发人员的积极性和工作效率。同时,当发布的版本出现问题的时候,改动也并不是太大。

 

3、文档最少化(Minimal Documents):文档最少化,其实,个人觉得,还要根据项目的真实情况作调整。必要的文档还是需要的。

 

4、现场客户(Customer Engagement):敏捷开发中,客户需要和开发人员呆在一起。然而很多时候,这点很难办到。如果能说服客户和开发人员呆在一起,那么固然很好。

 

5、自动化测试(Automated Testing):自动化测试主要靠一些自动化测试工具的使用,同时可能要结合一些自动化测试脚本。

 

6、持续集成(Continuous Integration):敏捷开发中,集成将是一件极其平凡的事。也许一天需要集成几次或者几十次。由于集成的平凡性,当遇到冲突时,很容易定为冲突的位置。

 

7、结对编程(Pair Programming):敏捷开发中可提倡采用结对编程,就是两个人共用同一台电脑进行编程。一个人编写测试的时候,另一个思考,一个人编写功能的时候,另一个人思考。同时,结对的好处是,发现bug及时。

 

8、每日会议(Stand Up):每日会议的时间大约为15分钟,会议上,每个人回答三个问题:昨天做了什么?今天打算做什么?遇到了哪些困难?

 

9、迭代性的调整计划(Adaptive Planning):一个新版本的发布,意味着一个迭代的结束,另一个迭代的开始。在这里我们要有一个缓冲时间,在这个缓冲时间中,我们需要做的是确定下一个迭代的具体目标,并同时调整下一个迭代中的时间安排。

 

10、合作是敏捷成功的关键(Collaborative Focus):敏捷开发中,责任不是某一个人来担当,而是整个开发团队。每个功能不是属于所属的开发者,而是整个团队。每个人都不需要经过模块负责人的同意,而对代码进行重构。但这样,又存在团队之间的共识了。

 

 

2018-08-15 11:43:58 Ffffatass 阅读数 243

敏捷开发流派有很多,但是万变不离其宗。

  • 个体与交互           胜过     过程与工具
  • 可以工作的软件   胜过     面面俱到的文档
  • 客户协作              胜过     合同谈判
  • 响应变化              胜过     遵循计划

敏捷开发是一种思想,是一种紧紧跟随其价值观的思想。敏捷有很多流派,有很多落地的方案,但是这些都是基于思想上的思考。思考是可以有不同的,但是思想是不变的。所有敏捷开发的唯一重点就是紧跟其核心思想,不要被形式束缚。

敏捷测试的特点

阅读数 1400

TDD测试驱动开发

阅读数 6

没有更多推荐了,返回首页