工具没有过时一说,只是看用这些工具能不能达到你的目的
你可以换位思考一下,业务量不变的情况,技术团队要 dao 人,你会 dao 哪个岗位
再补充一句,到裁员动 dao 的时候,在研发团队,第一个 dao 的就是测试岗
想做得好,开发会的,你也要会,开发不会的,你也得会,然后上限又比开发低
CTO 看的是对整个研发流程的影响,CEO 看的是对业务的影响,两者看的角度都不一样。如果你做的东西,对业务没大多影响,不被认可是不出奇的。
有机会转必须得转,等到以后想转都没机会了
不明白为啥要转回做测开
因为经历过这些场景。。。。不知道大厂怎样,反正在小公司,不能缩短新功能的测试时间,在上层看来,都不算有什么收益。
不懂行的领导,就会觉得,自动化应该是要提升效率的,需要减少版本迭代的测试时间,这样看起来才是有收益
有些人预研就是写个 demo,不深入研究,怎么会知道痛点
叫你们领导去用下
真心不建议做测试,我带的实习生,我都是建议找工作走后端。没经济压力的家庭优先考研,毕竟学历还是有用的。
像这种设备管理平台,我唯一想知道的就是怎么解决过充的问题。以前搞 UI 自动化的时候,连着真机跑,没多久手机电池就废了。
先确认真实的测试场景,是测拿视频地址的接口,还是要测流媒体服务器的表现,还是测 cdn。
先定义直播质量有哪些指标,再考虑怎么测,用哪些工具
代码改动会对旧逻辑产生影响,这难道不是有问题吗
我设计的唯一原则,用例之间不能用依赖。测试数据明明可以通过前置步骤去生成,为什么要这样互相依赖?
大而杂,全是熟悉就不好打了,还得是有专精,毕竟互联网,年龄摆在那
个人见解,最好是和服务端是同一个技术栈。至于现在那么多所谓的测开用 python,那是因为他们只会用 python 而已。
你们没有测试老大的吗,这东西不就是靠自己争取的
有没办法驱动国产浏览器?
菜的项目经理就是做这些,完全没有什么核心能力,是随时可以被替代的。
说说我这边的做法。国内项目研发都是业务为先,一般情况下,到了快要发布的时间节点(半天前),如果还有遗留问题,就会跟项目经理、业务方同步现在的情况。哪些问题需要一定修复,修的话有没延期风险,不修的话会有什么风险,大家对齐了之后,再决定发不发布。
如果是为了提高个人能力,肯定是自己写代码好的。
1、app 抓不到,有可能是客户端做了证书校验,问下相关开发
2、小程序没玩过,不清楚