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

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

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

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

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

收到，谢谢

有个疑问，这种替换方式只适合字符串吗？比如有个字段 age=18 是整形，替换后是字符串

pytest.main() 写在最外层的 conftest.py 即可

工具机制不同，请求数据不同，网络状态不同，硬件条件不同。。。很多原因都会造成这个现象。具体原因具体分析吧，最好直接看 server 端的日志

pycharm 可以看到 pytest 的版本，全局的可以用 pip show pytest 命令看下

千万别送书，尤其是本职工作相关的。奶茶点心不香吗，这么想不开

楼主优秀

测试技术提升只是一方面，也可以多学习质量管理方面的内容，比如推动更好的测试流程落地，甚至是项目质量流程。不要太焦虑，今天比昨天好就算进步

首选 redis，其次 ddddocr 识别

1、对应用例后面可以加字段，作为用例级的前/后置条件；
2、再加个单独的 sheet 页，维护项目级的前/后置；
3、登录也可以作为一条普通用例写在 Excel 中，无非是要处理 cookie，token 之类的 (框架要处理大量的项目兼容性)
本意是使用者无需接触，只需要关注用例的编写和维护，其他全部交给框架处理

要看公司的情况，权衡自研还是采购
1、katalon 开始收费，价格还不便宜，并且相较于其他商用工具优势没那么明显
2、有没有自研能力，自研出来的框架/工具能发达到预期

问题 1：大概是这么个过程：

问题 2：
接口自动化框架，支持数据库断言是必要的，与环境无关

问题 1：可以考虑将所有 response 存储一下，用的时候使用jsonpath获取一下
问题 2：数据库查询时传入参数（类似于问题 1 使用 jsonpath 方式获取到的 id）
问题 3：建议将用例和测试结果解耦，Excel 只用来维护用例，测试报告使用 allure 插件；
用例和报告解耦有几个好处：
1、用例多了后 Excel 会非常庞大，写数据比较慢还可能造成文件损坏；
2、allure 内容详尽，样式美观，可以作为标准的测试报告进行输出。

可以多看看HttpRunner的实现方式，是非常优秀的
同样是在 0 到 1 的过程中，共同进步

试试 allure 动态生成功能：allure.dynamic.title(casename)

现在的问题是，会议组织者怕遗漏或者担责任，拉会议时不管是否想干的全都拉上，导致大家参会越来越多，效率确越来越差。

生成用例不难，难的是怎样拿到接口数据

面覆盖到了，深度呢？比如接口自动化平台，有没有自动生成用例的功能、代码覆盖率统计、接口覆盖率统计、覆盖率提升相关统计、精准化测试。。。

5 楼说的是一个值得关注的点，还有可能就是自动化执行期间，用户被被人登录了，造成自动化获取的 token 失效

并不存在统一的规范，还是要看项目的情况和接口使用的具体场景来确定题主说的问题是否需要修改
1、如果是产品形式，要交给客户方使用和维护，某些问题就需要修改。
2、如果接口要提供给第三方调用，某些问题就需要修改。
3、如果接口只在此项目上使用，而且项目的规模不大，业务场景不负责，问题可以暂时不修改。
4、当然以上分析是要在跟团队沟通、向领导汇报前提下再确认的。

数据采集任务一般是根据系统需求，设置固定频率执行，测试单次采集任务的压力意义更大一点，主要考虑以下几点
1、单次采集数据量较大，采集服务处理速度与准确性
2、采集过程中数据异常、服务异常、三方接口异常情况的处理
3、采集服务数据库读写情况
4、了解三方接口返回数据的逻辑、限制 (频率、数据量等)、完整性