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

　　对测试驱动开发的感悟[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