依然在招哈

双方都没必要剑拔弩张的。到头来双方都是吃亏的

pytest 有数据驱动模块的。 不用写 for 循环。

我没测试过哈，只是我们运维推荐我用的

多谢提醒

听说微软在做 windows 的 docker。不过我没用过哈

但是集群化以后，就没办法固定 ip 了。只能端口映射。我们转集群的时候大家抱怨最多的就是没办法 ssh 进去看 log 了。要多几个步骤才能进入到容器里面

赞一个，补充一下如果想用 vnc 连接，需要自己设置密码，要改一下镜像。

鼓励楼主还有哪些 docker 方面的实践，都分享出来。 另外如果楼主是单点 docker 的话。 建议删除 docker0. 新建 br0 虚拟网桥然后把 docker 和宿主机都连到 br0 上来。然后用 none 模式启动，pipework 设置静态 ip。 这样就不用做宿主机:容器 端口映射了。 外部可直接通过 ip 访问

看我上面的回答哈

主要是重构方面的。当初我的同事用惯了 eclipse 了。 eclipse 的重构功能不能覆盖到字符串搜索。所以元素变量名改变的时候比较麻烦。不像 idea 中可以全局搜索字符串来帮你进行重构。我也不好强迫他们改用 idea。

case 之间不要做成相互依赖的。 如果一定要相互依赖，也要确保相互依赖的 case 在一台机器上有序的运行

是的，我们目前还是处于 POC(Proof of Concept) 阶段。对于搭建私有云的客户还是需要到场地内建模并做各种测试以证明符合客户需求。以后要尝试 POT(Proof of Technology)。直接从产品的各个维度提供业界认可的权威报告。这个被老大列在了今年的计划当中。

可怜我司就是做平台的。。。。所以我还是得硬着头皮去造数~~~ 最近跟某行合作。他们直接对测试用例，性能测试和测试数据提出了要求~。ToB 的业务想卖出去就是费事~~，我们还得派人去场地内在他们的环境上跑一遍性能测试以证明我们的产品能够支持他们的需求。

主要是维护起来是个噩梦。本来业务变化就很大，不仅要改 case 还得改框架，我觉得维护成本太高。 为了能让不会写代码的人使用。要封装的东西太多，例如如何让不懂代码的人调试和 debug？光这一项就够让我头疼了。又例如我还被要求过提供一个酷炫的 UI。总之各种坑。

恩？ 没更新头像的不是不能发帖了么？ bug 了？

python 的 json 模块不能搞这些事么？

没有。。。。测试类型不一样。。。我这边是做数据测试。所以才用这玩意。你不做这种测试就随便看看了解一下就行了。。。

额，最近在家比较闲

恩，如果单从以后你面试的角度来看的话。 其实接触服务端的东西反而会给你加分的。创业公司人手少，本就不会区分的那么严格。 一线大厂也都喜欢有能力 own 一整个模块的。 所以我觉得如果为了以后的发展来考虑的话，反而应该多接触接触后端的东西。

额，这个话题不用匿名的。有疑问挺好的一事儿。做服务端也挺好的，可以丰富你的经历。 而且现在很多公司的测试不分客户端服务端的。 就是一个人全做。多学点没啥坏处的。

额，为什么你一定认为测试开发是脱离了业务的呢~~~ 而且我也不太明白为什么你这么认定技术与业务是对立的~~~可能你没有碰到靠谱的技术人吧。我觉得其实不管什么职位，技术都是用来服务业务的。要求技术好，是因为技术越好越能服务业务。 就像我们招开发要招技术好的，招运维要招技术好的。为什么到了测试就一定得招技术不好的？难道测试已经不属于技术部门了么？技术好的人有能力让产品质量更好，有能力把技术转换成生产力提高效率。所以我们为什么要这么抵触技术 这么个东西呢？有了技术这么个东西，测试人员可以一键部署一整套产品环境，可以无人值守的维护整个团队几十上百的测试环境。 有了技术这么个东西，持续集成跑起来，可以提前发现 N 多个 bug。有了技术这个东西，devops 走起来，一键出包部署。有了技术这个东西，自动化测试走起来，原来要执行几天的测试现在可能只要几小时。所以我们不要排斥技术这个东西。而是要排斥不能服务于业务的技术。 如果要问我再工作中用到了多少技术， 我可以这么说，我要是变成一个不懂技术的人，我现在立马失业。 因为我现在 90% 以上的任务是没有技术做不了的。

恩恩，有用就好， 我也是最近在学习这些。所以记录一下学习的过程

谢谢支持哈~