搞技术便于跳槽时更好适应新工作，搞业务有可能换家公司从头积累。。。。人都是趋利的

匿名的人是不是 @ 不到他的？

#18 楼 @monkey 你的微信影响好多人哦~开阔了好多人的眼界，谢谢你哦~

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

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

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

#18 楼 @sordar 同意观点

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

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

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

@dongdong test

#20 楼 @anonymous 小白看了这些烂书，会被带坏。很多小白按书里的跑不通，你麻痹，书里就写错了。

其实在开发看来，21 天精通都是 shi，在测试还是小白的时候，觉得这些书也还可以，你稍微精通了点，就喜欢喷测试书，有意思吗，不爱看就不看

如果有疑问请向你的工作组长反馈，

我曾经也呆过一个创业公司，产品经理开会说，我们应该做一做安全性测试
然后被 boss 打回说，先把功能测好吧

我还碰到过一个设计师，每天花的最多的时间就是告诉你，我这个设计师对的，因为我觉得用户应该这样这样这样
你们不懂设计，不要瞎 bb，你们说服不了我的

其实每个人都有脾气，就看你怎么运用，加上每个人的性格不同，处理事情的方式也不一样

如果我是 LZ，我肯定是不能忍了

@dongdong 测试

测试开发是用来给测试部门刷成绩的，手工测试同学是用来扛活的，成绩刷到了，跟手工测试同学毛关系也没有，做做测试开发挺好的，至少还能有那么一丢丢的尊重

结果如何？

test @dongdong

#11 楼 @lihuazhang
代码在 github 上，这个怎么理解，有链接吗？

软件测试本来就是一个：测试基础 + 开发基础 + 业务和系统架构的 一个混合体。

测试的门槛不高，很多人都只是有点测试的基础。

卖书吗，总归想要大卖，所以面对的层次不能太高。如果讲的太深，谁买啊。

所以 21 天精通 xx 这类的书才会卖的好。

单纯从读者的角度讲，按需选择才是正确的。

#14 楼 @yangchengtest 说出了真理

#10 楼 @nickli 只负责骗钱，~

大话 1 的定位本来就不是技术吧，这有什么好黑的

#3 楼 @anonymous 大话移动测试，根本算不上什么技术书，跟技术挨不上边，最多算是作者茶语饭后跟别人吐槽吹牛逼的记录，没任何实际意义

所以买测试书不如上网看文档。

这位哥，你觉得你真的可以匿名么。。。。。。