从GoogleTest结果收集到分析：构建C++单元测试质量洞察体系

1. 项目概述：从“崩溃”到“洞察”的必经之路

如果你是一名C++开发者，并且正在使用GoogleTest（简称gtest）来构建你的单元测试框架，那么你很可能经历过这样的场景：本地运行，所有测试用例都欢快地通过了，绿色的“PASSED”字样让人安心。然而，当把代码提交到持续集成（CI）流水线，或者在一个更复杂的环境下运行成百上千个测试时，事情开始变得棘手。某个测试偶尔会失败，但错误信息一闪而过；测试套件的整体健康状况如何，是变好了还是变差了；哪些模块的测试最不稳定，需要优先关注？面对CI控制台里密密麻麻的日志输出，或者一个简单的通过/失败计数，我们常常感到的是一种“崩溃”——信息过载却又洞察不足。

这正是“从崩溃到洞察”这个标题想要揭示的核心矛盾与解决路径。GoogleTest本身是一个极其强大的单元测试框架，它提供了丰富的断言和测试组织能力。但是，它的默认输出（通常是控制台文本）更适合于开发者交互式运行和调试单个测试。当我们需要进行自动化、规模化、持续化的质量评估时，原生的输出形式就显得力不从心了。我们需要的不是一堆需要人工解析的文本，而是结构化的、可聚合的、可视化的数据，从而获得对代码质量真正的“洞察力”。

本指南旨在系统性地解决这个问题。我们将不仅仅停留在如何运行./your_tests --gtest_output=xml这个命令层面，而是深入探讨一整套从收集、解析、存储到分析和展示GoogleTest结果的工程化实践。无论你是想优化团队的CI/CD反馈循环，还是希望建立长期的测试质量度量体系，这里的内容都将提供从理论到实操的完整参考。我们将重点关注如何将分散的、非结构化的测试输出，转化为驱动代码质量改进的可靠指标。

2. 测试结果收集：超越默认文本输出

收集是分析的第一步，也是最关键的一步。如果收集到的数据本身就是残缺或难以处理的，后续所有分析都是空中楼阁。GoogleTest提供了多种输出格式，我们需要根据使用场景做出合理选择。

2.1 GoogleTest支持的输出格式与选择策略

默认情况下，GoogleTest将结果输出到标准输出（stdout）。这对于手动运行和即时调试是足够的，但对于自动化流程，我们需要更结构化的数据。

1. XML格式（--gtest_output=xml[:FILE]）：这是自动化集成中最常用、最核心的格式。它生成一个结构化的XML文件，包含了测试套件（TestSuite）、测试用例（TestCase）、运行状态（PASSED, FAILED, SKIPPED）、执行时间、时间戳以及详细的失败信息（包括出错的文件和行号）。几乎所有CI系统（如Jenkins, GitLab CI, GitHub Actions）和测试报告工具都原生支持或可以轻松解析JUnit风格的XML，而GoogleTest的XML格式与之兼容。

   • 选择理由：结构化程度高，信息完整，工具生态成熟。是连接测试执行与报告分析的“标准接口”。
   • 实操命令：./my_unittests --gtest_output=xml:test_results.xml

2. JSON格式（--gtest_output=json[:FILE]）：这是较新版本加入的格式。它提供了与XML类似的信息，但以JSON格式呈现。JSON对于现代Web应用和脚本处理来说更加友好。

   • 选择理由：如果你后续的分析管道基于Python、Node.js等语言，或者需要与前端可视化工具深度集成，JSON可能是更自然的选择。
   • 实操命令：./my_unittests --gtest_output=json:test_results.json

3. 控制台格式强化：虽然不直接生成文件，但通过结合--gtest_color=yes（彩色输出）、--gtest_brief=1（仅打印失败用例）等选项，可以优化本地开发时的阅读体验。但这不适用于自动化收集。

