深有体会，目前的产品搞不清需求，只是个业务人员的传话筒，每次需求评审的时候就擅自定了上线日期。在开发测试阶段不停的修改需求，上线时间还不能变，头疼

祝好，努力做出改变的人，值得被命运奖励

我们接口自动化也是利用 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 的标准。。。我辛苦上班才赚几个钱。目的是好的，只是这个形式值得商榷

每月一次，还只能是技术。。。这频率确实有点高。
1、是不是可以把整块的技术拆成点，也能借此机会把细节想明白；
2、不光可以分享，也可以问，痛点或者是项目应用方面的问题，也可以提出来，引导一下领导去推动解决；