构建测试环境流程的自动化将有助于防止这种延误的发生。

　　“发布我吧”

　　“发布我吧，让我去，

　　我的 bug已经不再是最重要的了……”

　　这些话不是我写的，而是在Web上看到的，但它特别切合我们的主题。

　　那么，您的开发团队已经构建了应用程序套件，成功将它部署在WebLogic域中，并通过自动测试脚本对应用程序进行了彻底的测试。在集群中测试了套件(使用Web服务作为集群的前端)，见到它在集群中运行，并证明了故障转移能正常工作。

　　团队准备好了发行说明和所有的归档文件。那么现在已经万事具备，只等用户验收测试了，祈祷用户会喜欢它吧，您就可以为这次成功交付举杯庆祝了。

　　醒醒吧!现实是生产套件的万里长征才刚刚迈出了第一步。成功的交付需要跨越无数的障碍，需要开发人员的多次尝试。于是测试开始了，将使用各种测试器或测试工具，将涉及套件和开发人员无权访问的机器，这些测试将找到错误，至少有几个错误是需要修复的，整个过程需要重复进行多次。

　　获得推进

　　测试通常在一组明确指定的环境中进行。现在讨论这些受控环境包括哪些，以及将一个应用程序从一个测试环境推进到下一个测试环境需要哪些条件。

　　受控环境

　　我使用术语“受控环境”表示访问受到某个策略限制的环境。生产环境是一个受控环境，分段测试环境也是一个受控环境。这两个环境的访问控制测试类似，但分段测试环境的限制性访问策略的可能更少一些。简单地说，“受控测试环境”是一个用来测试应用程序(套件)的、受控制的(即访问受策略限制)环境。

　　在受控环境下进行测试的目的是获得可重复的测试结果：在相同的环境下对相同的软件进行测试，应该获得相同的结果。“相同的条件”要求准备的测试环境是一致的并且是可重复的。自动环境构建应该确保环境最初位于可重复的环境中，但还需要更多的条件以确保测试发生在可重复环境下。应该进行访问控制，以限制环境构建后能够更改该环境的人以及所允许的更改。如果在测试前应用了运行时更改，那么应该在测试日志中记录这些更改(这一点很重要)，这样才能重新创建完全一样的测试环境，即重复构建时也要重新应用运行时更改。

　　可以正式或非正式(或者两者结合)的形式应用访问控制。如果您的项目使用正式访问控制，则通常通过可以保护策略规则的软件或硬件设备实现。如果您的项目不需要太过正式，那么可能会非正式的(即根据公认的实践经验)应用部分或全部访问控制。很明显，非正式控制很容易遭到破坏，有时甚至无意中就破坏了，这种环境需要安装审计软件，用于根据期望的设置检查环境配置，并在出现不可接受的变化时发出警告。

　　受控测试环境的例子有：性能测试环境、压力测试环境、用户验收测试环境等。在受控测试环境中，开发人员通常可以查看测试结果、调查问题或错误，但是不允许管理或修改环境配置或者参与测试执行过程。

　　受控环境涉及的问题不仅仅是硬件：它是相应的硬件、基础架构和软件的结合。例如，性能测试环境和压力测试环境可以使用同一个硬件，但软件配置可能不同，性能测试可能使用JVM启用诊断工具，以分析性能瓶颈，而压力测试则不需要JVM。

　　促进推进

　　在管理得比较好的项目中，您将通过大量受控环境迁移应用程序套件，需要逐个测试应用程序。图1提供了一个示例。

　　图1：通过多个可控测试环境迁移应用程序

　　在项目测试计划中应该确定各种测试环境及其使用方式。通过各种测试环境迁移套件并最终实现实际生产的过程称为应用程序推进。

　　作为项目测试计划的一部分，您的项目要定义入口标准(entry criteria)，并且在应用程序套件从一个环境推进到另一个环境时必须实现该标准。在受控环境中部署和测试需要大量成本(将在下文中讨论)，如果应用程序的质量不合格以至于进行测试没有任何意义，可以应用入口标准避免这些不必要的成本开销。

　　在使用迭代或敏捷开发环境的项目中，可能会在一个或多个受控环境中提交好几个版本的应用程序进行测试。对于后续测试的每一个版本，测试的成功标准通常将逐渐严格或逐渐宽松。如果不采用恰当的方法，准备测试环境和部署套件的成本将成倍增长，有时候甚至导致这些方法的价值受到质疑。幸运的是，我们有一些工具和技术可以有效并可靠地进行推进，本文中我们将回顾其中一些。

　　重新部署和重复测试

　　我们可以将与部署相关的推进任务划分为两个主要阶段：

　　环境供应

　　部署应用程序套件

　　术语供应(provisioning)可以宽泛地定义为“提供应用程序所需的资源，以便它能根据规范执行任务”。资源可以是BEA WebLogic Server容器本身的任何内容，从数据库连接到Web services和后端系统连通性。

　　为了彻底测试您的应用程序，您应该在每一个测试环境中多次部署和测试每一个应用程序。您可以从以下两种方法中选择：

　　对于每一个测试，同时执行环境供应和应用程序部署

　　只供应环境一次，然后对每次后续测试部署、测试并重新部署应用程序

　　第一种方法为每个测试重新构建环境，开销很大，但它的优点是无需为供应和部署设置不同的脚本，就好像它们是一个任务的两个部分一样。另一方面，如果您的测试计划需要复杂的测试环境，涉及到许多服务器和/或多个域，那么每次测试运行的供应开销可能过高以至于难以接受，这时可以采用后一种方法。

