运维和测试，难兄难弟，相煎何太急。

同类工具多如牛毛。不过我欣赏这种学习精神，虽然做出来的东西没什么用，但继续努力下去总能做得更好。

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

只有自动化测试、自动化运维，没听说过有自动化产品经理、自动化开发、自动化项目经理、自动化运营、自动化风控的。
这一点说明测试领域和运维领域的前人水准不够，胡乱起名字。你看开发，哪个开发是自己写二进制的，不都是编译器帮他 “自动化开发” 的吗？开发的前人聪明的地方在于，把人做的那部分编码工作定义为 “开发"，把机器自动化做的开发起了个名字叫 “编译”。

同理，测试领域内，首先应该把定义改一下，只有人做的测试才叫测试，机器做的可以叫 “检查” 或者 “校验”。压根就没有什么鬼的全自动化，顶多做一个自动化校验，那根本不叫测试。自动化校验只是测试的一部分，就像编译是开发的一部分一样。人做的那部分才是测试。

所以我极度反感自动化测试一词，综上，我是来支持半自动化测试的，并且提出，我们应该用新名词来定义测试。