“当前平台属于代码托管形式，在每次运行时会拉起一个 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、具体问题具体分析

好的，多谢大佬

好的，看到大佬的更新了，多谢

现在的做法是每次将生成的 CCI result 贴到 echarts 里，才能生成关系图，这种应用方式比较麻烦，也不太能做成自动化。对于这部分大佬有什么方案吗？

试了下，很不错，基本达到了预期效果，楼主威武！想问下，CCI result 除了用 echarts 展示，还有其他展示方式吗

不嫌麻烦的话 ，登录接口 response header 可以一个个试。最简单的还是找开发确认下，可能一分钟就能搞定了

才入行半年就开始摆烂不好吧

这问题比中东局势的问题还要大

不光测试行业，其他行业也可能存在这种情况。楼主这心态不利于个人发展呀

自动化框架？写测试平台？搞代码覆盖率？
能搞定一个就非常不错了吧，即使都搞定，还有精准化测试、AI 自动化测试。。。

只有罚没有奖？这么高频率的分享，除非给出准备的时间，不然还是蛮有负担的。再有，请客 300 的标准。。。我辛苦上班才赚几个钱。目的是好的，只是这个形式值得商榷