BEA WebLogic Platform應用程序通常作為復雜生產系統的一部分進行部署。當交付以WebLogic Platform為基礎的應用程序時，對應用程序進行正式測試需要恰當控制的測試條件，而提供這些條件本身是一項復雜的任務。如果沒有準備好恰當的環境并成功地進行應用程序部署，無法執行正式測試，從而影響交付，而交付時間安排上一點點的松懈都將導致整個項目的推遲。
構建測試環境流程的自動化將有助于防止這種延誤的發生。在本文中，我將展示對一個測試環境進行自動部署的工作如何重用于其他測試環境。
“發布我吧”
“發布我吧，讓我去，
我的 bug已經不再是重要的了……”
這些話不是我寫的，而是在Web上看到的，但它特別切合我們的主題。您可以在Web上查看完整版本，更多內容請參見 Filks站點。
那么，您的開發團隊已經構建了應用程序套件，成功將它部署在WebLogic域中，并通過自動測試腳本對應用程序進行了徹底的測試。開發人員可能已經閱讀并實現了Michael Meiner在 使用WLST和BEA Workshop在集群環境中開發Web應用程序（Dev2Dev，2006） 一文中的建議，在集群中測試了套件（使用Web服務作為集群的前端），見到它在集群中運行，并證明了故障轉移能正常工作。
團隊準備好了發行說明和所有的歸檔文件。那么現在已經萬事具備，只等用戶驗收測試了，祈禱用戶會喜歡它吧，您可以為這次成功交付舉杯慶祝了。
醒醒吧！現實是生產套件的萬里長征才剛剛邁出了第一步。成功的交付需要跨越無數的障礙，需要開發人員的多次嘗試。于是測試開始了，將使用各種測試器或測試工具，將涉及套件和開發人員無權訪問的機器，這些測試將找到錯誤，至少有幾個錯誤是需要修復的，整個過程需要重復進行多次。
獲得推進
測試通常在一組明確指定的環境中進行。現在討論這些受控環境包括哪些，以及將一個應用程序從一個測試環境推進到下一個測試環境需要哪些條件。
受控環境
我使用術語“受控環境”表示訪問受到某個策略限制的環境。生產環境是一個受控環境，分段測試環境也是一個受控環境。這兩個環境的訪問控制測試類似，但分段測試環境的限制性訪問策略的可能更少一些。簡單地說，“受控測試環境”是一個用來測試應用程序（套件）的、受控制的（即訪問受策略限制）環境。
在受控環境下進行測試的目的是獲得可重復的測試結果：在相同的環境下對相同的軟件進行測試，應該獲得相同的結果。“相同的條件”要求準備的測試環境是一致的并且是可重復的。自動環境構建應該確保環境初位于可重復的環境中，但還需要更多的條件以確保測試發生在可重復環境下。應該進行訪問控制，以限制環境構建后能夠更改該環境的人以及所允許的更改。如果在測試前應用了運行時更改，那么應該在測試日志中記錄這些更改（這一點很重要），這樣才能重新創建完全一樣的測試環境，即重復構建時也要重新應用運行時更改。
可以正式或非正式（或者兩者結合）的形式應用訪問控制。如果您的項目使用正式訪問控制，則通常通過可以保護策略規則的軟件或硬件設備實現。如果您的項目不需要太過正式，那么可能會非正式的（即根據公認的實踐經驗）應用部分或全部訪問控制。很明顯，非正式控制很容易遭到破壞，有時甚至無意中破壞了，這種環境需要安裝審計軟件，用于根據期望的設置檢查環境配置，并在出現不可接受的變化時發出警告。
受控測試環境的例子有：性能測試環境、壓力測試環境、用戶驗收測試環境等。在受控測試環境中，開發人員通常可以查看測試結果、調查問題或錯誤，但是不允許管理或修改環境配置或者參與測試執行過程。
