1. 为什么测试报告一定要用插件生成先抛出我做了这么多年测试开发的核心观点测试报告不是写给机器看的是写给明天早上的你看的也是写给不知道你代码里埋了什么坑的下一个人看的。你可以靠终端里的绿色点和F红色堆出一份“结果”但那只能回答“过了没有”这一个问题。等真正要排查问题、向团队同步进度、或者回溯三天前那批用例到底为什么失败的时候你就知道一份结构清晰、能留存、能展示细节的HTML测试报告有多重要了。pytest本身不提供报告生成能力它只管收集测试用例、执行断言、输出结果。而pytest-html就是专门补齐“报告”这一环的插件它会收集pytest运行过程中的所有结果数据包括用例名、模块路径、执行时间、状态、错误堆栈、预期与实际值然后渲染成一个独立的HTML页面。你不需要手动拼接字符串不需要写模板引擎一条命令行参数就能在测试结束后得到一份能直接发给别人看的报告。这篇博文面向的读者有两类一类是刚把pytest跑通、正在被“报告怎么展示”困扰的测试新手另一类是已经在用pytest做接口自动化或UI自动化但对pytest-html的配置项、定制能力、CI集成还不太清楚的从业者。两类读者都能在这篇里找到可以直接抄走的东西。pytest-html插件值得花一整篇文章来讲是因为它表面看起来简单——装插件、加参数、出报告三步走完——但实际用起来从环境配置到报告定制再到持续集成里的路径处理每个环节都有值得注意的细节。我接下来会把我在实操中踩过的坑、验证过的参数、改过的模板代码全部展开讲。2. 安装与快速生成第一份报告2.1 安装插件并验证环境安装pytest-html非常简单它已经发布在PyPI上直接用pip安装即可。我建议在安装前先确认你的Python环境和pytest版本避免插件和框架版本不兼容导致的诡异问题。pip install pytest-html如果你用的是Pipenv或Poetry管理依赖记得把pytest-html加到dev依赖组中。装完之后可以用下面的命令验证插件是否被pytest正确加载pytest --version正常情况下输出中会出现pytest-html的版本号比如pytest 8.0.2 pytest-html 4.1.1如果没有显示pytest-html的版本号说明插件没有装到当前pytest所处的Python环境中。这种情况最常见的诱因是你同时装了多个Python版本或者Pip安装到了系统环境而pytest运行在虚拟环境中。处理办法是重启终端激活正确的虚拟环境再重新执行安装。提示在Windows上如果你同时有多个Python版本建议使用python -m pip install pytest-html而不是裸的pip install因为前者会明确安装到当前python命令对应的环境。2.2 三步生成第一份HTML报告假设你已经有一份可运行的pytest测试用例。最简单的情况是这样的def test_addition(): assert 1 1 2 def test_string_contains(): assert hello in hello world把这些用例保存为test_demo.py然后在命令行执行pytest test_demo.py --htmlreport.html运行结束后工作目录下会出现一个report.html。用浏览器打开它你会看到页面上方有Summary区域总用例数、通过数、失败数、耗时、运行时间等信息一目了然。下面是完整的测试用例列表每个用例都标注了模块路径、测试函数名、执行耗时和结果状态。这就是pytest-html最基础也最核心的使用方式。但请注意默认生成的HTML文件在展示上有一个很大的问题它引用了外部CSS和JS文件也就是pytest-html在生成时会同时输出一个report.html和一个assets目录。如果你的报告只在本地打开这没什么影响但如果你想把这个HTML文件直接发给别人或者上传到CI服务器的Artifact中那HTML文件会因为找不到同级的assets目录而样式全丢。解决这个问题的方法非常直接加一个参数pytest test_demo.py --htmlreport.html --self-contained-html--self-contained-html会把所有样式、脚本、数据都内联到单个HTML文件中生成的报告不管放到哪里打开样式都是完整的。从第一份报告开始我就建议你养成带这个参数的习惯。别问为什么问就是当年我在Jenkins上打开一个没有样式的报告白底黑字看了整整一下午。2.3 默认报告里有哪些关键信息在深入定制之前你先要搞清楚pytest-html默认生成的报告里到底有什么才知道哪些信息需要进一步加工。Summary概要用例总数、通过/失败/跳过数量、总耗时、测试开始与结束时间。Environment环境信息Python版本、平台信息、pytest版本、插件版本等。这些信息在排查“换了环境用例状态不一致”时非常有用。Results结果列表每条用例的模块名、测试名、耗时、状态。点开失败用例可以看到完整的traceback、断言错误的预期值与实际值。Additional Information附加信息如果你在测试代码中通过pytest_html的API注入了自定义信息会显示在这里。默认报告已经能完成80%的信息传递工作。但要注意它默认不会自动包含你项目的环境变量、浏览器版本、接口地址这类上下文信息这些需要你手动配置后面的章节会详细说。3. 用命令行参数和配置文件锁定报告生成方式3.1 常用命令行参数一览pytest-html提供了一组命令行参数覆盖了从输出路径到报告标题的常用配置。我把最常用、最值得记住的参数整理成了表格你可以直接保存下来参数作用示例--html路径指定HTML报告输出路径--htmlreports/report.html--self-contained-html生成自包含HTML文件不依赖外部资源--self-contained-html--report-title标题设置报告页面的标题--report-title接口自动化测试报告--max-assets数量限制报告中嵌入资源文件的最大数量默认0表示不限制--max-assets20--report-log路径导出pytest运行日志可用于后续离线生成报告--report-loglog.json这里重点说一下--report-log很多新手根本不知道这个参数的存在。它的作用是把本次测试运行的所有数据用例、结果、错误信息、环境信息导出成一个JSON文件。你可以在测试结束后完全离开测试环境在另一个进程里用pytest --htmlreport.html --report-loglog.json这样的方式从JSON离线重建HTML报告。这个功能在什么场景下很有用比如CI流水线跑完测试后你希望把原始数据留存下来后续随时能重新生成任意格式的报告又比如你的测试执行环境和报告渲染环境分离测试机只负责跑用例报告由专门的服务器去渲染。这些都是实战中的真实需求。3.2 在pytest.ini里固化配置每次执行命令都打一长串参数既容易漏也容易错。正确做法是把常用配置写进pytest.ini的addopts中。这样即使你在命令行只敲pytest报告也会按固定规则生成。[pytest] addopts -v --htmlreports/report.html --self-contained-html --report-title接口自动化测试报告 --maxfail5这里有个细节值得注意--html的路径是相对当前工作目录也就是执行pytest命令的目录来解析的不是相对pytest.ini所在目录。如果你在项目根目录执行pytest路径没问题但如果哪天你在子目录下执行pytest报告就会生成到意想不到的位置。为了避免这种情况我习惯用rootdir参数配合--html来写绝对路径[pytest] rootdir . addopts -v --html{rootdir}/reports/report.html{rootdir}是pytest 7.0之后的占位符号会自动替换为rootdir的绝对路径。有了这个不管你在哪个目录下执行pytest报告只会出现在项目根目录的reports文件夹里。注意--html指定的目录如果不存在pytest-html会自动创建不需要你提前mkdir。但如果父目录本身没有写权限比如CI沙箱环境还是会在运行时报PermissionError。3.3 报告文件名带时间戳的两种写法固定文件名report.html有一个隐患每次运行都会覆盖上一次的报告。如果你今天跑挂了10次你只留得下最后一次的记录。这在排查问题时很难受因为你往往需要对比“第一次失败”和“最后一次失败”的差异。最简单的解决方式是文件名带时间戳pytest的--html参数支持任何合法的文件路径你可以利用Python的命令行字符串拼接能力在shell层面动态生成带时间的文件名pytest --htmlreports/report_$(date %Y%m%d_%H%M%S).html --self-contained-html这在Linux/macOS下直接可用。Windows下用PowerShell则写成pytest --htmlreports/report_$(Get-Date -Format yyyyMMdd_HHmmss).html --self-contained-html如果你希望所有逻辑都收拢到pytest内部不依赖外部shell语法那可以在conftest.py里做一个小钩子。用pytest的pytest_sessionfinish钩子在测试会话结束时把固定文件名的报告复制一份带时间戳的存档。想省事的直接复制全局钩子代码这里不展开后面第5章讲定制时会带一段示例。4. 让报告能真正用于复盘高级配置和技巧4.1 给报告加上环境信息让问题可复现默认报告里的Environment区域只包含Python版本、平台、pytest版本这些基础信息。但你在做接口自动化或UI自动化时真正需要的是接口的BaseURL、浏览器类型和版本、测试环境标识、数据库连接串等和业务强相关的信息。pytest-html提供了一种非常简单的注入方式在conftest.py里定义pytest_configure钩子往metadata里塞键值对就行。# conftest.py def pytest_configure(config): config.metadata[项目名称] 电商平台接口自动化 config.metadata[测试环境] staging config.metadata[接口BaseURL] https://api.staging.example.com config.metadata[浏览器] Chrome 120.0 config.metadata[数据库] postgresql://user:passhost:5432/testdb这段代码会在每次pytest会话启动时执行把四个键值对写入报告的Environment区域。你打开生成的HTMLSummary下方就会出现一个带有这些信息的“Environment”表格。这样做的好处是你看到一份报告不用问任何人就知道它当时跑在哪个环境、用的什么浏览器。我在团队里推行这一习惯后测试同事之间互相看报告拷问环境信息的次数直接少了一半。另外pytest-html有一个自动移除特定环境变量的机制默认会删除所有以PASSWORD、SECRET、TOKEN结尾的环境变量避免敏感信息泄漏到报告中。这是官方刻意设计的为的是安全考虑。如果你确实有一个以TOKEN结尾的变量想显示在报告中你可以通过自定义钩子pytest_report_header或者pytest_html_results_table_header来覆盖默认行为。但我的建议是别覆盖保持默认密码密钥不应该出现在任何人能看到的报告里。4.2 自定义结果表格追加你自己的列默认的结果表格只有测试名、耗时、状态这几列对于接口自动化来说你大概率想把“接口路径”“请求方法”“响应码”这些信息直接展现出来这样表格看过去就非常直观。pytest-html提供了一套钩子来自定义表格的列pytest_html_results_table_header控制表头pytest_html_results_table_row控制单元格内容。# conftest.py import pytest def pytest_html_results_table_header(cells): cells.insert(1, th接口路径/th) cells.insert(2, th请求方法/th) def pytest_html_results_table_row(report, cells): # 假设你在用例里通过 report 的属性注入了接口信息 cells.insert(1, ftd{report.interface_path or }/td) cells.insert(2, ftd{report.request_method or }/td)插入列之后还需要在测试用例或夹具里动态追加属性。你可以在用例执行前定义一个钩子在用例结束时把数据挂到report对象上pytest.hookimpl(hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() report.interface_path getattr(item, interface_path, 未知) report.request_method getattr(item, request_method, 未知)这段代码会拦截每条用例的测试报告生成过程把item的interface_path和request_method属性拷贝到report对象中最终被前面的表格钩子读取、显示。有读者可能会问为什么不直接用item.funcargs来取值因为item.funcargs拿到的参数字典在部分场景下是延迟加载的强行读取可能取不到值或者读到已经被清理的数据。用getattr(item, ...)的方式配合你在夹具里为item动态设置属性是最可控的方案。4.3 失败用例自动截图UI自动化必备对于UI自动化测试来说光有堆栈信息还不够。接口挂了可以看断言对比前端页面挂了你得能看到当时的页面状态。pytest-html允许你在报告里以extra的形式插入截图显示在Additional Information区域。前提是你得先把截图逻辑写进夹具或用例。下面是Selenium场景下的标准写法import pytest from selenium import webdriver pytest.fixture def driver(): driver webdriver.Chrome() yield driver driver.quit() def test_login_page(driver): driver.get(https://example.com/login) # ... 测试逻辑 assert driver.title 登录页要往报告里加截图利用pytest_html模块的工具函数import pytest from py.xml import html def test_login_page(driver, extra): driver.get(https://example.com/login) try: assert driver.title 登录页 except AssertionError: screenshot driver.get_screenshot_as_base64() extra.append(pytest_html.extras.image_base64(screenshot, 登录页截图)) raisepytest_html.extras.image_base64()把base64编码的截图嵌入HTML报告不需要额外的图片文件报告仍然是单文件的。除了截图pytest_html.extras还提供了html()方法可以把任意HTML片段插入报告url()方法可以插入一个超链接。提示截图嵌入会导致单文件报告的体积显著变大。一张1080p的截图base64化之后通常有100~300KB如果失败用例很多报告可能膨胀到几十MB。对于CI场景建议定期清理历史报告或者把--max-assets设置为一个合理值限制内嵌资源数量。不过如果你用的是pytest-selenium插件情况会简单很多。pytest-selenium已经内置了失败时自动截图并插入HTML报告的逻辑无需自己写额外钩子。我仍然选择手动实现截图代码的原因是为了告诉大家底层原理。这块逻辑一旦你理解透了不管换到playwright还是appium都能很快写出对应的适配代码。4.4 用CSS定制报告外观多跑一步就专业一分pytest-html生成的报告默认样式是简洁的白色背景、黑色文本风格偏朴素。如果你需要交付给客户或管理层看或者想统一成公司品牌风格可以通过自定义CSS来覆盖。具体的做法是创建一个CSS文件然后在conftest.py里用pytest_html_report_title但这个是改标题的别混了和pytest_configure钩子把CSS路径告诉插件。# conftest.py def pytest_configure(config): config.option.htmlpath reports/report.html config.option.self_contained_html True # 引入自定义样式 config._html_style open(custom.css, encodingutf-8).read()custom.css内容示例body { font-family: Microsoft YaHei, sans-serif; } h1 { color: #2c3e50; } table { width: 100%; border-collapse: collapse; } th { background-color: #3498db; color: white; } tr.passed { background-color: #d4edda; } tr.failed { background-color: #f8d7da; }这个方案的原理是pytest-html在渲染HTML时会先读取config._html_style变量中的CSS内容把它内联到style标签中。你可以在任何阶段动态修改这个变量从而控制最终报告样式。说实话如果你只是给自己看默认样式完全够用了没必要折腾CSS。但如果你做的是商业项目交付多花十分钟定制一下颜色、字体、Logo整个报告的专业感会提升一大截。这个投入产出比是很划算的。5. 与持续集成结合CI环境下的常见做法5.1 在Jenkins中保留并展示报告Jenkins里最直接的做法是在“构建后操作”中添加“Publish HTML reports”插件把reports/report.html指定为要发布的HTML文件。需要注意两个关键项HTML目录要填写reports这个目录而不是直接指到report.html文件。Index page填report.html。如果你用的是--self-contained-html那单文件保存很容易如果你没用这个参数Jenkins发布时要确保assets文件夹也被一起归档否则页面样式会丢失。实际操作中我还会在构建命令里把--html路径加上CI工作空间前缀或使用时间戳目录避免并发构建互相覆盖pytest tests/ --html${WORKSPACE}/reports/report_${BUILD_NUMBER}.html --self-contained-html${WORKSPACE}是Jenkins内置的环境变量${BUILD_NUMBER}是构建号。这样每次构建都会生成独立的报告文件点开历史构建报告都在。5.2 在GitLab CI中生成并上传报告GitLab CI的官方做法是把HTML报告作为测试报告Artifact上传。在.gitlab-ci.yml里这样写test: script: - pytest tests/ --htmlreports/report.html --self-contained-html artifacts: paths: - reports/ when: always expire_in: 30 dayswhen: always保证即使测试失败构建产物中也能留存报告这个关键字很容易被忽略。默认的when: on_success会导致测试失败时不生成Artifact那等于报告白跑了。有些人会用GitLab的reports: junit来实现MR页面上直接展示测试用例状态这是另一套方案跟pytest-html不冲突。pytest-html负责出完整的网页报告junit格式负责在MR详情页展示用例级状态两个都配互不干扰。注意GitLab的artifacts: reports: junit要求文件必须是JUnit XML格式这个需要用--junitxmlreport.xml参数生成pytest-html不负责这个。5.3 离线生成报告的进阶用法前面提到--report-log参数可以导出JSON日志。这个功能在复杂CI流水线中非常实用你把测试执行和报告生成拆成两个独立的Job测试Job负责跑用例并产出一个巨大的JSON日志文件报告Job从JSON中读取数据、渲染HTML。好处是测试环境不需要装任何和报告渲染相关的额外依赖。如果报告模板需要升级只需重跑报告Job不需要重新执行测试。原始数据可以留存方便后续生成任意格式的衍生报表。生成离线报告的命令很简单pytest --report-logrun_log.json # 测试结束后任何时候都能执行 pytest --htmlreport.html --report-logrun_log.json但要注意pytest --htmlreport.html --report-logrun_log.json这条命令在执行时不会重新跑测试它会直接读取run_log.json的内容渲染HTML。如果你写成了pytest --report-logrun_log.json --htmlreport.html它会真的去执行测试。参数顺序不会影响这个行为真正影响行为的是你是否指定了测试路径和是否传了--report-log。最保险的离线生成方式是单独建一个目录放一份空的pytest.ini然后用pytest --htmlreport.html --report-logrun_log.json来执行不给它测试路径它自然就只会读json了。6. pytest-html与Allure如何取舍写到这里肯定有读者要问既然pytest-html这么方便为什么我身边很多人都在用AllureAllure确实很火功能也确实强大但它和pytest-html的定位是不同的。我把两者的核心差异整理成一张对照表维度pytest-htmlAllure安装复杂度一个pip包零额外依赖需要安装allure-pytest插件 独立的Allure命令行工具报告生成测试结束后自动生成一键完成测试时输出json结果需要用allure命令二次生成报告复杂度简洁清晰上手门槛低功能全面支持趋势图、分类统计、历史对比定制成本通过钩子和CSS轻量易改通过注解和插件机制功能多但学习成本高CI集成直接上传html文件即可需要额外配置allure命令和生成目录适合场景中小项目、个人项目、对时间敏感的项目大型平台、需要长期维护的测试中心、各种看板需求如果你问我怎么选我的建议是分阶段项目刚起步、团队规模小先用pytest-html一小时内就能看到完整报告等测试用例量涨到几千条需要统计历史趋势、做模块维度对比的时候再引入Allure也不迟。Allure的全量接入成本不只是安装一个命令行工具还包括团队学习注解语义、维护分类规则、在CI里多串一个命令。这不是说pytest-html就比Allure差。恰恰相反pytest-html的优势就是“快”和“轻”安装一个pip包、加一个参数、拿到一份自包含HTML整个过程在五分钟内完成不依赖任何Java运行环境。另外pytest-html的报告是完全可以被其他工具二次消费的。比如你有定时任务跑完测试要把汇总信息发到钉钉或企业微信可以用脚本解析--report-log导出的JSON再拼接各种通知格式。Allure的做法则是让你写扩展插件开发成本明显高。7. 常见问题与排查技巧实录7.1 问题速查表我把这几年来用pytest-html遇到的、以及帮别人排查过的典型问题汇总成了一个速查表建议直接收藏。问题现象可能原因解决方案报告打开后样式全是乱的使用了非自包含模式且html和assets目录分离用--self-contained-html参数重新生成报告中Environment为空未在conftest.py中配置pytest_configure钩子参考4.1节添加metadata配置报告里没有traceback详情测试用例在try/except中吞掉了异常改用pytest.raises断言或主动raise穿透网页打开report.html是空白的直接双击打开某些安全模式下的本地文件使用本地HTTP服务预览如python -m http.server生成的报告非常大嵌入了大量base64截图或长traceback限制截图数量使用--max-assets并发执行下报告互相覆盖多个worker写入同一个html路径每个worker使用独立的报告路径或只在0号worker写入pytest-html未生效插件未安装到当前python环境检查pytest --version输出中的插件列表7.2 我踩过的几个坑单独拎出来说坑一xdist并行执行时报告数据丢失。如果你用pytest-xdist开启了多进程并行默认情况下只有主进程的报告会写入htmlworker进程的数据不会自动汇总。你需要加一个参数--htmlreport.html --self-contained-html同时让pytest-xdist的--distloadscope和pytest-html协同工作。实际操作时我在pytest.ini里加的是addopts -n 4 --htmlreports/report.html --self-contained-htmlxdist插件会自动把worker的结果合并到主进程再渲染前提是你要使用pytest-xdist的2.0以上版本。如果版本太老合并会失败甚至不生效。坑二报告里显示的中文乱码。如果你在报告里注入了中文环境信息或自定义字段发现浏览器显示乱码大概率是Windows下编码问题。对策是在conftest.py顶部强制声明utf-8编码的读取方式并确保写入metadata的内容本身就是正常的Unicode字符串。注意当HTML文件里包含中文时自包含模式下的meta charsetutf-8是必须的pytest-html默认会带上除非你用了很老的版本。坑三用fixture的extra参数时报错。在很多旧教程中会看到在测试函数里给extra传值的写法。pytest-html从4.0开始extra已经不能通过函数参数直接注入了你需要使用pytest_html的item属性或者在conftest.py使用钩子来操作。常见做法是def test_example(request): extra getattr(request.node, extra, []) extra.append(pytest_html.extras.text(自定义文本)) request.node.extra extra因为request.node就是当前测试节点对象为它设置extra属性pytest_html在渲染时会读取。这是新版插件的标准姿势别再用fixture传参了。7.3 一个小技巧报告也分“简短版”和“详细版”我在团队里推过一个做法日常调试用简单报告只记录用例名、状态、耗时不记录traceback——因为调试时你自己就在IDE里堆栈你直接看控制台更快。而CI上跑的正式报告则包含完整traceback和环境信息。实现方式很暴力准备两份pytest.ini# pytest.ini默认 [pytest] addopts -v --htmlreports/report.html --self-contained-html --report-title详细版测试报告# pytest.quick.ini调试用 [pytest] addopts -v --htmlreports/quick_report.html --self-contained-html --tbno --report-title简短版测试报告执行调试时pytest -c pytest.quick.ini这样调试会话生成的报告非常小打开速度快看起来清爽正式CI流水线则引用默认的pytest.ini产出详细且可排查问题的报告。8. 扩展思路基于pytest-html的报告还能怎么玩pytest-html的钩子机制决定了它不是一个封闭的黑盒你可以基于它做很多二次开发。除了前面讲到的表格列定制、CSS样式修改、失败截图嵌入还有一些偏“野路子”但非常出效果的扩展玩法。比如在pytest_sessionfinish钩子里测试全部跑完之后动态读取config.metadata和结果统计用Python的smtplib把报告作为附件或正文发送到你的邮箱。我见过有团队直接把pytest-html的报告转成PDF存档配合定时任务形成完整的质量周报。这些都是十几行代码的事但当你落地之后整个团队的测试结果流转效率会明显提升。我自己做得最多的一件事是在pytest_sessionfinish时将时间戳版本的报告重命名并归档到以日期命名的目录中同时删除30天前的旧报告避免CI工作空间持续膨胀。这段逻辑很简单但它让“报告管理”这件事变得异常轻松。# conftest.py import os import shutil from datetime import datetime, timedelta def pytest_sessionfinish(session, exitstatus): report_path reports/report.html if not os.path.exists(report_path): return date_str datetime.now().strftime(%Y%m%d) archive_dir os.path.join(reports, date_str) os.makedirs(archive_dir, exist_okTrue) shutil.copy(report_path, os.path.join(archive_dir, report.html)) # 清理30天前的报告目录 for d in os.listdir(reports): full_path os.path.join(reports, d) if os.path.isdir(full_path) and len(d) 8 and d.isdigit(): if datetime.strptime(d, %Y%m%d) datetime.now() - timedelta(days30): shutil.rmtree(full_path)这个归档方案不依赖shell语法跨平台运行都没问题。另外一个比较有意思的玩法是结合pytest-timeout与pytest-html在用例执行超时时自动标记失败并且在报告里注明“超时耗时”。这一点对接口自动化尤其有用接口长时间没有响应时你不能无限等待得给个合理阈值让用例失败。pytest-html会正常渲染超时失败的用例数据和普通断言失败一样清晰可见。9. 说实话为什么我依然推荐pytest-html这几年测试报告工具迭代很快从最开始的自研HTML模板到pytest-html再到Allure、ReportPortal这类重型平台我基本都上手实操过。如果你现在问我一个新项目该用哪套方案我的回答依然是如果只是内部测试团队使用pytest-html够了。核心原因是报告的本质是“有效传递信息”。pytest-html以极低的成本满足了99%的测试报告需求结果统计、失败详情、环境信息、自定义扩展、CI集成。它可能没有Allure那种一眼惊艳的仪表盘也没有历史趋势图但这些功能在初期根本用不上反而会让整个流程显得臃肿。如果你天天被团队问“为什么这块模块又挂了”那你要思考的不是换更炫酷的报告工具而是把测试数据治理好、把环境信息记录完整、把接口路径和请求参数显示出来。这些事pytest-html都能做而且基本不用写多少代码。根据我的实操经验最后再分享几个小建议第一从第一次使用pytest-html起就坚持用--self-contained-html别等到要分享报告时才回来补。第二环境信息一定要维护起来哪怕只是几行metadata键值对在出问题的时候能帮大忙。第三报告只是结果展示不要为了报告好看而写测试。先保证用例本身的断言质量再谈报告花不花哨。如果你现在手头正好有pytest项目花五分钟装上pytest-html试一下。先把基础报告跑起来再按这篇博文提到的功能点逐个加配置你会发现整个测试团队的工作方式都会变得清爽很多。