　　推进测试不要失败

　　推进应用程序套件不仅仅是构建一个现有环境的更大版本并在其中部署套件。各种受控测试环境将有特定的测试目标，这些目标通过不同的供应需求表现。

　　表1说明了这一点，它使用一个虚构但并非不切实际的大纲测试环境规范测试一个应用程序套件，只是在环境上有一些增加内容。

　　表1：说明测试环境规范

　　这些不同可能会给供应增加大量负担。通常，供应错误是通过部署错误表现的，因此在构建好环境并第一次部署应用程序套件之前您无法看到这些错误。

　　第一次使用受控环境时，解决部署问题通常很棘手。开发人员和供应团队都没有复杂环境中分析部署异常的经验。开发人员总是认为能在其自己的测试机器或集成环境中部署成功意味着同样能在其他环境中部署成功。从另一方面看，测试人员和操作人员总是认为开发人员在软件交付过程中已经解决了部署问题，因此经常失败，而这时开发人员解释说他们从来没有在如此复杂的受控环境中运行应用程序。

　　至少应该知道千万不要低估推进应用程序的难度，否则您会后悔莫及。

　　老实说，我并没有改动什么!

　　我们已经定义了受控环境，现在开始讨论建立一个这样的环境需要哪些条件。自动供应是其中一项技术。

　　自动供应

　　如果您总是使用配置向导构建环境，您可能会认为这个过程不能自动完成，因为用向导构建时需要如此多的人工参与。如果可能的话，您需要学习WebLogic Scripting Tool (WLST)，它可以使用一个脚本语言控制配置向导的所有功能。WLST可以导入向导使用的模版，并通过脚本执行向导图形接口提供的自定义。在下文我们将更详细地讨论WLST中的脚本问题。现在您只需要知道或者相信可以通过脚本构建环境。

　　表1指出了测试环境间可能存在的不同之处。但是，尽管您的项目中可能存在部分或所有这些不同，供应的核心仍然是从一个环境转变为另一个环境。毕竟，在每个环境中，相同的应用程序套件被部署在相同的平台上。通过确定环境需求的不同，您可以找出使用脚本自动进行成功部署的共同特征。因此，一个环境的供应形成所有其他测试应用程序套件所需环境的基础。编写供应自动脚本时，您应该预见所有后续测试环境的供应需求。要做到这一点，您必须清楚当前测试环境和未来测试环境可能存在的不同。您应该根据项目测试计划，做一个类似表1的草表。

　　使用脚本控制自动环境构建有助于促进统一性。它还允许供应处于配置变更管理之下。这是一个很重要的优点，对环境配置进行的未经严格测试的更改对应用程序有不利影响，甚至可能导致应用程序崩溃。通过在变更控制下进行的脚本维护，脚本可以还原到之前的版本，对脚本的更改在生效前必须经过验证过程。配置管理系统也提供了一些方法来记录更改的原因，这样能够提供如何到达当前设置的历史路线图;通常，它们能够提醒某些功能无法正常工作，因为以前尝试该功能时失败了。

　　脚本供应中一个经常被忽视的优点是，脚本可以捕获供应和部署的模式。通常，使用跨多个机器的多个服务器供应多个环境的复杂性要求更多的时间来完成，它所面临的挑战超出想象。如果在编写供应脚本时比较细致，例如，插入注释解释不够明显的细节，那么在将来的项目中，可以参考这些脚本列举该项目中遇到的供应挑战，并且可以在以后类似的项目中作为模型。在Orbism，我们有一个用户供应和部署任务的参考解决方案库，并根据我们咨询人员的现场经验不断更新，这为这些领域的共同挑战提供一个可访问的模型解决方案集合。

　　自动部署

　　有人会怀疑说，部署操作如此繁琐，几乎不可能自动化。但是，除非您的应用程序本身很繁琐，不然的话只要您在开发脚本中投入了多少精力，您就能获得多少回报。

　　脚本部署帮助确保后续测试中测试条件的统一性。如果使用手工部署，很难验证是否按相同的顺序采取了相同的步骤。如果流程是自动的，那么采取的步骤都会反映在脚本内容中。此外，与供应脚本一样，部署脚本本身可以使用配置管理和变更管理进行控制。

　　数据不仅仅是将一组新的部署文件提交到部署工具那么简单。在部署文件中，有一个设置明确定义了应用程序组件所需的资源需求。它们的校正值与环境有关，在能够被正确部署之前需要对部署文件进行修改。当向WebLogic Platform 9.x环境部署应用程序时，应用这些值的方法建议采用部署计划。此页面 中的WebLogic Platform 9.2在线文档讨论了向不同目标环境部署相同应用程序时如何使用部署计划。对于WebLogic Platform 8.1，部署自定义要复杂的多，涉及到解包归档文件，解析并编辑里面的内容，然后重新打包归档文件。复杂性是实行自动化的一个好理由。PO Sample 中可以找到说明解析和修改部署描述符的示例代码和脚本。

　　经常向WebLogic域部署和重部署可能会生成不可预料的异常。BEA Support Patterns站点 有一部分关于 troubleshooting deployment failure 的内容，讨论了许多部署和重部署应用程序时发生的常见异常。大多数情况下，建议在部署和重部署前进行额外的补救步骤，这些步骤必须被包含在应用程序部署脚本中。

　　(编辑:anna sui)