需求、接口和测试 ——我看测试驱动开发(一)

原创 2003年12月19日 19:16:00

需求、接口和测试

——我看测试驱动开发(一)

Spacesoft【暗夜狂沙】

  软件工程界一直存在这样的看法,“程序员不应该测试他们自己的代码”,原因是程序员在代码开发中形成的思维定势将不可避免的导致测试的盲区,同时,就个人感情而言,个人很难否决自己努力完成的工作成果。

    这样的观念使得专业的测试团队的出现成为可能,于是,在现代软件开发中,专业测试团队的介入使得软件的质量得到了相当程度上的保障。测试成为对软件质量保证的最后哨卡,开始随着人们对软件质量和可靠性的关注而取得了日渐重要的位置。

    但是,软件工程的研究同样告诉我们另外一个观点:在软件开发周期的越早期发现错误,那个错误将带来的损失将越小。 下面这些图表摘自<<实用软件度量>>(Capers Jones,McGraw-Hill 1991),它列出了准备测试,执行测试,和修改缺陷所花费的时间(以一个功能点为基准),这些数据显示单元测试的成本效率大约是集成测试的两倍 系统测试的三倍(参见条形图)。

    尽管在传统测试理论中,测试几乎已经伴随了整个开发周期:单元测试、集成测试、系统测试、验收测试。但是,更多的时候我们遇到的情况是:至少在项目开始集成之前,测试是基本不存在的。程序员不愿意在模块完成之后再花时间来写测试代码(事实上,很多程序员连文档都欠奉),而测试人员则不会写测试代码(能写代码的话通常都已经被抓去写代码了)。事实上,即使测试人员愿意写测试代码来完成对代码的单元测试,这样的分工也是不划算的,因为这引入了额外的人与人之间的交流成本。于是我们的测试通常是在集成阶段开始进入的,于是我们不得不在这个时候在来面对可能的模块质量问题、模块设计问题以及其他许多早在那之前就应该已经解决的问题。   

    这个情况在传统工业里是不可想象的。你无法想象波音飞机在开始总装之前没有对它的零件进行过像样的测试,但是你却常常看到我们对一大堆没有进行过单元测试的代码进行集成。这个模块有内部逻辑错误吗?它有内存泄漏吗?它能够应付那些极端的边界条件吗?它达到了需求的要求了吗?不知道,先拼起来再说,到时候测试发现不了问题就会放我们过关的。然后你盯着每周的bug 列表看,看到bug 数渐渐下降,渐渐的接近出厂要求,然后你擦擦头上的冷汗:“感谢上帝,看来这次又过关了”。但是,难免会有一天,你的邮箱里塞满了来自用户的抱怨,告诉你你的程序又在某个你想不到的地方出了问题。

    问题在哪?问题在于我们要求程序员在完成开发之后再完成一套东西的开发,而这些东西并不是要开发的软件的一部分,并且将在项目结束时被抛弃。对程序员而言,这等于叫他额外的多完成一些原本不需要的任务,这是很难被接受的,即使他能理解这样做的重要性。这是人性的弱点。那么,我们如何让测试更进一步的深入开发过程,尽可能保证软件每个组件的质量呢?这就要求我们放手让测试驱动开发的过程,让对需求的承诺直接的传递到每个组件的开发当中。

    在详细设计的过程当中,需求总是可以分解到模块,并且确定了模块之间的接口。之后才是正式的开发。于是对各个模块来说,“这个组件要实现什么功能?”“它将如何被使用?”这样的需求总是完整的被体现在了各个模块的接口上,也就是说,保证对接口的使用能够正确无误的进行,就保证了这个模块的最终质量。那么,我们先走一步,针对模块的接口写出测试代码,这样在以后开发的时候,就可以确定我们的模块是否达到了我们的需求。也就是说,我们把单元测试提前了,提前到单元代码的开发之前。

    先写测试代码的带来了很多好处。首先,在很多时候,需求是不清晰或者说不完整的,那么写测试代码的过程就是使需求清晰化的过程,这使以后的开发免除了很多麻烦和争执。其次,这使得我们得以在整个开发过程中保持一套详尽的单元测试代码,而这在代码重构里是必不可少的。最后,先写测试代码会影响程序员的心理,使他们重视用户的需求和体验,而不是仅仅打算实现模块的功能和避免被发现错误。

   然后,我们在整个开发过程中将由这些测试来决定代码如何编写,因为这些测试代码代表的是接口的标准,而接口正是需求的化身。对于这个开发模式,Peter Coad 给出了以下的描述:

     a.. 编写和保持一套详尽的单元测试。

     a.. 要先建立相关的单元测试和验收(acceptance)测试,然后根据测试编写代码。

     a.. 由测试来决定如何编写代码。

    下面我们来总结我们上面提到的要点:

    1)针对接口开发,使接口代表需求

    2)用测试评价接口是否符合需求,并且在开发过程中保持足够详尽的测试

    3)在代码的修改、重构等变化时,用测试保证代码质量

    在更高层的视野看来,测试驱动编程事实上是把测试对软件整体质量的保证引入到软件单元的开发中来,使得整个开发过程中的质量得到更进一步的监护 。

