产品就是业务的传话筒 + 搬运工，需求描述 20 个字，需要自己翻译成 1000 字的需求分析才能落地

你这是烫手的山芋呀，1、领导想让线上跑，2、看不到效果就劝退。。。，三思、慎重

自动化停用，这部分回归的工作还是要人来完成。自动化不是万能的，也不是一劳永逸的，leader 们确实要好好权衡这个关系。

大部分项目都是以前端为入口的，接口不会面对这么多考验，而且项目的人力成本投入也不支持做这么详细的校验。所以一般接口测试是用来保障正常入参、正常业务场景，项目有特殊要求除外

对我来说目前主要用的是代码变动影响到的接口，所以树状图更直观一些

好的，多谢

想请问下大佬，allure 报告中的 history 有解决方案吗

拿 bug 绝对数量做考核，测试要被玩死了

从提升平台使用率的角度看，造数的这种改造没什么帮助的吧。我们现在也面临这种尴尬处境，框架改成平台后，使用率反而降低了。了解下来，主要是以下几点：
1、框架的自由度高，而且还能看到框架的实现，调试也方便，使用者是有一定收获的；
2、使用平台限制比较多，而且写一条用例要操作几个表单才能完成，便捷性差很多；

没用过，不过理解下来可以分几步走：
1、构建一个基础镜像，包含 python、selenium、Chrome 等、脚本依赖插件等
2、每次执行，引用步骤 1 的镜像构建一个新镜像，包含最新脚本
3、基于步骤 2 的镜像启动容器
4、具体问题具体分析