BEA WebLogic Platform应用程序通常作为复杂生产系统的一部分进行部署。当交付以WebLogic Platform为基础的应用程序时，对应用程序进行正式测试需要恰当控制的测试条件，而提供这些条件本身就是一项复杂的任务。如果没有准备好恰当的环境并成功地进行应用程序部署，就无法执行正式测试，从而影响交付，而交付时间安排上一点点的松懈都将导致整个项目的推迟。

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

　　“发布我吧”

　　“发布我吧，让我去，

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

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

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

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

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

　　获得推进

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

　　受控环境

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

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

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

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

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