传统的软件开发都是需求分析-设计-编码-测试的过程,这样的过程也能够确保交付正确的软件产品给用户,但是效率却很低下(功能特别简单的软件除外)。 这是因为,如果软件的功能比较复杂,规模较大的情况下,先完成编码(即便同时进行了功能调试),必然会隐藏了很多Bug在其中,这将使得后续的测试会花费更多的时间来找出前期编码过程中埋入的缺陷,而缺陷的定位和修复,以及回归测试等又要花费大量的时间。 所以,传统的开发过程很难具有较高的开发效率。 敏捷开发由此提出来测试驱动开发(TDD)以提高软件开发效率。 测试驱动开发,就是测试先行,在编码之前先写测试,为代码设定一个质量之门,也指明了方向;而根据测试进行代码的编写将更快捷,通过测试后的代码就是质量得到保证的代码,后面的开发无需再担心前面代码会出现缺陷,因为它们已经被验证是正确的。 这就使得这种开发过程不会出现传统开发过程中前期隐藏大量Bug到后期才被发现和修复导致的大量工作量的消耗,那自然就会使得这种开发过程有较短的开发周期,较高的开发效率。 理论上,测试先行是可以提高效率。 越早发现Bug,消除它的代价就越低。测试驱动开发完美地实践了这一测试公理。 除此以外,测试驱动开发还实践着另一个公理:小步快走效率高。 小步快走的意思是将需求拆分成较小的需求块,这样的测试容易编写,代码容易实现,代码的验证也很快。这种方式会避免较大需求块测试编写时间长,代码实现和验证的时间都被拉长,导致工期剧增(因为随着功能复杂、规模增大,耗费的周期会呈指数增长而非线性增长)。 测试驱动开发是针对代码块的,它可以使得开发人员快速实现代码功能。但是,虽然代码的实现快速而正确,但它却未必满足需求。要使软件能够快速交付,除了应用测试驱动开发(TDD)外,还要应用验收测试驱动开发(ATDD)。 验收测试驱动开发是针对需求来编写测试的,每个功能实现之后再通过根据需求编写出来的测试,这样就可以在实现功能的同时就获得满足需求的功能,当最后的功能实现之后,就可以进行软件交付了。 测试驱动开发确保软件内部质量,相当于单元测试和集成测试先行;验收测试驱动开发确保软件外部质量,相当于配置项测试和系统测试先行。 如果需要进一步提高效率,还需要实施持续集成和自动化测试。 既然测试先行可以提高效率的原理是“越早发现Bug,消除它的代价就越低”以及“小步快走效率高”,那么即便组织不具备实施完整的敏捷TDD和ATDD实践的条件,不妨考虑低配版的测试先行——实现一个单元即对这个单元进行单元测试,验证该单元的正确性;实现两个单元则进行集成和集成测试,验证集成后单元的正确性;一个功能实现了,就进行配置项测试,验证功能的正确性,相信也会获得优于传统的软件开发效率。 如果测试先行提高开发效率,你想改变你的开发过程吗? 这正是: 测试先行找问题,修复缺陷成本低 传统过程不拘泥,先行测试应期许 参考书目:测试驱动开发的艺术,作者:Lasse Koskela,译者:李贝,出版社:人民邮电出版社 |
|