1. 项目概述为什么我们需要一个“自动写测试报告”的 Skill在软件开发和测试的日常里写测试报告这件事说大不大说小不小但绝对是个“脏活累活”。想象一下这个场景你刚跑完一轮包含上百个用例的自动化测试Jenkins 的控制台输出了一长串日志Allure 生成了漂亮的图表但你还得手动去整理“本次测试覆盖了哪些模块”、“发现了几个 Bug”、“阻塞问题是什么”、“建议下一步怎么做”。这个过程枯燥、重复还容易因为疲劳而出错特别是当测试频率很高比如每天都有多次构建时写报告的时间甚至可能超过分析问题的时间。这就是我决定动手自建一个“自动写测试报告” Skill 的初衷。它不是一个独立的庞大系统而是一个可以嵌入到现有 CI/CD 流水线或测试框架中的智能小工具。它的核心目标很明确将结构化的测试结果数据如 JUnit XML、Allure JSON和自然语言的需求如“生成一份给项目经理看的概要报告”自动转换为一篇逻辑清晰、重点突出、可直接交付的测试报告文档。这背后依赖的关键技术正是当前大热的 LLM大语言模型。我们不是让 LLM 凭空创造而是让它扮演一个“高级测试分析员”的角色基于我们提供的“事实”测试数据和“模板”报告框架进行信息提炼、总结归纳和风险提示。最近在开发者社区里像OpenClaw、dify这类 LLM 应用框架以及skill这种可插拔功能模块的概念非常流行。我这个项目本质上就是在打造一个专属于测试领域的skill。它接收测试数据调用 LLM 的推理和文本生成能力输出符合要求的报告。这不仅能将测试人员从重复劳动中解放出来更能通过 LLM 的“洞察力”发现一些人工浏览日志时可能忽略的关联模式或潜在风险提升报告的价值。2. 整体设计与核心思路拆解2.1 技能Skill的定位与边界首先得明确这个“自动写测试报告”是一个Skill而不是一个Platform或Framework。这意味着它应该轻量、专注、易于集成。它的输入和输出必须定义得非常清晰输入结构化的测试结果数据 可选的自然语言指令。输出一份格式良好的测试报告Markdown / HTML / Word。它的边界在于不负责执行测试用例那是 Jenkins、GitLab CI、pytest、Playwright 等工具的事也不负责深度分析代码缺陷那是 APM、日志分析平台的事。它的职责是“翻译”和“总结”。基于这个定位技术选型上就会倾向于选择那些擅长处理结构化任务、支持函数调用Function Calling或具备较强长文本理解能力的 LLM 服务或本地模型。2.2 核心架构与工作流设计整个 Skill 的工作流可以分解为以下几个核心阶段我将其设计为一个可配置的管道Pipeline数据采集与标准化这是基石。测试报告的质量首先取决于输入数据的质量。Skill 需要适配多种测试框架的输出格式如 JUnit XML、Allure 结果目录、pytest-html 报告等。这一步需要将它们解析并统一转换为一个内部的、结构化的数据模型例如一个包含TestSuite,TestCase,Status,Duration,ErrorLog等字段的 JSON 对象。这步工作相对传统但鲁棒性很重要要能处理各种边缘情况比如被截断的日志、异常字符等。指令解析与上下文构建用户可能通过简单指令来定制报告例如“写一份给开发看的详细报告重点列出失败的用例和错误日志”或“生成一份给产品经理的简报只关注通过率和核心功能点”。Skill 需要解析这些指令并将其转化为对 LLM 的“提示词Prompt”。同时将上一步得到的标准化测试数据以清晰的方式如结构化摘要、关键数据表格组织进提示词的上下文Context中。这里的一个关键技巧是如何在有限的上下文窗口内既包含足够的信息又避免冗余。LLM 调用与报告生成这是智能核心。将构建好的提示词和上下文发送给 LLM。这里的选择很多云端 API如 OpenAI GPT-4 Claude 文心一言等。优势是能力强、开箱即用但涉及数据隐私和持续成本。本地模型如通过Ollama部署的Llama 3、Qwen等。优势是数据完全本地、无网络依赖但对硬件有要求且模型能力可能稍逊于顶级云端模型。专用框架如OpenClaw、LangChain。它们提供了更高级的抽象比如工具调用、工作流编排。OpenClaw近期社区热度很高它强调的Agent和Skill概念与本项目非常契合可以基于它来封装这个报告生成能力使其更容易被其他智能体调用。 我的选择是在原型阶段使用云端 API 快速验证效果在成熟期提供配置项允许用户选择接入云端 API 或指定的本地模型服务。提示词工程是这里的重中之重需要精心设计系统指令System Prompt和用户指令User Prompt引导 LLM 扮演好“测试分析师”的角色。后处理与格式输出LLM 返回的通常是纯文本。我们需要将其转换为更友好的格式。例如识别 LLM 输出的 Markdown 格式并将其渲染为 HTML或者集成像python-docx这样的库直接生成 Word 文档。也可以支持将报告上传到 Confluence、钉钉/飞书群等协作平台。2.3 技术栈选型考量后端语言Python是首选。它在测试自动化领域生态丰富pytest, requests, selenium数据处理库强大pandas, json并且是大多数 LLM 框架和库OpenAI SDK, LangChain,OpenClaw的主要支持语言。LLM 交互层初期直接使用openai或anthropic的官方 SDK 最简单。如果考虑更复杂的流程控制如多步推理、条件判断LangChain或OpenClaw这类框架会更有优势。特别是OpenClaw其Skill的设计理念可以直接复用。数据解析根据要支持的测试报告格式选用相应的解析库如xml.etree.ElementTree处理 JUnitjson库处理 Allure 的 JSON 文件。部署与集成最终这个 Skill 应该打包成一个 Docker 镜像可以通过环境变量配置 API Key、模型选择等。它提供简单的 HTTP API如 FastAPI 实现方便被 Jenkins Pipeline、GitLab CI.gitlab-ci.yml文件或任何脚本调用。注意关于OpenClaw的热词与潜在问题在搜索热词中看到了openclaw安装、openclaw部署以及错误信息openclaw llamap svr operator(): got exception。这提示我们如果选择基于OpenClaw开发需要仔细处理其部署依赖和运行时环境。那个400错误很可能是在调用其内部服务时请求参数不合法或服务未正确启动导致的。在自建 Skill 时如果依赖此类外部框架必须将其稳定性作为风险点考虑做好降级处理例如当OpenClaw服务不可用时回退到直接调用 LLM API。3. 核心模块详解与实现要点3.1 数据采集与标准化模块这个模块是流水线的源头必须健壮。我设计了一个插件化的架构来支持不同数据源。核心数据模型定义 首先定义一个内部通用的TestResult数据类这里用 Pydantic 模型示意因为它能提供良好的类型提示和数据验证。from pydantic import BaseModel from enum import Enum from typing import List, Optional from datetime import datetime class TestStatus(str, Enum): PASSED “passed” FAILED “failed” SKIPPED “skipped” BROKEN “broken” # 可能表示测试环境问题导致的失败 class TestCase(BaseModel): name: str suite: str # 所属测试集/类名 status: TestStatus duration: float # 单位秒 error_message: Optional[str] None stack_trace: Optional[str] None logs: Optional[str] None # 额外的自定义日志 tags: List[str] [] # 可用于分类如 “smoke”, “api” class TestExecution(BaseModel): project_name: str start_time: datetime end_time: datetime total_cases: int passed_cases: int failed_cases: int skipped_cases: int test_cases: List[TestCase] # 所有用例的详情 environment: dict {} # 测试环境信息如 {“browser”: “chrome 120”, “env”: “staging”}插件化解析器实现 为每种支持的格式实现一个解析器类它们都继承自一个基类ResultParser。from abc import ABC, abstractmethod import xml.etree.ElementTree as ET import json from pathlib import Path class ResultParser(ABC): abstractmethod def parse(self, source_path: str) - TestExecution: “”“将源文件/目录解析为统一的 TestExecution 对象。”“” pass class JUnitXmlParser(ResultParser): def parse(self, xml_path: str) - TestExecution: tree ET.parse(xml_path) root tree.getroot() test_cases [] for suite in root.findall(‘testsuite’): suite_name suite.get(‘name’, ‘unknown’) for case in suite.findall(‘testcase’): case_name case.get(‘name’) duration float(case.get(‘time’, 0)) status TestStatus.PASSED error_msg None # JUnit 中失败用 failure错误用 error failure case.find(‘failure’) error case.find(‘error’) if failure is not None: status TestStatus.FAILED error_msg failure.get(‘message’, ‘’) ‘\n’ failure.text if failure.text else ‘’ elif error is not None: status TestStatus.BROKEN error_msg error.get(‘message’, ‘’) ‘\n’ error.text if error.text else ‘’ # 处理 skipped? 有些框架用 skipped 标签 test_cases.append(TestCase( namecase_name, suitesuite_name, statusstatus, durationduration, error_messageerror_msg )) # 计算统计数据 total len(test_cases) passed sum(1 for c in test_cases if c.status TestStatus.PASSED) failed sum(1 for c in test_cases if c.status TestStatus.FAILED) # 这里简化了时间实际应从 XML 属性或文件时间获取 return TestExecution( project_namePath(xml_path).stem, start_timedatetime.now(), end_timedatetime.now(), total_casestotal, passed_casespassed, failed_casesfailed, skipped_casestotal - passed - failed, test_casestest_cases ) class AllureResultParser(ResultParser): # Allure 结果是一系列 JSON 文件通常在一个目录里 def parse(self, results_dir: str) - TestExecution: # 实现遍历 results_dir 下的 *.json 文件解析每个测试用例的详细结果 # 逻辑比 JUnit 复杂因为信息更分散但能获取更丰富的步骤step和附件信息 pass实操心得日志处理错误日志和堆栈信息可能很长直接全塞给 LLM 会浪费上下文。这里需要做一个智能摘要提取关键错误行如包含 “Error:”, “Exception:”, “failed assertion” 的行并截取前 N 行和后 N 行。可以写一个简单的函数来处理。性能考量如果测试用例数量极大上万在内存中保存所有TestCase详情可能压力大。可以考虑两种模式“完整模式”用于详细报告“摘要模式”只统计数量和采样部分失败用例详情用于生成概览报告。环境信息务必收集测试环境信息如代码版本号、测试服务器 IP、数据库版本等。这些信息对于问题复现至关重要也是报告的有价值组成部分。可以从环境变量、配置文件或通过运行时 API 获取。3.2 提示词工程与上下文构建模块这是决定报告质量的核心。我们不能简单地把一堆 JSON 丢给 LLM 说“写个报告”。需要精心设计提示词。系统指令System Prompt设计 系统指令用于设定 LLM 的角色和行为规范。它应该相对稳定。你是一位资深的软件测试工程师和质量分析师。你的任务是根据提供的测试执行结果数据生成专业、清晰、有针对性的测试报告。 请严格遵守以下要求 1. **基于事实**报告中的所有结论、数据和描述必须严格基于我提供的测试结果数据。不要捏造或推断不存在的信息。 2. **结构清晰**报告应至少包含概述测试目标、时间、环境、数据总览通过率、耗时统计、详细分析重点分析失败/阻塞的用例、风险与建议、附录可选。 3. **语气专业**根据报告受众调整语气。给开发者的报告可以更技术化直接引用错误日志给项目经理的报告应更关注整体质量、风险和进度影响。 4. **突出重点**优先分析和呈现失败FAILED和异常中断BROKEN的用例。对于通过的用例可以分类总结无需逐一列出。 5. **提供洞察**尝试从失败用例中归纳共同点例如是否集中在某个模块、某种类型的接口、特定的数据条件并提出具体的排查建议或后续测试重点。 输出格式请使用 Markdown以便后续渲染。用户指令与上下文构建 用户指令包含本次请求的具体要求和注入的数据。请生成一份测试报告。 **报告受众**项目开发团队与测试负责人。 **报告详细程度**详细。需要列出所有失败用例的名称、所属模块和错误摘要。 **特别关注点**请分析失败用例是否与最近更新的“用户支付”模块相关。 以下是本次测试执行的详细结果数据 ## 测试执行概览 - 项目名称{{project_name}} - 测试环境{{environment | tojson}} - 开始时间{{start_time}} - 结束时间{{end_time}} - 总用例数{{total_cases}} - 通过数{{passed_cases}} (通过率{{”%.1f%%”|format(passed_cases/total_cases*100)}}) - 失败数{{failed_cases}} - 跳过数{{skipped_cases}} - 总耗时{{”%.1f”|format(sum(c.duration for c in test_cases))}} 秒 ## 失败用例详情前10个按耗时降序 {% for case in test_cases if case.status “failed” %} ### {{case.suite}}::{{case.name}} - **状态**: {{case.status}} - **耗时**: {{case.duration}}秒 - **错误摘要**: {{case.error_message | truncate(200)}} {% endfor %} ## 所有用例状态分布 此处可以是一个简单的 Markdown 表格展示各个 Suite 的通过/失败情况 请基于以上数据生成报告。实现要点模板引擎如上所示我使用了类似 Jinja2 的模板语法来动态生成用户消息。这样可以将数据模型灵活地填充到预设的模板中。Python 的jinja2库完美胜任。上下文长度管理这是最大的挑战之一。如果失败用例有几百个每个的日志都很长很容易超出模型的上下文窗口。策略有摘要与采样只发送前 N 个失败用例的完整信息其余的仅统计数量。分层处理先让 LLM 基于摘要数据生成报告大纲和核心结论再针对它提出的需要深挖的特定失败用例发起第二轮查询获取详细日志。这需要更复杂的 Agent 工作流OpenClaw或LangChain在这类多步推理上有优势。外部知识库将详细的测试日志存储到向量数据库如 Chroma当 LLM 需要分析某个具体失败时通过检索增强生成RAG的方式获取相关内容。但这增加了系统复杂度。指令参数化将“受众”、“详细程度”、“特别关注点”作为 Skill 的可配置参数允许调用方动态指定。3.3 LLM 服务集成与调用模块这一模块负责与选定的 LLM 服务进行通信。为了灵活性我设计了一个通用的LLMClient抽象类。from abc import ABC, abstractmethod import openai from openai import OpenAI import anthropic import os from typing import List, Dict, Any class LLMClient(ABC): abstractmethod def generate_report(self, system_prompt: str, user_prompt: str) - str: “”“调用 LLM传入系统提示和用户提示返回生成的报告文本。”“” pass class OpenAIClient(LLMClient): def __init__(self, model: str “gpt-4-turbo-preview”, api_key: str None): self.client OpenAI(api_keyapi_key or os.getenv(“OPENAI_API_KEY”)) self.model model def generate_report(self, system_prompt: str, user_prompt: str) - str: try: response self.client.chat.completions.create( modelself.model, messages[ {“role”: “system”, “content”: system_prompt}, {“role”: “user”, “content”: user_prompt} ], temperature0.2, # 温度设低保证报告稳定性避免创造性过强 max_tokens4000 # 根据模型和需要调整 ) return response.choices[0].message.content except Exception as e: # 记录日志并可能触发降级策略 raise RuntimeError(f“调用 OpenAI API 失败: {e}”) class ClaudeClient(LLMClient): def __init__(self, model: str “claude-3-sonnet-20240229”, api_key: str None): self.client anthropic.Anthropic(api_keyapi_key or os.getenv(“ANTHROPIC_API_KEY”)) self.model model # … 类似的实现 class OllamaClient(LLMClient): def __init__(self, base_url: str “http://localhost:11434”, model: str “llama3”): self.base_url base_url self.model model # 可以使用 requests 或 ollama 官方 python 库 def generate_report(self, system_prompt: str, user_prompt: str) - str: # 将 system_prompt 和 user_prompt 组合成 Ollama 支持的格式 combined_prompt f“{system_prompt}\n\n{user_prompt}” # 调用 Ollama 的 generate API pass配置与工厂模式 在 Skill 的主配置文件中可以指定使用哪个客户端。# config.yaml llm: provider: “openai” # 可选openai, claude, ollama, openclaw_proxy model: “gpt-4-turbo” api_key: ${ENV_OPENAI_KEY} # 支持从环境变量读取 base_url: “https://api.openai.com/v1” # 对于 Ollama 或自部署模型修改此项 report: default_audience: “developer” default_detail_level: “normal” output_format: “markdown” # markdown, html, docx然后在代码中使用工厂方法创建对应的客户端实例。重要提示关于OpenClaw集成的思考如果社区生态成熟将本 Skill 封装为一个OpenClaw Skill会非常有价值。这意味着我们的报告生成能力可以被任何基于OpenClaw的智能体Agent调用。例如一个监控 CI 流水线的 Agent在检测到测试失败后可以自动调用本 Skill 生成报告然后将其发送到钉钉群。这需要遵循OpenClaw的 Skill 开发规范通常需要定义一个清晰的输入/输出 Schema并注册到OpenClaw的框架中。热词中提到的openclaw llamap svr operator(): got exception错误提醒我们在集成时要特别注意服务发现、API 版本兼容性和错误处理。3.4 报告后处理与输出模块LLM 返回的是 Markdown 文本我们可以根据需求进行进一步加工。格式转换Markdown 转 HTML使用markdown库或mistune可以轻松转换。可以结合pygments实现代码高亮。Markdown 转 Word使用python-docx库需要解析 Markdown 语法并映射到 Word 的段落、标题、表格等样式。这是一个相对复杂但体验很好的功能。直接输出 Markdown最简单可以集成到支持 Markdown 的 Wiki如 GitLab Wiki或文档系统。样式与品牌化 可以为 HTML 报告注入自定义 CSS使其符合公司或团队的视觉规范。对于 Word可以预定义.dotx模板文件生成时应用模板中的样式。分发集成文件系统保存到指定目录Jenkins 等 CI 工具可以将其归档为构建产物。邮件发送将 HTML 报告作为邮件正文发送给相关干系人。Webhook 推送将报告内容通过飞书、钉钉、企业微信等平台的机器人 Webhook 发送到群聊。注意消息长度限制过长的报告可能需要先上传为文件再发送文件链接。Confluence 等 Wiki调用 Confluence REST API 创建或更新页面。4. 完整实操流程从零搭建并集成到 CI/CD假设我们为一个使用pytest框架并通过Allure生成报告的 Python 项目搭建这个 Skill并集成到 Jenkins 流水线中。4.1 环境准备与 Skill 开发创建项目结构auto-test-report-skill/ ├── src/ │ ├── __init__.py │ ├── models.py # 数据模型 (TestExecution, TestCase) │ ├── parsers/ # 解析器插件 │ │ ├── __init__.py │ │ ├── base.py │ │ ├── junit_parser.py │ │ └── allure_parser.py │ ├── prompts/ # 提示词模板 │ │ ├── system_prompt.j2 │ │ └── user_prompt.j2 │ ├── llm_clients/ # LLM 客户端 │ │ ├── __init__.py │ │ ├── base.py │ │ ├── openai_client.py │ │ └── ollama_client.py │ ├── formatters/ # 输出格式化 │ │ ├── __init__.py │ │ ├── markdown_formatter.py │ │ └── html_formatter.py │ └── main.py # 主入口CLI 或 HTTP Server ├── config.yaml # 配置文件 ├── requirements.txt # 依赖 ├── Dockerfile └── README.md编写核心逻辑按照前面章节的设计实现各个模块。主入口main.py提供一个命令行接口例如python -m src.main \ --parser allure \ --source ./allure-results \ --audience pm \ --detail brief \ --output ./report.md容器化编写Dockerfile将 Skill 打包成镜像便于在 Jenkins Agent 等环境中一致地运行。4.2 集成到 Jenkins Pipeline在 Jenkinsfile 中在测试阶段之后添加一个生成报告的步骤。pipeline { agent any stages { stage(‘Checkout’) { ... } stage(‘Build’) { ... } stage(‘Test’) { steps { sh ‘pytest --alluredirallure-results ./tests’ } post { always { // 无论测试成功与否都生成报告 script { // 运行我们的 Skill 容器 sh ‘“’“ docker run --rm \ -v “${WORKSPACE}/allure-results:/data/input” \ -v “${WORKSPACE}:/data/output” \ -e OPENAI_API_KEY”\${OPENAI_API_KEY}” \ my-registry/auto-test-report-skill:latest \ --parser allure \ --source /data/input \ --output /data/output/test-report-${BUILD_NUMBER}.md “’“’ } // 可选将 Markdown 转换为 HTML sh ‘pandoc test-report-${BUILD_NUMBER}.md -o test-report-${BUILD_NUMBER}.html’ // 归档报告 archiveArtifacts artifacts: ‘test-report-*.html, test-report-*.md’, fingerprint: true } } } } }4.3 集成到本地开发流程除了 CI/CD这个 Skill 也可以用于本地开发。可以在项目的Makefile或justfile中添加一个命令.PHONY: test-report test-report: pytest --alluredir./.allure-results ./tests python -m src.main \ --parser allure \ --source ./.allure-results \ --audience developer \ --output ./local-test-report.md echo “报告已生成: ./local-test-report.md”开发者运行make test-report后不仅能跑测试还能立刻得到一份 AI 分析的详细报告快速了解本次改动的影响。5. 常见问题、优化方向与避坑指南在实际搭建和使用过程中我遇到了不少问题也总结出一些优化思路。5.1 典型问题与排查问题现象可能原因排查与解决思路LLM 生成的报告内容空洞、重复1. 提示词指令不够具体。2. 输入给 LLM 的测试数据上下文过于简单只有统计数字没有用例详情。3. 模型温度temperature参数过高导致随机性大。1. 细化系统指令明确要求“对比历史数据”、“分析失败模式”。2. 确保用户提示词中包含了有代表性的失败用例详情即使只有几个。3. 将temperature调低至 0.1-0.3增加确定性。报告中出现“幻觉”描述了不存在的测试模块或问题LLM 过度“发挥”基于训练数据中的模式进行了推断。1. 在系统指令中反复强调“严格基于提供的数据”。2. 在用户提示词开头或结尾再次用加粗强调这一点。3. 对于关键结论如“核心功能模块A存在严重缺陷”可以让 LLM 必须引用数据中的具体用例名称来支撑其论断。调用 LLM API 超时或返回速率限制错误1. 网络问题。2. 请求的上下文Token 数太长生成时间超时。3. 免费账号或低层级 API 密钥有 RPM每分钟请求数限制。1. 实现重试机制如 exponential backoff。2. 优化上下文减少不必要的细节。对长日志进行摘要。3. 监控 API 使用情况考虑升级套餐或使用多个 Key 负载均衡。对于本地模型检查 Ollama 等服务是否内存不足。解析 Allure 结果时某些自定义标签或附件信息丢失解析器没有处理 Allure JSON 中的所有字段。1. 查阅 Allure JSON 格式规范完善解析逻辑。2. 将自定义标签如severity_critical解析到TestCase.tags中并在提示词中要求 LLM 特别关注高严重性的用例。集成到 Jenkins 后Docker 容器内无法访问宿主机上的测试结果文件Docker 卷挂载路径错误或权限问题。1. 仔细检查-v参数确保宿主机路径和容器内路径对应正确。2. 在 Jenkins Agent 上使用pwd命令确认当前工作目录。3. 简单测试在容器内运行ls -la /data/input查看文件是否存在。5.2 性能与成本优化缓存与差分报告如果两次测试之间只有少量用例发生变化可以缓存上一次的详细解析结果和 LLM 生成的报告。第二次运行时只将变化的用例信息发送给 LLM让它生成一个“差分报告”重点说明新增的失败或恢复的用例。这能大幅减少 Token 消耗和生成时间。模型选择对于日常的、格式固定的报告可以使用更便宜、更快的模型如gpt-3.5-turbo。对于重要的发布前测试或复杂的失败分析再切换到能力更强的模型如gpt-4。可以在配置中根据测试结果的重要性动态选择模型。异步与队列在 CI 高并发场景下报告生成可能成为瓶颈。可以将报告生成任务推送到一个内部队列如 Redis RQ 或 Celery由后台 Worker 异步处理避免阻塞 CI 流水线。5.3 扩展性与高级功能多维度分析除了测试结果还可以接入其他数据源如代码变更Git Diff关联失败用例与最近修改的代码文件提示开发者可能的影响范围。性能数据如果有效能测试可以将接口响应时间、吞吐量等指标纳入报告让 LLM 分析性能退化。历史趋势接入数据库获取历史通过率曲线让 LLM 分析本次测试结果在趋势中的位置。自定义规则与检查点允许用户定义一些规则例如“如果核心模块的通过率低于 95%则报告标题必须标记为【高风险】”。这些规则可以在 LLM 生成报告前或生成后作为硬性检查点。交互式报告生成的 HTML 报告可以不仅仅是静态文本。可以嵌入一些简单的交互元素比如点击失败用例名称展开详细日志或者通过按钮触发对该用例的“根因分析”发起另一轮更聚焦的 LLM 查询。最后一点个人体会自建这样一个 Skill 最大的价值不在于完全取代测试人员撰写报告而在于将人从信息搬运和格式整理的体力劳动中解放出来让我们能更专注于 LLM 不擅长的部分复杂的逻辑推理、与开发人员的深度沟通、以及基于业务上下文和团队经验的最终决策。它更像一个不知疲倦的初级分析师帮你完成了数据清洗和初稿而你把关最终的质量和方向。在实现过程中对提示词的打磨、对数据边界的处理其本身也是对测试分析和总结能力的又一次深度思考。 基于LLM与OpenClaw框架的自动化测试报告生成Skill设计与实践
1. 项目概述为什么我们需要一个“自动写测试报告”的 Skill在软件开发和测试的日常里写测试报告这件事说大不大说小不小但绝对是个“脏活累活”。想象一下这个场景你刚跑完一轮包含上百个用例的自动化测试Jenkins 的控制台输出了一长串日志Allure 生成了漂亮的图表但你还得手动去整理“本次测试覆盖了哪些模块”、“发现了几个 Bug”、“阻塞问题是什么”、“建议下一步怎么做”。这个过程枯燥、重复还容易因为疲劳而出错特别是当测试频率很高比如每天都有多次构建时写报告的时间甚至可能超过分析问题的时间。这就是我决定动手自建一个“自动写测试报告” Skill 的初衷。它不是一个独立的庞大系统而是一个可以嵌入到现有 CI/CD 流水线或测试框架中的智能小工具。它的核心目标很明确将结构化的测试结果数据如 JUnit XML、Allure JSON和自然语言的需求如“生成一份给项目经理看的概要报告”自动转换为一篇逻辑清晰、重点突出、可直接交付的测试报告文档。这背后依赖的关键技术正是当前大热的 LLM大语言模型。我们不是让 LLM 凭空创造而是让它扮演一个“高级测试分析员”的角色基于我们提供的“事实”测试数据和“模板”报告框架进行信息提炼、总结归纳和风险提示。最近在开发者社区里像OpenClaw、dify这类 LLM 应用框架以及skill这种可插拔功能模块的概念非常流行。我这个项目本质上就是在打造一个专属于测试领域的skill。它接收测试数据调用 LLM 的推理和文本生成能力输出符合要求的报告。这不仅能将测试人员从重复劳动中解放出来更能通过 LLM 的“洞察力”发现一些人工浏览日志时可能忽略的关联模式或潜在风险提升报告的价值。2. 整体设计与核心思路拆解2.1 技能Skill的定位与边界首先得明确这个“自动写测试报告”是一个Skill而不是一个Platform或Framework。这意味着它应该轻量、专注、易于集成。它的输入和输出必须定义得非常清晰输入结构化的测试结果数据 可选的自然语言指令。输出一份格式良好的测试报告Markdown / HTML / Word。它的边界在于不负责执行测试用例那是 Jenkins、GitLab CI、pytest、Playwright 等工具的事也不负责深度分析代码缺陷那是 APM、日志分析平台的事。它的职责是“翻译”和“总结”。基于这个定位技术选型上就会倾向于选择那些擅长处理结构化任务、支持函数调用Function Calling或具备较强长文本理解能力的 LLM 服务或本地模型。2.2 核心架构与工作流设计整个 Skill 的工作流可以分解为以下几个核心阶段我将其设计为一个可配置的管道Pipeline数据采集与标准化这是基石。测试报告的质量首先取决于输入数据的质量。Skill 需要适配多种测试框架的输出格式如 JUnit XML、Allure 结果目录、pytest-html 报告等。这一步需要将它们解析并统一转换为一个内部的、结构化的数据模型例如一个包含TestSuite,TestCase,Status,Duration,ErrorLog等字段的 JSON 对象。这步工作相对传统但鲁棒性很重要要能处理各种边缘情况比如被截断的日志、异常字符等。指令解析与上下文构建用户可能通过简单指令来定制报告例如“写一份给开发看的详细报告重点列出失败的用例和错误日志”或“生成一份给产品经理的简报只关注通过率和核心功能点”。Skill 需要解析这些指令并将其转化为对 LLM 的“提示词Prompt”。同时将上一步得到的标准化测试数据以清晰的方式如结构化摘要、关键数据表格组织进提示词的上下文Context中。这里的一个关键技巧是如何在有限的上下文窗口内既包含足够的信息又避免冗余。LLM 调用与报告生成这是智能核心。将构建好的提示词和上下文发送给 LLM。这里的选择很多云端 API如 OpenAI GPT-4 Claude 文心一言等。优势是能力强、开箱即用但涉及数据隐私和持续成本。本地模型如通过Ollama部署的Llama 3、Qwen等。优势是数据完全本地、无网络依赖但对硬件有要求且模型能力可能稍逊于顶级云端模型。专用框架如OpenClaw、LangChain。它们提供了更高级的抽象比如工具调用、工作流编排。OpenClaw近期社区热度很高它强调的Agent和Skill概念与本项目非常契合可以基于它来封装这个报告生成能力使其更容易被其他智能体调用。 我的选择是在原型阶段使用云端 API 快速验证效果在成熟期提供配置项允许用户选择接入云端 API 或指定的本地模型服务。提示词工程是这里的重中之重需要精心设计系统指令System Prompt和用户指令User Prompt引导 LLM 扮演好“测试分析师”的角色。后处理与格式输出LLM 返回的通常是纯文本。我们需要将其转换为更友好的格式。例如识别 LLM 输出的 Markdown 格式并将其渲染为 HTML或者集成像python-docx这样的库直接生成 Word 文档。也可以支持将报告上传到 Confluence、钉钉/飞书群等协作平台。2.3 技术栈选型考量后端语言Python是首选。它在测试自动化领域生态丰富pytest, requests, selenium数据处理库强大pandas, json并且是大多数 LLM 框架和库OpenAI SDK, LangChain,OpenClaw的主要支持语言。LLM 交互层初期直接使用openai或anthropic的官方 SDK 最简单。如果考虑更复杂的流程控制如多步推理、条件判断LangChain或OpenClaw这类框架会更有优势。特别是OpenClaw其Skill的设计理念可以直接复用。数据解析根据要支持的测试报告格式选用相应的解析库如xml.etree.ElementTree处理 JUnitjson库处理 Allure 的 JSON 文件。部署与集成最终这个 Skill 应该打包成一个 Docker 镜像可以通过环境变量配置 API Key、模型选择等。它提供简单的 HTTP API如 FastAPI 实现方便被 Jenkins Pipeline、GitLab CI.gitlab-ci.yml文件或任何脚本调用。注意关于OpenClaw的热词与潜在问题在搜索热词中看到了openclaw安装、openclaw部署以及错误信息openclaw llamap svr operator(): got exception。这提示我们如果选择基于OpenClaw开发需要仔细处理其部署依赖和运行时环境。那个400错误很可能是在调用其内部服务时请求参数不合法或服务未正确启动导致的。在自建 Skill 时如果依赖此类外部框架必须将其稳定性作为风险点考虑做好降级处理例如当OpenClaw服务不可用时回退到直接调用 LLM API。3. 核心模块详解与实现要点3.1 数据采集与标准化模块这个模块是流水线的源头必须健壮。我设计了一个插件化的架构来支持不同数据源。核心数据模型定义 首先定义一个内部通用的TestResult数据类这里用 Pydantic 模型示意因为它能提供良好的类型提示和数据验证。from pydantic import BaseModel from enum import Enum from typing import List, Optional from datetime import datetime class TestStatus(str, Enum): PASSED “passed” FAILED “failed” SKIPPED “skipped” BROKEN “broken” # 可能表示测试环境问题导致的失败 class TestCase(BaseModel): name: str suite: str # 所属测试集/类名 status: TestStatus duration: float # 单位秒 error_message: Optional[str] None stack_trace: Optional[str] None logs: Optional[str] None # 额外的自定义日志 tags: List[str] [] # 可用于分类如 “smoke”, “api” class TestExecution(BaseModel): project_name: str start_time: datetime end_time: datetime total_cases: int passed_cases: int failed_cases: int skipped_cases: int test_cases: List[TestCase] # 所有用例的详情 environment: dict {} # 测试环境信息如 {“browser”: “chrome 120”, “env”: “staging”}插件化解析器实现 为每种支持的格式实现一个解析器类它们都继承自一个基类ResultParser。from abc import ABC, abstractmethod import xml.etree.ElementTree as ET import json from pathlib import Path class ResultParser(ABC): abstractmethod def parse(self, source_path: str) - TestExecution: “”“将源文件/目录解析为统一的 TestExecution 对象。”“” pass class JUnitXmlParser(ResultParser): def parse(self, xml_path: str) - TestExecution: tree ET.parse(xml_path) root tree.getroot() test_cases [] for suite in root.findall(‘testsuite’): suite_name suite.get(‘name’, ‘unknown’) for case in suite.findall(‘testcase’): case_name case.get(‘name’) duration float(case.get(‘time’, 0)) status TestStatus.PASSED error_msg None # JUnit 中失败用 failure错误用 error failure case.find(‘failure’) error case.find(‘error’) if failure is not None: status TestStatus.FAILED error_msg failure.get(‘message’, ‘’) ‘\n’ failure.text if failure.text else ‘’ elif error is not None: status TestStatus.BROKEN error_msg error.get(‘message’, ‘’) ‘\n’ error.text if error.text else ‘’ # 处理 skipped? 有些框架用 skipped 标签 test_cases.append(TestCase( namecase_name, suitesuite_name, statusstatus, durationduration, error_messageerror_msg )) # 计算统计数据 total len(test_cases) passed sum(1 for c in test_cases if c.status TestStatus.PASSED) failed sum(1 for c in test_cases if c.status TestStatus.FAILED) # 这里简化了时间实际应从 XML 属性或文件时间获取 return TestExecution( project_namePath(xml_path).stem, start_timedatetime.now(), end_timedatetime.now(), total_casestotal, passed_casespassed, failed_casesfailed, skipped_casestotal - passed - failed, test_casestest_cases ) class AllureResultParser(ResultParser): # Allure 结果是一系列 JSON 文件通常在一个目录里 def parse(self, results_dir: str) - TestExecution: # 实现遍历 results_dir 下的 *.json 文件解析每个测试用例的详细结果 # 逻辑比 JUnit 复杂因为信息更分散但能获取更丰富的步骤step和附件信息 pass实操心得日志处理错误日志和堆栈信息可能很长直接全塞给 LLM 会浪费上下文。这里需要做一个智能摘要提取关键错误行如包含 “Error:”, “Exception:”, “failed assertion” 的行并截取前 N 行和后 N 行。可以写一个简单的函数来处理。性能考量如果测试用例数量极大上万在内存中保存所有TestCase详情可能压力大。可以考虑两种模式“完整模式”用于详细报告“摘要模式”只统计数量和采样部分失败用例详情用于生成概览报告。环境信息务必收集测试环境信息如代码版本号、测试服务器 IP、数据库版本等。这些信息对于问题复现至关重要也是报告的有价值组成部分。可以从环境变量、配置文件或通过运行时 API 获取。3.2 提示词工程与上下文构建模块这是决定报告质量的核心。我们不能简单地把一堆 JSON 丢给 LLM 说“写个报告”。需要精心设计提示词。系统指令System Prompt设计 系统指令用于设定 LLM 的角色和行为规范。它应该相对稳定。你是一位资深的软件测试工程师和质量分析师。你的任务是根据提供的测试执行结果数据生成专业、清晰、有针对性的测试报告。 请严格遵守以下要求 1. **基于事实**报告中的所有结论、数据和描述必须严格基于我提供的测试结果数据。不要捏造或推断不存在的信息。 2. **结构清晰**报告应至少包含概述测试目标、时间、环境、数据总览通过率、耗时统计、详细分析重点分析失败/阻塞的用例、风险与建议、附录可选。 3. **语气专业**根据报告受众调整语气。给开发者的报告可以更技术化直接引用错误日志给项目经理的报告应更关注整体质量、风险和进度影响。 4. **突出重点**优先分析和呈现失败FAILED和异常中断BROKEN的用例。对于通过的用例可以分类总结无需逐一列出。 5. **提供洞察**尝试从失败用例中归纳共同点例如是否集中在某个模块、某种类型的接口、特定的数据条件并提出具体的排查建议或后续测试重点。 输出格式请使用 Markdown以便后续渲染。用户指令与上下文构建 用户指令包含本次请求的具体要求和注入的数据。请生成一份测试报告。 **报告受众**项目开发团队与测试负责人。 **报告详细程度**详细。需要列出所有失败用例的名称、所属模块和错误摘要。 **特别关注点**请分析失败用例是否与最近更新的“用户支付”模块相关。 以下是本次测试执行的详细结果数据 ## 测试执行概览 - 项目名称{{project_name}} - 测试环境{{environment | tojson}} - 开始时间{{start_time}} - 结束时间{{end_time}} - 总用例数{{total_cases}} - 通过数{{passed_cases}} (通过率{{”%.1f%%”|format(passed_cases/total_cases*100)}}) - 失败数{{failed_cases}} - 跳过数{{skipped_cases}} - 总耗时{{”%.1f”|format(sum(c.duration for c in test_cases))}} 秒 ## 失败用例详情前10个按耗时降序 {% for case in test_cases if case.status “failed” %} ### {{case.suite}}::{{case.name}} - **状态**: {{case.status}} - **耗时**: {{case.duration}}秒 - **错误摘要**: {{case.error_message | truncate(200)}} {% endfor %} ## 所有用例状态分布 此处可以是一个简单的 Markdown 表格展示各个 Suite 的通过/失败情况 请基于以上数据生成报告。实现要点模板引擎如上所示我使用了类似 Jinja2 的模板语法来动态生成用户消息。这样可以将数据模型灵活地填充到预设的模板中。Python 的jinja2库完美胜任。上下文长度管理这是最大的挑战之一。如果失败用例有几百个每个的日志都很长很容易超出模型的上下文窗口。策略有摘要与采样只发送前 N 个失败用例的完整信息其余的仅统计数量。分层处理先让 LLM 基于摘要数据生成报告大纲和核心结论再针对它提出的需要深挖的特定失败用例发起第二轮查询获取详细日志。这需要更复杂的 Agent 工作流OpenClaw或LangChain在这类多步推理上有优势。外部知识库将详细的测试日志存储到向量数据库如 Chroma当 LLM 需要分析某个具体失败时通过检索增强生成RAG的方式获取相关内容。但这增加了系统复杂度。指令参数化将“受众”、“详细程度”、“特别关注点”作为 Skill 的可配置参数允许调用方动态指定。3.3 LLM 服务集成与调用模块这一模块负责与选定的 LLM 服务进行通信。为了灵活性我设计了一个通用的LLMClient抽象类。from abc import ABC, abstractmethod import openai from openai import OpenAI import anthropic import os from typing import List, Dict, Any class LLMClient(ABC): abstractmethod def generate_report(self, system_prompt: str, user_prompt: str) - str: “”“调用 LLM传入系统提示和用户提示返回生成的报告文本。”“” pass class OpenAIClient(LLMClient): def __init__(self, model: str “gpt-4-turbo-preview”, api_key: str None): self.client OpenAI(api_keyapi_key or os.getenv(“OPENAI_API_KEY”)) self.model model def generate_report(self, system_prompt: str, user_prompt: str) - str: try: response self.client.chat.completions.create( modelself.model, messages[ {“role”: “system”, “content”: system_prompt}, {“role”: “user”, “content”: user_prompt} ], temperature0.2, # 温度设低保证报告稳定性避免创造性过强 max_tokens4000 # 根据模型和需要调整 ) return response.choices[0].message.content except Exception as e: # 记录日志并可能触发降级策略 raise RuntimeError(f“调用 OpenAI API 失败: {e}”) class ClaudeClient(LLMClient): def __init__(self, model: str “claude-3-sonnet-20240229”, api_key: str None): self.client anthropic.Anthropic(api_keyapi_key or os.getenv(“ANTHROPIC_API_KEY”)) self.model model # … 类似的实现 class OllamaClient(LLMClient): def __init__(self, base_url: str “http://localhost:11434”, model: str “llama3”): self.base_url base_url self.model model # 可以使用 requests 或 ollama 官方 python 库 def generate_report(self, system_prompt: str, user_prompt: str) - str: # 将 system_prompt 和 user_prompt 组合成 Ollama 支持的格式 combined_prompt f“{system_prompt}\n\n{user_prompt}” # 调用 Ollama 的 generate API pass配置与工厂模式 在 Skill 的主配置文件中可以指定使用哪个客户端。# config.yaml llm: provider: “openai” # 可选openai, claude, ollama, openclaw_proxy model: “gpt-4-turbo” api_key: ${ENV_OPENAI_KEY} # 支持从环境变量读取 base_url: “https://api.openai.com/v1” # 对于 Ollama 或自部署模型修改此项 report: default_audience: “developer” default_detail_level: “normal” output_format: “markdown” # markdown, html, docx然后在代码中使用工厂方法创建对应的客户端实例。重要提示关于OpenClaw集成的思考如果社区生态成熟将本 Skill 封装为一个OpenClaw Skill会非常有价值。这意味着我们的报告生成能力可以被任何基于OpenClaw的智能体Agent调用。例如一个监控 CI 流水线的 Agent在检测到测试失败后可以自动调用本 Skill 生成报告然后将其发送到钉钉群。这需要遵循OpenClaw的 Skill 开发规范通常需要定义一个清晰的输入/输出 Schema并注册到OpenClaw的框架中。热词中提到的openclaw llamap svr operator(): got exception错误提醒我们在集成时要特别注意服务发现、API 版本兼容性和错误处理。3.4 报告后处理与输出模块LLM 返回的是 Markdown 文本我们可以根据需求进行进一步加工。格式转换Markdown 转 HTML使用markdown库或mistune可以轻松转换。可以结合pygments实现代码高亮。Markdown 转 Word使用python-docx库需要解析 Markdown 语法并映射到 Word 的段落、标题、表格等样式。这是一个相对复杂但体验很好的功能。直接输出 Markdown最简单可以集成到支持 Markdown 的 Wiki如 GitLab Wiki或文档系统。样式与品牌化 可以为 HTML 报告注入自定义 CSS使其符合公司或团队的视觉规范。对于 Word可以预定义.dotx模板文件生成时应用模板中的样式。分发集成文件系统保存到指定目录Jenkins 等 CI 工具可以将其归档为构建产物。邮件发送将 HTML 报告作为邮件正文发送给相关干系人。Webhook 推送将报告内容通过飞书、钉钉、企业微信等平台的机器人 Webhook 发送到群聊。注意消息长度限制过长的报告可能需要先上传为文件再发送文件链接。Confluence 等 Wiki调用 Confluence REST API 创建或更新页面。4. 完整实操流程从零搭建并集成到 CI/CD假设我们为一个使用pytest框架并通过Allure生成报告的 Python 项目搭建这个 Skill并集成到 Jenkins 流水线中。4.1 环境准备与 Skill 开发创建项目结构auto-test-report-skill/ ├── src/ │ ├── __init__.py │ ├── models.py # 数据模型 (TestExecution, TestCase) │ ├── parsers/ # 解析器插件 │ │ ├── __init__.py │ │ ├── base.py │ │ ├── junit_parser.py │ │ └── allure_parser.py │ ├── prompts/ # 提示词模板 │ │ ├── system_prompt.j2 │ │ └── user_prompt.j2 │ ├── llm_clients/ # LLM 客户端 │ │ ├── __init__.py │ │ ├── base.py │ │ ├── openai_client.py │ │ └── ollama_client.py │ ├── formatters/ # 输出格式化 │ │ ├── __init__.py │ │ ├── markdown_formatter.py │ │ └── html_formatter.py │ └── main.py # 主入口CLI 或 HTTP Server ├── config.yaml # 配置文件 ├── requirements.txt # 依赖 ├── Dockerfile └── README.md编写核心逻辑按照前面章节的设计实现各个模块。主入口main.py提供一个命令行接口例如python -m src.main \ --parser allure \ --source ./allure-results \ --audience pm \ --detail brief \ --output ./report.md容器化编写Dockerfile将 Skill 打包成镜像便于在 Jenkins Agent 等环境中一致地运行。4.2 集成到 Jenkins Pipeline在 Jenkinsfile 中在测试阶段之后添加一个生成报告的步骤。pipeline { agent any stages { stage(‘Checkout’) { ... } stage(‘Build’) { ... } stage(‘Test’) { steps { sh ‘pytest --alluredirallure-results ./tests’ } post { always { // 无论测试成功与否都生成报告 script { // 运行我们的 Skill 容器 sh ‘“’“ docker run --rm \ -v “${WORKSPACE}/allure-results:/data/input” \ -v “${WORKSPACE}:/data/output” \ -e OPENAI_API_KEY”\${OPENAI_API_KEY}” \ my-registry/auto-test-report-skill:latest \ --parser allure \ --source /data/input \ --output /data/output/test-report-${BUILD_NUMBER}.md “’“’ } // 可选将 Markdown 转换为 HTML sh ‘pandoc test-report-${BUILD_NUMBER}.md -o test-report-${BUILD_NUMBER}.html’ // 归档报告 archiveArtifacts artifacts: ‘test-report-*.html, test-report-*.md’, fingerprint: true } } } } }4.3 集成到本地开发流程除了 CI/CD这个 Skill 也可以用于本地开发。可以在项目的Makefile或justfile中添加一个命令.PHONY: test-report test-report: pytest --alluredir./.allure-results ./tests python -m src.main \ --parser allure \ --source ./.allure-results \ --audience developer \ --output ./local-test-report.md echo “报告已生成: ./local-test-report.md”开发者运行make test-report后不仅能跑测试还能立刻得到一份 AI 分析的详细报告快速了解本次改动的影响。5. 常见问题、优化方向与避坑指南在实际搭建和使用过程中我遇到了不少问题也总结出一些优化思路。5.1 典型问题与排查问题现象可能原因排查与解决思路LLM 生成的报告内容空洞、重复1. 提示词指令不够具体。2. 输入给 LLM 的测试数据上下文过于简单只有统计数字没有用例详情。3. 模型温度temperature参数过高导致随机性大。1. 细化系统指令明确要求“对比历史数据”、“分析失败模式”。2. 确保用户提示词中包含了有代表性的失败用例详情即使只有几个。3. 将temperature调低至 0.1-0.3增加确定性。报告中出现“幻觉”描述了不存在的测试模块或问题LLM 过度“发挥”基于训练数据中的模式进行了推断。1. 在系统指令中反复强调“严格基于提供的数据”。2. 在用户提示词开头或结尾再次用加粗强调这一点。3. 对于关键结论如“核心功能模块A存在严重缺陷”可以让 LLM 必须引用数据中的具体用例名称来支撑其论断。调用 LLM API 超时或返回速率限制错误1. 网络问题。2. 请求的上下文Token 数太长生成时间超时。3. 免费账号或低层级 API 密钥有 RPM每分钟请求数限制。1. 实现重试机制如 exponential backoff。2. 优化上下文减少不必要的细节。对长日志进行摘要。3. 监控 API 使用情况考虑升级套餐或使用多个 Key 负载均衡。对于本地模型检查 Ollama 等服务是否内存不足。解析 Allure 结果时某些自定义标签或附件信息丢失解析器没有处理 Allure JSON 中的所有字段。1. 查阅 Allure JSON 格式规范完善解析逻辑。2. 将自定义标签如severity_critical解析到TestCase.tags中并在提示词中要求 LLM 特别关注高严重性的用例。集成到 Jenkins 后Docker 容器内无法访问宿主机上的测试结果文件Docker 卷挂载路径错误或权限问题。1. 仔细检查-v参数确保宿主机路径和容器内路径对应正确。2. 在 Jenkins Agent 上使用pwd命令确认当前工作目录。3. 简单测试在容器内运行ls -la /data/input查看文件是否存在。5.2 性能与成本优化缓存与差分报告如果两次测试之间只有少量用例发生变化可以缓存上一次的详细解析结果和 LLM 生成的报告。第二次运行时只将变化的用例信息发送给 LLM让它生成一个“差分报告”重点说明新增的失败或恢复的用例。这能大幅减少 Token 消耗和生成时间。模型选择对于日常的、格式固定的报告可以使用更便宜、更快的模型如gpt-3.5-turbo。对于重要的发布前测试或复杂的失败分析再切换到能力更强的模型如gpt-4。可以在配置中根据测试结果的重要性动态选择模型。异步与队列在 CI 高并发场景下报告生成可能成为瓶颈。可以将报告生成任务推送到一个内部队列如 Redis RQ 或 Celery由后台 Worker 异步处理避免阻塞 CI 流水线。5.3 扩展性与高级功能多维度分析除了测试结果还可以接入其他数据源如代码变更Git Diff关联失败用例与最近修改的代码文件提示开发者可能的影响范围。性能数据如果有效能测试可以将接口响应时间、吞吐量等指标纳入报告让 LLM 分析性能退化。历史趋势接入数据库获取历史通过率曲线让 LLM 分析本次测试结果在趋势中的位置。自定义规则与检查点允许用户定义一些规则例如“如果核心模块的通过率低于 95%则报告标题必须标记为【高风险】”。这些规则可以在 LLM 生成报告前或生成后作为硬性检查点。交互式报告生成的 HTML 报告可以不仅仅是静态文本。可以嵌入一些简单的交互元素比如点击失败用例名称展开详细日志或者通过按钮触发对该用例的“根因分析”发起另一轮更聚焦的 LLM 查询。最后一点个人体会自建这样一个 Skill 最大的价值不在于完全取代测试人员撰写报告而在于将人从信息搬运和格式整理的体力劳动中解放出来让我们能更专注于 LLM 不擅长的部分复杂的逻辑推理、与开发人员的深度沟通、以及基于业务上下文和团队经验的最终决策。它更像一个不知疲倦的初级分析师帮你完成了数据清洗和初稿而你把关最终的质量和方向。在实现过程中对提示词的打磨、对数据边界的处理其本身也是对测试分析和总结能力的又一次深度思考。