我说一下我的看法吧。关于第一点。把自动化测试放到单独的 slave 上运行的情况，一般是 master 机运行的东西太多了带不起来，或者 master 机不具备自动化测试所需要的环境。例如如果你的测试是 UI 自动化，那么一半由 Linux 组成的 master 机就跑不了，或者你们用的 jdk 不一样等等原因。我不清楚你们是哪个情况哈，如果都不是那我觉得那是没什么必要单独弄一台机器。
关于第二点呢。有些情况来说，确实要 qa 来提供搭建自动化测试环境脚本的。因为很多情况下 OP 或 PMO 只能给你一个原始的环境。他是不知道你的自动化测试框架到底依赖了什么东西。测试框架与开发框架本就是可以互相独立的。例如以前我们开发用 PHP 开发，我用 java 语言照样测试。OP 和 PMO 最多也就是帮你搞定产品的部署，让他们去部署自动化测试环境确实强人所难。毕竟他们平时的工作已经很忙了。当然了如果你们的 op 和 pmo 十分强大或者很闲那就另说了。创业公司可能都没有这两个职位，都是开发和测试兼职做了。例如我的自动化测试环境都是我自己做 docker 的镜像，下载开发代码，打包，部署。安装 jdk，maven 什么的都是基本的
至于第三点，我也不太理解为啥不用 jekins 发邮件和看报告。这些功能 jekins 都有，是你们公司不会用？还是你们公司有别的特别的考虑我就不知道了。

#1 楼 @ycwdaaaa 第一点我也是理解 master 带不动，用 slavey 去跑任务，关键是现在 slave 节点也不去跑，而是 slave 节点再发程序到另外一台目标机上运行测试，完全脱离了 jenkins 的监控范围，就是因为此种方式，导致 jenkins 解析不了测试报告，因为测试报告不在 jenkins 的 workspace 中生成
至于第二点，倒真是因为后期可能很多台机器要部署环境，配置工程师也说这样我没加一台机器就要重新部署一次环境，我想既然你都开始用虚拟机来扩容增加节点，为什么不做一个带有基础环境的虚拟机镜像，这也算是一劳永逸的事情，为什么要运行脚本的时候我要提供基础环境，而且在 windows 中，不是所有依赖都可以用绿色软件来解决的
第三点，配置工程师总是和我强调后期可能多个事业部都会用到这一套环境，其他所有部门都是这样做的，为什么你们测试部这么特殊，我是想什么我都用批处理干了，那我特么要 jenkins 有毛用，这不重复造轮子嘛

#2 楼 @anonymous 我觉得你们应该用 docker 或者虚拟机，隔离不同部门，甚至不同项目的运行环境。

一个环境多个部门共用以后绝对是噩梦。

曾经做过好几年配置管理的人来回答：
1：持续集成是一种理念，从最早的每日构建开始发展到持续集成，即尽早编译，尽早测试，尽早的发现和解决问题。
2：任何的持续集成工具，都只是一个框架，从很早的 cruisecontrol 是这样，IBM 的 buildforge 也是一样，就是和版本管理工具做集成，发现变更，触发构建脚本，触发后续操作（通知，部署，测试等），Jenkins 也是一种框架，至于里面的构建环境的准备，部署的过程，触发通知等操作都需要自己用 Plugin 或写脚本来实现。

另外，你说的几个：
1：构建环境和发布环境肯定是要独占的，因为你要确保你的构建环境是正确的环境。多系统共用更是噩梦。
2：环境肯定要干净，要不然出问题都不知道哪里出的， 另外， 这活只要干一次即可。
3：Jenkins 是一个框架，如果没有发邮件通知的功能，自己可以定制，另外，测试报告本来就不应该在 Jenkins 中展示。

我觉得还不如你自己搞一套测试自己的就好了。

本人专职持续集成测试，
1.不在 slave 上跑 case 的情况也常见。但不代表脱离 jenkins 控制范围。我们这儿是在 slave 上启动测试，从机器 A 开始执行测试脚本，对机器 B 上的待测软件做测试。一样可以把测试结果收回 slave 上。你没收，自然没有结果。
2.也很正常，还是那句话，都能做，只是在于你有没有做。我们这里，上一点上提到的机器 A，在旧时代是自己装好软件的机器，现在云时代是自己装好之后再复制出来 n 台的虚拟机。
机器 B 的待测软件环境，旧时代是用脚本在每次测试时重装整个系统，云时代是每次测试时重新建栈。
3.邮件也是能发的，但如果你指望配置一下就完事，连个插件都不用装，那真是做梦。最基本的原理是让你的 slave 等着真正的测试机跑完测试结果并发回 slave 机。这一点都想不到或不愿意去想，你还搞什么持续集成？