首先要说明一点，由测试人员独占和负责配置的环境才是真正的测试环境，没有真正的测试环境，自动化测试也就无从谈起。只有让测试人员决定是否变更环境配置，是否部署新版本的软件包，才有可能使测试活动顺利进行，较少被意外活动干扰。从现实经验看，成功建立自动化测试体系的测试团队往往和开发人员处于平等的地位，并有能力完全负责测试环境的维护和软件包的部署，其它人员对测试环境的任何改动都是严格禁止的；而实施失败的测试团队则比较弱势，无法做到拥有真正的测试环境，这种情况下手工测试都会经常遇到干扰而暂停，自动化测试体系也就无从谈起了。

测试环境的管理与软件的集成过程相互关联，典型地包括以下活动：

• 同步测试环境与生产环境。当涉及到同一产品的多个研发团队时，保证测试活动开始前所有的软件包版本与生产环境一致。

• 构建一个或多个需要测试软件包。

• 部署测试包到集成测试环境。

• 验证测试包的有效性，包括是否有包缺失，是否有多余包，版本是否正确等。

• 验证依赖的第三方环境是否正常运行。

• 启动自动化测试用例集，可能需要多次迭代直到消除误报。

• 监控测试运行期间的环境状态，包括CPU使用率、内存占用率等。

这些活动是可以通过脚本流程化的，很可能一个团队正在编写或已经有了大量的与测试环境配置相关的脚本。如果将这些分散的脚本集中管理，既可以一键执行，又能够根据时间调度，对测试环境的管理就会更加灵活。另外这种集中管理和调度也使我们能够提供一致的环境状态报告，方便与相关人员分享。

Jekins和Hudson这一类CI工具是一种选择，但更偏向于驱动一个过程，而不是面向环境的，对分布在不同主机上的各类脚本进行管理也很不方便，因此需要使用者做更多适配工作。

TestMP自动化测试管理平台的测试环境管理模块定义了环境(Environment)，主机(Host)，任务(Task)，执行绪(Execution)，追踪(Trace)等元素，由用户建立其中联系。例如一个Environment可能包含多个Task，Task包含多个Execution，Execution映射到Host上的一个命令或脚本，执行过程中和之后可以获得Trace，最终生成测试环境的状态报告。由此可见TestMP的测试管理是围绕测试环境建立和驱动测试流程的，这也是它与CI工具的区别。