对测试驱动开发的感悟[1]

发表于:2010-01-19来源:作者:点击数: 标签:开发驱动感悟
对测试驱动开发的感悟[1] 软件测试工具 最近听到了很多关于软件 质量 的话题,自己前段时间也参加个 PMP ( 项目管理 )的培训,所以一时对于质量控制特别感兴趣,在这里想和大家共同讨论下! 软件质量,是所有人都很关心的东西。我们在开发过程中为了保证质量

  对测试驱动开发的感悟[1]   软件测试工具

  最近听到了很多关于软件质量的话题,自己前段时间也参加个PMP(项目管理)的培训,所以一时对于质量控制特别感兴趣,在这里想和大家共同讨论下!

  软件质量,是所有人都很关心的东西。我们在开发过程中为了保证质量,从中引进了软件测试。它在整个的过程中起到的作用不言而预,但是它也存在一些问题:

  1、在软件测试中要保证软件的高质量就必须增加项目的成本,从而需要增加测试人员,延长项目时间,购买或学习测试工具的成本。

  2、因为这种测试是依赖与开发完后才提交给测试人员的,所以如果测试中出现BUG,就会出现BUG打回,再次提交测试...,这中间还需要测试人员和开发人员的沟通,这也是一个成本的增加

  3、这种方式会使得开发人员对测试人员产生依赖,从而降低代码的质量,减少自己的测试.....

  我们为什么不能把测试前移呢!让开发人员自己对软件的业务就做个完整的测试,然后把代码提交给测试人员,这样就可以减少BUG的数量,同时可以让测试人员不只关注与功能性的问题,可以关注更深层次的问题(性能,用户体验...),这种方式就是做单元测试。其实这个东西很早就有了,每个人都知道它,只是如何做的问题,我相信其实很多公司都做到,有些做的很好,但也有些是失败的!我自己经历过失败,体会过它的麻烦和迷惑,也经历了成功,体会到了它的好处。所以把这些写出来分享下!

  软件就是由代码组成的,所以软件的质量就是代码的质量,我们出了BUG就从代码开始入手找问题,然后修改代码。但是当你的软件从小慢慢变大时候,代码越来越多,彼此之间的关联越来越紧密,这样就带来了一个问题"修改一部分代码后会影响多少?",如果你拿这个问题去问那些项目中没有单元测试的开发人员,他们给出的答案都是通过"拍脑袋"来的,这样绝对会给你的项目带来风险。为了降低风险,项目开始要求开发人员做单元测试,但是做过后得出,这真的可以降低成本吗!花了太多的时间去写测试代码(甚至比开发时间还要多),对于质量的保证也没有达到预期的效果...,项目做完后,发现做单元测试的和没有做成本多很多,所以接着就放弃了!..... 这种现象我想是我们都想做它但又不做它的最大因素。

  其实我想大家对它的理解有点误差,我认为他最大的用处不是用来测试代码,而是测试设计!!代码从是设计来的,保证了设计的正确性不也保证了代码嘛!软件中的未知风险太多了,其实很多出于设计,对于设计很难去评价好,还是坏,很难找到一个衡量的标准,但是我想TDD,给了我们一个标准,虽然不能去完整的评价,但至少可以是一部分,可以降低它的风险。

  这里慢慢开始引入了本文的主题,测试驱动开发(TDD)。我的理解上,单元测试如果不是TDD这种模式,就没有太多的必要去做,因为那样投入做单元测试的成本和收益之间找不到平衡点。

  "测试驱动开发"的经历

  测试驱动开发简称TTD,全名Test-Driven Developmentd。它是敏捷开发的一个重要组成部分,来源与"极限编程"。我接触它是从一年前的那天(具体时间不记得了~ 呵呵!)开始的.....

  接触

  记得两年前的某天,我正在公司偷偷地看电视剧"奋斗",这时看到邮箱中的一封邮件: 部门下了一个确定"要求每个项目开发过程中加入单元测试"。当我听到"单元测试"的时候,满头的问号,"它是什么东西,做什么用的....?"(当时还很菜,居然还听过单元测试...!),接着不停的开始找资料,足足花了一个星期才把它了解,然后做了一个简单的DEMO,写些简单的测试代码,把它放到 Nunit上,看着都是通过的提示,兴奋呀!

  这时就和项目中的一个"大牛"开始讨论它了,忽然"大牛"的口中蹦出了三个英文单词"TDD",然后和我讲了一大堆,我根本就不知道他说什么(水平有限,当时理解不了),只是重复着三个字"明白了"。接着他说,项目的这个版本你设计的时候,加入单元测试吧,如果可以的话,也试下TDD.....

  我是一个喜欢挑战的人,所以一开始就玩先写测试代码,结果呢!大家都明白,菜鸟嘛!一定失败咯,其中的原因是:根本就没有"测试驱动开发"的思想,完全不知道如何开始先写测试代码,而且还没有理解MOCK!下面只有乖乖地和别人一样,等代码写完后再写测试代码。

原文转自:http://www.ltesting.net