肯定是需要持续维护的
我也想知道是怎么统计节省人力的,但是在平常项目中确实能够因为其实有大量的基准案例自动化了,所以手工测试的部分只有全新需求的案例和部分难以自动化或者自动化不了的案例,相对来说确实比之前轻松了不少,大版本发布(大版本要求全部案例执行一遍保证功能)时除了全新需求的测试用例,老需求的案例也因此能够快速验证(大概 5000 个自动化案例)
这个我在刚刚踏入测试行业的时候就见识到了,记得有一次需求测试,测试案例都已经写完了,测试方案那些都弄完了,执行案例的时候突然发现可能有个比较大的逻辑实现漏洞,然后立马去问开发是不是那个实现方式会不会有这样的漏洞,开发听到我和他说了之后,和我说的一句话就是你不和我说我怎么知道你不知道(需求是小需求,之前没有开发设计文档那些)
第七点这个感觉还是要评估,不过重点应该是开发评估改动影响面,测试根据影响面进行基本的功能测试和发散测试,这个 要结合实际去看
第九点好像挺多公司都这样
厉害确实
基本操作吧
建议加精
但是你写好去上传,如果不是自己公司的大模型要考虑泄密问题
看吧,现在我是走一步看一步,先把自己当前做好了先
怎么大伙搞自动化都会卡在这啊
有没有可能你拿个 token 就可以直接跳过这个验证码
小公司的安全说实话了解的不多,相对大一点公司卷的要命,35 岁以上说实话除了极个别超高 T 级或者安全专家,平常等级的安全测试没见过
确实,有点看笑了
建议以后引用他人评论的时候可以给名字头像打一下马赛克
高飞大佬 可以专门出一期发一下看看,感觉会很不错
据我了解没有
APP 了解的不多,不过以前小时候拿垃圾手机玩游戏的时候经常因为内存原因闪退
确实有干货,很多都是目前行业已经在做,或者已经规划好的发展方向
确实,不如自己问问其他测试同事或者问问 SRE
我说我看到的,基本稍微大一点的公司,哪怕整个项目组只有 10 个人,哪怕只是孵化项目,这里面都最起码有一个专门的 DFX 测试
大公司应该也还是这样吧
自信一点是全部
这是?