8 楼，junit,testng 有几个能知道内部实现方式的？随便封装几个接口，就喜欢把自己的工作叫框架。现状就是这样。
东哥，你下的开源库，你还能改改的叫 jar，sdk 是你不会改的。。。😄

这个要具体看情况，也不能全叫工具包吧。像 junit，testng 这类比 spring 简单得多，那么它是工具包还是框架呢？

#2 楼 @anonymous 这个是匿名的头像，和 doctorq 的头像还是有点出入的。

#5 楼 @codeskyblue 匿名帖默认不显示名字。。。

有人叫你帅哥你是答应还是不答应呢？同理有人把你写的工具包叫框架，你的内心又是如何呢？

这个我也纠结了一段时间，最近一直在做技术，在业务上面疏忽了，技术上来了，业务成了短板。
实际上：是我看透了业务，都是一样，八九不离十，现在我看技术也是同样的感觉，八九不离十。

你是 D.Q？

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

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

#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 上，这个怎么理解，有链接吗？