感谢回复,目前我也准备在持续测试上多做些研究
你说能发现一些 bug 但是比较少;所以是不是存在其他发现不了的 bug?然后这些自动化测试发现不了的 bug 是属于前端问题还是后端问题?
你这边说到 “自动化团队的价值”,其实也就是测试的价值
测试的价值可以体现在四个方面:
题目里说的情况,“发现 bug”,只是测试价值的其中一个方面,毕竟随着测试的进行、产品质量的提升,发现的 bug 越来越少其实是合理的
所以从这个角度来看,自动化测试的价值并不是只有发现 bug,如果自动化测试没有发现 bug,说明系统的表现和行为都是符合预期的(自动化脚本没有问题的情况下),这可以为系统增强信心。同时,通过使用自动化来替代手动测试,为持续测试提供了可能性,可以更频繁地触发测试,比如在每日部署和版本部署之后进行,可以比手动更快地发现可能引入的新 bug(或者更快地保证被测功能没有受影响),并且这个信息也可以提供给更多的人(主楼里提到的 “全员抄送”),让其他利益相关方都知道自动化测试的结果,也有助于提高团队的质量意识,这些其实都体现了自动化测试的价值。
我没看懂你的留言
发现不了的 bug 也都是后端的么?
纯开发工具,不深入测试前线,不就是开发岗位吗?和测开有什么关系?真正的测开都是深入做过测试的,如果做纯工具平台开发,而且平台都是产品级的,建议后面直接换开发岗,要论天花板,做开发才能走的更远。
是某五山路某公司?曾经的经历,极为相似,已经离开了。当时还和测开的吵起来了,搞出来的平台提意见竟然被吐槽又不是给你用的,撒几把扯淡什么,被吐槽技术能力不能,给你你做的出来吗?真吉尔蛋疼,怎么会有这样的测开,业务测试就是测开的上帝,竟然被这么吐槽。
还是你懂
如果不换行业,业务知识当然比工具有用的,不必担心,换行业就很难说了
殊途同归,最终还是看业务价值。业务价值取决于亮点,真实业务价值以及老板吹牛逼的能力。所以工具线的老板或者其靠山软实力不强,建议跑路或者直接转开发。
至于业务线上的测开,首先你得有时间学习。网上抄抄自动化是不会有高速成长的,怎么让老板给你时间带薪学习,这是个问题。
真要二选一,建议纯工具开发,道理大家都知道,好跳槽好转型,进可攻退可守。
找工作的时候,工具开发的路更广点吧
肯定是业务性测开,换个角度,如果公司裁员,你是保留懂业务的,还是保留只懂工具开发的
业务性测开也要具备工具开发的能力,基于业务展开的测试才是很多公司需要的,工具测开那就是开发。
小团队里边,或者大 boss 不够重视的团队里边,纯工具性测开根本活不下去
大部分都是混合的,指那打那
职业天花板我觉得都差不多,工具性测开或者业务性测开,我理解如果只看测试通道,都是技术型测试岗,天花板都是测试架构师?
不过从公司层面,可能业务性测开会更有价值,因为工作效果会比较明显。工具性测开,如果可以做到类似统一服务这种形式,各个业务基于统一接口来调用,那极端点说,找开发做不是更快更稳?
个人观点,纯工具开发,不如直接转开发,天花板更高
能落地才行,每个团队都有考核没办法的事。。
测开还是看天分,有些需要测开的公司随着大批人员的需要已经降低门槛了,不少测开感觉都是脚本水平,然后一直写脚本。
看个人吧,我觉得业务性测开能够帮助到业务测试,但是没法深入下去;工具性测开能够深入下去,具有平台思维,但是可能开发的平台,不适合业务体系!
应该是深度与广度的区别
我的理解其实大可不必这么区分。
就算是你说的业务性测开的工具,也是需要自己写一些前端让普通功能测试去调用的。而且你要想针对性的测试,你也是要对开发的框架有所了解的。
这个帖子可以回答这个问题,其实还是对测开的期待不一样。测试人员希望测开能真的解决一些痛点问题,但是测开人员经常会觉的自己技术较好,改个框架就让别人去用。研发出来的平台也好,工具也好,也许并不是当前团队的真实痛点。
https://testerhome.com/topics/30771
要教人用的产品,大神一般收到的都是骂声,更别说 n 流开发拍脑袋想的东西。
测开一般就是开发这种产品的角色。
搂猪图样图森破.…
有了平台,过去需要个位数测试,现在需要两位数,增加就业岗位
平台高大上,或者难用,duo 高多难咱都得学会,建立门槛,避免被卷