当然是测试管，运维主要是辅助，提供一些基础服务，做一些支持。 很多地方是运维管理测试环境，那是因为测试水平太次，想管也管不了。

恩恩，以后有机会欢迎来探讨

还好哈哈，大家多跟我说说话就热闹多了

坚持坚持~~ 再坚持~~

谢谢~~ 总算有点人气儿了~~哈哈

是有点孤独~ 不过好在工作上用的到， 坚持的下去。 也算给自己的工作留下点足迹吧。

差不多是这种感觉

写 shell 就好了。 或者写 python 都行。 参数化构建后你在 Jenkins 里可以用 $ 符号引用了。 下面设置构建任务的时候，弄一个构建前的 shell 脚本。 把参数写进去就行了

楼主在数据采集这边做的不错，也是费了不少心思了。这应该是一个多分类的模型场景吧。 我看楼主也是有意识的统计 TP,TN,FP,FN。 只是分类模型不能只看准确率 (accuracy) 的, 应该算出测试集的 AUC， 列出混淆矩阵。 算出精准率 (precision),召回 (recall) 和 F1 Score。 这样的评估报告才是比较权威一点的。建议楼主看看我写的一篇帖子：https://testerhome.com/topics/11153

都可以~

我写简历也没啥技巧。 就是把自己做过事，用过的技术详细的往上面堆。

特征工程总的来说是从原始数据中提取出对于机器学习算法有效的特征的步骤。 这是建立在熟悉业务和统计的角度上展开的，有很多时候原始表中的数据不能够直接被机器学习算法使用。 举例我们想要预测购买行为， 那么当前日期就是一个很重要的字段 (碰上双十一那一天购买量会暴增)，但是这个时间字段中的年份可能我并不想要，因为不论是哪一年都有双十一这一天。如果把时间这个字段整个不作处理就作为特征交给算法的话，显示是不合适的。 所以我们要在特征工程里对时间字段拆分，把年份去掉，提取出月份，小时，秒作为组合特征并离散化处理，我们可能只需要月份，可能需要月份和小时的组合特征，也可能要月份，小时以及分钟，秒做精确的组合特征。 离散化处理后的每一个特征只有两个值：0 或者 1. 表明是否命中这个特征。我们的公式是 y =wx + b。所有的特征必须是数字化，可计算的。时间类型显然不能做数字计算，所以离散化也有一个作用是把数据变成可计算状态。 特征工程就是从原始字段中根据业务提取出对模型有效的特征出来 不知道这么解释可以么？

还是咽喉肿痛 我不适合出去 high

欢迎欢迎~~

加油

趁着还有激情的时候逼自己一把。

其实也没那么轻描淡写，前期封装这套体系的时候也是费了不少功夫的。前期打好基础了后面才能这么逍遥

恩，那也可以，只是第一次 commit 就好了。 以后根据这个镜像写 dockefile 就好了

挺好的，够用就行，其他的服务不用都追求极致。 根据你们的需求来就行。 swarm 我当初只是在调研方案的时候搞过一个单节点的出来，了解的不深，不知道加一些容灾，持久化，7 层路由等需求是不是特别麻烦。k8s 是自带就有这些方案的。 不过你们测试环境体量没那么大的话也没必要搞这些。够用就好。就是尽量别 commit， 能做 dockerfile 还是用 dockerfile 比较好。以防以后环境变化的时候会很麻烦

恩，可能你现在还没有感受到 docker 的好处，这也挺正常的。刚开始接触 docker 的人多多少少都会有这个想法的。 你可以想象一下， 现在你们只有 2 套测试环境，环境也不复杂，没有多少服务，所以用 jenkins+shell 是没问题的。 如果你的环境数量扩大 10 倍，20 倍，30 倍，甚至 100 倍的话，纯虚拟机 +shell 还管不管的过来呢？模块更新的时候， 环境依赖变更的时候，服务挂掉的时候， 甚至是环境迁移的时候 (由于某种原因该服务器下线或者迁移到其他机房，这期间难道环境就这么不可用不管了么？) 还有所有这些环境的配置管理和服务发现怎么办？运维成本会变成一个噩梦，有多少人都会累的像条狗。所以这时候 docker+ 容器编排框架就体现出了无穷的优势，只要有镜像，可以迅速更新所有的环境，增容扩容也很简单，同时监控，容灾，持久化等等都做的好好的。 以你现在测试环境的规模确实是很难感受到 docker 的好处的，在这种体量下用 docker 还是虚拟机都无所谓，区别不大。

我现在用 docker+k8s 管理着一个容器集群，高峰期七八十套环境共存，加上测试服务，监控，集群管理，测试执行机器也在这里面跑着。 而运维的人只有我一个，而且我还是带搭不惜理的管着 (我平时有测试任务和开发任务)。 这时候就体现出了 docker 的巨大优势和其强大的生态圈，k8s 的自动化运维做的很强，所以我才可以这么悠闲的管着这么多环境。

我觉得你看看我这篇帖子吧：https://testerhome.com/topics/10809

恩，是的。 devops 的流行就是因为研发团队与运维团队中间那巨大的无形的墙。devops 致力于摧毁这堵墙。 同样的测试团队与运维和开发团队也有无形的强。 一定要学会自己开发和运维。

没错， 书中还有很出名的一句话就是测试开发的最主要任务就是能让别人更容易的测试。 这本书好像是 09 年出版的把我忘了。 是 google 早就玩的炉火纯青的模式。但是现在这么多年过去了，google 内部一定已经改变了很多，这就不是咱么知道的了

写的挺好的，关于上面图里说的应该是对测试开发工程师的定义。我个人觉得对于这个职位的定义可以更广泛一点。诚如楼主所说，开发一个 Jmeter 应该算是开发的活，而使用它的人是测试。 但在工作中开发人员在业务需求上就已经是忙的不可开交了。而我们却急需某些工具来帮助我们更好的测试, 这时候是不能等他们来做的，而且很多时候他们也做不好，因为他们不理解我们最急切的需求。 所以测试开发是可以更偏向开发和架构一点。而且 testops 的概念现在已经被提出来了，测试人员去做一些运维和开发的事情，我觉得这将是未来的发展趋势。

先看看《google 软件测试之道》先正正三观