注意：在CI环境中，务必指定输出文件路径（如xml:$(pwd)/results.xml），并确保该文件被声明为构建产物（Artifact），以便后续步骤能够访问。一个常见的错误是只指定了格式没指定文件，或者文件路径不可访问，导致结果丢失。

2.2 在CI/CD流水线中集成结果收集

仅仅能生成报告文件还不够，我们需要将其无缝嵌入开发流程。这里以GitHub Actions为例，展示一个标准的集成模式。

name: C++ CI with GoogleTest on: [push, pull_request] jobs: build-and-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Configure and Build run: | cmake -B build -DCMAKE_BUILD_TYPE=Debug cmake --build build - name: Run Tests # 关键步骤：运行测试并指定XML输出 run: ./build/tests/my_test_suite --gtest_output=xml:$(pwd)/test_results.xml # 即使测试失败，CI步骤也应继续，以便收集失败报告 continue-on-error: true - name: Upload Test Results # 关键步骤：将结果文件作为构件上传，供后续步骤或人工下载查看 uses: actions/upload-artifact@v4 if: always() # 无论测试成功与否，都上传结果 with: name: gtest-results path: test_results.xml retention-days: 7

关键点解析：

• continue-on-error: true和if: always()：这是结果收集的黄金法则。测试失败正是我们需要分析的时候，因此收集动作绝不能因为测试失败而中断。这两个配置确保了无论测试通过与否，结果文件都会被生成并上传。
• 构件（Artifact）：上传的结果文件可以在GitHub Actions的界面中直接下载查看，也为后续可能添加的自动化分析步骤提供了数据源。

2.3 处理大规模测试：分片、重试与结果合并

当测试套件非常庞大时，一次性运行所有测试可能耗时过长，或者因资源限制而不可行。此时需要分而治之。

1. 测试分片（Sharding）：使用--gtest_total_shards和--gtest_shard_index参数可以将测试套件均匀分割成多个分片，在多个机器或进程上并行运行。

   # 在机器1上运行 ./tests --gtest_total_shards=4 --gtest_shard_index=0 --gtest_output=xml:result_0.xml # 在机器2上运行 ./tests --gtest_total_shards=4 --gtest_shard_index=1 --gtest_output=xml:result_1.xml # ... 以此类推

   实操心得：分片能极大缩短测试反馈时间。但要注意，测试用例必须是独立的，不能有执行顺序依赖或共享全局状态，否则分片会导致随机失败。

2. 失败重试（Retry）：对于某些因环境抖动（如网络、定时）导致的“脆性测试”（Flaky Tests），可以实施重试策略。GoogleTest本身不直接提供重试参数，但可以通过外层脚本实现。

   # 一个简单的重试脚本示例 MAX_RETRIES=3 for i in $(seq 1 $MAX_RETRIES); do ./tests --gtest_output=xml:result_try_$i.xml if [ $? -eq 0 ]; then cp result_try_$i.xml final_result.xml echo "Tests passed on attempt $i" break fi echo "Attempt $i failed, retrying..." done

   注意事项：重试机制是一把双刃剑。它掩盖了测试不稳定的问题，而非解决。长期来看，应该致力于消除脆性测试，而不是依赖重试。重试应仅作为临时措施，并需要监控重试率，重试率过高意味着测试代码或环境存在严重问题。

3. 结果合并：分片或重试后，我们会得到多个XML报告文件。大多数CI系统和分析工具（如后面提到的XSLT转换或自定义脚本）都需要一个统一的报告。你需要编写或使用工具来合并这些XML文件。一个简单的思路是使用Python的xml.etree.ElementTree或lxml库，读取所有XML文件，将<testsuites>下的<testsuite>节点合并到一个新的根节点下。注意处理重复的套件名和总时间累加。

3. 测试结果解析：从原始数据到结构化信息

收集到XML/JSON报告后，我们面对的是纯文本数据。解析的目的，是将其转化为程序容易处理的内存对象（如字典、列表），为后续分析和持久化做准备。

