测试给开发打分,还跟绩效挂钩。。。这是什么脑袋想出来的主意
建议接 allure
永远叫不醒装睡的人
总结:多干活、少拿钱,进一步降低测试工作的价值
感谢楼主详细的回复,我也实战一下,多谢
最近也在考虑容器环境的问题,请教楼主几个问题:
1、被测服务部署在容器中,jacoco 监听的 port 是否要对外映射
2、被测服务部署容器 ip 重启部署后有可能会变,如何解决
3、编译部署与覆盖率获取时点不一致造成的代码差异,会有影响吗
我也是 Jenkins 配置的 allure 报告,正常生成的。楼主的情况应该不是 Jenkins 的问题,可以先手动 generate 试一下。
机会肯定是好的,看你有没有勇气走出舒适区,迎接挑战,患得患失是最大的阻碍。选择这个机会可能后悔 3、5 年,如果失去了这个机会,是不是会后悔 30、50 年。
点都很真实,解决方案也给的很靠谱,但有些问题还是无解。比如现在公司效益不好,研发都是以产品为导向。项目立项的时候就已经确定了上线的 deadline,过程中需求延期、开发延期、需求变更。。。,后期测试堆人能解决上线时间问题,但质量就堪忧了
“当前平台属于代码托管形式,在每次运行时会拉起一个 docker init 所有相关依赖后 再运行自动化脚本”
对于这个问题,是否可以拆成 2 步走:
step1:构建一个框架/平台级的基础镜像 image_base,包含所有基础依赖
step2:运行任务时基于用例 +image_base 构建可执行镜像
深有体会,目前的产品搞不清需求,只是个业务人员的传话筒,每次需求评审的时候就擅自定了上线日期。在开发测试阶段不停的修改需求,上线时间还不能变,头疼
祝好,努力做出改变的人,值得被命运奖励
我们接口自动化也是利用 swagger 获取接口信息、参数信息,然后根据参数必填和类型填写随机值。这样做的目的不是用来冒烟的,而是为后续编写自动化用例提供参考,不过效果也不是太明显。想要直接生成可用的冒烟用例太难了,目前还没有好的方案
有机会还是要走管理的路,在底层永远是被动的,可以舍弃的。还有任何技术都弥补不了的信息差,任何一点风吹草动都可能是致命性打击
产品就是业务的传话筒 + 搬运工,需求描述 20 个字,需要自己翻译成 1000 字的需求分析才能落地
你这是烫手的山芋呀,1、领导想让线上跑,2、看不到效果就劝退。。。,三思、慎重
自动化停用,这部分回归的工作还是要人来完成。自动化不是万能的,也不是一劳永逸的,leader 们确实要好好权衡这个关系。
大部分项目都是以前端为入口的,接口不会面对这么多考验,而且项目的人力成本投入也不支持做这么详细的校验。所以一般接口测试是用来保障正常入参、正常业务场景,项目有特殊要求除外
对我来说目前主要用的是代码变动影响到的接口,所以树状图更直观一些
好的,多谢
想请问下大佬,allure 报告中的 history 有解决方案吗
拿 bug 绝对数量做考核,测试要被玩死了
从提升平台使用率的角度看,造数的这种改造没什么帮助的吧。我们现在也面临这种尴尬处境,框架改成平台后,使用率反而降低了。了解下来,主要是以下几点:
1、框架的自由度高,而且还能看到框架的实现,调试也方便,使用者是有一定收获的;
2、使用平台限制比较多,而且写一条用例要操作几个表单才能完成,便捷性差很多;
没用过,不过理解下来可以分几步走:
1、构建一个基础镜像,包含 python、selenium、Chrome 等、脚本依赖插件等
2、每次执行,引用步骤 1 的镜像构建一个新镜像,包含最新脚本
3、基于步骤 2 的镜像启动容器
4、具体问题具体分析
好的,多谢大佬