分类标签归档：自动化测试
2026年5月记录，分类「测试工具」。这里不追求大而全，主要记录一个测试点从发现到落地的过程。
自动化覆盖率看板如果只统计脚本数量，很容易误导。我更想看需求、风险点、用例、自动化脚本和执行结果之间的关系。
对测试来说，最后要落到可复现、可验证、可交接，文章也是按这个思路写的。
需求ID | 风险等级 | 测试点 | 自动化状态 | 最近执行 | 失败原因
REQ-1024 | 高 | 订单提交 | 已覆盖 2025年12月记录，分类「测试工具」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。
质量度量不是为了年底汇报好看，而是找出下一年要重点改进的模块和流程。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
缺陷逃逸率 = 线上缺陷数 / 总缺陷数
自动化有效率 = 有稳定执行记录的用例 / 自动化用例总数
2025年3月记录，分类「Playwright」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。
视觉回归最怕截图很多但全是噪音。我只对稳定、关键、业务价值高的区域做截图断言。
记录这篇的目的，是让下次遇到同类问题时少走一轮弯路。
expect(page.locator('[data-testid="order-card"]')).to_have_scree2025年1月记录，分类「AI测试」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。
AI 生成用例我更愿意把它当草稿助手，不直接当结论。它能帮忙补思路，但业务规则和风险等级必须人工确认。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
输入: 需求原文 + 接口字段 + 历史缺陷
输出: 场景、输入、动作、期望、风险等级
人工: 校验业务规则和不可测2024年2月记录，分类「自动化测试」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。
Selenium 4 BiDi 对测试最有用的地方，是能更方便地观察浏览器日志、网络事件和页面行为，而不只是操作元素。
我更关注它在真实提测流程里怎么落地，而不是单独演示一个命令或脚本。
logs = driver.get_log("browser")
errors 2024年2月记录，分类「pytest」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。
xdist 能缩短执行时间，也会把共享数据问题一次性暴露出来。账号、订单号、缓存 key、临时文件都需要隔离。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
@pytest.fixture
def unique_user(worker_id):
2023年10月记录，分类「Playwright」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。
前端偶现失败只看截图经常不够。Trace Viewer 能把 DOM、请求、控制台、操作步骤串起来，适合排查偶发等待和接口慢导致的问题。
记录这篇的目的，是让下次遇到同类问题时少走一轮弯路。
npx p2023年8月记录，分类「自动化测试」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。
移动端自动化的稳定性，很多时候不是 Appium 本身的问题，而是定位策略太脆弱、等待条件太粗、测试机状态不可控。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
el = WebDriverWait(driver, 10).until(
lamb2022年12月记录，分类「接口测试」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。
年底做接口巡检，我不会把所有接口平均扫一遍，而是优先看高频、资金、权限、导出、批量操作这些风险更高的接口。
我当时想确认的不是工具能不能跑，而是这个点能不能稳定地变成测试资产。
接口分级: P0资金 / P1核心流程 / P2普通查询
巡检维度: 调用量、缺陷数、告警数、最近变更
2022年8月记录，分类「自动化测试」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。
Page Object 很容易被写成另一种面条代码：所有元素和所有动作都塞进一个类，最后比裸 Selenium 还难读。我后来更关注页面对象到底有没有表达业务动作。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
class OrderPa