构建测试环境流程的自动化将有助于防止这种延误的发生。在本文中，我将展示对一个测试环境进行自动部署的工作如何重用于其他测试环境。
“发布我吧”
“发布我吧，让我去，
我的 bug已经不再是最重要的了……”
这些话不是我写的，而是在Web上看到的，但它特别切合我们的主题。您可以在Web上查看完整版本，更多内容请参见 Filks站点。
那么，您的开发团队已经构建了应用程序套件，成功将它部署在WebLogic域中，并通过自动测试脚本对应用程序进行了彻底的测试。开发人员可能已经阅读并实现了Michael Meiner在 使用WLST和BEA Workshop在集群环境中开发Web应用程序（Dev2Dev，2006） 一文中的建议，在集群中测试了套件（使用Web服务作为集群的前端），见到它在集群中运行，并证明了故障转移能正常工作。
团队准备好了发行说明和所有的归档文件。那么现在已经万事具备，只等用户验收测试了，祈祷用户会喜欢它吧，您就可以为这次成功交付举杯庆祝了。
醒醒吧！现实是生产套件的万里长征才刚刚迈出了第一步。成功的交付需要跨越无数的障碍，需要开发人员的多次尝试。于是测试开始了，将使用各种测试器或测试工具，将涉及套件和开发人员无权访问的机器，这些测试将找到错误，至少有几个错误是需要修复的，整个过程需要重复进行多次。
获得推进
测试通常在一组明确指定的环境中进行。现在讨论这些受控环境包括哪些，以及将一个应用程序从一个测试环境推进到下一个测试环境需要哪些条件。
受控环境
我使用术语“受控环境”表示访问受到某个策略限制的环境。生产环境是一个受控环境，分段测试环境也是一个受控环境。这两个环境的访问控制测试类似，但分段测试环境的限制性访问策略的可能更少一些。简单地说，“受控测试环境”是一个用来测试应用程序（套件）的、受控制的（即访问受策略限制）环境。
在受控环境下进行测试的目的是获得可重复的测试结果：在相同的环境下对相同的软件进行测试，应该获得相同的结果。“相同的条件”要求准备的测试环境是一致的并且是可重复的。自动环境构建应该确保环境最初位于可重复的环境中，但还需要更多的条件以确保测试发生在可重复环境下。应该进行访问控制，以限制环境构建后能够更改该环境的人以及所允许的更改。如果在测试前应用了运行时更改，那么应该在测试日志中记录这些更改（这一点很重要），这样才能重新创建完全一样的测试环境，即重复构建时也要重新应用运行时更改。
可以正式或非正式（或者两者结合）的形式应用访问控制。如果您的项目使用正式访问控制，则通常通过可以保护策略规则的软件或硬件设备实现。如果您的项目不需要太过正式，那么可能会非正式的（即根据公认的实践经验）应用部分或全部访问控制。很明显，非正式控制很容易遭到破坏，有时甚至无意中就破坏了，这种环境需要安装审计软件，用于根据期望的设置检查环境配置，并在出现不可接受的变化时发出警告。
受控测试环境的例子有：性能测试环境、压力测试环境、用户验收测试环境等。在受控测试环境中，开发人员通常可以查看测试结果、调查问题或错误，但是不允许管理或修改环境配置或者参与测试执行过程。
文章来源于领测软件测试网 https://www.ltesting.net/
