高效开发与彻底的软件测试

发表于:2009-06-17来源:作者:点击数: 标签:软件测试开发
“千般路”与“磨豆腐” 很久以前听一个故事:从前有个小伙子,少时有大志,长大后却无好营生,开了个豆腐作坊,每天磨豆腐累得腰酸背疼。每到夜深人静,小伙子辗转反侧,总想找条更好的“事业之路”,可是想过千百条、尝试过几十条路,都走不通。夜不成寝,
“千般路”与“磨豆腐”

  很久以前听一个故事:从前有个小伙子,少时有大志,长大后却无好营生,开了个豆腐作坊,每天磨豆腐累得腰酸背疼。每到夜深人静,小伙子辗转反侧,总想找条更好的“事业之路”,可是想过千百条、尝试过几十条路,都走不通。夜不成寝,白天干活更累,小伙子不由慨叹:“晚上想过千般路,白天还得磨豆腐”。

  不久以前看过一篇文章:《CMM欺骗了中国的软件业》,内容是对CMM热的反思。CMM当然不会主动欺骗人,实际上是我们的软件业自己欺骗自己。我们从来不缺少“某某模式”,“面向某某”,“某某认证”等等听起来美妙无比的东西,问题是实际的研发过程中能做得到码?现实是残酷的,美妙的概念漫天飞舞,开发过程仍然是作坊式的,正是:“晚上想过千般路,白天还得磨豆腐”。

  中国的故事通常都有圆满的结局,现在接着说“磨豆腐”的故事。过了很长时间,小伙子终于面对现实,不再沉迷于不切实际的空想,用心磨好豆腐,闲时琢磨些个窍门,慢慢地,他的豆腐质量越来越好,每天产量也越来越多,作坊越开越大,成了远近闻名的“豆腐老板”,后来,他做起了别的生意,发现年轻时的空想,其实很多都是可行的,因为现在“能力”和“财力”都不同了。

  再说软件开发。我们不反对任何理论、技术、方法、模式等等,但第一,您的企业或团队做得到吗?不要做“如果开发时间延长一倍,就可以做到”之类毫无意义的假设。第二,做了真的有效益吗?效益是指扣除成本之后的收益。如果不具备这两点,那么还是不要整天想着“千般路”,首先想想如何好好的“磨豆腐”吧。

  对于所有软件开发来说,代码编写都是无可逃避的“磨豆腐”。改进代码编写工作,高率效低成本地开发出高质量的代码,对于软件产品能否在激烈的竞争中胜出,对于软件企业的生存和发展,都具有重要的现实意义。

  本文是Visual Unit应用的范例项目C++代码文档生成器的主题文档,叙述的正是改进代码编写工作的方法和工具,所有内容均经过实战检验,具有\"可行\"和\"效益\"两个特征,\"可行\"是指较低门槛或没有门槛,凭现有条件即可实施;\"效益\"是指能产生立竿见影的效果。

  本文所援引的范例项目,模拟最糟糕的开发团队,最混乱的开发流程:由很少写代码的测试和预研部门开发,人员不固定,时间也不固定,谁有空就写上一些;没有设计,没有文档,基至也不在代码文件中保存编码人员的信息,成员完全依赖于阅读代码和测试用例来理解其他成员写的代码;除了简单的命名规则外,没有其他规范,甚至连一个函数原则上不能超过50行之类的基本规范也没有(范例中有超过200行的函数CMacro::Unwind(),一万多条路径)。 任何开发团队和开发流程都会好于范例项目的开发团队和开发流程,因此,范例所展示的方法和工具,具有\"广泛可行性\"。

  本文介绍如何进行高效编码调试和实现彻底的单元测试。编码调试是任何软件开发都无可逃避的工作,在Visual Unit的支持下编码调试,只是把本来就一定要做的工作改变一下方式,不需要多做什么,就可以大幅提高编程效率和质量;另一方面,Visual Unit彻底改变了单元测试难于实施或成本昂贵的局面,无论团队中开发与测试人员的比例是怎么样的,都可以轻松快捷地实现彻底的单元测试。

  高效编码调试

  任何软件开发,都离不开编码调试。对于稍为复杂一点的函数,一般来说,编写几行代码,就要执行一下,看它们是否按预想的工作,然后再继续写,写完后还要将各种可能输入都执行一下。如何执行?一般由别的代码来调用,也就是说需要驱动,驱动通常是在开始编写函数实现代码之前建立,这样才能一边编写一边调试。驱动大致可分为自然驱动和专门驱动。

  自然驱动:利用项目中已有的代码作为驱动,通常是在被调试的函数中加断点,从界面执行一个需要调用该函数的功能,调试器中断时就可以调试了;专门驱动:为需要调试的函数编写专门的驱动代码,通过执行驱动代码来执行被调试函数。

  自然驱动的主要优点是不需要其他工作就可以直接调试,甚至感觉不到需要驱动,主要缺点是输入数据通常是公共的,即很多代码都使用相同的输入源进行调试,实际输入往往是经过其他代码处理后的中间结果,要针对各种可能输入都进行调试往往很困难,造成调试不全面,程序员的思维受到局限,难于做到全面地考虑各种可能输入。

  专门驱动的主要优点是输入数据是专门针对于被测试程序,容易做到比较全面,程序员的思维也会比较全面,对编写功能齐全的健壮的程序很有好处,要针对某种特定输入进行调试比较容易,缺点是需要花费大量的时间来编写驱动代码。

  显然,自然驱动的主要问题是不全面,代码错误较多,专门驱动的主要问题是编写驱动代码很费时。有没有更好的方法,既不需要编写驱动代码,又能方便且全面地调试?有 !这就是自动驱动,即在Visual Unit的支持下编码调试,不但无需费时间写驱动代码,更拥有多种独特的便利,可以大幅提高编码调试的质量和效率。

  Visual Unit是单元测试工具,但也是高效编程调试的支持环境,在Visual Unit的支持下调试,既全面又省时:

  自动生成驱动代码,但又可以方便地设定调试输入;

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