35 做技术是累,不过累至少工作踏实一些吧,像我的领导就会所谓的 “管理”,技术一点不懂,说被干就被干,一点脾气没有。
自己平时多少学点就觉得有些累,看见大佬的学习记录那根本就是相当累,而且脱产的话主要心累。
我之前看 MIT 的微积分课也没坚持到最后,看了 7、8 节吧,每节都特别费劲,然后还得来回来去看,后面实在看不懂就放弃了,改学《托马斯》的微积分,发现之前学不好的原因是没题练,学了 1/3 写了好几个本子,之后简单看了下线代就看上吴恩达的机器学习课了,就会照着操作,深入也没整明白。机器学习从入门到放弃。
刚开始搞中等了,感觉直接难出一个等阶,大佬是怎么练算法的?也是刷题还是工作中就练了
大佬是就看见这一句回复的吗?
搜 “子方法” 和 “子程序” 都没搜索到对应的内容,但我实践之后发现这种写法的作用:一个方法,写在另一个方法里面,跟自己单写是一样。都是可以被别的地方调用到自己这个方法,这种写法的好处是:一、编写方便,直接写到其他调用自己的方法里面直接调用就好;二、方便调用父方法的参数。大概这些。
能不能搞个根据规则自动筛选的脚本,带口字的,全角数字的,信誉啥诚信啥的,筛选出来管理员人工确认后删除
社区需要大佬这种警醒式的文章,给心里有迷惑的同行们一些深刻见底的洞见。
啥时候先把之前的 Q 币给补上就行了
感觉楼主的问题在于拿开发的本事去测试里熬,另外在说你领导对你的各种暴击,我看你的描述感觉你的工作能力应该还是挺强的,至于 “做事情有自己的方法论,但还未落地” 这种,建议当屁看,但是如果能自己战胜挑战一般都会获得成长。
不过要说我这种干过几年的测试有什么建议的话,还是让自己开心最重要,跟自己内心走。
写个脚本自动读下接口文档,我们是 swagger,我就做了个自动读取 swagger 的脚本然后写入 excel,这样只要自己手动录入接口参数就可以
哈哈,真的是槽神
都是实践出的真知。
可能每个人角度也不一样吧,话有点呛,帖子我也删了,老哥也祝好。
不错,要把 Q 币发一下就更好了 https://testerhome.com/topics/27029
恒总你懂的
感觉大哥完全没读题
“员工数量你们想按谷歌的开发测试比,员工质量你们能跟人比吗?”
很有道理
啥时候公布啊?或者用你们的解释权解释一下
今年:
1.年初疫情在家在办,每天晚上看一节微积分课程
2.看了四分之一的课程觉得理解度太低,改练题,买了《托马斯的微积分》开练
3.练了 3、4 个月,写完了几个练习本(当然间距比较大),当中也学了一些线性代数
5.6 月左右开始看吴恩达的机器学习课程,看了一个多月,有理解有不懂的,也不知道如何落地,机器学习方面的努力搁置……(感觉上办年的收获就是再看同事发的算法题感觉极其自信)
6.看了两三个月各学科有兴趣的书,解惑和增长知识
7.开始着手开搞接口自动化测试,搞完接口自动化之后发现自己对于接口测试的提升极大。
8.最近开搞 WEB 的 UI 自动化回归,今天开搞 app 的。
下一步:
搞测试平台,把 UI 和接口自动放上去,再看看怎么和 jenkins 接合一下部署个定期的脚本。
刚看了楼主的:“集成 Chrome 插件 可以让业务测试执行的时候自动生成业务自动化脚本”,我觉得我也可以搞一下
数据变动很正常,变动就得维护脚本,这不应该算问题,应该算在自动化之初就考虑的成本
如题:当在后台做相应操作前端会改变界面或数据
这种场景我觉得可以使用接口结合 UI 自动化的方式对功能进行测试。
分为三步:
首先,后台作为动作的发起方,先对后台进行测试:使用 WEB 自动化操作后台后,通过数据库对数据进行查询验证后台的操作是否成功
第二步是测试移动端前台:直接通过调用接口模拟后台操作,查看移动端前台页面或数据是否有改变
第三步是联合测试(纯模拟用户实际使用):使用 web 自动化操作后台,并使用移动端自动化来验证前台是否正常确响应
单回答这个问题的话,是用这种分层的形式进行测试。
然后讨论实际应用中可能遇到的问题是:
如何管理这种串联形式的用例?
每测一个点都要三步感觉会不会用到的数据有些复杂?那我们把用例要用到的数据先用替代方式表现出来:
1.A1 A2
2.B1 B2
3.A1 B2(第三步用到的数据和前两步有重合)
并且由于每三步实际只测试了一个功能点,所以可以将 A1 A2 B1 B2 列为一条用例数据。
测试脚本只需要对对应位置的数据进行存取即可。
看了一下报错,确实是点击不到,报的是 ElementClickInterceptedException,
加了一句
driver.execute_script("arguments[0].click();", loc)
就好了。
大佬你是怎么一下就发现是可以定位到但是点击不到的?