简介面向Web自动化测试入门与进阶人群的资源包系统讲解从工具选型到报告生成的全流程。内容涵盖Selenium、Puppeteer、Appium等主流框架的适用场景并按测试设计、编码实现、执行分析、报告输出的顺序拆解同时给出测试环境、性能指标、缺陷管理、代码覆盖率等报告维度适合测试工程师、前端开发者及持续集成团队作为方法参考。资源包为zip压缩包体积约23.63MB暂未收录具体文件清单发布至今已有854人学习下载。针对描述中出现的auto_ui-master资源也解释了其可能为自动化UI测试项目代码仓库或Git主分支辅助读者理解脚本与配置的组织逻辑便于在实际项目中复现测试流程、完善报告模板。1. web 版本自动化测试报告在解决什么问题跑完 200 条 web 自动化用例只看一句「全部通过」失败堆栈混在一起没人能一眼看出问题集中在哪个模块这种执行结果还称不上报告。真正能用的 web 版本自动化测试报告要把「哪条用例、按什么步骤、在哪个 URL、页面截图是什么样、控制台报了什么错」组织成可审查的证据链让人不用重跑用例就能判断问题归属。它服务两类人一类是测开自己用来反查用例写法导致的误报另一类是项目组和客户用来确认本次迭代的回归范围与遗留风险。报告合不合格的标准就一条拿到报告的人能不能回答「这次迭代能不能发」。下文按我日常落地的顺序展开先讲报告层该不该单独设计和怎么选型再给 pytest 加 Allure 的最小可跑通工程然后落到标注参数与失败现场采集最后用重试与归档技巧处理报告里最影响信任度的偶发失败。2. 报告层单独设计web 自动化测试报告的工具选型与对比2.1 默认输出和可审查报告之间的断层pytest 默认的 short test summary info 只给文件路径和函数名Selenium 的 console log 只记录 driver 动作序列。用例在 CI 里跑完日志被滚动窗口截断后失败时的 HTTP 状态码、等待超时的秒数、页面 DOM 状态都丢了排障只能重跑。常见做法是把报告层当作测试框架里独立的模块在收集器、执行器、定位器、断言器之外专门有一个组件负责把执行过程的结构化数据渲染成人和机器都能读的产物。这个组件管理的不是「打印了几行日志」而是「每个动作发生在什么时间、携带什么上下文」。报告层独立设计还有一层原因报告链路本身也要能被验证。报告生成做成独立步骤后可以不跑全量用例用两条冒烟用例确认截图是否正确挂载、步骤名是否正确展示、时间线是否完整比在几百条用例的套件里调试报告代码快得多。2.2 pytest-html、Allure、Playwright HTML 报告对比工具数据来源报告形态适合场景pytest-htmlpytest 钩子直接生成单文件 HTML小型项目、快速交付Allureallure-results JSON 中间产物静态站点支持趋势图中大型回归、对外交付ExtentReports封装后写入单文件带图表Java 技术栈、Jenkins 集成Playwright HTML内置收集 trace单文件含网络和快照纯 Playwright 项目选型的底线是看它能否给出步骤级时间线一条用例内部每个 action 的开始与结束时间。有了时间线才能区分是等待策略太短导致的元素未出现还是接口响应真的超过了阈值。pytest-html 默认只给用例级时间Allure 的 allure.step 可以将动作级时间下钻Playwright 的 HTML 报告则把每个 locator 操作和网络请求记录在 trace 里排查前端加载 web 视图超时这类问题时最直接。pytest-html 用法极简一条命令就能出单文件报告pytest --htmlreport.html --self-contained-html--self-contained-html把 CSS 内嵌进文件否则发出去的 HTML 会引用本机样式文件对方打开就是纯文本目录。这个参数细节在跨机器查看报告时经常被忽略。2.3 按团队规模选报告方案与维护成本团队在三五人以内、用例几百条一个 pytest-html 加失败截图 base64 内嵌就够用交付时单独发一个文件没有部署成本。到了跨团队共享测试结论的阶段我一般会切到 Allure原因是 allure-results 目录与执行机解耦执行机只落 JSON 文件展示机任何时刻重新渲染历史趋势数据可以累积不丢。另一个容易踩的坑是直接用 Jenkins 的 HTML Publisher 发 Allure 产物Allure 的静态站点带 JS 资源Publisher 对动态加载支持不好常见做法是先运行 allure generate 生成纯静态目录再发布。选型还要算维护成本。pytest-html 几乎没有学习成本但样式定制要改它的 Jinja 模板Allure 需要团队理解 JSON 中间产物的生命周期首次接入大概花半天ExtentReports 适合已有 Java 测试框架的工程从 pytest 体系迁过去成本偏高。我一般建议新项目直接 Allure老项目保持现状报告工具的迁移优先级永远排在用例可靠性与 flaky 治理之后。3. 用 pytest 加 Allure 跑通 web 自动化测试报告的最小工程3.1 初始化环境与依赖安装mkdir web-test-report cd web-test-report python -m venv venv source venv/bin/activate pip install pytest allure-pytest selenium webdriver-manager这段命令先建虚拟环境隔离依赖版本再安装 pytest 作为用例执行器、allure-pytest 作为报告插件。selenium 提供浏览器驱动 APIwebdriver-manager 自动匹配本机 Chrome 版本省去手动找 chromedriver 的步骤。注意不要在全局 Python 环境里直接装allure-pytest 对 pytest 版本敏感和已有依赖冲突时最常见的现象是 Allure 步骤不展示、装饰器不生效。依赖在报告链路中的职责pytest收集与执行用例产出原始结果allure-pytest将执行结果写入 allure-results 中间产物selenium驱动真实浏览器执行 web 操作webdriver-manager按浏览器版本自动提供驱动3.2 写一条带 Allure 标注的登录冒烟用例import allure from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait allure.feature(登录模块) allure.story(密码登录) allure.severity(allure.severity_level.CRITICAL) allure.title(使用有效账号密码登录跳转首页) def test_login_success(): driver webdriver.Chrome() try: driver.get(http://example.com/login) WebDriverWait(driver, 10).until( lambda d: d.find_element(By.ID, username).is_displayed() ) driver.find_element(By.ID, username).send_keys(tester) driver.find_element(By.ID, password).send_keys(pass1234) driver.find_element(By.ID, submit).click() assert dashboard in driver.current_url # URL 变化是跳转最稳定的信号 finally: driver.quit()Feature 对应报告面板中的一级分组story 是二级分组severity 控制严重级别筛选title 覆盖默认的函数名显示。显式等待替代隐式等待避免网络抖动时在 find_element 阶段直接误报。用 current_url 断言而不是等待页面完全加载因为登录跳转场景下 URL 变化语义最稳定页面资源加载慢不影响断言本身。3.3 生成报告的两条核心命令pytest --alluredirallure-results -q allure generate allure-results -o allure-report --clean allure open allure-report第一条命令把每条用例的结构化执行数据写进 allure-results这是中间产物用例和 json 文件一一对应。第二条命令把 json 渲染成静态站点--clean每次清空输出目录避免旧报告残留干扰判断。第三条在默认浏览器打开报告。中间产物与最终报告分离的意义在 CI 里最明显allure-results 可以作为构建产物归档执行结束 24 小时后再生成报告数据也不丢。提示pytest 7.x 要配 allure-pytest 2.13 以上执行后 allure-results 目录为空时先检查插件是否真的被 pytest 加载运行pytest --version看插件列表。3.4 在无显示器环境执行并验证报告资源路径from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--headlessnew) options.add_argument(--window-size1920,1080) driver webdriver.Chrome(optionsoptions)无头模式用于 CI 或服务器上没有图形界面的场景--headlessnew是 Chrome 109 之后推荐的写法旧写法--headless在新版本里逐步被替换。固定 1920x1080 视口保证截图尺寸统一避免窄视口下元素折叠导致定位失败。服务端环境还要按需加--no-sandbox否则以 root 运行时会直接拒绝启动。生成后验证报告资源路径是否相对化ls allure-results | head python -m http.server 8000 --directory allure-report先确认 allure-results 下新 json 文件数量与用例数一致再起本地静态服务访问报告页面。很多团队本地能打开报告到 CI 或换一台机器就样式丢失根因就是资源路径写成了本机绝对路径这条验证命令能在提交前拦截这个问题。4. web 自动化测试报告必调的 4 个标注参数与失败现场指标4.1 severity、feature、story、step 四层标注severity 分 BLOCKER、CRITICAL、NORMAL、MINOR、TRIVIAL 五级报告筛选器里可以按严重级别过滤。我一般把核心交易链路的用例标成 CRITICAL文案类校验标 MINOR用筛选器就能快速得到「本次遗留风险清单」。feature 和 story 的分层对应需求树的模块与子功能命名不要用英文缩写报告是给项目组看的中文模块名在筛选器里的可读性高得多。step 负责用例内部的动作级标注with allure.step(输入账号): driver.find_element(By.ID, username).send_keys(tester) with allure.step(提交登录表单): driver.find_element(By.ID, submit).click()级别含义典型场景BLOCKER阻断发布登录、支付链路CRITICAL核心功能异常下单流程NORMAL普通功能缺陷列表筛选MINOR轻微文案问题提示语错误TRIVIAL样式细节按钮间距step 是报告里步骤级时间线的数据来源失败时报告会高亮到具体 step而不是只给一个堆栈。四个参数配合后报告支持三种查询按 severity 看遗留风险按 feature 看模块回归范围按 step 看单个动作的耗时波动。耗时波动在 web 场景尤其值得盯同一个 step 昨天 200ms 今天 2s大概率是接口或前端资源问题而不是断言逻辑变了。4.2 失败截图与浏览器日志挂载pytest.hookimpl(hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: driver item.funcargs.get(driver) # 前提driver 以 fixture 方式传入 if driver: allure.attach( driver.get_screenshot_as_png(), name失败现场截图, attachment_typeallure.attachment_type.PNG, )pytest_runtest_makereport 是插件级钩子call 阶段代表用例函数体执行完毕此时判断 failed 再把截图挂进报告。关键点是 item.funcargs 取 driver要求 driver 必须是 pytest fixture 的返回值不能是模块级全局变量否则用例之间共享状态会产生串台。截图之外我一般会同时挂 performance 时间点和 console 的关键报错文本失败用例的证据链按「一图一日志一耗时」组织评审时不用重新登录测试环境。4.3 passed、broken、failed 三个指标的读法passed 表示断言全部通过failed 是断言失败指向业务逻辑或元素定位broken 是执行阶段抛异常比如元素超时未找到、driver 启动失败指向测试环境或用例自身不稳定。web 自动化测试里 broken 占比超过 30% 时先不要提单按三个顺序检查隐式等待改显式等待排查被测页面是否有阻断渲染的 JS 报错确认 CI 与本地浏览器版本、时区一致。这三个原因占 web 自动化测试报告异常的大多数。4.4 environment.properties 与 categories 配置Allure 支持用 environment.properties 注入执行环境信息BrowserChrome 122 Envstaging Build20240401-12把这个文件放进 allure-results 目录再重新生成报告概览页顶部会直接展示浏览器、环境、构建号。报告流传出去之后看的人都清楚对应哪套环境这是 web 项目多环境并行回归时最容易漏的配置。categories.json 则可以把失败归类成已知缺陷、产品缺陷、环境问题常见做法是在工程里维护一份 json把已知 issue 的异常文本匹配进去报告里直接筛出「待产品确认」的用例集合减少评审时逐条翻用例的时间。5. 报告不稳定用重试标记与趋势数据反查 web 端偶发失败5.1 先判定 flaky 再决定是否修用例报告里最影响信任度的是偶发失败上午全绿下午同一批红了三个重跑又恢复。我一般先把这类用例单独拉出来跑 10 次统计失败率低于 20% 的先标 flaky 而不是直接改定位器超过 50% 的才进入用例审查。直接在定位器上反复试错往往把原本稳定的用例改出新的不稳定。5.2 用 pytest-rerunfailures 做受控重试pip install pytest-rerunfailures pytest --reruns 2 --reruns-delay 2 --alluredirallure-results--reruns是失败后的最多重跑次数--reruns-delay是间隔秒数给前端资源加载留出余量。重跑会影响报告统计口径Allure 里重跑后通过的用例带 retry 标记评审时要区分首次失败与最终通过不能把 flaky 用例直接算进回归通过率。5.3 报告归档与性能探针用例报告要能当回归基线结果就必须可对比。每次执行结束把报告归档成带时间戳的目录cp -r allure-report reports/$(date %Y%m%d-%H%M)再配合一个只读的 reports 目录服务两周内的失败趋势一眼可见。最后一个技巧是给 web 项目加一条只采集性能数据的探针用例用 step 名称记录 TTFB 和 LCP当功能用例失败且探针的 LCP 同时超阈值时优先查前端资源加载而不是用例定位器报告就从「有没有挂」升级成「为什么挂」的入口。本文还有配套的精品资源点击获取 Web自动化测试报告：用pytest+Allure打造可审查证据链
简介面向Web自动化测试入门与进阶人群的资源包系统讲解从工具选型到报告生成的全流程。内容涵盖Selenium、Puppeteer、Appium等主流框架的适用场景并按测试设计、编码实现、执行分析、报告输出的顺序拆解同时给出测试环境、性能指标、缺陷管理、代码覆盖率等报告维度适合测试工程师、前端开发者及持续集成团队作为方法参考。资源包为zip压缩包体积约23.63MB暂未收录具体文件清单发布至今已有854人学习下载。针对描述中出现的auto_ui-master资源也解释了其可能为自动化UI测试项目代码仓库或Git主分支辅助读者理解脚本与配置的组织逻辑便于在实际项目中复现测试流程、完善报告模板。1. web 版本自动化测试报告在解决什么问题跑完 200 条 web 自动化用例只看一句「全部通过」失败堆栈混在一起没人能一眼看出问题集中在哪个模块这种执行结果还称不上报告。真正能用的 web 版本自动化测试报告要把「哪条用例、按什么步骤、在哪个 URL、页面截图是什么样、控制台报了什么错」组织成可审查的证据链让人不用重跑用例就能判断问题归属。它服务两类人一类是测开自己用来反查用例写法导致的误报另一类是项目组和客户用来确认本次迭代的回归范围与遗留风险。报告合不合格的标准就一条拿到报告的人能不能回答「这次迭代能不能发」。下文按我日常落地的顺序展开先讲报告层该不该单独设计和怎么选型再给 pytest 加 Allure 的最小可跑通工程然后落到标注参数与失败现场采集最后用重试与归档技巧处理报告里最影响信任度的偶发失败。2. 报告层单独设计web 自动化测试报告的工具选型与对比2.1 默认输出和可审查报告之间的断层pytest 默认的 short test summary info 只给文件路径和函数名Selenium 的 console log 只记录 driver 动作序列。用例在 CI 里跑完日志被滚动窗口截断后失败时的 HTTP 状态码、等待超时的秒数、页面 DOM 状态都丢了排障只能重跑。常见做法是把报告层当作测试框架里独立的模块在收集器、执行器、定位器、断言器之外专门有一个组件负责把执行过程的结构化数据渲染成人和机器都能读的产物。这个组件管理的不是「打印了几行日志」而是「每个动作发生在什么时间、携带什么上下文」。报告层独立设计还有一层原因报告链路本身也要能被验证。报告生成做成独立步骤后可以不跑全量用例用两条冒烟用例确认截图是否正确挂载、步骤名是否正确展示、时间线是否完整比在几百条用例的套件里调试报告代码快得多。2.2 pytest-html、Allure、Playwright HTML 报告对比工具数据来源报告形态适合场景pytest-htmlpytest 钩子直接生成单文件 HTML小型项目、快速交付Allureallure-results JSON 中间产物静态站点支持趋势图中大型回归、对外交付ExtentReports封装后写入单文件带图表Java 技术栈、Jenkins 集成Playwright HTML内置收集 trace单文件含网络和快照纯 Playwright 项目选型的底线是看它能否给出步骤级时间线一条用例内部每个 action 的开始与结束时间。有了时间线才能区分是等待策略太短导致的元素未出现还是接口响应真的超过了阈值。pytest-html 默认只给用例级时间Allure 的 allure.step 可以将动作级时间下钻Playwright 的 HTML 报告则把每个 locator 操作和网络请求记录在 trace 里排查前端加载 web 视图超时这类问题时最直接。pytest-html 用法极简一条命令就能出单文件报告pytest --htmlreport.html --self-contained-html--self-contained-html把 CSS 内嵌进文件否则发出去的 HTML 会引用本机样式文件对方打开就是纯文本目录。这个参数细节在跨机器查看报告时经常被忽略。2.3 按团队规模选报告方案与维护成本团队在三五人以内、用例几百条一个 pytest-html 加失败截图 base64 内嵌就够用交付时单独发一个文件没有部署成本。到了跨团队共享测试结论的阶段我一般会切到 Allure原因是 allure-results 目录与执行机解耦执行机只落 JSON 文件展示机任何时刻重新渲染历史趋势数据可以累积不丢。另一个容易踩的坑是直接用 Jenkins 的 HTML Publisher 发 Allure 产物Allure 的静态站点带 JS 资源Publisher 对动态加载支持不好常见做法是先运行 allure generate 生成纯静态目录再发布。选型还要算维护成本。pytest-html 几乎没有学习成本但样式定制要改它的 Jinja 模板Allure 需要团队理解 JSON 中间产物的生命周期首次接入大概花半天ExtentReports 适合已有 Java 测试框架的工程从 pytest 体系迁过去成本偏高。我一般建议新项目直接 Allure老项目保持现状报告工具的迁移优先级永远排在用例可靠性与 flaky 治理之后。3. 用 pytest 加 Allure 跑通 web 自动化测试报告的最小工程3.1 初始化环境与依赖安装mkdir web-test-report cd web-test-report python -m venv venv source venv/bin/activate pip install pytest allure-pytest selenium webdriver-manager这段命令先建虚拟环境隔离依赖版本再安装 pytest 作为用例执行器、allure-pytest 作为报告插件。selenium 提供浏览器驱动 APIwebdriver-manager 自动匹配本机 Chrome 版本省去手动找 chromedriver 的步骤。注意不要在全局 Python 环境里直接装allure-pytest 对 pytest 版本敏感和已有依赖冲突时最常见的现象是 Allure 步骤不展示、装饰器不生效。依赖在报告链路中的职责pytest收集与执行用例产出原始结果allure-pytest将执行结果写入 allure-results 中间产物selenium驱动真实浏览器执行 web 操作webdriver-manager按浏览器版本自动提供驱动3.2 写一条带 Allure 标注的登录冒烟用例import allure from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait allure.feature(登录模块) allure.story(密码登录) allure.severity(allure.severity_level.CRITICAL) allure.title(使用有效账号密码登录跳转首页) def test_login_success(): driver webdriver.Chrome() try: driver.get(http://example.com/login) WebDriverWait(driver, 10).until( lambda d: d.find_element(By.ID, username).is_displayed() ) driver.find_element(By.ID, username).send_keys(tester) driver.find_element(By.ID, password).send_keys(pass1234) driver.find_element(By.ID, submit).click() assert dashboard in driver.current_url # URL 变化是跳转最稳定的信号 finally: driver.quit()Feature 对应报告面板中的一级分组story 是二级分组severity 控制严重级别筛选title 覆盖默认的函数名显示。显式等待替代隐式等待避免网络抖动时在 find_element 阶段直接误报。用 current_url 断言而不是等待页面完全加载因为登录跳转场景下 URL 变化语义最稳定页面资源加载慢不影响断言本身。3.3 生成报告的两条核心命令pytest --alluredirallure-results -q allure generate allure-results -o allure-report --clean allure open allure-report第一条命令把每条用例的结构化执行数据写进 allure-results这是中间产物用例和 json 文件一一对应。第二条命令把 json 渲染成静态站点--clean每次清空输出目录避免旧报告残留干扰判断。第三条在默认浏览器打开报告。中间产物与最终报告分离的意义在 CI 里最明显allure-results 可以作为构建产物归档执行结束 24 小时后再生成报告数据也不丢。提示pytest 7.x 要配 allure-pytest 2.13 以上执行后 allure-results 目录为空时先检查插件是否真的被 pytest 加载运行pytest --version看插件列表。3.4 在无显示器环境执行并验证报告资源路径from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--headlessnew) options.add_argument(--window-size1920,1080) driver webdriver.Chrome(optionsoptions)无头模式用于 CI 或服务器上没有图形界面的场景--headlessnew是 Chrome 109 之后推荐的写法旧写法--headless在新版本里逐步被替换。固定 1920x1080 视口保证截图尺寸统一避免窄视口下元素折叠导致定位失败。服务端环境还要按需加--no-sandbox否则以 root 运行时会直接拒绝启动。生成后验证报告资源路径是否相对化ls allure-results | head python -m http.server 8000 --directory allure-report先确认 allure-results 下新 json 文件数量与用例数一致再起本地静态服务访问报告页面。很多团队本地能打开报告到 CI 或换一台机器就样式丢失根因就是资源路径写成了本机绝对路径这条验证命令能在提交前拦截这个问题。4. web 自动化测试报告必调的 4 个标注参数与失败现场指标4.1 severity、feature、story、step 四层标注severity 分 BLOCKER、CRITICAL、NORMAL、MINOR、TRIVIAL 五级报告筛选器里可以按严重级别过滤。我一般把核心交易链路的用例标成 CRITICAL文案类校验标 MINOR用筛选器就能快速得到「本次遗留风险清单」。feature 和 story 的分层对应需求树的模块与子功能命名不要用英文缩写报告是给项目组看的中文模块名在筛选器里的可读性高得多。step 负责用例内部的动作级标注with allure.step(输入账号): driver.find_element(By.ID, username).send_keys(tester) with allure.step(提交登录表单): driver.find_element(By.ID, submit).click()级别含义典型场景BLOCKER阻断发布登录、支付链路CRITICAL核心功能异常下单流程NORMAL普通功能缺陷列表筛选MINOR轻微文案问题提示语错误TRIVIAL样式细节按钮间距step 是报告里步骤级时间线的数据来源失败时报告会高亮到具体 step而不是只给一个堆栈。四个参数配合后报告支持三种查询按 severity 看遗留风险按 feature 看模块回归范围按 step 看单个动作的耗时波动。耗时波动在 web 场景尤其值得盯同一个 step 昨天 200ms 今天 2s大概率是接口或前端资源问题而不是断言逻辑变了。4.2 失败截图与浏览器日志挂载pytest.hookimpl(hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: driver item.funcargs.get(driver) # 前提driver 以 fixture 方式传入 if driver: allure.attach( driver.get_screenshot_as_png(), name失败现场截图, attachment_typeallure.attachment_type.PNG, )pytest_runtest_makereport 是插件级钩子call 阶段代表用例函数体执行完毕此时判断 failed 再把截图挂进报告。关键点是 item.funcargs 取 driver要求 driver 必须是 pytest fixture 的返回值不能是模块级全局变量否则用例之间共享状态会产生串台。截图之外我一般会同时挂 performance 时间点和 console 的关键报错文本失败用例的证据链按「一图一日志一耗时」组织评审时不用重新登录测试环境。4.3 passed、broken、failed 三个指标的读法passed 表示断言全部通过failed 是断言失败指向业务逻辑或元素定位broken 是执行阶段抛异常比如元素超时未找到、driver 启动失败指向测试环境或用例自身不稳定。web 自动化测试里 broken 占比超过 30% 时先不要提单按三个顺序检查隐式等待改显式等待排查被测页面是否有阻断渲染的 JS 报错确认 CI 与本地浏览器版本、时区一致。这三个原因占 web 自动化测试报告异常的大多数。4.4 environment.properties 与 categories 配置Allure 支持用 environment.properties 注入执行环境信息BrowserChrome 122 Envstaging Build20240401-12把这个文件放进 allure-results 目录再重新生成报告概览页顶部会直接展示浏览器、环境、构建号。报告流传出去之后看的人都清楚对应哪套环境这是 web 项目多环境并行回归时最容易漏的配置。categories.json 则可以把失败归类成已知缺陷、产品缺陷、环境问题常见做法是在工程里维护一份 json把已知 issue 的异常文本匹配进去报告里直接筛出「待产品确认」的用例集合减少评审时逐条翻用例的时间。5. 报告不稳定用重试标记与趋势数据反查 web 端偶发失败5.1 先判定 flaky 再决定是否修用例报告里最影响信任度的是偶发失败上午全绿下午同一批红了三个重跑又恢复。我一般先把这类用例单独拉出来跑 10 次统计失败率低于 20% 的先标 flaky 而不是直接改定位器超过 50% 的才进入用例审查。直接在定位器上反复试错往往把原本稳定的用例改出新的不稳定。5.2 用 pytest-rerunfailures 做受控重试pip install pytest-rerunfailures pytest --reruns 2 --reruns-delay 2 --alluredirallure-results--reruns是失败后的最多重跑次数--reruns-delay是间隔秒数给前端资源加载留出余量。重跑会影响报告统计口径Allure 里重跑后通过的用例带 retry 标记评审时要区分首次失败与最终通过不能把 flaky 用例直接算进回归通过率。5.3 报告归档与性能探针用例报告要能当回归基线结果就必须可对比。每次执行结束把报告归档成带时间戳的目录cp -r allure-report reports/$(date %Y%m%d-%H%M)再配合一个只读的 reports 目录服务两周内的失败趋势一眼可见。最后一个技巧是给 web 项目加一条只采集性能数据的探针用例用 step 名称记录 TTFB 和 LCP当功能用例失败且探针的 LCP 同时超阈值时优先查前端资源加载而不是用例定位器报告就从「有没有挂」升级成「为什么挂」的入口。本文还有配套的精品资源点击获取