请不要直接甩链接,用户体验很差。至少把正文贴过来。
可以看看 airtest ,appium 好像也有类似的插件。
改到旧逻辑的话,那通过代码 diff、和开发沟通等方式圈定影响范围,再针对性地去回归?一般改到旧逻辑,且改动较大,那就可以当做新功能完整测试了,这个时候原有的埋点也不一定能满足产品需要,需要产品更新下埋点需求。如果改动少,可以针对性回归。
这类问题用刚才我说的招也能快速发现最严重的问题,但很难保障无遗漏。核心点还是要知道开发改了啥,这样才能事半功倍。当然有资源直接把 UI 自动化和埋点检测结合,进行自动化验证,是最好的。不过听你说快速迭代和经常改到旧逻辑,估计你自动化维护成本也不会低。
楼主的回答主要还是没体现技术含量。一般问这个问题其实是想通过这个例子了解你的技术水平,以及是否能说得清 bug 背后的原理、原因及解决方案。
如果沿着楼主这个例子,作为面试官期望听到:
1、为何会出现这个问题,是 mysql 某个版本的 bug 还是官方有明确说过会出现这个问题?官方给出的正确用法是什么?
2、开发的具体修复方式是怎样的,改了什么代码或者配置?这个改进方案会不会只是掩盖问题,而非解决问题?(比如 Integer 改为 Long ,延迟问题的发生)
3、后续怎么把这个变成规范或者流程,尽可能保障以后其他人、其他项目不会再踩同样的坑?
建议要了解下背后的原因,一般风险应该在新埋点,老埋点不应该有影响。
还有一个招,让产品在测试环境就建好后续线上要用的几个主要漏斗报表,产品验收时让产品也看看数据有没有明显问题(比如漏报或错报引起转化断层)。
文中只提到了 无法正常访问、ping 不通,然后就开始推断是 DNS 问题,有点片面了吧。建议你把具体报错附上来?
要让 ping 失败方法很多的,网页打开也一样,不一定就是 DNS 的问题。端口不通、证书不通过等都有可能,都是 “不正常”
没看懂正文里提的方案。。。globals()['storageID']
没看懂怎么冒出来的。
要做关联参数而且数据放 yaml ,核心点是要让 yaml 具备取值和赋值的能力。因为你没提到你原来 yml 是怎么样的,所以不好给具体建议,建议可以参考下 httprunner 的写法。
用户已删
查了下后台,只看 1 月 7 日注册用户看不出什么,用户信息看起来和正常和用户没什么两样。目前发广告的基本隔几天就注册 1-2 个账号,不发贴分不出来是正常用户还是注册来发广告的。后面会考虑加入微信认证,用户一天发帖量限制,以及被举报多的帖子和用户自动屏蔽功能来提高下发广告成本。
看完整篇文章,有几个位置感觉到楼主不大开心的点:
申请了只做一线技术人员。后来回想起来这个决定,让我处于一种尴尬的境地,没有一个合适的业务团队可以让我进入。
但是总觉得缺少什么,缺少志同道合的伙伴,在工作中能沟通的只有研发反而不是测试的同事,工作上也好像没有很大的提升
光说我们自己的技术领导, 说实话 ” 一个集合是否会有重复数据,一个列表是否有序 的问题"都不知道的人, 我实在没办法过多的认同和交流
1、自己想持续做一线,但后面又有点后悔选择了只做一线。是否应该重新考虑下,自己是想做一线还是往上走带团队?这个 7 年多工作经验,大部分公司里都是一个团队 leader 了,而且你之前其实也有带团队经验。
2、工作中能沟通的只有研发而不是测试的同事,没太明白是什么情况,新项目组只有你一个测试?即使如此,也可以和其他项目的测试交流吧?
3、空降领导都很容易有调性不合的问题,最持久的还是从下面升上去的,至少和公司调性比较一致。既然对你的领导有不少不满意的地方,为何自己不往上走去当这个领导,用自己更有效的方法来解决这些问题?
4、看评论,原文应该有提到不低的薪酬,那个人理解应该是薪酬给的还挺不错了,加上股权基本没有太大跳的动力。现在困惑的是继续留在这家公司做的事情自己不满意。以你在公司这么老的资历和人脉,要调配到一个自己想去的位置应该还是有可能的。主要是你要想好,是放弃一线的 “简单生活” 往上走,还是知足常乐当个一线且控制住自己不去羡慕那些可能比你还年轻点的 leader 。
楼主的核心应该是没想好自己的目标,所以基本上是随遇而安,偶尔一次自己能做选择的点(比如 19 年的公司调整)也只是选择一个相对安全的选项。人无远虑,必有近忧,建议楼主可以想想自己 35 岁的时候要变成什么样,然后倒推自己要做什么,这样焦虑感应该就没那么强了。
PS:同今年 30 岁,也有过带整个测试团队的经历。有一个点感受还是挺明显的,那就是一线其实很多东西接触不到,很难成为公司的核心,视野也很受限(比如对业务的接触,一线的起点可能是产品的需求,但 leader 的起点可能是公司高层才能参加的经营沟通会。一线关注的是这个交互怎么做用户体验才好,怎么做到尽善尽美,leader 关注的是哪个功能涉及公司盈利和核心目标,要着重做好,其他的能跑通就成,不影响最终达成目标),一个人的力量也会很有限。所以单纯做一个一线,你可以做到团队的核心,但很难做到公司的核心。对于这个年龄,大家更多的期望应该还是你多年的工作经验能在整个团队发挥更大的作用,只是做一线不一定能发挥出来。
如果你是不关注顺序,只关注元素相同,那两个列表都用一样的规则排个序,再比较就好了。
可以买服务,给测试用例然后 1-2 天出报告。
好友请求已发
刷算法的,前面有提到很多了,不再重复。
但对于 或者走测开该怎么开始学习。
,个人理解:测开的关键点不是算法,而是工具平台开发,需要的是一些常用的设计理念(如接口测试框架怎么设计,UI 自动化大概怎么套路)和开发能力(后端 + 前端,大部分情况下需要的技能比 crud 高不了多少)。
如果要开始,先找到自己平时工作中的一些痛点,然后用技术手段解决它,逐步做起来吧。测开很关注的是实际解决问题的能力,解决问题过程中上面提到的开发相关方法就会按需学习到了。
刷题更多是一些大公司进去的敲门砖,实际工作上真的要用到刷题时用到的算法相对比较少,常用的基本上都封装到工具类里了。当然如果你做大数据、算法或者机器学习类的除外哈。
建议:
1、docker 和 k8s 有相应的社区或者官方文档,可以上去看看。
2、大数据个人也不大了解,建议可以百度找下其他人零基础的入门路线,一般豆瓣会有。
3、还有一个很重要的点楼主没说出来,不知道楼主有没有想清楚,那就是那就是学习之后的用途是什么?docker 和 k8s 还能算是工具学习,大数据就是一个领域了,内容比较多,没有相对具体的目标,容易迷失或者坚持不下去。
想先问下,你有怎么尝试找过这方面的学习资料,能分享下吗?相比直接告知你有什么资料可以参考,更想了解你怎么找的,看这方面有什么可以给建议。
毕竟以后学习遇到问题,还是需要你自己先想办法找答案的。
具体怎么访问的,访问报什么错,贴上来?
从你启动日志看,应该没问题呀。数据库或者依赖安装如果有问题,连最后这个 Started CaseServerApplication 都出不来。正常如果启动后没有人访问,日志是不会自动增加的。
麻烦加下薪酬范围吧?社区招聘帖老规矩。
我理解你的意思,确实是会有这样的人,做完平台后只简单落地一个项目,写几个简单的用例,就拿着这个平台出去跳槽。
但领导也不傻,大家也不傻。这种情况下做出来的平台,谁敢用。。。既然领导都想强推了,说明还是想做长期的(领导自然得去想怎么让平台能长期发展)。既然做长期,那还是有机会达成共赢的。
而且我觉得,就算沟通到最后发现真的是这种残酷的现实,没法往下走,但也不代表这个沟通就是不必要的吧。个人不喜欢猜测别人的想法,更不喜欢基于自己的这些猜测去限制自己的行动。别人想啥你控制不了,但你做啥是你能控制的,是否要主动去沟通也是你可以控制的。主动然后碰壁总比窝在自己的世界里要好吧,而且就我自己个人经验,主动去沟通了,结果总会比完全不沟通要好,甚至很多时候会发现结果比自己想象要好得多。
可能观念不同吧。我的基本观念是大家都是同一个团队的战友,应该能合作获得共赢。多一个敌人不如多一个朋友。
如果能共赢,做平台开发者的踏脚石也没问题,本身平台也是自己的踏脚石呀,以后出来了说自己业务实践中自动化测试做的怎么怎么牛逼,也是对自己有好处的。
把你实际使用中不好用的点都罗列一番,然后把你用脚本写的好处都罗列一番(特别是效率上和效果上,平台写一个用例的时间脚本可以写好几个,或者有些挺需要自动化的用例平台上没法做),做个比较给领导和平台开发同学看。名义上可以说是这个平台在你所在业务的落地成果汇报。
如果领导有最终为业务服务的想法,应该是愿意听取你的意见的不直接强推的。平台开发同学如果不是自嗨型,也应该很愿意接受你的意见,去兼容脚本或者优化平台上的功能。
不过有一个点要留意,一般领导最担心的是每个人都这么单干团队就没法管了,百花齐放然后人一走变成烂摊子没人接。所以还是得取得一些平衡,比如把脚本和平台结合起来,数据上报平台,脚本编写也有一些基本框架规范限制。这块其实一般能做平台的测开同学也能做脚本框架,可以一起沟通达成共识。
那就写呗。自己作为用户,换个做自动化的方式不是应该很容易么?
建议你可以看看 agileTC 官方 wiki 里他们的调研报告。
只是可以比较确定的是,基于脑图的在线用例管理平台,且开源的,目前看到确实只有 agileTC 这一个。各个大厂内部基本也都有(比如几年前 360 就有分享过),基于百度 kityminder 做改造,但基本都不对外也不开源。
突然发现社区里广州的同学不少。。。
AgileTC 能满足你这 3 个要求呀,建议直接用吧。
现在脑图的在线用例管理平台,各家基本都没开源。
很精彩的 2020 年~