数据量超大?接口响应成功后,页面加载渲染太慢;还是接口响应就很慢?前者是前端问题,后者是后端问题。不知道说的对不对
就是开发者工具啊,chrome 的开发者工具还不够使?
首先,需要团队正确认识自动化团队的价值,包括自动化团队本身。
总结的不错!只是第 3 条犯了循环论证的错误,跟用余弦定理证明勾股定理一样
自动化在我理解中,主要是不是用来发现 BUG。
那用来干嘛?有以下几点:
了解;当然,确实如果辛辛苦苦写了很多自动化脚本,结果新版本一上通过率极高,但是还是有很多 bug 没能发现,这确实会” 对人生产生怀疑 “;其实不能说自动化测试发现的 bug 少,它的价值就不高。因为随着迭代的进程,bug 必然会越来越少。新业务的 bug 没有被自动化测试体现出来,说明开发新业务的时候对原有系统的破坏性(改造)小,这也是好事。(不过我的项目组就没有这个烦恼,开发经常改着改着就破坏原业务了 )至于如何进一步提升所谓的价值,我确实没有相关经验。期待你的后续分享吧
自动化测试主要是回归测试,所以没发现的 bug 主要分为 3 类
1:新业务的 bug,也就是没被自动化覆盖的业务的 bug, 这个不属于自动化测试的锅
2: 用例不全 ,目前自动化测试主要是对测试用例的脚本翻译成自动化,所以这个是测试用例设计者的锅
3:脚本对用例覆盖不全,导致漏测,这实实在在是自动化测试的锅
感谢回复,目前我也准备在持续测试上多做些研究
你说能发现一些 bug 但是比较少;所以是不是存在其他发现不了的 bug?然后这些自动化测试发现不了的 bug 是属于前端问题还是后端问题?
你这边说到 “自动化团队的价值”,其实也就是测试的价值
测试的价值可以体现在四个方面:
题目里说的情况,“发现 bug”,只是测试价值的其中一个方面,毕竟随着测试的进行、产品质量的提升,发现的 bug 越来越少其实是合理的
所以从这个角度来看,自动化测试的价值并不是只有发现 bug,如果自动化测试没有发现 bug,说明系统的表现和行为都是符合预期的(自动化脚本没有问题的情况下),这可以为系统增强信心。同时,通过使用自动化来替代手动测试,为持续测试提供了可能性,可以更频繁地触发测试,比如在每日部署和版本部署之后进行,可以比手动更快地发现可能引入的新 bug(或者更快地保证被测功能没有受影响),并且这个信息也可以提供给更多的人(主楼里提到的 “全员抄送”),让其他利益相关方都知道自动化测试的结果,也有助于提高团队的质量意识,这些其实都体现了自动化测试的价值。
我没看懂你的留言
发现不了的 bug 也都是后端的么?
纯开发工具,不深入测试前线,不就是开发岗位吗?和测开有什么关系?真正的测开都是深入做过测试的,如果做纯工具平台开发,而且平台都是产品级的,建议后面直接换开发岗,要论天花板,做开发才能走的更远。
是某五山路某公司?曾经的经历,极为相似,已经离开了。当时还和测开的吵起来了,搞出来的平台提意见竟然被吐槽又不是给你用的,撒几把扯淡什么,被吐槽技术能力不能,给你你做的出来吗?真吉尔蛋疼,怎么会有这样的测开,业务测试就是测开的上帝,竟然被这么吐槽。
还是你懂
如果不换行业,业务知识当然比工具有用的,不必担心,换行业就很难说了
殊途同归,最终还是看业务价值。业务价值取决于亮点,真实业务价值以及老板吹牛逼的能力。所以工具线的老板或者其靠山软实力不强,建议跑路或者直接转开发。
至于业务线上的测开,首先你得有时间学习。网上抄抄自动化是不会有高速成长的,怎么让老板给你时间带薪学习,这是个问题。
真要二选一,建议纯工具开发,道理大家都知道,好跳槽好转型,进可攻退可守。
找工作的时候,工具开发的路更广点吧
肯定是业务性测开,换个角度,如果公司裁员,你是保留懂业务的,还是保留只懂工具开发的
业务性测开也要具备工具开发的能力,基于业务展开的测试才是很多公司需要的,工具测开那就是开发。
小团队里边,或者大 boss 不够重视的团队里边,纯工具性测开根本活不下去
大部分都是混合的,指那打那
职业天花板我觉得都差不多,工具性测开或者业务性测开,我理解如果只看测试通道,都是技术型测试岗,天花板都是测试架构师?
不过从公司层面,可能业务性测开会更有价值,因为工作效果会比较明显。工具性测开,如果可以做到类似统一服务这种形式,各个业务基于统一接口来调用,那极端点说,找开发做不是更快更稳?
个人观点,纯工具开发,不如直接转开发,天花板更高
能落地才行,每个团队都有考核没办法的事。。