`
sunguanxing
  • 浏览: 1083401 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

TDD(Test-Driven Development)

阅读更多
  测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践,但不只适用于XP(Extreme Programming),同样可以适用于其他开发方法和过程。

  TDD的基本思路就是通过测试来推动整个开发的进行,但测试驱动开发并不只是单纯的测试工作,而是把需求分析,设计,质量控制量化的过程。

  TDD的重要目的不仅仅是测试软件,测试工作保证代码质量仅仅是其中一部分,而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求(对象、功能、过程、接口等),主要是编写测试用例框架对功能的过程和接口进行设计,而测试框架可以持续进行验证。

  优点:在任意一个开发节点都可以拿出一个可以使用,含少量bug并具一定功能的产品。

  缺点:增加代码量。测试代码是系统代码的两倍或更多。

  TDD = TFD + Refactoring

  (TFD -- Test First Development)

  计算机领域:

  Test Drived Develop

  测试驱动开发是一种开发方法,是开发人员参与的活动。 其效果是以可执行的形式文档化你的需求,迫使你分清职责隔离依赖以驱动你的设计,编织安全网以便将Bug扼杀在在摇篮状态,防止其逃逸。可传统测试人员的活动是试图找到已经逃逸的Bug。这两种活动都是必要的,而且毫不冲突,互为补充。

  那么测试人员在新的特性还没开发完成之前做什么呢? 除了提前写测试用例,无论是自动化的还是非自动化的,而需要测试人员参加的一项重要活动,就是参与特性验收条件的制定。 之前经常发生开发人员按照自己的理解去编码,测试人员按照自己的理解去测试,直到开发完成,测试过程中才发现理解的不一致,开始产生争执并阻塞等待业务分析人员(如果幸运的话)或者行政主管(如果开发过程混乱的话)的仲裁。 解决办法就是,在开始开发新特性前的一刹那,由业务分析人员,测试人员,开发人员进行一次讨论,就验收条件达成一致并形成记录,然后测试人员和开发人员分头去写测试和实现。
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics