产品就是业务的传话筒 + 搬运工，需求描述 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、不光可以分享，也可以问，痛点或者是项目应用方面的问题，也可以提出来，引导一下领导去推动解决；

然后我们从 pod 读取文件/app/jacoco.exec 写入我们的报告生成服务即可

请问大佬从 pod 读取 exec 文件是如何实现的？

1、建议日构建，发布构建太频繁不建议使用；
2、出现执行失败要分析，环境问题、数据问题、用例问题、出现 bug；大部分接口自动化发现的问题都是误修改引发的，比如修改 A 接口，影响了 B 接口，导致 B 接口用例执行失败；
3、根据研发流程来，如果有较详细的接口文档，可以修后接口用例后再执行；不然就是执行失败后再针对性调整；

提出这种问题，看来楼主还没遭受过社会的毒打。千万不要自作主张动生产数据，无论什么目的，即使领导让你动，也要获取多方确认（领导、运维、业务等）后再实施。不然出了问题锅只能自己背，小测试的抗风险能力差，如果遇到这种问题，基本就是走人了，慎重！

除了正常场景，有些异常场景是否也要覆盖，比如 读取的文件不存在、文件格式不符合要求、大文件、空文件等