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

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

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

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

  • 测试开发之路----概要 at October 16, 2019

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

  • 测试开发之路----概要 at October 15, 2019

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

  • 我明白了, 你想做个统一的页面把所有自动化测试类型集成进去。 在这个上面操作。 这个可以啊,纯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的失败。 都是因为不稳定。