就坚持做自己最擅长的事儿吧， 别想太多了。 就算有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的失败。 都是因为不稳定。