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

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

看板目的

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

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

数据来源

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

需求ID | 风险等级 | 测试点 | 自动化状态 | 最近执行 | 失败原因
REQ-1024 | 高 | 订单提交 | 已覆盖 

阅读全文

年终质量度量：缺陷、自动化和线上告警

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

度量目的

质量度量不是为了年底汇报好看，而是找出下一年要重点改进的模块和流程。

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

指标选择

• 缺陷按模块、严重级别、发现阶段、逃逸原因统计。
• 自动化看有效覆盖和失败定位，不只看用例数量。
• 线上告警和用户反馈要回流到测试策略。

缺陷逃逸率 = 线上缺陷数 / 总缺陷数
自动化有效率 = 有稳定执行记录的用例 / 自动化用例总数

数据口径

• 指标口径前后一致。
• 每个高风险模块有

阅读全文

postman变量使用技巧

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

变量层级

Postman 变量看着简单，实际很容易因为环境变量、集合变量、全局变量混用导致请求跑偏。我这篇主要记录自己的分层习惯。

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

常见写法

• host、tenant、账号放环境变量。
• token、订单号、流水号放集合变量。
• 调试临时值用本地变量，不提交到团队集合。

pm.collectionVariables.set("order_id", pm.response.json

阅读全文

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

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

报告不是装饰

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

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

附件怎么放

• 接口失败附上 curl、响应体和 traceId。
• UI 失败附截图、页面地址和浏览器 console。
• 按模块、优先级、失败类型打标签，方便筛选。

allure.attach(resp.text, name="response",

阅读全文

Postman环境变量和前置脚本的实战整理

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

变量怎么分

Postman 很适合联调，但变量乱了也很容易把人带坑里。我整理这篇，是为了让集合可以在本地、测试环境、预发环境之间稳定切换。

记录这篇的目的，是让下次遇到同类问题时少走一轮弯路。

前置脚本做什么

• 环境变量只放 host、账号、租户这类会随环境变化的值。
• collection 变量放 token、业务 id 这类运行过程中产生的值。
• 前置脚本只做签名、时间戳、公共 header，不写复杂业务流程。

pm.environment.s

阅读全文