测试自动化
自动化的测试是了解当前系统是否达到准备发布状态的第一步。自动化测试应伴随系统中的全部新代码。除此之外，当老的、未测试的代码被改变的时候，程序员应为代码编写新的测试。最后，当在验收测试或产品中发现缺陷时，应记录这一测试以证明缺陷，并且这一新测试应加入到全部测试集合中以避免今后发生相同的问题。当系统中所有的单元测试全部通过后，程序员应当对其代码有信心，相信不会影响系统的其他部分。
从敏捷的观点来看，自动化的单元级测试是构建流程的扩展。程序员每次运行构建流程并成功编译代码时，应遵循所有的应用单元测试。在敏捷配置管理环境中，损坏的单元测试与损坏的构建严重程度是一样的。这样小问题就不会扩展为大问题了。大问题（诸如全部程序停止工作）不会隐藏在后台。取而代之的是，团队可以在问题发生时定位，不断增长的单元测试集增加了准确监测错误的可能性。
我要补充一点关于单元级和系统级测试的内容：明智的项目和企业会进行 测试数据管理。这样就使得测试数据很容易的创建、修改、维护（当系统数据结构发展变化时）、存储（在每次测试前）。当数据模型发生大的变化时，甚至是在某些情况下，当开发数据库被清理掉时，依赖于脆弱的以及被随意修改的数据结构的大量自动化测试集就可以得到迅速的调整。
持续集成
持续集成与源代码控制、自动化构建流程、值得信赖的自动化测试集共同保证了开发过程中系统的稳定性和系统性能。在持续集成的环境中，程序员需要编写代码，在工作站上运行构建和测试，一天内多次进行检入。同时，有一台构建机（或一组机器）用以编译整个系统，在类似于产品配置的干净的环境中运行所有测试。这种行为可通过手动或者自动的方式启动 -- 或者间隔固定的时间或者由程序员检查代码。当代码没有在干净的环境中通过构建和测试时，无论什么原因，都会在检查后提醒全体成员。大部分情况下，敏捷团队都不会允许任何人检入额外的代码，直到解决了问题。
持续集成带来的好处是，它灌输了一种开发原则，不鼓励检入低质量的代码，且当问题发生时需要立刻解决。由于每天要进行多次代码检入 ，处于集成环境中的程序员很少或从不改变引起不稳定构建的代码。除此之外，如果遇到未完成的代码，团队的构建机制能够在几小时内记录它，而不是几天或几周。因此，程序员在中断代码前，不得不仔细考虑整体设计，甚至需要进行一些测试。这意味着处于持续集成环境中的程序员很少会在系统代码中直接进行试验，很少出现写了一半却忘记完成的函数，或是将系统组件遗忘在某处。当编写代码后立即监测出错误，解决问题所花费的时间往往少于几天或几周后才发现时所花费的时间。 这样，就保证了高质量的代码和更加迅速的发行周期。
对于大系统的可扩展的敏捷配置管理
大型企业经历过许多类似中小型项目遇到过的 CM 问题，还有部分附加的多系统、多项目、多初始属性的问题。例如，当小项目未监测出一个缺陷或者遇到了需要花费几个小时甚至几天才能解决的集成问题时，对于大型企业来说也许会花费几周的时间才能解决。相似的还有，对于小项目的源代码控制和版本的问题相比较于大型企业没有可依赖的配置管理系统时所遇到的系统回滚或多应用重新部署问题来说，简直是微不足道的。依据其规模与复杂度来说，适当的配置管理实践对于大企业是十分必要的。
此文章共有8页 上一页 1 2 3 4 5 6 7 8 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