欢迎光临作者的个人主页:http://www.mrspace.net/

说说测试驱动开发

1 测试驱动开发模式1.1 重新定义“测试”这是一张影响图: 普通箭头表示当第一个节点增长时,第二个节点也会做相应的增长。 带圆圈的箭头表示当第一个节点增长时,第二个节点也会做相应的减少。 当压力越大...
  • deniro_li
  • deniro_li
  • 2017年04月28日 10:53
  • 1977

【学习笔记】C#测试驱动开发

第一章 通向测试驱动开发之路 敏捷方法简介: 个人与互动 重于 流程与工具可用的软件 重于 详尽的文件与客户合作 重于 合约协商响应变化 重于 遵循计划 敏捷注重交流沟通,应对变...
  • qiaoxinwei
  • qiaoxinwei
  • 2014年05月06日 16:28
  • 1377

TDD测试驱动开发

http://www.cnblogs.com/zhq3051/ 一.前言 不知道大家有没听过“测试先行的开发”这一说法,作为一种开发实践,在过去进行开发时,一般是先开发用户界面或者是类,然后再...
  • wuxiaobingandbob
  • wuxiaobingandbob
  • 2015年08月06日 13:32
  • 1815

Java程序员的推荐阅读书籍之九《测试驱动开发》

Robbin的推荐语:   《测试驱动开发 by Example》 本书最大特点是很薄,看起来没有什么负担。你可以找一个周末的下午,一边看,一边照做,一个下午就把书看完,这本书的所有例子...
  • huangyuanmu
  • huangyuanmu
  • 2013年11月18日 13:26
  • 841

测试驱动开发优缺点

前言      近期学习了TDD(测试驱动开发),但是由于没有亲身使用太多,所以说不出太多感受,但是看到了一篇博客,觉得讲的挺好的,跟大家分享下。 正题     不觉间,采用测试驱动开发(T...
  • zhaodandan19910306
  • zhaodandan19910306
  • 2015年06月30日 19:16
  • 1872

测试驱动开发(TDD)实战小例子(JAVA版)

我们知道,测试驱动开发(TDD)的基本思想就是在开发功能代码之前,先编写测试代码。也就是说在明确要开发某个功能后,首先思考如何对这个功能进行测试,并完成测试代码的编写,然后编写相关的代码满足这些测试用...
  • sunli880127
  • sunli880127
  • 2013年10月17日 15:24
  • 1756

基于测试驱动的iOS开发

测试按照阶段划分为:单元测试、集成测试、系统测试和回归测试。单元测试是对软件组成单元进行测试,其目的是检验软件基本组成单位的正确性,其测试对象是软件设计的最小单位——模块。单元测试是一种白盒测试。白盒...
  • wang1514869032
  • wang1514869032
  • 2016年08月09日 11:35
  • 770

测试驱动开发心得体会

手头开发项目时进行了TDD,发现它非常好用,具体表现在如下方面: 1.引导程序员设计合理的功能粒度和易测的外部模块接口。 2.自动化测试,能够在保证质量的前提下进行重构,对代码进行修改后可以方便地...
  • kimicsdn
  • kimicsdn
  • 2016年11月16日 17:02
  • 389

简图记录-C语言嵌入式测试驱动开发基础

简图记录学习~ 《测试驱动的嵌入式C语言开发》 TDD测试驱动开发是一种增量式软件开发技术。 其特点是通过 写自动测试测试用例->编写代码通过用例->重构优化代码 的微循环增量开发。 很多嵌入...
  • runafterhit
  • runafterhit
  • 2016年10月30日 22:24
  • 371

测试驱动开发三部曲——走出TDD丛林

软件工程问题及解决       1. 总结归纳需求时,因为用户对需求理解不清,需求的变化,可通过需求管理解决,在沟通中应先澄清概念,定义,范围,背景及沟通的形式(原型和图片比较合适)       ...
  • dananhai381
  • dananhai381
  • 2012年09月29日 15:24
  • 1112
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:需求、接口和测试 ——我看测试驱动开发(一)
举报原因:
原因补充:

(最多只允许输入30个字)