3.1 解析XML报告的核心要素

一个典型的GoogleTest XML报告结构如下：

<?xml version="1.0" encoding="UTF-8"?> <testsuites tests="3" failures="1" disabled="0" errors="0" time="2.345" timestamp="2023-10-27T08:15:30" name="AllTests"> <testsuite name="MathUtilsTest" tests="2" failures="1" disabled="0" errors="0" time="1.234"> <testcase name="Add_PositiveNumbers" status="run" result="completed" time="0.123" classname="MathUtilsTest" /> <testcase name="Divide_ByZero" status="run" result="completed" time="0.456" classname="MathUtilsTest"> <failure message="Expected equality of these values:&#xA; result&#xA; Which is: 0&#xA; expected&#xA; Which is: 1" type=""><![CDATA[path/to/math_test.cpp:45 Expected equality of these values: result Which is: 0 expected Which is: 1]]></failure> </testcase> </testsuite> <testsuite name="StringUtilsTest" tests="1" failures="0" disabled="0" errors="0" time="1.111"> <testcase name="ReverseString" status="run" result="completed" time="0.789" classname="StringUtilsTest" /> </testsuite> </testsuites>

我们需要关注的核心字段包括：

• 根节点：<testsuites>包含全局信息：总测试数(tests)、失败数(failures)、总耗时(time)。
• 套件节点：<testsuite>对应一个测试夹具（Test Fixture），包含该夹具下的测试统计。
• 用例节点：<testcase>对应一个TEST或TEST_F宏定义的测试函数。最重要的属性是name（函数名）、time（执行时间）和classname（所属的夹具类名）。
• 失败信息：<failure>节点，仅在测试失败时出现。其message属性和文本内容包含了断言失败的具体信息，是调试的关键。

3.2 使用Python进行灵活解析与初步分析

Python因其强大的库支持和脚本灵活性，是进行结果解析的理想选择。以下是一个使用xml.etree.ElementTree的解析示例，它不仅能解析，还能立即进行一些简单的分析。

import xml.etree.ElementTree as ET from datetime import datetime import sys def parse_gtest_xml(xml_path): """解析GoogleTest XML报告，返回结构化数据和基础分析""" tree = ET.parse(xml_path) root = tree.getroot() summary = { 'total_tests': int(root.attrib.get('tests', 0)), 'total_failures': int(root.attrib.get('failures', 0)), 'total_errors': int(root.attrib.get('errors', 0)), 'total_time': float(root.attrib.get('time', 0.0)), 'timestamp': root.attrib.get('timestamp'), 'test_suites': [] } slowest_tests = [] # 用于找出最慢的测试 failing_tests = [] # 用于收集失败用例详情 for suite in root.findall('testsuite'): suite_name = suite.attrib['name'] suite_data = { 'name': suite_name, 'tests': int(suite.attrib.get('tests', 0)), 'failures': int(suite.attrib.get('failures', 0)), 'time': float(suite.attrib.get('time', 0.0)), 'test_cases': [] } for case in suite.findall('testcase'): case_name = case.attrib['name'] case_time = float(case.attrib.get('time', 0.0)) case_status = 'PASSED' failure_msg = None # 检查是否有<failure>或<error>子节点 failure_elem = case.find('failure') if failure_elem is not None: case_status = 'FAILED' failure_msg = failure_elem.attrib.get('message', '') + "\n" + (failure_elem.text or '') failing_tests.append({ 'suite': suite_name, 'case': case_name, 'time': case_time, 'message': failure_msg[:500] # 截取前500字符，防止过长 }) case_data = { 'name': case_name, 'status': case_status, 'time': case_time } suite_data['test_cases'].append(case_data) # 记录执行时间最长的测试（例如前5名） slowest_tests.append((f"{suite_name}.{case_name}", case_time)) summary['test_suites'].append(suite_data) # 分析：找出最慢的5个测试 slowest_tests.sort(key=lambda x: x[1], reverse=True) summary['top_slowest'] = slowest_tests[:5] # 分析：计算通过率 if summary['total_tests'] > 0: summary['pass_rate'] = (summary['total_tests'] - summary['total_failures'] - summary['total_errors']) / summary['total_tests'] * 100 else: summary['pass_rate'] = 0.0 return summary, failing_tests if __name__ == '__main__': if len(sys.argv) < 2: print("Usage: python parse_results.py <path_to_xml>") sys.exit(1) xml_file = sys.argv[1] summary, failures = parse_gtest_xml(xml_file) print("=== 测试执行摘要 ===") print(f"总测试数: {summary['total_tests']}") print(f"失败数: {summary['total_failures']}") print(f"错误数: {summary['total_errors']}") print(f"总耗时: {summary['total_time']:.2f} 秒") print(f"通过率: {summary['pass_rate']:.1f}%") print(f"时间戳: {summary['timestamp']}") print("\n=== 最慢的5个测试用例 ===") for name, time in summary['top_slowest']: print(f" {name}: {time:.3f} 秒") if failures: print(f"\n=== 失败的测试用例 ({len(failures)}个) ===") for fail in failures: print(f"* {fail['suite']}.{fail['case']} ({fail['time']:.3f}s)") print(f" 错误: {fail['message'][:200]}...") # 打印部分错误信息 else: print("\n所有测试通过！")

