摘要:
同样使用 Python 标准库 logging 打日志,有的项目输出路径能在 PyCharm 控制台点击跳转、定位到行,有的却只能当字符串看。本文从 PyCharm 控制台路径识别规则入手,排查并复现这个差异,并给出一个基于 logging.Filter 的相对路径优化实现。 一、背景与现象 在 P 阅读全文
同样使用 Python 标准库 logging 打日志,有的项目输出路径能在 PyCharm 控制台点击跳转、定位到行,有的却只能当字符串看。本文从 PyCharm 控制台路径识别规则入手,排查并复现这个差异,并给出一个基于 logging.Filter 的相对路径优化实现。 一、背景与现象 在 P 阅读全文
posted @ 2026-09-04 09:30
EXIORAN
阅读(87)
评论(0)
推荐(1)

在 CI/CD 流程里,"跨阶段的数据共享和状态传递"是一个非常常见的需求——上一个阶段算出来的值、跑出来的状态、检测到的事实,往往需要传给下一个阶段继续用。但 Jenkins 声明式流水线里,顶层 environment {} 定义的变量是"不可变"的,这一点让不少同学吃过亏。本文聊聊这个问题的来
在研发与运维的日常里,"传个文件"这件看起来极小的事,往往会被无限放大——日志包在 A 同事的机器上、安装包在 B 同事的桌面上、配置脚本散在各个项目目录里;好不容易发到群里,过两天就过期了;更怕的是有人手滑把还在用的关键文件给删了。 自研了一套文件共享服务,把这些问题用一个网页、一套后端机制整体解
本文承接前作《pytest 钩子:pytest_report_teststatus 实践》与《pytest 钩子:pytest_collection_finish 实践》。前两篇解决了「数据从哪里来」的问题——通过 pytest 钩子上报用例采集与执行结果;本文聚焦「数据到哪里去」——基于 Gola
在上一篇《别再干等测试报告了:用 pytest 钩子实时追上用例执行进度》中,我们用 pytest_report_teststatus 实现了"每个用例执行完后即时上报状态"。但有个问题遗留下来:执行进度再实时,也只能告诉你'哪些跑过了',没法回答'原本应该跑哪些、还有哪些没跑'。本文用 pytes
在日常测试开发中,"抓取接口参数"是高频操作——但很多时候我们只想拿到参数,并不希望请求真的下发。这篇文章讲清楚为什么要拦截、传统方案的痛点,以及如何用 Chrome 插件 RouteInterceptor 一键解决。 写在前面 完整源码领取:关注公众号【Code自习室】,回复后台回复RouteIn
在上一篇流水线提效中我们提到:"用例执行顺序优化"会单独出文章讲解,本文就来填这个坑。当用例数量上千、并发数开到 8 时,经常会遇到一个反直觉现象:并发越高,反而越慢,通过率也变低。根因不在并发本身,而在"用例执行顺序不合理"导致的环境资源争抢。本文从问题定位、方案演进到最终代码实现,一步步讲清如何
CI/CD 流水线是研发效能的"动脉"——它快,团队就轻快;它慢,每次提交都得喝杯咖啡等结果。很多团队的流水线起初 5 分钟跑完,几个月后悄悄膨胀到 30 分钟,开发体验和提交频率双双下降。本文系统整理流水线耗时优化的 5 大方向,每一项都附可落地的命令和配置示例,看完就能上手。 一、为什么流水线会
在大型测试套件中,跑完所有用例往往需要几十分钟甚至更长。期间"跑到第几条?通过率多少?"一直是黑盒——直到全部结束、测试报告生成后才能看到结果。本文介绍如何利用 pytest 内置钩子 pytest_report_teststatus,在每个用例执行结束时即时上报数据,配合外部汇总即可实现实时进度看
浙公网安备 33010602011771号