我应该是全社区最啰嗦的人。 https://testerhome.com/articles/21015

楼主，下次请讲师的时候最好先打听一圈吧。 你也真是不问世事。。。。。

自己先用起来吧， 等自己对这个东西熟悉了， 帮助研发做镜像，做部署方案。 让他们尝到甜头了就好推了

就坚持做自己最擅长的事儿吧， 别想太多了。 就算有 100 条比纯技术更好的路， 但是不适合自己也是枉然。

恩， 怎么说呢。 其实在职业发展的路上，大多数人大部分时间都是自学的，能有水平好的师傅肯认认真真教你的情况基本上很难遇到，尤其测试领域里就更难遇到了。 所以楼主觉得老大教不了自己的这个情况不用太纠结， 因为大家差不多都是这样的。 等你成长起来以后你会发现， 一般部门里老大要委以重任的人， 是要教老大应该做什么的人， 而不是老大教你该怎么做的人。

反而是一个有技术挑战的工作环境更能让一个人成长起来。 就像你说的学的东西不用在工作中的话， 你也不敢说熟练。 所以学以致用才是最重要的。多想想怎么在工作中进行创新来提高效率是很重要的。

还有就是关于学什么东西，该往哪个领域发展的问题。 自动化，容器化， 大数据等等等等都是方向，关键在于你能不能找到相关的工作岗位以及你能不能坚持下去。 你现在的情况是先不要纠结哪个方向最好， 而是抓住一个机会就走下去。 毕竟你现在还没有挑工作的能力， 现在只能是工作挑你。 任何一个领域你研究的深了，结果都不会差的。 还有就是其实后来你就慢慢知道了， 技术不仅仅是写代码， 甚至往后面发现 当你处理一个大型系统的时候，你大部分精力都不是在写代码上。你要学习的东西也早就超越了写代码的范畴。 比如学习各种中间件，分布式系统， 容器编排系统等等等等。 很多时候就是学这些东西学 1，2 个月。 然后上手写代码去做相关的事情就 1，2 周甚至几天就结束了。 比如我在 K8S 下做环境部署的时候， 在这之前学 k8s 学了 1 个多月，到写部署脚本的时候 3 天写完。 因为只有拥有能足够维护一整套 k8s 的能力的时候，你才能去真的写那几百行代码， 否则出了点什么问题你都解决不了。 所以平时可以不要只关注代码层面的东西， 不懂代码的人绝对不是技术人，但是技术绝对不仅仅是代码。 事实上代码写多了你就发现就那么回事了， 什么 UI，接口，单测，白盒黑盒的都没什么挑战了。

没事的，条条大路通罗马， 加油~~~

你直接点开我的个人主页看把。。。我好久没维护这个目录了

我明白了， 你想做个统一的页面把所有自动化测试类型集成进去。 在这个上面操作。 这个可以啊，纯 web 开发的领域了。 你们想怎么搞就能怎么搞了~

为什么你们非要把自动化测试弄出个平台来。。。。。。还要弄的像个产品一样。。。。

额，我不是写过么。 就是那个什么 UI 自动化军规和常用设计模式。 我们的 UI 自动化真的没别的花样了。 就是老老实实的写代码。 说有花样也就是 grid 是启动在 k8s 里的， 可以并发几百个浏览器进行测试。

TO B 的业务产品形态相对稳定， 节奏相对慢一些。 比较好积累自动化测试用例

我们主要是 web，我们大多数是因为环境不稳定。 因为我们的产品关系。 会起非常多的分布式任务， 这些分布式任务有 hive 的， 有 spark 的， 有 k8s 的。 环境依赖很重，这些分布式系统本身就有抖动， 比如 k8s 某个节点出现点问题， 可能就有一些 case 直接失败， hadoop 如果出现 IO 抖动， 可能任务就超时了， 训练某些模型的时候，需要从外网下载数据， 如果当时网络卡了一点， 可能也失败了。 当然还有一些 case 就是不稳定， 有些 UI 交互很恶心， 就是非常不稳定的。

基本上 UI 自动化稳定性超过 95% 的地方， 要么是用例太少， 要么就是把不稳定的直接删除了。 我们之前维护过几千多的 UI 自动化测试用例， 后来稳定性在 97%。 但是你要知道我们曾经删除了上千条不稳定的测试脚本。 想不删用例达到 95% 很那。 我现在的项目目前是 1700 条 UI 自动化测试用例。 这一次我们没有删除不稳定的 case，每一次跑少说也是几十个 case 的失败。 都是因为不稳定。

第四范式

其实路径有很多的，在不同的行业和领域下，需要学习的东西是不一样的。 当然了通用的能力都差不多， 比如需要学习 python 和 java，在语言的基础上写自动化测试 (UI,API) 和自己写点小工具和平台，还有 linux 基础技能这些都是作为测开需要的通用能力， 属于基本上在哪都用的上的。 但是接下来需要我们在某个领域上进行深耕，学习更底层的技能。 就像我之前说的 k8s，因为我是混容器圈的，这是我选择的领域，所以这个领域内的所有东西都要去学， 包括 docker，k8s 以及在他们之上构建的容器生态里的很多开源项目。为此我专门去学了 golang 语言，并用 k8s 的 client-go 自己编写 k8s 的 CRD，controller 以及编写针对 k8s 的混沌工程项目。 这些都是在容器这个领域内需要用的技能。 它跟通用技术不一样，它是服务端技术，并且是特定领域的服务端技术，虽然它跟通用技术不一样，这些技术被限定在了一个领域内才能发挥价值。 但是往往拥有比较深的领域技能才是通向高阶测开的门票。 所以选择一个领域比较重要， 我之前确实说要多学一学容器的东西，比如 k8s。 因为这是一个之后服务端的主流技术，到今天可以发现 k8s 的势头非常猛，各个厂商的容器化已经成了定势。 而且从最近开源出来的项目来看 k8s 已经侵入了 AI，大数据，分布式计算等领域， 所以我一直认为这是一个值得去拼的领域。 还有其他领域，比如大数据领域，AI 领域。 就看你个人如何选择了。 当然这些是从我的经历和角度去看的。 我没有移动端的经验，所以不知道移动端有什么领域值得去深入研究。 你要做一个选择， 选对行业，挑对公司， 努力是排在这两个之后的。

冗余啊~~~ 多实例设计就好了。 更新的时候在备上升级， 然后一切换。

恩~ 我理解楼主纠结的是如果要重复进入 125 分别进行操作 1 和 2，重复的工作会带来运行时间的延长等问题。 那是其实在自动化项目里， 可维护性 > 性能 。 适当的把 case 进行拆分是必要的， 不能把太多的逻辑放在一起。 性能问题可以交给分布式运行策略来提升

一般都是业务形态不一样导致的。 尤其 TO C 和 TO B 的发版周期差别巨大。 在 TO C 的业务上，隔几天发一个版本都是正常的。 但是在 TO B 领域动辄几个月甚至一年。 面对的用户群体不一样， 节奏就不一样。

是不是不在一个 frame 里？可以下载一个在浏览器上使用 xpath 搜寻控件的插件试试

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

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

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

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

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

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