这个脚本提供了一个强大的起点。你可以轻松地扩展它，例如将结果存入数据库（如SQLite、PostgreSQL）、生成更详细的JSON报告，或者与团队的告警系统集成（当通过率低于阈值或出现特定模块失败时发送通知）。

3.3 解析过程中的常见陷阱与处理

1. 时间格式不一致：time属性通常是浮点数秒，但确保你的解析代码能处理可能的格式异常（如空字符串或非数字）。
2. CDATA处理：失败信息通常包裹在<![CDATA[...]]>中，ElementTree会自动处理，但如果你用其他方式解析（如字符串匹配），需要注意。
3. 大型文件处理：对于超大的XML报告（数万测试用例），使用ET.iterparse()进行增量解析可以避免一次性加载整个文件到内存，提升性能和资源利用率。
4. 合并文件的解析：如果你合并了多个分片的结果，解析逻辑需要能处理可能存在重复testsuite名称的情况（相同套件在不同分片），正确累加其tests、failures和time属性。

4. 测试结果存储与历史追踪

一次性的测试结果有价值，但连续的历史数据价值更大。它可以帮助我们回答：代码质量是在改善还是在恶化？本次提交引入了多少不稳定的测试？哪个模块的测试耗时在持续增长？

4.1 设计简单有效的结果存储方案

对于中小型项目，一个轻量级的方案是使用SQLite数据库。它无需单独的服务器，文件即可管理，非常适合集成到CI流程中。

我们可以设计一张简单的表来存储每次测试运行的摘要：

CREATE TABLE test_runs ( id INTEGER PRIMARY KEY AUTOINCREMENT, run_timestamp DATETIME NOT NULL, -- 运行时间 git_commit_hash TEXT, -- 关联的代码提交哈希 git_branch TEXT, -- 分支名 total_tests INTEGER, passed_tests INTEGER, failed_tests INTEGER, skipped_tests INTEGER, total_duration REAL, -- 总耗时（秒） pass_rate REAL, -- 通过率 summary_json TEXT -- 可存储更详细的摘要JSON，供扩展 );

此外，还可以创建另一张表存储失败用例的详细信息，便于追踪“常败将军”：

CREATE TABLE test_failures ( id INTEGER PRIMARY KEY AUTOINCREMENT, run_id INTEGER, -- 关联test_runs.id test_suite TEXT NOT NULL, test_case TEXT NOT NULL, failure_message TEXT, duration REAL, FOREIGN KEY (run_id) REFERENCES test_runs(id) );

