我帮客户 3 天搭建 pytest 框架并集成 CI 的实战踩坑实录上个月接了个金融类客户的内部管理系统优化项目。他们团队大概 5 个人每次发版都要手工点一遍核心流程耗时半天。客户希望我能把自动化测试搞起来目标是把回归时间压到 10 分钟以内。说实话这种需求我见多了难点从来不在工具本身而在怎么让业务同事愿意用。他们之前试过写脚本但维护成本太高最后都烂尾了。第一次开会时测试组长直言不讳地说只要别增加他们的工作量什么都行。这句话我记在了心里。项目规模不大但业务逻辑复杂涉及资金流转容错率极低。框架选型与数据隔离策略当时有方案 A 用 unittest方案 B 用 pytest。我选了 pytest因为 fixture 管理方便插件生态好。unittest 写起来太啰嗦setUp 和 tearDown 嵌套多了容易晕。一开始我觉得写几个脚本就行结果发现错了。业务逻辑耦合太紧测试数据清理成了大问题。核心问题在于测试用例之间的数据污染。如果用例 A 创建了用户用例 B 依赖这个用户一旦顺序变化就报错。为了解决这个问题我在 conftest.py 里写了一个 session 级别的数据库连接 fixture确保每个用例执行前后都清理数据。pythonconftest.pyimport pytestimport osfrom sqlalchemy import create_enginefrom sqlalchemy.orm import sessionmakerpytest.fixture(scopesession)def db_engine():engine create_engine(os.getenv(DB_URL))yield engineengine.dispose()pytest.fixturedef db_session(db_engine):Session sessionmaker(binddb_engine)session Session()yield sessionsession.rollback()session.close()这段配置看起来简单但当时我为了省事没做 rollback直接 delete。后来在 CI 里发现事务提交后 delete 失效导致数据堆积。坑死了。最后改成 rollback 才稳定下来。还有参数化测试我用 pytest.mark.parametrize 把不同权限的用户测试场景合并成了一个用例代码量直接少了一半。另外我引入了 pytest-html 插件生成报告比默认的文本输出直观得多。客户看到彩色的报告时脸色明显好看了不少。我特意把失败用例标红成功用例标绿视觉上冲击力很强。CI 流水线集成与排错框架搭好后下一步是集成到 GitLab CI。客户用的是自建的 GitLab 服务器Runner 是 Linux 环境。我原本以为只要配置好环境变量就能跑结果第一次提交就失败了。报错信息显示数据库连接超时。我检查了代码本地明明能连。试了一圈发现是 Runner 所在的机器没有配置内网 DNS 解析。开发环境能解析CI 环境不行。这在本地开发时根本遇不到因为本地直接走 hosts 或者能访问内网。当时我盯着日志看了半小时以为是防火墙问题后来才意识到是网络环境差异。日志里反复打印 Connection refused让我误以为是端口没开。我在 .gitlab-ci.yml 里加了一步安装 DNS 工具并验证连接但这治标不治本。最终方案是在 Runner 的 hosts 文件里硬编码了数据库 IP。虽然不优雅但稳定。客户那边网络策略管得严改 DNS 配置需要走流程硬编码是最快的解决方案。yaml.gitlab-ci.ymltest:stage: testscript:pip install -r requirements.txtpytest tests/ --htmlreport.html --self-contained-htmlartifacts:paths:report.htmlonly:main有意思的是客户后来要求把测试报告直接发到群里。我加了个脚本解析 HTML 报告提取失败用例摘要通过 Webhook 推送。这一步虽然增加了复杂度但业务同事终于愿意看报告了。之前报告躺在服务器上没人看现在直接推送到工作群谁负责哪个模块一眼就能看见。还有一个小细节依赖安装时间太长。我把 requirements.txt 里的包版本锁死了并且配置了 pip 镜像源。CI 执行时间从 5 分钟降到了 2 分钟。客户对此很满意因为开发速度提升了。说实话自动化测试不是搭好了就完事。后续维护才是大头。我留了一份文档给他们的测试同学里面记录了常见报错和排查步骤。希望他们能真正用起来而不是最后又变成另一个烂尾项目。这次项目最大的收获不是技术而是明白了工具必须服务于人而不是让人服务于工具。如果测试同学觉得写用例太麻烦框架再好也是白搭。所以我特意简化了用例编写规范只要继承基类就行。本文基于实际项目经验整理欢迎在评论区交流技术问题。