本文承接前作《pytest 钩子pytest_report_teststatus 实践》与《pytest 钩子pytest_collection_finish 实践》。前两篇解决了「数据从哪里来」的问题——通过 pytest 钩子上报用例采集与执行结果本文聚焦「数据到哪里去」——基于Golang Echo搭建一套前后端服务对钩子上报的数据做汇总、持久化与可视化最终形成一份可检索、可下钻、可追溯、可扭转的动态测试报告让 pytest 的产出真正服务于研发与测试协同。一、背景与整体思路1.1 为什么需要这层服务pytest 生态里并不缺报告方案自带--html、--junit-xml社区有allure、pytest-reporter等。但绝大多数方案本质上都是一次性产物存在几个长期痛点跑完才生成执行过程中无法看到状态进程被杀或异常退出就一切归零每次跑完覆盖同一份报告文件下一次跑就丢无法沉淀历史无法跨任务对比失败用例靠记忆「这条上次是不是同一个问题、上次怎么处理、谁处理过」完全靠人脑记忆与群消息翻屏多人多机器散落本地、CI、定时任务各跑各的报告文件散落各处难以统一分发与归档。而通过pytest 钩子实时上报 Golang 后端汇总的架构可以把每一次执行沉淀为一条「任务记录」、把每一条用例沉淀为一条「用例记录」并支持后续的检索、评审、追溯——让报告从一次性产物变成持续演进的资产。1.2 整体架构┌──────────────┐ pytest hooks ┌──────────────────────┐ ┌──────────────────┐ │ pytest runner│ ───────────────▶ │ Golang Echo Server │◀──────▶│ MySQL / Storage │ │ (collection, │ HTTP POST │ /autotest/task/... │ │ task / case / │ │ report) │ │ REST API │ │ review / history │ └──────────────┘ └──────────────────────┘ └──────────────────┘ │ │ JSON ▼ ┌──────────────────┐ │ Frontend (HTML/ │ │ JS / CSS) │ │ 可视化交互层 │ └──────────────────┘整体分为三层采集层pytest_collection_finish钩子上报用例采集结果用例总数、Node ID、markerspytest_report_teststatus钩子上报用例执行结果pass/fail/skip、duration、traceback。服务层Golang Echo 提供 RESTful 接口负责数据汇总、查询、评审、历史、导出、生成测试缓存、删除。展示层原生 HTML 原生 JS无重型框架实现三层弹窗下钻交互配合 Toastify 提示。二、功能总览整套服务围绕「测试任务」一个核心页面对外暴露能力自上而下分成四个递进功能功能入口解决什么功能 1任务列表可视化/autotest/task/index多任务概览、检索、分发、归档功能 2任务详情可视化列表点「查看」单任务下钻到用例级功能 3失败用例详情与状态扭转详情中点失败用例失败用例人工评审与状态扭转功能 4用例历史追溯评审弹窗点「查看历史」同一用例跨任务的历史轨迹下面分别展开。三、功能 1任务列表可视化3.1 功能介绍对测试任务的数据进行简要可视化作为平台首页与门户。具体能力包括对测试任务进行可视化展示直观展示测试任务用例总数、成功、失败、跳过、未执行等用例状态的数量支持对测试任务的过滤搜索支持按任务名称、通过率、时间等字段排序支持一键导出测试数据支持一键生成测试缓存数据。3.2 字段与交互任务列表以表格形式呈现每行对应一次测试任务列含义如下列名含义可排序任务名称任务的唯一标识点击可进入任务详情✅总数该任务下用例总数✅成功执行通过的用例数—失败执行失败的用例数—跳过被 skip 的用例数—已排查人工复核过、已确认状态的用例数—未执行未跑出结果的用例数unknown—通过率Passed / Total 的百分比✅时间任务创建时间✅操作查看 / 导出 / 缓存 三个动作—搜索顶部搜索框支持按任务名称模糊匹配点击「搜索」按钮或回车触发客户端过滤响应极快分页10 / 50 / 100 条每页可切支持跳转到指定页行操作「查看」进入详情「导出」生成下载链接「缓存」生成失败用例缓存压缩包。3.3 效果四、功能 2任务详情可视化4.1 功能介绍对测试任务做更详细的可视化从「任务级」下钻到「用例级」。具体能力详细展示测试任务的用例总数与通过率以及各个状态成功 / 失败 / 跳过 / 未执行用例数量详细展示测试任务的用例名称、耗时、状态、Node ID 等信息支持对测试用例的搜索支持按用例状态过滤用例支持按用例执行耗时排序。4.2 筛选与排序详情弹窗顶部提供三个筛选/排序控件按用例名或 NodeID 筛选实时oninput过滤匹配用例名或node_id如tests/test_login.py::test_login_ok按结果筛选下拉框选项包含全部 / 通过 / 失败 / 跳过 / 已排查 / 未执行按耗时排序点击「耗时 ↕」按钮在降序 → 升序 → 不排序三态之间循环便于定位最慢用例。筛选区右侧实时显示已匹配 / 总数计数方便确认当前过滤结果范围。4.3 用例列表筛选后的用例以表格呈现列包括用例名 / 结果 / 耗时 / Node ID。结果列会附加状态徽标已排查、已标记通过。对失败或已排查用例Node ID与结果单元格均可点击进入失败详情与评审弹窗。4.4 效果五、功能 3失败用例详情与状态扭转5.1 功能介绍针对失败用例在排查过程中为了避免重复排查或排查遗漏平台引入了「用例状态扭转」机制。具体能力展示用例的基本信息用例名称、当前状态展示当前失败的 Traceback渲染时会把Error/Exception/Traceback等关键行高亮便于一眼定位异常抛出点支持状态扭转已排查 / 标记通过支持添加本次排查的备注信息支持查看历史排查数据。5.2 状态扭转的设计意图pytest 原生结果只有passed / failed / skipped三态缺乏「人工评审」这一维度。平台在用例上叠加了一层review_status已排查明确为「这条失败我看过、是预期内的」但不改变结论标记通过明确为「这条不再视为失败」下次回归该用例不再被记为失败。这样在跨任务对比时可以快速区分「真正的新增失败」与「已知问题」让回归报告的可信度大幅提升。5.3 效果六、功能 4用例历史追溯6.1 功能介绍「查看历史」用于追溯某个用例过去所有的执行与评审轨迹对偶发问题、环境问题的判定非常友好。具体能力支持展示历史的排查数据排查人员、时间、排查结果、当时的报错 traceback、备注信息支持查看某条历史 Traceback 的详细日志。6.2 价值切换查看某条历史 traceback 时标题会自动改为历史 #N时间方便区分「最新」与「某次历史」。这样排查同学既能看到「现在长什么样」也能看到「过去什么时候变过、为什么变」对偶发问题、环境问题、时序问题的判定非常友好。6.3 效果七、与 pytest 钩子的协作本服务的数据全部由 pytest 端的钩子上报而来二者协同形成一个闭环。7.1pytest_collection_finish上报采集结果在用例收集完成后触发把整批用例的Node ID、名称、markers一次性上报到后端形成「待执行用例」集合。这一步是「未执行unknown」状态的来源——后续若某条用例没出现在pytest_report_teststatus上报中则会一直保留为unknown便于发现用例被静默 skip / 收集失败的情况。7.2pytest_report_teststatus上报执行结果每个用例执行完触发把pass/fail/skip、duration、traceback等实时上报后端据此更新对应用例的状态。这样即便测试中断如进程被杀也已经留存了已执行部分的结果比「跑完才生成报告」的传统方案更稳健。7.3 112 的效果单独的钩子只是「事件源」没有可视化就只能看日志单独的可视化如果数据是静态文件就失去了「动态、可沉淀」的优势钩子 服务的组合让每一次 pytest 执行都自动成为平台上的一个可查、可评、可追溯的任务真正实现动态报告。八、典型使用场景回归报告查阅日常回归跑完后进入「测试任务」列表按通过率排序找到本次回归任务点「查看」查看失败用例与未执行用例。失败用例排查在任务详情弹窗中按结果筛选failed点击失败用例的 NodeID 查看 Traceback结合堆栈与备注判断是产品 Bug、用例问题还是环境问题。状态扭转确认是已知问题后在评审弹窗填写备注并点击「已排查」或「标记通过」下次回归该用例不再被记为失败。历史追溯对偶发失败用例点「查看历史」回看历次执行与评审记录对比不同时间点的 Traceback定位问题是否发生变化。结果分发点击「导出」生成下载链接复制后贴到群消息或工单中让相关同学离线查看完整报告。缓存重试点击「缓存」生成失败用例缓存压缩包提供下载地址基于失败缓存快速重试失败用例。九、小结服务的「测试任务」模块把「跑测试」之后的全部动作都收口到了一个页面里列表概览 → 用例下钻 → 失败排查 → 评审扭转 → 历史追溯形成完整闭环。从技术视角看它做了三件有价值的事把 pytest 钩子的「事件流」沉淀为「数据资产」——通过 Golang Echo 把零散的钩子上报聚合为可查询的任务/用例记录把「一次性报告」升级为「动态报告」——支持评审扭转与历史追溯让用例状态会随着人不断介入而演进把「个人跑测」升级为「团队协同」——导出、缓存、登录态保护让测试结果天然具备分发与协同属性。这正是 112 的效果pytest 钩子负责「采得全」Golang 服务负责「存得久、查得动」前端负责「看得清、用得上」三者一起构成了一套面向自动化测试结果的实用型可视化平台。相关阅读《pytest 钩子pytest_report_teststatus 实践》——介绍如何上报用例执行结果《pytest 钩子pytest_collection_finish 实践》——介绍如何上报用例采集结果