在CI脚本中，在解析完XML报告后，可以插入数据到该数据库：

import sqlite3 from datetime import datetime def store_run_summary(db_path, summary, commit_hash='', branch=''): conn = sqlite3.connect(db_path) cursor = conn.cursor() passed = summary['total_tests'] - summary['total_failures'] - summary['total_errors'] cursor.execute(''' INSERT INTO test_runs (run_timestamp, git_commit_hash, git_branch, total_tests, passed_tests, failed_tests, skipped_tests, total_duration, pass_rate) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?) ''', ( datetime.now().isoformat(), commit_hash, branch, summary['total_tests'], passed, summary['total_failures'], 0, # GoogleTest默认不报告skipped，需特殊处理 summary['total_time'], summary['pass_rate'] )) run_id = cursor.lastrowid conn.commit() conn.close() return run_id

4.2 集成版本信息：关联代码与测试结果

为了建立测试结果与代码版本的关联，必须在CI环境中捕获版本信息（如Git提交哈希）。这可以通过环境变量或命令获取，并传递给结果存储脚本。

# 在CI脚本中 GIT_COMMIT_HASH=$(git rev-parse --short HEAD) GIT_BRANCH=$(git branch --show-current) python3 store_results.py --db test_history.db --xml test_results.xml --commit $GIT_COMMIT_HASH --branch $GIT_BRANCH

这样，当你发现某次运行通过率骤降时，可以立刻定位到是哪个提交引入的问题，结合git bisect等工具，能极大提升问题排查效率。

4.3 可视化历史趋势

有了数据库，就可以用简单的脚本或工具生成趋势图。例如，使用Python的matplotlib库：

import sqlite3 import matplotlib.pyplot as plt import matplotlib.dates as mdates from datetime import datetime conn = sqlite3.connect('test_history.db') cursor = conn.cursor() cursor.execute('SELECT run_timestamp, pass_rate FROM test_runs ORDER BY run_timestamp') data = cursor.fetchall() conn.close() timestamps = [datetime.fromisoformat(row[0]) for row in data] pass_rates = [row[1] for row in data] plt.figure(figsize=(12, 6)) plt.plot(timestamps, pass_rates, marker='o', linestyle='-', linewidth=2) plt.axhline(y=95, color='r', linestyle='--', alpha=0.5, label='95% Threshold') # 添加合格线 plt.xlabel('Run Time') plt.ylabel('Pass Rate (%)') plt.title('Test Pass Rate Trend Over Time') plt.gca().xaxis.set_major_formatter(mdates.DateFormatter('%m-%d %H:%M')) plt.gcf().autofmt_xdate() # 旋转日期标签 plt.grid(True, alpha=0.3) plt.legend() plt.tight_layout() plt.savefig('pass_rate_trend.png') plt.show()

生成的图表可以嵌入到CI系统的总结邮件或内部仪表盘中，让团队对质量态势一目了然。

5. 高级分析与洞察挖掘

基础的数据收集和存储之后，我们可以进行更深层次的分析，从数据中挖掘出真正驱动质量改进的洞察。

5.1 识别性能退化与脆性测试

1. 测试用例执行时间分析：监控每个测试用例的执行时间变化。突然变慢的测试可能意味着代码逻辑变得复杂，或者引入了性能瓶颈。可以定期运行一个基准测试，记录每个用例的耗时，并与历史数据对比，对超出阈值（如增长超过50%）的用例发出警告。

   -- 查询某个测试用例最近5次运行的时间 SELECT run_timestamp, duration FROM test_failures WHERE test_suite='MySuite' AND test_case='MySlowTest' ORDER BY run_timestamp DESC LIMIT 5;

2. 脆性测试（Flaky Tests）识别：这是测试分析中最具价值的部分之一。脆性测试是指那些时而通过、时而失败，且失败原因非确定性的测试。它们严重损害测试套件的可信度。可以通过分析历史失败数据来识别：

   • 高失败频率但非连续失败：某个测试在历史上频繁失败，但并非每次运行都失败。
   • 失败信息多样化：同一个测试，每次失败的错误信息不同（可能是竞态条件、未清理的全局状态等）。
   • 识别方法：计算每个测试用例的“失败率”（失败次数/出现次数），并对失败率在10%到90%之间的测试进行标记和审查。接近50%失败率的测试是典型的脆性测试候选。

5.2 测试覆盖率与结果关联分析

虽然GoogleTest本身不生成覆盖率报告，但我们可以结合像gcov/lcov（GCC）或OpenCppCoverage（Windows）这样的工具。关键是将覆盖率数据与测试结果关联起来。

1. 生成覆盖率报告：在编译时添加覆盖率标识（如-fprofile-arcs -ftest-coverage），运行测试后，使用lcov收集数据并生成HTML报告。
2. 关联分析思路：
   • 针对失败测试：查看失败测试用例所覆盖的代码行。如果某些代码行只在失败的测试中被覆盖，那么这些行很可能是问题的根源。
   • 针对新增代码：在代码审查时，不仅看单元测试是否通过，还要看新增的代码行是否被新老测试充分覆盖。可以设置门禁：新增代码的覆盖率必须达到一定标准（如80%）才能合并。
   • 建立仪表盘：创建一个仪表盘，同时展示“每日构建通过率”和“代码行覆盖率”两个趋势图。观察它们之间的相关性。通过率下降时，覆盖率是否也同步下降？这可能意味着测试本身被破坏或跳过。

5.3 构建质量门禁与自动化告警

数据分析的最终目的是驱动行动。我们可以基于分析结果设置自动化的质量门禁和告警。

1. 门禁规则示例：

   • 整体通过率：低于95%则标记构建为不稳定（Unstable）或失败。
   • 新增失败：与上次成功构建相比，出现了之前从未失败过的测试用例，则必须人工审查。
   • 性能回归：任何测试用例的执行时间相比历史平均值增长超过100%，则发出警告。
   • 关键模块失败：针对核心模块（如支付、鉴权）的测试失败，直接标记构建为失败。

2. 告警集成：在CI脚本的末尾，调用分析脚本，根据上述规则判断。如果触发告警，可以通过邮件、Slack、钉钉或企业微信Webhook发送通知。通知内容应包含：

   • 构建编号和提交信息。
   • 触发的规则详情（例如：“MathUtilsTest.Add_PositiveNumbers 执行时间从0.1s增长到0.3s，超过阈值”）。
   • 直接链接到失败的测试日志或详细的报告页面。

# 一个简单的门禁检查脚本示例 def evaluate_quality_gates(summary, previous_run_summary): issues = [] if summary['pass_rate'] < 95.0: issues.append(f"整体通过率({summary['pass_rate']:.1f}%)低于95%门禁。") if previous_run_summary: new_failures = set(summary['failing_tests']) - set(previous_run_summary['failing_tests']) if new_failures: issues.append(f"发现新增失败用例: {', '.join(new_failures)}") # ... 更多规则检查 return issues

6. 实用工具链与生态系统集成

除了自己动手构建，也可以利用现有的强大工具来提升效率。

6.1 专用测试报告工具

1. XSLT样式表转换：GoogleTest源码中自带了一个gtest.xsl样式表文件。你可以用它直接将XML报告转换为更易读的HTML。

   # 需要xsltproc工具 xsltproc /path/to/googletest/scripts/gtest.xsl test_results.xml > test_report.html

   生成的HTML报告包含了可折叠的测试套件、颜色高亮（红/绿）的测试状态，以及详细的失败堆栈，非常适合手动查看单次运行结果。

2. CI系统插件：

   • Jenkins: “JUnit”插件可以直接处理GoogleTest的XML报告，提供趋势图、历史记录和失败用例的快速导航。
   • GitLab CI: 在.gitlab-ci.yml中定义artifacts:reports:junit路径，GitLab会自动在Merge Request界面和Pipeline详情页中解析并展示测试结果，非常方便。
   • GitHub Actions: 有诸如dorny/test-reporter等第三方Action，可以将JUnit格式的XML转换为GitHub Checks API的格式，在Pull Request中直接显示测试通过/失败状态和注释。

6.2 与监控和日志系统集成

对于大型分布式系统，测试可能只是质量守护的一部分。可以将测试结果的关键指标（如通过率、总耗时）推送到像Prometheus这样的监控系统中。

1. 暴露为Metrics：在测试运行结束后，运行一个脚本，将pass_rate、test_duration_seconds、test_failures_total等指标按照test_suite作为标签，写入一个临时文件（符合Prometheus文本格式）。

   # 示例：prometheus_metrics.txt # HELP test_pass_rate The pass rate of the test suite. # TYPE test_pass_rate gauge test_pass_rate{suite="MathUtilsTest"} 100.0 test_pass_rate{suite="StringUtilsTest"} 66.7 # HELP test_duration_seconds Total duration of the test suite. # TYPE test_duration_seconds gauge test_duration_seconds{suite="MathUtilsTest"} 1.234 test_duration_seconds{suite="StringUtilsTest"} 1.111

2. 使用Pushgateway推送：通过Prometheus的Pushgateway，将这些临时的作业指标推送到Prometheus服务器。

   curl -X POST --data-binary @prometheus_metrics.txt http://pushgateway.example.org:9091/metrics/job/gtest_ci

3. 在Grafana中可视化：之后，你就可以在Grafana中创建仪表盘，像监控系统服务一样监控你的测试健康度，设置告警规则（如通过率连续3次低于90%）。

6.3 自定义报告生成器进阶示例

如果你需要高度定制化的报告，可以基于之前的解析脚本，使用Jinja2模板引擎生成美观的HTML报告。

import jinja2 # ... (之前的解析代码) def generate_html_report(summary, failures, output_path='report.html'): template_str = """ <!DOCTYPE html> <html> <head><title>GoogleTest Report - {{ timestamp }}</title> <style> body { font-family: sans-serif; margin: 20px; } .summary { background: #f5f5f5; padding: 15px; border-radius: 5px; } .passed { color: green; } .failed { color: red; font-weight: bold; } table { border-collapse: collapse; width: 100%; margin-top: 20px; } th, td { border: 1px solid #ddd; padding: 8px; text-align: left; } th { background-color: #4CAF50; color: white; } tr:nth-child(even) { background-color: #f2f2f2; } </style> </head> <body> <h1>测试执行报告</h1> <div class="summary"> <p><strong>总测试数:</strong> {{ summary.total_tests }}</p> <p><strong>通过率:</strong> <span class="{{ 'passed' if summary.pass_rate > 95 else 'failed' }}">{{ "%.1f"|format(summary.pass_rate) }}%</span></p> <p><strong>总耗时:</strong> {{ "%.2f"|format(summary.total_time) }} 秒</p> </div> {% if failures %} <h2>失败用例详情</h2> <table> <tr><th>测试套件</th><th>测试用例</th><th>错误信息</th></tr> {% for f in failures %} <tr><td>{{ f.suite }}</td><td>{{ f.case }}</td><td><pre>{{ f.message }}</pre></td></tr> {% endfor %} </table> {% else %} <h2 class="passed">所有测试通过！</h2> {% endif %} </body> </html> """ template = jinja2.Template(template_str) html_content = template.render(summary=summary, failures=failures, timestamp=summary['timestamp']) with open(output_path, 'w', encoding='utf-8') as f: f.write(html_content) print(f"报告已生成: {output_path}")

这个简单的示例可以扩展为包含历史趋势图（通过嵌入Chart.js）、不同套件的详细对比、与Bug跟踪系统（如Jira）的链接等功能的强大内部报告门户。