pytest-html插件完全指南：从安装到定制生成专业测试报告

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 --html=report.html

运行结束后，工作目录下会出现一个report.html。用浏览器打开它，你会看到页面上方有Summary区域：总用例数、通过数、失败数、耗时、运行时间等信息一目了然。下面是完整的测试用例列表，每个用例都标注了模块路径、测试函数名、执行耗时和结果状态。

这就是pytest-html最基础也最核心的使用方式。但请注意，默认生成的HTML文件在展示上有一个很大的问题：它引用了外部CSS和JS文件，也就是pytest-html在生成时会同时输出一个report.html和一个assets目录。如果你的报告只在本地打开，这没什么影响；但如果你想把这个HTML文件直接发给别人，或者上传到CI服务器的Artifact中，那HTML文件会因为找不到同级的assets目录而样式全丢。

解决这个问题的方法非常直接，加一个参数：

pytest test_demo.py --html=report.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提供了一组命令行参数，覆盖了从输出路径到报告标题的常用配置。我把最常用、最值得记住的参数整理成了表格，你可以直接保存下来：

这里重点说一下--report-log，很多新手根本不知道这个参数的存在。它的作用是把本次测试运行的所有数据（用例、结果、错误信息、环境信息）导出成一个JSON文件。你可以在测试结束后完全离开测试环境，在另一个进程里用pytest --html=report.html --report-log=log.json这样的方式从JSON离线重建HTML报告。

这个功能在什么场景下很有用？比如CI流水线跑完测试后，你希望把原始数据留存下来，后续随时能重新生成任意格式的报告；又比如你的测试执行环境和报告渲染环境分离，测试机只负责跑用例，报告由专门的服务器去渲染。这些都是实战中的真实需求。

3.2 在pytest.ini里固化配置

每次执行命令都打一长串参数，既容易漏也容易错。正确做法是把常用配置写进pytest.ini的addopts中。这样即使你在命令行只敲pytest，报告也会按固定规则生成。

[pytest] addopts = -v --html=reports/report.html --self-contained-html --report-title=接口自动化测试报告 --maxfail=5

这里有个细节值得注意：--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 --html=reports/report_$(date +%Y%m%d_%H%M%S).html --self-contained-html

这在Linux/macOS下直接可用。Windows下用PowerShell则写成：

pytest --html="reports/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:pass@host:5432/testdb"

这段代码会在每次pytest会话启动时执行，把四个键值对写入报告的Environment区域。你打开生成的HTML，Summary下方就会出现一个带有这些信息的“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, f"<td>{report.interface_path or ''}</td>") cells.insert(2, f"<td>{report.request_method or ''}</td>")

插入列之后，还需要在测试用例或夹具里动态追加属性。你可以在用例执行前定义一个钩子，在用例结束时把数据挂到report对象上：

@pytest.hookimpl(hookwrapper=True) 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, "登录页截图")) raise

pytest_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", encoding="utf-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/ --html=reports/report.html --self-contained-html artifacts: paths: - reports/ when: always expire_in: 30 days

when: always保证即使测试失败，构建产物中也能留存报告，这个关键字很容易被忽略。默认的when: on_success会导致测试失败时不生成Artifact，那等于报告白跑了。

有些人会用GitLab的reports: junit来实现MR页面上直接展示测试用例状态，这是另一套方案，跟pytest-html不冲突。pytest-html负责出完整的网页报告，junit格式负责在MR详情页展示用例级状态，两个都配，互不干扰。

注意：GitLab的artifacts: reports: junit要求文件必须是JUnit XML格式，这个需要用--junitxml=report.xml参数生成，pytest-html不负责这个。

5.3 离线生成报告的进阶用法

前面提到--report-log参数可以导出JSON日志。这个功能在复杂CI流水线中非常实用：你把测试执行和报告生成拆成两个独立的Job，测试Job负责跑用例并产出一个巨大的JSON日志文件，报告Job从JSON中读取数据、渲染HTML。好处是：

1. 测试环境不需要装任何和报告渲染相关的额外依赖。
2. 如果报告模板需要升级，只需重跑报告Job，不需要重新执行测试。
3. 原始数据可以留存，方便后续生成任意格式的衍生报表。

生成离线报告的命令很简单：

pytest --report-log=run_log.json # 测试结束后，任何时候都能执行： pytest --html=report.html --report-log=run_log.json

但要注意，pytest --html=report.html --report-log=run_log.json这条命令在执行时不会重新跑测试，它会直接读取run_log.json的内容渲染HTML。如果你写成了pytest --report-log=run_log.json --html=report.html，它会真的去执行测试。参数顺序不会影响这个行为，真正影响行为的是你是否指定了测试路径和是否传了--report-log。最保险的离线生成方式是单独建一个目录放一份空的pytest.ini，然后用pytest --html=report.html --report-log=run_log.json来执行，不给它测试路径，它自然就只会读json了。

6. pytest-html与Allure如何取舍

写到这里，肯定有读者要问：既然pytest-html这么方便，为什么我身边很多人都在用Allure？Allure确实很火，功能也确实强大，但它和pytest-html的定位是不同的。我把两者的核心差异整理成一张对照表：

如果你问我怎么选，我的建议是分阶段：项目刚起步、团队规模小，先用pytest-html，一小时内就能看到完整报告；等测试用例量涨到几千条，需要统计历史趋势、做模块维度对比的时候，再引入Allure也不迟。Allure的全量接入成本不只是安装一个命令行工具，还包括团队学习注解语义、维护分类规则、在CI里多串一个命令。

这不是说pytest-html就比Allure差。恰恰相反，pytest-html的优势就是“快”和“轻”，安装一个pip包、加一个参数、拿到一份自包含HTML，整个过程在五分钟内完成，不依赖任何Java运行环境。

另外，pytest-html的报告是完全可以被其他工具二次消费的。比如你有定时任务跑完测试，要把汇总信息发到钉钉或企业微信，可以用脚本解析--report-log导出的JSON，再拼接各种通知格式。Allure的做法则是让你写扩展插件，开发成本明显高。

7. 常见问题与排查技巧实录

7.1 问题速查表

我把这几年来用pytest-html遇到的、以及帮别人排查过的典型问题汇总成了一个速查表，建议直接收藏。

7.2 我踩过的几个坑，单独拎出来说

坑一：xdist并行执行时报告数据丢失。如果你用pytest-xdist开启了多进程并行，默认情况下只有主进程的报告会写入html，worker进程的数据不会自动汇总。你需要加一个参数：--html=report.html --self-contained-html，同时让pytest-xdist的--dist=loadscope和pytest-html协同工作。实际操作时，我在pytest.ini里加的是：

addopts = -n 4 --html=reports/report.html --self-contained-html

xdist插件会自动把worker的结果合并到主进程再渲染，前提是你要使用pytest-xdist的2.0以上版本。如果版本太老，合并会失败甚至不生效。

坑二：报告里显示的中文乱码。如果你在报告里注入了中文环境信息或自定义字段，发现浏览器显示乱码，大概率是Windows下编码问题。对策是在conftest.py顶部强制声明utf-8编码的读取方式，并确保写入metadata的内容本身就是正常的Unicode字符串。注意当HTML文件里包含中文时，自包含模式下的<meta charset="utf-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 --html=reports/report.html --self-contained-html --report-title=详细版测试报告

# pytest.quick.ini（调试用） [pytest] addopts = -v --html=reports/quick_report.html --self-contained-html --tb=no --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_ok=True) 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(days=30): 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试一下。先把基础报告跑起来，再按这篇博文提到的功能点逐个加配置，你会发现整个测试团队的工作方式都会变得清爽很多。