其实我没明白， 自动化上不去，他们是怎么有胆子重构的

不是调用其他 case， 就是你应该封装一个业务逻辑层。 case 是去调用业务逻辑层的东西的。 比如所有 case 都要登录，那就专门有个地方是写登录的逻辑的。 比如有很多的 case 在测试的时候依赖一些数据， 比如要测试查询订单那就要先有这个订单存在。 那么就可以专门有一个地方是封装的下单的逻辑。 理论上，case 要是精简的。 大部分的逻辑要封装到业务层里去。

第一个楼主纠结的应该不是独立性， 而是纠结一个 case 依赖的太多其他业务逻辑到底是不是好的。 其实你都已经是 UI 自动化了， 测试的就是系统集成， 这时候为啥还要避免这个情况呢。 case 尽量避免依赖这是单元测试的思路~ 所以才有各种 mock 技术么。

第二个就是测试数据到底是应该预先创建好的，还是实时调用系统功能来创建的。 看你们的情况了， 个人建议是团队水平不错就实时调用系统功能创建 (我们团队目前是这么做的)，水平不好的就预先创建吧。

PS： 建议楼主现阶段尽量少看这些纯理论书，没啥好处。

其实现在 kubeadmin 已经比我写文章那会好用多了~~~ 我写的时候还是阿尔法版本， 现在应该已经正式 release 了。 用那玩意装 k8s 还是挺简单的

没用过 minikube。。。。为啥不直接正式安装。 用这个玩具呢。。。

简单不代表就好。。。。。如果真的好， 不会基本所有 liunx 发行版本都用 systemd 作为默认选项了

现在还有人用这东西么？ 不是都用 systemd 了么

当你用坚持 这两个字来形容你的工作的时候。 就是你快坚持不住的时候了。

为啥那么多环境要共享一个域名。。。。这么奇葩的机制怎么这么像我再 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 的状态贴一下