想到的一些思路, 有没想到的欢迎补充:
编码阶段: 代码层面的预防, 比如: 静态扫描, AI 提示?; 结合 IDE 插件, CI 门禁...
测试阶段: 围绕 “选机型” 和 “选用例”, 可能有几种或多种结合 (执行时机和方式: 测试阶段/CI 门禁, 手动/自动, 本地/云平台): 1.针对性的测试,根据 code diff/开发沟通,选取可能影响的机型进行相关功能的最小测试; 2,防御性的测试, 在一定机型 (全量/剪枝), 跑高优用例/精准推荐用例; 3.随机测试, 在一定机型, 跑 monkey/UI 树遍历
发布阶段: 灰度, 报警监控...

GUI 自动化, 原生控件可以试试 pywinauto

文章开头的链接是 Not Found

QT 确实不太确定, pywinauto 是通过 windows 的 API 获取控件

用过 pywinauto,还算稳定,不过是 N 年前了, swing 可以用 jemmy 注入

纯探讨, 不合适的地方望指出. 团队是要完成目标或者承载更大目标为首要任务的, 不是 “学校”,人才有梯度也很正常, 从当下和中长期目标出发做盘点判断是否人才符合各位置的需求, 根据具体情况判断启动内部培训/外部招聘来补充 (或适度汰换); 对于培训, 如果个人没意愿, 强加上去会事倍功半, 内驱动和外激励都是需要的,需要根据个体需求做平衡, 重点培养有潜力有驱动力的成员, 成事的成就感也是一种激励, 指导成员成事的过程也是一种培训; 当然日常的技术氛围也不能忽视.

多实例问题, 我的做法是: 定时任务不随 web 服务启动, 单独一个实例不启动 web 只启动定时任务. 代码可以放到同一个仓库, 只是不同角色启动不同的服务; 定时任务复用 web 的逻辑可以引用 flask 上下文环境

可以直接看源码

在终端里面是正常的 (windows 系统没试), 默认有提供锁, 实例初始化时会将显示位置 position(指定或自动获取) 记录到全局_instances 里,

锁可以参考 TqdmDefaultWriteLock 类的注释:
Provide a default write lock for thread and multiprocessing safety.
Works only on platforms supporting fork (so Windows is excluded).
You must initialise a tqdm or TqdmDefaultWriteLock instance
before forking in order for the write lock to work.
On Windows, you need to supply the lock from the parent to the children as
an argument to joblib or the parallelism lib you use.

成功获取锁之后会先执行 moveto 方法, 根据 position 将光标移动到相应的位置, 再写 msg, 这段逻辑可以参考 display 方法和 moveto 方法

unittest 可以写一个单例维护 driver, 例如用类变量, case 里面用这个单例返回的 driver, 用 atexit 注册一个 driver 的退出函数, 可以实现

或者单例维护的是 cookie/session 之类的校验值, 初始化时取出来存到类变量 (或外部存储,例如 redis/mysql) 后 driver 立即销毁, 这样 case 执行完就不用处理这个 driver 销毁

或者再极端点, 写一个小 service 来做处理获取及校验 cookie/session 的事, case 去这个 service 拿, 也可

fixture 可以设置 scope 为 session, 用 yield 实现退出
https://docs.pytest.org/en/latest/reference/fixtures.html#higher-scoped-fixtures-are-executed-first

但是感觉像是起个容器远程操作固定的打包机做打包动作, 有理解错误地方望指正

是否可以考虑 docker in docker 来 build&push 镜像, 用完即抛, 部署时 k8s 从镜像仓库直接拉取就可以了