产品就是业务的传话筒 + 搬运工,需求描述 20 个字,需要自己翻译成 1000 字的需求分析才能落地
你这是烫手的山芋呀,1、领导想让线上跑,2、看不到效果就劝退。。。,三思、慎重
自动化停用,这部分回归的工作还是要人来完成。自动化不是万能的,也不是一劳永逸的,leader 们确实要好好权衡这个关系。
大部分项目都是以前端为入口的,接口不会面对这么多考验,而且项目的人力成本投入也不支持做这么详细的校验。所以一般接口测试是用来保障正常入参、正常业务场景,项目有特殊要求除外
对我来说目前主要用的是代码变动影响到的接口,所以树状图更直观一些
好的,多谢
想请问下大佬,allure 报告中的 history 有解决方案吗
拿 bug 绝对数量做考核,测试要被玩死了
从提升平台使用率的角度看,造数的这种改造没什么帮助的吧。我们现在也面临这种尴尬处境,框架改成平台后,使用率反而降低了。了解下来,主要是以下几点:
1、框架的自由度高,而且还能看到框架的实现,调试也方便,使用者是有一定收获的;
2、使用平台限制比较多,而且写一条用例要操作几个表单才能完成,便捷性差很多;
没用过,不过理解下来可以分几步走:
1、构建一个基础镜像,包含 python、selenium、Chrome 等、脚本依赖插件等
2、每次执行,引用步骤 1 的镜像构建一个新镜像,包含最新脚本
3、基于步骤 2 的镜像启动容器
4、具体问题具体分析