分类标签归档：pytest

从需求到自动化覆盖率看板

发表评论 538 浏览量

从需求到自动化覆盖率看板

2026年5月记录，分类「测试工具」。这里不追求大而全，主要记录一个测试点从发现到落地的过程。

看板目的

自动化覆盖率看板如果只统计脚本数量，很容易误导。我更想看需求、风险点、用例、自动化脚本和执行结果之间的关系。

对测试来说，最后要落到可复现、可验证、可交接，文章也是按这个思路写的。

数据来源

  • 需求拆成测试点，并标记风险等级。
  • 自动化脚本关联到具体测试点，而不是只关联模块。
  • 看板展示通过率、失败原因、最近执行时间和未覆盖原因。
需求ID | 风险等级 | 测试点 | 自动化状态 | 最近执行 | 失败原因
REQ-1024 | 高 | 订单提交 | 已覆盖

阅读全文

pytest-xdist并发执行时的数据隔离

发表评论 1217 浏览量

pytest-xdist并发执行时的数据隔离

2024年2月记录，分类「pytest」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。

并发后暴露的问题

xdist 能缩短执行时间，也会把共享数据问题一次性暴露出来。账号、订单号、缓存 key、临时文件都需要隔离。

这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。

隔离策略

  • 用 worker_id 给测试数据加后缀。
  • 每个 worker 使用独立账号池或独立租户。
  • teardown 失败时记录残留数据，方便清理。
@pytest.fixture
def unique_user(worker_id):

阅读全文

Python 3.12到3.13：测试脚本升级注意点

发表评论 1518 浏览量

Python 3.12到3.13：测试脚本升级注意点

2024年1月记录，分类「Python」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。

升级前

Python 小版本升级看起来不大，但测试脚本依赖的库、虚拟环境、类型提示和弃用 API 都可能受影响。

整理时我特意把输入、动作、观察点和风险拆开，方便后面补用例。

兼容性检查

  • 先锁定 requirements 和当前 Python 版本，留出可回退环境。
  • 用 py_compile 和 pytest 跑基础兼容检查。
  • 重点看 requests、pytest、playwright、数据库驱动这些依赖。
python3.1

阅读全文

Allure报告怎么服务于问题定位

发表评论 1715 浏览量

Allure报告怎么服务于问题定位

2023年1月记录，分类「测试工具」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。

报告不是装饰

Allure 报告如果只展示通过率，价值很有限。我更关心失败用例点进去以后，能不能直接看到请求、响应、截图、日志和环境信息。

整理时我特意把输入、动作、观察点和风险拆开，方便后面补用例。

附件怎么放

  • 接口失败附上 curl、响应体和 traceId。
  • UI 失败附截图、页面地址和浏览器 console。
  • 按模块、优先级、失败类型打标签，方便筛选。
allure.attach(resp.text, name="response",

阅读全文

pytest fixture分层设计：登录、数据和环境隔离

发表评论 2305 浏览量

pytest fixture分层设计：登录、数据和环境隔离

2022年3月记录，分类「pytest」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。

拆分原则

fixture 写不好，自动化会越来越像一团共享状态。这篇记录的是我把登录、造数、清理和环境配置拆开后的做法，重点是让单条用例可以独立运行。

我更关注它在真实提测流程里怎么落地，而不是单独演示一个命令或脚本。

层级设计

  • session 级只放环境配置和公共 client，不放业务数据。
  • function 级 fixture 负责创建订单、用户、审批单这类会被修改的数据。
  • yield 后清理失败也要记录，不要静默吞掉。
@py

阅读全文