为啥那么多环境要共享一个域名。。。。这么奇葩的机制怎么这么像我再 58 到家那会。。。。

我一般就是开怼~~

还有对应的 service 也都创建好了么？

你安装了 ingress-controller 了么？

建议看看我之前写的文章，就知道该学什么了。 https://testerhome.com/topics/17092

某阿里 90 后 P9：啊，我是没那个什么大局观了， 我也就能写一写 etcd 这种世界级的底层组件，解决解决全世界程序员头疼的服务发现负载均衡等务实的问题。 那什么行业大局观的，行业人员职业发展的啥子我是没关心过了。 看来我还是太低端了

1. 恩是的， 每个 node 就是一个物理机， 我们公司目前都是使用物理机搭建 k8s 集群
2. 是的，一个节点可以启动多套环境。 k8s 中有 namespce，每个环境用 namespace 隔离，对外使用 ingress 提供不同的域名访问机制
3. Pod 中有部署多个容器也有只部署一个容器的，看业务特性吧。 以前的时候我们是使用 sidecar 模式在一个 pod 里部署两个服务 ，一个主服务，一个 filebeat 容器收集日志。

尽量不要用软链， 一些容器编排系统不支持， 比如 k8s。

最好把相关的日志和当前 kube-system 下的 pod 的状态贴一下

等 dns 启动起来应该就好了。你先看看 dns 出了什么问题

多往底层做做，多往大项目中走走。 你就会发现，有些时候用什么语言，不是根据自己的喜好了。 所以我才说选择什么语言，尽量少考虑语法特性，而是根据自己所从事的领域的生态才做决定。

其实我建议大家选择一门语言的时候，主要从生态上抉择，而不是语法上。

其实每种自动化手段和实现方式都有它的发挥空间， 有些时候 UI 自动化效果不好可能只是因为某些场景是不适合大规模铺开 UI 自动化或者是实现的手段不正确。 但是不能假设所有的场景都是不适合铺开 UI 自动化的。 有些地方的 UI 自动化效果是很好的，也能节省非常大的人力成本。

按这情况看来， 所有人都支持你推广新框架， 那还犹豫什么 ~直接搞起了

这个主要看你现在所处的情况。我假设你现在的框架是比 RF 好很多的。那么你主要需要面对以下 4 点。

• 第一看你们已有的根据 RF 做的自动化已经积累了多大的规模了， 如果规模小，迁移成本小，那就还好说。 如果规模大就很难推，除非新的框架比旧的框架有很明显的颠覆式的优势，但即便这样也是要给他们专门排期去迁移，所以就很麻烦。 很多地方的技术陈旧，代码烂不是工程师水平低，而是历史原因了，不能随便动。
• 第二看人，之前做 RF 二次开发的那个人还在不在这里， 或者团队里还有没有其他技术骨干 (可以影响 boss 的想法的)，你的这个推广会不会撬动了他们的利益和地位，不是所有人都那么豁达的。
• 第三看老大是不是挺你， 你是否能说服老大力排众议，甚至不顾其他人的反对和不配合强行推下去。
• 第四看你能不能用新框架在一个业务线上做出明显比之前的框架好很多的成绩。一开始就全面推广是不大靠谱的， 一般都是先找个业务线试点， 这个就看你自己的功力了，能否在这个业务线上带着他们做出明显比之前好的成绩来。 这中间你可能面对其他人技术能力差，不会写代码，不配合，个人情绪等等， 当然也可能给你分一个特别给力的 team。 如果这阶段做不好，除非你是 boss 的小舅子。。否则基本就凉了。

以上是在你的框架比 RF 强很多的情况下你需要面对的。 当然了如果要我说，从长远来看写代码做自动化的效率肯定比 RF 强很多， 但从你的描述看，你们团队应该有不少人不会写代码吧。 所以之前才用 RF 来做就是为了迁就没有代码能力的同学。 那么问题就来了，在你们这个团队的人员水平下，你的框架还真不敢说就比 RF 更适合。 毕竟 RF 做关键字驱动已经很长时间了， 而且如果你们的业务就比较小，case 量较少，那用 RF 还是用新框架也无所谓的。 大炮威力再强再好，可是如果人家只想打个蚊子呢？

综上所述，其实我很少去硬推什么东西，硬推一个东西的成本和风险都太大了，收益也不一定高。如果团队已经有积累了，只要没什么大问题就让他们先用着。 主要精力还是留着去优化和开荒比较好，尽量慎重做颠覆性的决策。 当然你可以把新框架用在一个还没有自动化的业务线上，这样阻力会很小，他人的抵触情绪也比较低，也容易成功， 把它做成一个标杆项目，那么不用你推进，自然有人会来找你。

哎， 我发现咱们这里的人太容易走极端，钻牛角尖。 没有人说过做自动化的人就不去点点点了， 也没有人说过点点点的人就不做自动化了。 这就好比行军打仗中的游骑兵，降的了烈马，挽的了大弓，还身背弯刀随时准备砍人，本来就是要求多种技能于一身的职业。 你不能一竿子打死说别人写代码的没有测试思维，设计不出好用例。 也不能一竿子打死做业务测试的人就一行代码都不会写只能点点点，这种想法是在耍流氓。

发现更多的 bug 不是正道， 保证产品的质量才是正道，发现更多的 bug 是保证产品质量的一个重要手段， 但不是唯一的手段。 而且除了更多的发现 bug， 还要更快的发现 bug，因为测试时间永远是有限的，研发修 bug 的时间也是有限的。 况且有些测试类型，还真只能靠自动化， 比如兼容性测试，稳定性测试。

所以楼主还是少些抱怨， 拥抱一下现在的行业变化吧。 时代已经变了， 已经很少有人只点点点或者只写自动化了。

大家收一下， 别太发散了。 楼主喷的不是数据驱动， 而是做的不好的数据驱动和关键字驱动。 这点我也是赞成的。 就像研发有句话叫过度设计， 认为过度设计的东西是不好的。 同样的，自动化测试如果过度设计，把数据驱动进行过度的设计反而是不好的。 其实数据驱动这么小的一个东西没必要单拉出来大书特书，大多数时候就用 java 中 testng 的 dataprovider 这种就够了。 还是把主要的设计精力放在怎么封装业务逻辑，能够更稳定的支撑大规模的自动化 case 上吧。

不错不错， 我这边也是这样做的。 同时还结合普罗米修斯和 grafana 把监控的仪表盘也弄上去了

楼主还是放宽心一点， 少一点抱怨。 因为这样其实对自己没什么好处，也改变不了现状， 外物无法改变，起码你自己做成不看学历看能力的人就好了。 而且如果你的能力不变， 只是学历变成了 211 学历，就能把工资上涨 12-15k 这个假设是不太靠谱的。。。 学历还没能把差距拉成这样。。。。 工作的越是久， 学历的因素会越低的。 当然如果你在事业单位就另说了。

额。。这还没到年末呢， 怎么就开始总结了