打造可追查的自动化测试报告)
Allure 报告里最能看出一个自动化测试工程师功力的地方往往不是用例写得有多复杂而是给报告里塞的“证据”有多讲究。我自己维护过几个用 pytest PO 模式跑了几年的自动化项目越到后期越发现allure.attach() 这个看起来不起眼的方法才是让 allure 报告从“能看”变成“能查、能追、能复盘”的关键。很多人刚开始接触 allure.attach() 只知道它能往报告里贴点东西实际用起来却容易踩坑要么报告里什么都没有要么图片乱码要么附件体积大得离谱。这篇文章把我这几年在自动化测试allure报告里使用 allure.attach() 的经验完整拆开讲从方法参数到底层逻辑从 pytest PO 框架整合到问题排查全部按可落地的思路写。看完你就能把截图、请求响应、日志、HTML快照这些“证据”全部挂进报告让团队在看报告的时候不需要反复问你是怎么回事。1. 理解 allure.attach()它到底挂在哪个环节1.1 一个自带“证据链”的报告才是好报告你可以把 allure 报告想象成测试用例的“结案卷宗”。用例执行过程是流水账而报告是给所有人看的最终档案。一份只有“PASS/FAIL” 几行日志的报告就像一份没有证物清单的结案报告别人只能看到结论完全不知道过程发生了什么。allure.attach() 就是往卷宗里塞证物的一套接口它负责把测试过程中产生的各种文件、文本、图片、JSON、HTML 等资源挂载到测试用例或测试步骤上。我见过很多团队失败用例全靠开发自己复现效率低得离谱。后来我们把接口返回、前端截图、数据库查询结果全部 attach 进报告开发排查问题时打开报告就像看监控回放一样直接通常几分钟就能定位。这个转变的核心就一句话把“能证明现场”的数据主动放进报告里而不是等人来问的时候再去翻日志。1.2 两个常用变体attach 与 attach.fileallure 库给我们的核心方法是allure.attach()但它其实有两条路可以走allure.attach(body, name, attachment_type, extension)直接传入内存中的字符串或二进制内容。allure.attach.file(source, name, attachment_type, extension)传入一个本地文件路径方法会读取文件内容并挂到报告里。下面是一个最基础的调用示例import allure # 挂一段纯文本 allure.attach(这里是测试输出的日志内容, name执行日志, attachment_typeallure.attachment_type.TEXT) # 挂一段 JSON 字符串 import json response_body json.dumps({code: 200, data: {id: 123}}, ensure_asciiFalse, indent2) allure.attach(response_body, name接口响应, attachment_typeallure.attachment_type.JSON) # 挂一张图片二进制流 image_bytes open(screenshot.png, rb).read() allure.attach(image_bytes, name失败现场截图, attachment_typeallure.attachment_type.PNG) # 从文件挂载和直接传 bytes 效果等价 allure.attach.file(screenshot.png, name页面截图, attachment_typeallure.attachment_type.PNG)这里有几个容易混淆的参数我需要重点解释一下attachment_type决定 allure 如何渲染这个附件。你传JSON类型报告里就能格式化折叠展示传TEXT类型就是普通文本传PNG类型就会以图片形式展示。选错类型会导致显示异常比如把图片声明成 TEXT报告里会是一堆乱码。extension是文件扩展名如果没传allure 会根据attachment_type自动补全。手动传扩展名通常用在保存文件时比如extensionlog。如果是 str 类型的 bodyallure 内部会按 UTF-8 编码如果是 bytes 类型就是原始字节。任何想传None的偷懒想法都会导致执行时报错。我平时会把 attach 的参数表贴在工位旁边方便写的时候快速查。各位可以直接抄走这个表方法适用场景推荐类型allure.attach(body, name..., attachment_type...)内存中的数据如接口响应、日志文本、截图二进制TEXT / JSON / PNGallure.attach.file(source, name..., attachment_type...)已落盘的文件如导出的 CSV、日志文件、截图文件CSV / TEXT / PNGallure.attach(body, attachment_typeallure.attachment_type.HTML)HTML 页面源代码或自定义 HTML 片段HTMLallure.attach(body, attachment_typeallure.attachment_type.XML)XML 报文、配置内容XML2. 把错误变成证据截图、日志、响应体一次到位2.1 失败时自动截图并挂到用例上自动化测试里最刚需的 attach 场景就是把 UI 自动化失败时的页面截图挂到报告里。很多人写截图逻辑时喜欢在except里判失败再截图其实不优雅因为你可能漏掉某些异常分支。更稳妥的做法是在 pytest 的 fixture 或 hook 里统一处理。我在 PO 模式下比较常用的一个做法是在BasePage里把截图操作封装成一个公共方法import allure from datetime import datetime class BasePage: def __init__(self, driver): self.driver driver def attach_screenshot(self, name页面截图): timestamp datetime.now().strftime(%Y%m%d_%H%M%S) png self.driver.get_screenshot_as_png() allure.attach( png, namef{name}_{timestamp}.png, attachment_typeallure.attachment_type.PNG )这样在步骤里只需要调用page.attach_screenshot()就能把当前屏幕状态固化到报告里。但要注意不是每一个操作步骤都需要截图。如果每个点击都截图报告立刻变成截图堆加载速度几何级下降到最后根本没人愿意打开看。我只建议在关键节点截图比如登录后首页、下单成功页、异常弹窗出现时。2.2 保存接口请求与响应调试像翻监控记录接口自动化或 UI 自动化的底层接口调用如果不把请求体和响应体 attach 出来接口有问题时你在报告里看到的只是一个红叉完全不知道为什么。我以前吃过亏服务端返回 500报告里只有断言失败的提示然后要登录服务器翻日志来回折腾半小时。后来统一封装了请求日志收集函数import json import allure def attach_api_detail(method, url, request_dataNone, responseNone): summary { method: method, url: url, request: request_data, response_code: getattr(response, status_code, None), response_body: response.text if response is not None else None } allure.attach( json.dumps(summary, ensure_asciiFalse, indent2), namef接口明细 {method} {url}, attachment_typeallure.attachment_type.JSON )调用的时候在 requests 或 httpx 的外层封装里加一行即可。尤其要注意的是JSON 字符串如果中文多记得ensure_asciiFalse再 indent2否则报告里有人工编码的中文转义开发看起来想砸电脑。2.3 附加执行日志与系统信息除了截图和接口数据执行环境的日志同样值得挂到报告里。比如用例跑挂时你往往需要知道运行的是哪台机器、浏览器版本、当前分辨率、后端环境地址等。这些信息塞到 name 或日志附件里比单看异常堆栈更有价值。我常用的一个方案是把日志收集到一个 StringIO 缓冲区最后统一 attach 成一个文本附件import io import logging import allure log_stream io.StringIO() handler logging.StreamHandler(log_stream) logger logging.getLogger(auto_test) logger.addHandler(handler) logger.setLevel(logging.DEBUG) # ... 测试过程中 logger.info(...) 会自动写入 log_stream def attach_runtime_log(): log_content log_stream.getvalue() if log_content: allure.attach( log_content, name运行日志, attachment_typeallure.attachment_type.TEXT, extension.log )注意这个 handler 要确保测试用例结束后再调用attach_runtime_log()不然日志还没 flush 完就 attach内容会缺尾巴。用getvalue()而不是先read()是因为 stream 的位置指针可能导致读取不到内容。2.4 把性能指标和原始数据也塞进去如果你的自动化里做了性能采样比如记录接口响应耗时、数据库查询耗时那么在 allure 报告里 attach 一条 JSON 或 CSV 数据也是很好的习惯。这里我用 CSV 举例子因为很多团队习惯用 Excel 打开看连续数据import csv import io import allure def attach_metrics_csv(metrics_list): output io.StringIO() writer csv.writer(output) writer.writerow([时间, 接口名, 耗时ms, 是否成功]) for m in metrics_list: writer.writerow([m[time], m[api], m[cost_ms], m[success]]) allure.attach( output.getvalue(), name性能指标统计, attachment_typeallure.attachment_type.CSV, extension.csv )这个东西看似简单实际用起来很香。有一次生产环境偶发慢请求开发怎么都复现不了我把连续三次回归测试里的接口耗时 CSV 贴到缺陷单里那个 request 耗时曲线一目了然。3. 在 pytest PO 框架里把它用出花来3.1 钩子函数里的“自动挂载”pytest 的钩子函数是 allure.attach() 的最佳落点之一。你可以在pytest_runtest_makereport这个 hook 里判断用例失败或成功然后自动执行截图、日志等 attach 逻辑。好处是用例代码里不需要写任何 attach 相关代码用例保持干净故障处理集中管理。我推荐的一个基础模板是这样的import allure import pytest from selenium import webdriver 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) if driver is not None: try: allure.attach( driver.get_screenshot_as_png(), name失败截图, attachment_typeallure.attachment_type.PNG ) allure.attach( driver.page_source, name页面HTML源码, attachment_typeallure.attachment_type.HTML ) except Exception: pass # 页面可能已经崩溃或不可交互这里有个关键点item.funcargs里能取到 fixture 的返回值但前提是 fixture 已经在用例执行过程中被初始化。如果你的 driver fixture 是 session 级别取起来也很方便。但如果你是在yield之后才拿 driver要注意 driver 可能已经被关闭。我在项目里通常让 driver fixture 先抛出异常等call阶段的report生成后再重点判断失败场景。3.2 PO 模式中 attach 的放置位置在 PO 模式Page Object页面对象模式里我建议把 attach 能力放到每个 Page 对象的基类里而不是直接在每个页面写重复的截图代码。原因是 PO 本身就是要消灭重复页面操作里的截图行为本质上是通用动作。我习惯在BasePage里增加两个方法一个是attach_log一个是attach_screenshot。同时在一些重要的业务断言区域偷拍关键页面快照。例如在订单提交成功页面时我甚至会把整个页面的关键元素状态整理成 JSON 附加上去class OrderPage(BasePage): def attach_order_info(self): order_info { 订单号: self.order_no.text, 金额: self.amount.text, 状态: self.status.text } allure.attach( json.dumps(order_info, ensure_asciiFalse, indent2), name订单提交结果, attachment_typeallure.attachment_type.JSON )这比单纯贴截图更结构化后续做数据比对、统计也能直接从报告里复制文本不需要对着图片 OCR。3.3 文件形式的附件attach.file 的使用场景有一种常见误区一提到附件就只往内存里塞字符串。其实 allure.attach.file() 在真实项目里也很实用尤其是处理那些本来就会自动落盘的文件。比如你做了 PDF 下载验证或者导出了 Excel/CSV 数据你可以在断言文件存在后直接把文件挂到报告上import allure def test_download_file(tmp_path): # 假设下载逻辑已经得到 output_path output_path tmp_path / export.csv # 断言下载成功并把文件 attach 到报告 assert output_path.exists() allure.attach.file( str(output_path), name导出的CSV文件, attachment_typeallure.attachment_type.CSV, extension.csv )这样查看报告的人不需要回到测试机上去翻工作目录直接从报告里下载一份原始文件。我见过有团队连服务端的 response 文件都用这种方式贴非常方便。在使用attach.file时要注意如果文件非常大也不建议直接贴原始文件最好先压缩成 zip 再挂。报告服务器磁盘空间和浏览器的加载压力都要考虑。3.4 不要陷入“乱挂载”的误区我知道看到这里你可能想“那我每个用例都多 attach 点东西越多越好”。千万别。attach 的本质是补充证据链不是刷存在感。一个用例挂 5 个以上附件报告会变得特别臃肿有时候 Allure 报告的加载速度会慢到让同事直接放弃打开。我自己经历过的惨痛教训是某次把每个接口请求的完整密文 body 都 attach 出去了那个报告文件体积直接翻了十几倍最后在 CI 上不仅生成报告慢而且浏览器打开要卡几十秒。后来我们定了个规矩默认只挂失败现场和关键节点证据完整流水靠日志自行按需拉取。所以建议你在设计 attach 策略时先问自己三个问题这个附件对排查有没有直接帮助它对当前用例是不是唯一性数据如果不下钻别人能不能看懂三个问题都想清楚再动手写。4. 常见问题与排查技巧实录4.1 报告里明明调用了 attach却看不到内容这类问题在所有 allure 使用者里遇到率极高。最常见原因是你把相同名字的附件重复挂载了多次导致 allure 在展示时只保留了最后一次或内容被分散到不同步骤节点里。更隐蔽的原因是如果 attach 发生在某个with allure.step代码块之外那它会被挂到整个用例上但报告默认可能收合到一级节点有些人不知道点开用例详情。我的排查顺序一般是看allure-results目录下是否生成了对应*.attachments文件。如果文件还在但报告里没有说明展示层出了问题重新生成报告或使用allure generate --clean清空历史数据。看 attach 的代码有没有执行。可以在 attach 前加个print确认执行顺序避免因为异常提前退出。检查是否在teardown之后调用。如果 driver 已经 quit你再用 driver 截图自然会报错而且这个报错会吞掉原本要 attach 的内容。4.2 报告体积爆炸附件超过了正常范围这个问题我把原因分成两类一类是策略问题一类是技术问题。策略上就是前面说的挂载太积极。技术上可能是你 attach 原始大图或超大日志没限制大小。我现在的项目里有一个约定俗成的做法截图先压缩再挂载。举个例子直接在内存里用 Pillow 压缩from io import BytesIO from PIL import Image import allure def attach_compressed_screenshot(driver, name失败截图, max_width1200): png_data driver.get_screenshot_as_png() image Image.open(BytesIO(png_data)) if image.width max_width: scale max_width / image.width image image.resize((max_width, int(image.height * scale))) buffer BytesIO() image.save(buffer, formatJPEG, quality70) allure.attach( buffer.getvalue(), namename, attachment_typeallure.attachment_type.JPEG, extension.jpg )这样一张 3MB 的截图能压到 200KB 左右报告大小立竿见影地降下来。压成 JPEG 可能牺牲一点画质但对定位问题够用了。4.3 中文乱码或显示成 ASCII 转义这通常是因为没有在json.dumps里设置ensure_asciiFalse。另外如果你 attach 的是日志文本请一定使用attachment_typeTEXT而不是默认类型。默认类型在某些情况下会被判定为other或blob渲染时可能乱码。防止乱码的兜底办法allure.attach( content_text.encode(utf-8), name中文内容, attachment_typeallure.attachment_type.TEXT, extension.txt )把字符串编码成 bytes 再传让 allure 按原始字节展示能避开很多隐式转码问题。4.4 HTML 附件预览被浏览器安全策略限制当你 attach 一个 HTML 类型的附件本来是想让同事在报告里直接看到可交互的页面快照或自定义报表。但 Allure 的 HTML 附件是通过 iframe 渲染的有些浏览器或安全策略下iframe 会拒绝加载包含脚本或特定外部资源的页面看起来是一片空白。解决方法有三个方向尽量在 attach 前对 HTML 做“净化”去掉外链脚本和跨域资源。如果只是要看源码直接使用 TEXT 类型 attach让同事复制到编辑器查看。避免重复使用同一文件名否则 allure 的附件文件可能被覆盖。我在实际工作中用的是第二种居多。因为 UI 用例失败时真正的页面源码多数贴近原生与其强求一个不可交互的 HTML 快照不如直接给文本源码方便搜索关键词。4.5 attach 后执行 allure generate 没有更新报告很多人跑完pytest后直接执行allure generate allure-results -o allure-report然后就打开旧报告发现附件没出来。其实原因很简单默认情况下allure generate不会清空旧的allure-report目录旧附件和新附件混在一起有些文件因为重名直接覆盖。我最推荐的命令是这样allure generate allure-results -o allure-report --clean--clean会在生成前清空输出目录保证报告是从最新结果生成的。这条命令我已经写了无数次属于“避坑标配”。4.6 附件顺序和预期不一致如果你在一个测试用例里先 attach 了一张截图然后又 attach 一段日志最后报告展示顺序是乱的那大概率是 attach 调用本身跨越了多个allure.step节点。Allure 报告里的附件顺序严格遵循它所在步骤的执行顺序。如果你希望截图和日志一定挨着展示可以把它们包在同一个with allure.step(失败信息记录)块里with allure.step(失败信息记录): allure.attach(screenshot_png, name截图, attachment_typeallure.attachment_type.PNG) allure.attach(log_text, name日志, attachment_typeallure.attachment_type.TEXT)这样在报告里附件会稳定出现在同一步骤下不会跑到“外层用例”到处乱挂。这也是很多新人在体验报告时觉得“附件忽前忽后”的原因。5. 高级玩法把 attach 变成团队共识5.1 用动态名称区分同一用例的多轮截图有些用例本来就是循环执行多次操作这时候如果每次都叫页面截图报告里根本区分不开。我通常给附件命名加上业务标识或时间戳timestamp datetime.now().strftime(%H%M%S) allure.attach( image_bytes, namef第{i}轮投票后页面截图_{timestamp}, attachment_typeallure.attachment_type.PNG )命名规律一定要固定。比如我们用“动词对象状态”的格式点击下单后弹窗截图_143001.png、接口返回异常时的响应体_143002.json。这样同事扫一眼附件列表就知道发生了什么。5.2 在 pytest fixture 中统一收集测试上下文你可以用一个 fixture 统一收集用例名、用例描述、数据文件版本、是否有依赖服务等上下文最后统一 attach 成一份 JSON 或 Markdown 文本。比如pytest.fixture(autouseTrue) def attach_test_context(request): yield context { 用例名称: request.node.name, 模块: request.module.__name__, 测试环境: get_current_env(), 浏览器版本: get_browser_version(), 执行时间: datetime.now().isoformat(), } allure.attach( json.dumps(context, ensure_asciiFalse, indent2), name测试上下文, attachment_typeallure.attachment_type.JSON )这个上下文附件对于沉淀测试资产特别有价值。当团队复盘某个历史版本时可以直接从报告里找到当时的执行环境不用再去翻 CI 里的流水线参数。5.3 让团队通过附件模板形成“共同语言”如果你带团队或者负责测试平台我强烈建议在代码仓库里维护一个conftest.py或者allure_utils.py模块把常用的 attach 方法全部封装成函数并注释清楚使用场景。这样做的好处有两个新人不需要理解 allure API 细节只要调用attach_api_detail()或attach_screenshot()就能正确挂载。团队里所有报告长一个样子观察和排查效率自然提高不会出现一个人挂 JSON、另一个人贴截图拼接文本的情况。我在项目里封装的脚本核心就一个文件所有测试代码都从里面 import后续如果升级 attach 逻辑全团队同步改一处即可。5.4 关于“Allure 报告辅助决策”的一些个人看法最后再分享一个小技巧我习惯在冒烟回归跑完后根据 attach 的接口响应或系统指标 JSON直接在现场把报告投影出来让开发、产品、测试围在一起过一遍。这不是在讲“报告做得多漂亮”而是在讲“证据链是否完整”。附件里面包含的接口入参出参、页面状态、服务日志往往比任何口头描述都更有说服力。allure.attach() 用久了你会慢慢形成一种直觉看到一条用例失败脑子里第一反应应该是“这个失败需要哪些附件支撑才能让看的人快速下判断”。带着这个直觉去写代码那份自动化测试报告就不再只是测试结束后的装饰品而是真正能让团队一起复盘的“现场存档”。
Allure附件实战：用allure.attach()打造可追查的自动化测试报告
Allure 报告里最能看出一个自动化测试工程师功力的地方往往不是用例写得有多复杂而是给报告里塞的“证据”有多讲究。我自己维护过几个用 pytest PO 模式跑了几年的自动化项目越到后期越发现allure.attach() 这个看起来不起眼的方法才是让 allure 报告从“能看”变成“能查、能追、能复盘”的关键。很多人刚开始接触 allure.attach() 只知道它能往报告里贴点东西实际用起来却容易踩坑要么报告里什么都没有要么图片乱码要么附件体积大得离谱。这篇文章把我这几年在自动化测试allure报告里使用 allure.attach() 的经验完整拆开讲从方法参数到底层逻辑从 pytest PO 框架整合到问题排查全部按可落地的思路写。看完你就能把截图、请求响应、日志、HTML快照这些“证据”全部挂进报告让团队在看报告的时候不需要反复问你是怎么回事。1. 理解 allure.attach()它到底挂在哪个环节1.1 一个自带“证据链”的报告才是好报告你可以把 allure 报告想象成测试用例的“结案卷宗”。用例执行过程是流水账而报告是给所有人看的最终档案。一份只有“PASS/FAIL” 几行日志的报告就像一份没有证物清单的结案报告别人只能看到结论完全不知道过程发生了什么。allure.attach() 就是往卷宗里塞证物的一套接口它负责把测试过程中产生的各种文件、文本、图片、JSON、HTML 等资源挂载到测试用例或测试步骤上。我见过很多团队失败用例全靠开发自己复现效率低得离谱。后来我们把接口返回、前端截图、数据库查询结果全部 attach 进报告开发排查问题时打开报告就像看监控回放一样直接通常几分钟就能定位。这个转变的核心就一句话把“能证明现场”的数据主动放进报告里而不是等人来问的时候再去翻日志。1.2 两个常用变体attach 与 attach.fileallure 库给我们的核心方法是allure.attach()但它其实有两条路可以走allure.attach(body, name, attachment_type, extension)直接传入内存中的字符串或二进制内容。allure.attach.file(source, name, attachment_type, extension)传入一个本地文件路径方法会读取文件内容并挂到报告里。下面是一个最基础的调用示例import allure # 挂一段纯文本 allure.attach(这里是测试输出的日志内容, name执行日志, attachment_typeallure.attachment_type.TEXT) # 挂一段 JSON 字符串 import json response_body json.dumps({code: 200, data: {id: 123}}, ensure_asciiFalse, indent2) allure.attach(response_body, name接口响应, attachment_typeallure.attachment_type.JSON) # 挂一张图片二进制流 image_bytes open(screenshot.png, rb).read() allure.attach(image_bytes, name失败现场截图, attachment_typeallure.attachment_type.PNG) # 从文件挂载和直接传 bytes 效果等价 allure.attach.file(screenshot.png, name页面截图, attachment_typeallure.attachment_type.PNG)这里有几个容易混淆的参数我需要重点解释一下attachment_type决定 allure 如何渲染这个附件。你传JSON类型报告里就能格式化折叠展示传TEXT类型就是普通文本传PNG类型就会以图片形式展示。选错类型会导致显示异常比如把图片声明成 TEXT报告里会是一堆乱码。extension是文件扩展名如果没传allure 会根据attachment_type自动补全。手动传扩展名通常用在保存文件时比如extensionlog。如果是 str 类型的 bodyallure 内部会按 UTF-8 编码如果是 bytes 类型就是原始字节。任何想传None的偷懒想法都会导致执行时报错。我平时会把 attach 的参数表贴在工位旁边方便写的时候快速查。各位可以直接抄走这个表方法适用场景推荐类型allure.attach(body, name..., attachment_type...)内存中的数据如接口响应、日志文本、截图二进制TEXT / JSON / PNGallure.attach.file(source, name..., attachment_type...)已落盘的文件如导出的 CSV、日志文件、截图文件CSV / TEXT / PNGallure.attach(body, attachment_typeallure.attachment_type.HTML)HTML 页面源代码或自定义 HTML 片段HTMLallure.attach(body, attachment_typeallure.attachment_type.XML)XML 报文、配置内容XML2. 把错误变成证据截图、日志、响应体一次到位2.1 失败时自动截图并挂到用例上自动化测试里最刚需的 attach 场景就是把 UI 自动化失败时的页面截图挂到报告里。很多人写截图逻辑时喜欢在except里判失败再截图其实不优雅因为你可能漏掉某些异常分支。更稳妥的做法是在 pytest 的 fixture 或 hook 里统一处理。我在 PO 模式下比较常用的一个做法是在BasePage里把截图操作封装成一个公共方法import allure from datetime import datetime class BasePage: def __init__(self, driver): self.driver driver def attach_screenshot(self, name页面截图): timestamp datetime.now().strftime(%Y%m%d_%H%M%S) png self.driver.get_screenshot_as_png() allure.attach( png, namef{name}_{timestamp}.png, attachment_typeallure.attachment_type.PNG )这样在步骤里只需要调用page.attach_screenshot()就能把当前屏幕状态固化到报告里。但要注意不是每一个操作步骤都需要截图。如果每个点击都截图报告立刻变成截图堆加载速度几何级下降到最后根本没人愿意打开看。我只建议在关键节点截图比如登录后首页、下单成功页、异常弹窗出现时。2.2 保存接口请求与响应调试像翻监控记录接口自动化或 UI 自动化的底层接口调用如果不把请求体和响应体 attach 出来接口有问题时你在报告里看到的只是一个红叉完全不知道为什么。我以前吃过亏服务端返回 500报告里只有断言失败的提示然后要登录服务器翻日志来回折腾半小时。后来统一封装了请求日志收集函数import json import allure def attach_api_detail(method, url, request_dataNone, responseNone): summary { method: method, url: url, request: request_data, response_code: getattr(response, status_code, None), response_body: response.text if response is not None else None } allure.attach( json.dumps(summary, ensure_asciiFalse, indent2), namef接口明细 {method} {url}, attachment_typeallure.attachment_type.JSON )调用的时候在 requests 或 httpx 的外层封装里加一行即可。尤其要注意的是JSON 字符串如果中文多记得ensure_asciiFalse再 indent2否则报告里有人工编码的中文转义开发看起来想砸电脑。2.3 附加执行日志与系统信息除了截图和接口数据执行环境的日志同样值得挂到报告里。比如用例跑挂时你往往需要知道运行的是哪台机器、浏览器版本、当前分辨率、后端环境地址等。这些信息塞到 name 或日志附件里比单看异常堆栈更有价值。我常用的一个方案是把日志收集到一个 StringIO 缓冲区最后统一 attach 成一个文本附件import io import logging import allure log_stream io.StringIO() handler logging.StreamHandler(log_stream) logger logging.getLogger(auto_test) logger.addHandler(handler) logger.setLevel(logging.DEBUG) # ... 测试过程中 logger.info(...) 会自动写入 log_stream def attach_runtime_log(): log_content log_stream.getvalue() if log_content: allure.attach( log_content, name运行日志, attachment_typeallure.attachment_type.TEXT, extension.log )注意这个 handler 要确保测试用例结束后再调用attach_runtime_log()不然日志还没 flush 完就 attach内容会缺尾巴。用getvalue()而不是先read()是因为 stream 的位置指针可能导致读取不到内容。2.4 把性能指标和原始数据也塞进去如果你的自动化里做了性能采样比如记录接口响应耗时、数据库查询耗时那么在 allure 报告里 attach 一条 JSON 或 CSV 数据也是很好的习惯。这里我用 CSV 举例子因为很多团队习惯用 Excel 打开看连续数据import csv import io import allure def attach_metrics_csv(metrics_list): output io.StringIO() writer csv.writer(output) writer.writerow([时间, 接口名, 耗时ms, 是否成功]) for m in metrics_list: writer.writerow([m[time], m[api], m[cost_ms], m[success]]) allure.attach( output.getvalue(), name性能指标统计, attachment_typeallure.attachment_type.CSV, extension.csv )这个东西看似简单实际用起来很香。有一次生产环境偶发慢请求开发怎么都复现不了我把连续三次回归测试里的接口耗时 CSV 贴到缺陷单里那个 request 耗时曲线一目了然。3. 在 pytest PO 框架里把它用出花来3.1 钩子函数里的“自动挂载”pytest 的钩子函数是 allure.attach() 的最佳落点之一。你可以在pytest_runtest_makereport这个 hook 里判断用例失败或成功然后自动执行截图、日志等 attach 逻辑。好处是用例代码里不需要写任何 attach 相关代码用例保持干净故障处理集中管理。我推荐的一个基础模板是这样的import allure import pytest from selenium import webdriver 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) if driver is not None: try: allure.attach( driver.get_screenshot_as_png(), name失败截图, attachment_typeallure.attachment_type.PNG ) allure.attach( driver.page_source, name页面HTML源码, attachment_typeallure.attachment_type.HTML ) except Exception: pass # 页面可能已经崩溃或不可交互这里有个关键点item.funcargs里能取到 fixture 的返回值但前提是 fixture 已经在用例执行过程中被初始化。如果你的 driver fixture 是 session 级别取起来也很方便。但如果你是在yield之后才拿 driver要注意 driver 可能已经被关闭。我在项目里通常让 driver fixture 先抛出异常等call阶段的report生成后再重点判断失败场景。3.2 PO 模式中 attach 的放置位置在 PO 模式Page Object页面对象模式里我建议把 attach 能力放到每个 Page 对象的基类里而不是直接在每个页面写重复的截图代码。原因是 PO 本身就是要消灭重复页面操作里的截图行为本质上是通用动作。我习惯在BasePage里增加两个方法一个是attach_log一个是attach_screenshot。同时在一些重要的业务断言区域偷拍关键页面快照。例如在订单提交成功页面时我甚至会把整个页面的关键元素状态整理成 JSON 附加上去class OrderPage(BasePage): def attach_order_info(self): order_info { 订单号: self.order_no.text, 金额: self.amount.text, 状态: self.status.text } allure.attach( json.dumps(order_info, ensure_asciiFalse, indent2), name订单提交结果, attachment_typeallure.attachment_type.JSON )这比单纯贴截图更结构化后续做数据比对、统计也能直接从报告里复制文本不需要对着图片 OCR。3.3 文件形式的附件attach.file 的使用场景有一种常见误区一提到附件就只往内存里塞字符串。其实 allure.attach.file() 在真实项目里也很实用尤其是处理那些本来就会自动落盘的文件。比如你做了 PDF 下载验证或者导出了 Excel/CSV 数据你可以在断言文件存在后直接把文件挂到报告上import allure def test_download_file(tmp_path): # 假设下载逻辑已经得到 output_path output_path tmp_path / export.csv # 断言下载成功并把文件 attach 到报告 assert output_path.exists() allure.attach.file( str(output_path), name导出的CSV文件, attachment_typeallure.attachment_type.CSV, extension.csv )这样查看报告的人不需要回到测试机上去翻工作目录直接从报告里下载一份原始文件。我见过有团队连服务端的 response 文件都用这种方式贴非常方便。在使用attach.file时要注意如果文件非常大也不建议直接贴原始文件最好先压缩成 zip 再挂。报告服务器磁盘空间和浏览器的加载压力都要考虑。3.4 不要陷入“乱挂载”的误区我知道看到这里你可能想“那我每个用例都多 attach 点东西越多越好”。千万别。attach 的本质是补充证据链不是刷存在感。一个用例挂 5 个以上附件报告会变得特别臃肿有时候 Allure 报告的加载速度会慢到让同事直接放弃打开。我自己经历过的惨痛教训是某次把每个接口请求的完整密文 body 都 attach 出去了那个报告文件体积直接翻了十几倍最后在 CI 上不仅生成报告慢而且浏览器打开要卡几十秒。后来我们定了个规矩默认只挂失败现场和关键节点证据完整流水靠日志自行按需拉取。所以建议你在设计 attach 策略时先问自己三个问题这个附件对排查有没有直接帮助它对当前用例是不是唯一性数据如果不下钻别人能不能看懂三个问题都想清楚再动手写。4. 常见问题与排查技巧实录4.1 报告里明明调用了 attach却看不到内容这类问题在所有 allure 使用者里遇到率极高。最常见原因是你把相同名字的附件重复挂载了多次导致 allure 在展示时只保留了最后一次或内容被分散到不同步骤节点里。更隐蔽的原因是如果 attach 发生在某个with allure.step代码块之外那它会被挂到整个用例上但报告默认可能收合到一级节点有些人不知道点开用例详情。我的排查顺序一般是看allure-results目录下是否生成了对应*.attachments文件。如果文件还在但报告里没有说明展示层出了问题重新生成报告或使用allure generate --clean清空历史数据。看 attach 的代码有没有执行。可以在 attach 前加个print确认执行顺序避免因为异常提前退出。检查是否在teardown之后调用。如果 driver 已经 quit你再用 driver 截图自然会报错而且这个报错会吞掉原本要 attach 的内容。4.2 报告体积爆炸附件超过了正常范围这个问题我把原因分成两类一类是策略问题一类是技术问题。策略上就是前面说的挂载太积极。技术上可能是你 attach 原始大图或超大日志没限制大小。我现在的项目里有一个约定俗成的做法截图先压缩再挂载。举个例子直接在内存里用 Pillow 压缩from io import BytesIO from PIL import Image import allure def attach_compressed_screenshot(driver, name失败截图, max_width1200): png_data driver.get_screenshot_as_png() image Image.open(BytesIO(png_data)) if image.width max_width: scale max_width / image.width image image.resize((max_width, int(image.height * scale))) buffer BytesIO() image.save(buffer, formatJPEG, quality70) allure.attach( buffer.getvalue(), namename, attachment_typeallure.attachment_type.JPEG, extension.jpg )这样一张 3MB 的截图能压到 200KB 左右报告大小立竿见影地降下来。压成 JPEG 可能牺牲一点画质但对定位问题够用了。4.3 中文乱码或显示成 ASCII 转义这通常是因为没有在json.dumps里设置ensure_asciiFalse。另外如果你 attach 的是日志文本请一定使用attachment_typeTEXT而不是默认类型。默认类型在某些情况下会被判定为other或blob渲染时可能乱码。防止乱码的兜底办法allure.attach( content_text.encode(utf-8), name中文内容, attachment_typeallure.attachment_type.TEXT, extension.txt )把字符串编码成 bytes 再传让 allure 按原始字节展示能避开很多隐式转码问题。4.4 HTML 附件预览被浏览器安全策略限制当你 attach 一个 HTML 类型的附件本来是想让同事在报告里直接看到可交互的页面快照或自定义报表。但 Allure 的 HTML 附件是通过 iframe 渲染的有些浏览器或安全策略下iframe 会拒绝加载包含脚本或特定外部资源的页面看起来是一片空白。解决方法有三个方向尽量在 attach 前对 HTML 做“净化”去掉外链脚本和跨域资源。如果只是要看源码直接使用 TEXT 类型 attach让同事复制到编辑器查看。避免重复使用同一文件名否则 allure 的附件文件可能被覆盖。我在实际工作中用的是第二种居多。因为 UI 用例失败时真正的页面源码多数贴近原生与其强求一个不可交互的 HTML 快照不如直接给文本源码方便搜索关键词。4.5 attach 后执行 allure generate 没有更新报告很多人跑完pytest后直接执行allure generate allure-results -o allure-report然后就打开旧报告发现附件没出来。其实原因很简单默认情况下allure generate不会清空旧的allure-report目录旧附件和新附件混在一起有些文件因为重名直接覆盖。我最推荐的命令是这样allure generate allure-results -o allure-report --clean--clean会在生成前清空输出目录保证报告是从最新结果生成的。这条命令我已经写了无数次属于“避坑标配”。4.6 附件顺序和预期不一致如果你在一个测试用例里先 attach 了一张截图然后又 attach 一段日志最后报告展示顺序是乱的那大概率是 attach 调用本身跨越了多个allure.step节点。Allure 报告里的附件顺序严格遵循它所在步骤的执行顺序。如果你希望截图和日志一定挨着展示可以把它们包在同一个with allure.step(失败信息记录)块里with allure.step(失败信息记录): allure.attach(screenshot_png, name截图, attachment_typeallure.attachment_type.PNG) allure.attach(log_text, name日志, attachment_typeallure.attachment_type.TEXT)这样在报告里附件会稳定出现在同一步骤下不会跑到“外层用例”到处乱挂。这也是很多新人在体验报告时觉得“附件忽前忽后”的原因。5. 高级玩法把 attach 变成团队共识5.1 用动态名称区分同一用例的多轮截图有些用例本来就是循环执行多次操作这时候如果每次都叫页面截图报告里根本区分不开。我通常给附件命名加上业务标识或时间戳timestamp datetime.now().strftime(%H%M%S) allure.attach( image_bytes, namef第{i}轮投票后页面截图_{timestamp}, attachment_typeallure.attachment_type.PNG )命名规律一定要固定。比如我们用“动词对象状态”的格式点击下单后弹窗截图_143001.png、接口返回异常时的响应体_143002.json。这样同事扫一眼附件列表就知道发生了什么。5.2 在 pytest fixture 中统一收集测试上下文你可以用一个 fixture 统一收集用例名、用例描述、数据文件版本、是否有依赖服务等上下文最后统一 attach 成一份 JSON 或 Markdown 文本。比如pytest.fixture(autouseTrue) def attach_test_context(request): yield context { 用例名称: request.node.name, 模块: request.module.__name__, 测试环境: get_current_env(), 浏览器版本: get_browser_version(), 执行时间: datetime.now().isoformat(), } allure.attach( json.dumps(context, ensure_asciiFalse, indent2), name测试上下文, attachment_typeallure.attachment_type.JSON )这个上下文附件对于沉淀测试资产特别有价值。当团队复盘某个历史版本时可以直接从报告里找到当时的执行环境不用再去翻 CI 里的流水线参数。5.3 让团队通过附件模板形成“共同语言”如果你带团队或者负责测试平台我强烈建议在代码仓库里维护一个conftest.py或者allure_utils.py模块把常用的 attach 方法全部封装成函数并注释清楚使用场景。这样做的好处有两个新人不需要理解 allure API 细节只要调用attach_api_detail()或attach_screenshot()就能正确挂载。团队里所有报告长一个样子观察和排查效率自然提高不会出现一个人挂 JSON、另一个人贴截图拼接文本的情况。我在项目里封装的脚本核心就一个文件所有测试代码都从里面 import后续如果升级 attach 逻辑全团队同步改一处即可。5.4 关于“Allure 报告辅助决策”的一些个人看法最后再分享一个小技巧我习惯在冒烟回归跑完后根据 attach 的接口响应或系统指标 JSON直接在现场把报告投影出来让开发、产品、测试围在一起过一遍。这不是在讲“报告做得多漂亮”而是在讲“证据链是否完整”。附件里面包含的接口入参出参、页面状态、服务日志往往比任何口头描述都更有说服力。allure.attach() 用久了你会慢慢形成一种直觉看到一条用例失败脑子里第一反应应该是“这个失败需要哪些附件支撑才能让看的人快速下判断”。带着这个直觉去写代码那份自动化测试报告就不再只是测试结束后的装饰品而是真正能让团队一起复盘的“现场存档”。
