测试驱动开发的问题

chaorenwopashei 2007-10-24 07:01:01

敏捷模式中的测试驱动开发

事实上，现在最新的软件开发项目管理的模式之一甚至将软件测试的优先权提高到高于软件功能本身的开发之上。在敏捷模式（Agile Model）实践范围中的测试驱动开发模式（Test Driven Development，简称TDD）要求将软件的测试机制和可测性首先开发到软件中去，把对软件进行测试的功能作为软件功能开发的不可缺少的一部分来对待。它要求所有软件功能组件都必须有自己的进行自我的单元测试的机能、并且要求程序编写人员在开发软件的功能程序编码之前，先开发进行这些功能自我测试的程序。测试的程序编写完成之后，就开始进行单元测试的运行。这时候，由于提供功能的程序源代码都还没有编写，所以刚开始的时候这样的自我单元测试当然都是通不过的。当这些单元测试都能运行之后，开发团队然后才开始编写每个单元里面的具体功能的程序。
由于进行自我测试的程序已经完成了，每个功能开发完了之后，开发人员就马上可以启动单元的自我测试程序。要是单元的功能程序开发得完善，这时单元的自我测试就能通过，单元的开发就算完成了，测试人员再进一步进入到下一步的其它测试，比如使用案例的测试和系统整合的测试，等等；要是单元的功能程序在开发中有问题或缺陷，这时单元测试就还是无法通过，那么开发人员和测试人员就先集中精力来分析到底是什么缺陷和错误造成单元组件的功能程序无法通过那些自我测试，然后可以根据测试失败的症状进行单元功能程序的纠错工作。
举例来说，如果我们需要开发一个进行文档选择的功能组件。采用传统的开发方法的话，就是开发人员先将文档选择的功能程序开发出来，然后进行黑箱效应测试，证实文档能被选择之后就完了。采用TDD的开发方法，我们就不是先开发如何选择文档的功能程序，而是先考虑这个组件该如何进行单元测试。所以开发人员先编写在文档选择的使用过程中进行检测可能出现差错的测试程序。这些测试检验代码的白箱效应的测试，比如进行文档选择后的数据检查、以及程序的逻辑检查等等。等到这些单元测试程序完成并能够运行之后，再开始编写实际的文档选择的功能程序。每个局部功能程序编写完毕就立即运行单元测试，直到单元测试全部通过为止。这时开发人员也可以根据软件构架设计的有求，对功能代码中的一些运算方程函数进行模块优化性的分解（也叫Refactor），除去任何重复的代码等等。任何源代码改动和分解之后，必须再次运行所有的单元测试，直到全部通过后才进行证实使用方案的黑箱效应测试，比如检测文档选择正确的结果、选择错误的结果、文档打不开的结果、文档找不到的结果等等。

这样的开发运作流程和管理的理念是，所有的程序都应该有它的可随时启动和利用的测试机制（Test Harness），而且这种测试机制应该是每个软件功能组件单元的不可分割的一个组成部分。我们首先开发这些提供测试机制的程序，建立一个可供测试的框架。然后通过先测试失败、加上功能后然后造成测试成功这样一种反面性的验证，来证实开发出来的软件是符合所设计的测试要求的。所以你可以看得出来，测试驱动开发的模式的主导思想是为满足测试而开发。
比喻来说，这就好像是修建一条铁道线，得先把铁路轨道的标准定了、轨道先铺上，然后再在铁路上运行与轨道宽度标准相符合、专门为它而造的火车。铁路轨道的宽度标准决定了所用的火车必须遵循的宽度。所以可以说，轨道宽度标准是一个制约了火车合格标准的框架。先有了这个框架可以很容易地证实造出来的火车是否符合要求。当然，你也许可以不顾宽度标准先造个火车再说，但这样造出来的火车不见得能在轨道上跑：要是轮距宽度不符合轨道标准，你就得返工重做。TDD的管理模式就是这个先造检测标准的理念在软件开发上的运用，就好像是你先定好轨道的宽度，然后说：按照这个标准造火车，不能在这个轨道上跑的火车就自动不合格；TDD的管理模式使开发人员建立同样的思路：按照这个测试标准去开发程序，通不过这些测试的软件就自动不合格。
这样的开发方法有很多好处，最明显的好处是“强迫”开发人员在设计程序的同时，并列进行必须进行的单元测试设计，催促你去思考如何验证你的程序单元的逻辑正确性和单元的完整性。更重要的是，这样的开发模式有助于推动进行自动化测试的工具程序的开发、提高测试的效率，因为那些事先设计好的的单元测试程序，在单元的功能程序编写过程中，可以被随时使用，来验证所开发的功能程序部分是否符合要求。
这样的开发项目管理模式和理念，很明显地是将软件测试的作用和重要性提高到一个开发战略的层面。测试不再是简单的开发完毕后再考虑使用的质量管理的辅助手段而已，而是衡量软件在开发过程中每个单元组件是否能够通过，可以说是掌握了项目进度的“生杀大权”。
这个开发管理模式相对来说是一个比较新颖的方法，它对传统的开发流程的项目管理造成了不可避免的冲击，因此并不是很容易被开发团队接受，特别在绝大多数的在开发人员说了算的企业文化里，这样的开发方法的使用和推广很容易受到开发团队的阻力，因为它不仅用开发流程的改革来承认测试的重要性，并且由于开发人员被要求进行单元测试的开发和执行的额外工作，开发人员的工作量和习惯也都需要作一定的改变。
但是毫无疑问，这个项目管理模式所能够带来的巨大好处是有目共睹的。这也是为什么这几年来在业界中像敏捷模式、TDD模式等新型管理方法在软件开发的项目管理上被越来越广泛地利用。就拿微软本身来说，我们目前也正在进行一场内部的改革项目管理的“革命”：两年前，总部产品开发部门有少数一些项目经理们自愿组成一个推广敏捷模式的兴趣社团，在少数几个开发团队开始推动敏捷模式和TDD等。他们有点像个“地下组织”，因为绝大多数的产品开发团队还是在使用传统的方法，公司也没有人正式倡导敏捷模式等。但是近两年来，采用TDD等模式来充分发挥测试对质量管理起到的好处，很快就得到很多团队的共识，因为那些采用了这些模式的团队在软件质量的增进上有明确的数据可以证实，这种尊重测试的方法为提高软件质量、降低Bug Count（缺陷数）、最终帮助开发项目的成功所能带来的巨大好处。在好几次公司的经验交流会上，一些采用了敏捷模式和TDD等方法的团队公布详细的质量管理的数据比较，来证明这些新方法的优越性。微软快速适应变化的特性使得公司很快地也学会支持对新型模式的采用，现在全公司对技术员工进行开发工程教育的部门也开辟相关的课程，帮助一起来推广对敏捷模式和TDD等管理改革的采用，颇有“星星之火快要燎原”的气势。有的团队甚至采用配对的两人坐在一起开发的工作模式：一个人开发进行单元测试的程序，另一个人接着开发功能程序、并马上进行测试。两个人来回使用同一台计算机来完成对某个组件的开发。

...全文