测试自动化

  自动化的测试是了解当前系统是否达到准备发布状态的第一步。自动化测试应伴随系统中的全部新代码。除此之外,当老的、未测试的代码被改变的时候,程序员应为代码编写新的测试。后,当在验收测试或产品中发现缺陷时,应记录这一测试以证明缺陷,并且这一新测试应加入到全部测试集合中以避免今后发生相同的问题。当系统中所有的单元测试全部通过后,程序员应当对其代码有信心,相信不会影响系统的其他部分。

  从敏捷的观点来看,自动化的单元级测试是构建流程的扩展。程序员每次运行构建流程并成功编译代码时,应遵循所有的应用单元测试。在敏捷配置管理环境中,损坏的单元测试与损坏的构建严重程度是一样的。这样小问题不会扩展为大问题了。大问题(诸如全部程序停止工作)不会隐藏在后台。取而代之的是,团队可以在问题发生时定位,不断增长的单元测试集增加了准确监测错误的可能性。

  我要补充一点关于单元级和系统级测试的内容:明智的项目和企业会进行测试数据管理。这样使得测试数据很容易的创建、修改、维护(当系统数据结构发展变化时)、存储(在每次测试前)。当数据模型发生大的变化时,甚至是在某些情况下,当开发数据库被清理掉时,依赖于脆弱的以及被随意修改的数据结构的大量自动化测试集可以得到迅速的调整。

  持续集成

  持续集成与源代码控制、自动化构建流程、值得信赖的自动化测试集共同保证了开发过程中系统的稳定性和系统性能。在持续集成的环境中,程序员需要编写代码,在工作站上运行构建和测试,内多次进行检入。同时,有一台构建机(或一组机器)用以编译整个系统,在类似于产品配置的干净的环境中运行所有测试。这种行为可通过手动或者自动的方式启动 -- 或者间隔固定的时间或者由程序员检查代码。当代码没有在干净的环境中通过构建和测试时,无论什么原因,都会在检查后提醒全体成员。大部分情况下,敏捷团队都不会允许任何人检入额外的代码,直到解决了问题。

  持续集成带来的好处是,它灌输了一种开发原则,不鼓励检入低质量的代码,且当问题发生时需要立刻解决。由于每天要进行多次代码检入 ,处于集成环境中的程序员很少或从不改变引起不稳定构建的代码。除此之外,如果遇到未完成的代码,团队的构建机制能够在几小时内记录它,而不是几天或几周。因此,程序员在中断代码前,不得不仔细考虑整体设计,甚至需要进行一些测试。这意味着处于持续集成环境中的程序员很少会在系统代码中直接进行试验,很少出现写了一半却忘记完成的函数,或是将系统组件遗忘在某处。当编写代码后立即监测出错误,解决问题所花费的时间往往少于几天或几周后才发现时所花费的时间。 这样,保证了高质量的代码和更加迅速的发行周期。

  对于大系统的可扩展的敏捷配置管理

  大型企业经历过许多类似中小型项目遇到过的 CM 问题,还有部分附加的多系统、多项目、多初始属性的问题。例如,当小项目未监测出一个缺陷或者遇到了需要花费几个小时甚至几天才能解决的集成问题时,对于大型企业来说也许会花费几周的时间才能解决。相似的还有,对于小项目的源代码控制和版本的问题相比较于大型企业没有可依赖的配置管理系统时所遇到的系统回滚或多应用重新部署问题来说,简直是微不足道的。依据其规模与复杂度来说,适当的配置管理实践对于大企业是十分必要的。

  配置管理的敏捷方法能够帮助大企业定位配置管理问题,同时保持对客户需求变化、进化的业务环境、不断提高的技术的灵活性。除此之外,敏捷配置管理方法还能够帮助新项目重复使用现有系统与项目的构建流程加快构建与运行的脚步。

  本部分中,我们将会探讨在大型开发组织中使用敏捷实践的三个主题。第一,我们将探讨如何灵活的执行敏捷的 CM 流程为单个项目团队和大型开发组织带来好处。第二,如何在地点分散的企业中的分布式项目上使用敏捷配置管理方法。后,企业如何通过深思熟虑的应用与流程集成加速软件交付周期,增强规模经济。

  有效的团队协调:共享代码库和链式构建

  每天的项目环境中往往需要团队间共享代码,使用通用库,甚至共享一个又一个的构建流程。例如,一个项目也许需要包含其它项目的构建与测试行为。这可能包括获得共享库的更新版本以确保其它项目的改变不会影响团队的代码,或是保证团队代码库德变化不会影响另一个项目代码的功能。而且,项目间可以共享随时更新的核心资源。这种资源可以包括通用类或类似于测试工具与测试数据生成器等。这种情况在大型企业中十分普遍,它们会自然而然的形成,不需要企业自身的协调。

  敏捷方法为开发团队提供了更有效合作、实时通信以保证项目进展的机会。通过提供构建成功/失败的快速反馈,开发者能够在恰当的时候检测与解决问题。