Qwen1.5-1.8B GPTQ实战案例：自动化软件测试报告生成

Qwen1.5-1.8B GPTQ实战案例自动化软件测试报告生成每次跑完一轮自动化测试面对满屏的日志文件和一堆“PASSED”、“FAILED”状态你是不是也感到头疼手动整理测试结果、分析失败原因、编写测试报告这些工作既繁琐又耗时还容易出错。最近我们尝试将Qwen1.5-1.8B GPTQ模型引入到团队的软件测试流程中用它来自动化处理这些重复性工作。效果怎么样简单来说原本需要半小时手动整理的测试报告现在几分钟就能自动生成而且内容更清晰、分析更到位。这篇文章我就来分享一下我们是怎么做的以及在实际项目中遇到了哪些坑、怎么解决的。如果你也在为测试报告发愁不妨看看这个思路。1. 为什么需要AI来生成测试报告在聊具体怎么做之前我们先看看传统测试报告生成有哪些痛点。首先是信息碎片化。自动化测试工具比如JUnit、pytest、Selenium它们输出的结果往往是分散的。你可能有一个XML格式的测试结果文件一个文本格式的日志文件还有一堆截图。把这些信息拼凑成一份人类能轻松理解的报告本身就是一个体力活。其次是分析深度不够。工具生成的报告通常只会告诉你“哪个用例失败了”但很少会告诉你“为什么失败”。是数据问题环境问题还是代码逻辑有缺陷测试人员需要自己去翻看堆栈跟踪和日志一点点分析这个过程非常依赖个人经验。最后是效率瓶颈。在敏捷开发或持续集成环境中测试可能每天甚至每小时都在跑。如果每次都要人工去汇总和分析测试人员的时间就被牢牢绑在了重复劳动上很难去做更有价值的探索性测试或质量体系建设。我们引入Qwen1.5-1.8B GPTQ模型目标很明确让机器去做信息的提取、整合和初步分析让人去做最终的决策和深度问题排查。这个1.8B参数的模型经过GPTQ量化后对资源要求不高可以在普通的测试服务器甚至开发机上快速运行非常适合这种“辅助型”任务。2. 搭建你的自动化报告生成流水线想法很好但具体怎么落地呢下面是我们搭建的一个基础流水线你可以根据自己的项目情况调整。2.1 核心思路与准备工作我们的核心思路是“收集-处理-生成”三步走收集在自动化测试执行完毕后将所有的原始输出结果文件、日志、截图路径等收集到一个地方。处理用Python脚本读取这些原始数据进行必要的清洗和格式化然后构造一个清晰的提示词Prompt交给Qwen模型。生成模型根据提示词输出结构化的测试报告摘要。你需要准备两样东西Qwen1.5-1.8B GPTQ模型可以从常用的模型社区获取已经量化好的版本。GPTQ量化大大降低了模型对显存的需求使得在消费级显卡上运行成为可能。一个能运行该模型的推理框架比如transformers库搭配auto-gptq或者一些集成了GPU推理的Web框架。我们选择的是transformersauto-gptq因为比较灵活。首先安装必要的库pip install transformers torch auto-gptq2.2 从原始日志到模型输入数据预处理模型看不懂原始的XML或杂乱的日志我们需要把数据“喂”得优雅一些。假设我们有一次JUnit测试生成的test-results.xml和一个对应的执行日志test-run.log。我们写一个预处理脚本import xml.etree.ElementTree as ET import re def parse_junit_xml(xml_path): 解析JUnit XML格式的测试结果文件 tree ET.parse(xml_path) root tree.getroot() total_tests int(root.attrib.get(tests, 0)) failures int(root.attrib.get(failures, 0)) errors int(root.attrib.get(errors, 0)) skipped int(root.attrib.get(skipped, 0)) test_cases [] for testcase in root.findall(.//testcase): case_info { classname: testcase.attrib.get(classname), name: testcase.attrib.get(name), time: testcase.attrib.get(time), status: PASSED } # 检查是否有失败或错误 if testcase.find(failure) is not None: case_info[status] FAILED failure testcase.find(failure) case_info[failure_message] failure.attrib.get(message, ) # 截取堆栈跟踪的前几行避免过长 case_info[failure_trace] failure.text[:500] if failure.text else elif testcase.find(error) is not None: case_info[status] ERROR error testcase.find(error) case_info[error_message] error.attrib.get(message, ) case_info[error_trace] error.text[:500] if error.text else test_cases.append(case_info) return { summary: {total: total_tests, failures: failures, errors: errors, skipped: skipped}, test_cases: test_cases } def extract_key_logs(log_path, line_limit50): 从日志文件中提取关键错误或异常行 key_lines [] error_patterns [rERROR, rException, rFAILED, rAssertionError] with open(log_path, r, encodingutf-8) as f: for i, line in enumerate(f): if any(re.search(pattern, line, re.IGNORECASE) for pattern in error_patterns): key_lines.append(fLine {i1}: {line.strip()}) if len(key_lines) line_limit: break return key_lines[:line_limit] # 使用示例 junit_data parse_junit_xml(test-results.xml) key_logs extract_key_logs(test-run.log) print(f测试总数{junit_data[summary][total]}) print(f失败用例{junit_data[summary][failures]})这个脚本做了两件事一是从XML中提取结构化的测试结果二是从日志中过滤出可能相关的错误信息。这样我们就得到了模型可以理解的“素材”。2.3 构造提示词告诉模型你要什么这是最关键的一步。模型的表现很大程度上取决于你如何提问。我们的目标是让模型生成一份包含总结、失败分析和建议的报告。def build_report_prompt(junit_data, key_logs): 构建用于生成测试报告的提示词 failed_cases [c for c in junit_data[test_cases] if c[status] in [FAILED, ERROR]] prompt f 你是一个资深的软件测试工程师。请根据以下自动化测试结果数据生成一份简洁、专业的测试报告摘要。 ### 测试执行概要 - 总用例数{junit_data[summary][total]} - 通过数{junit_data[summary][total] - junit_data[summary][failures] - junit_data[summary][errors]} - 失败数{junit_data[summary][failures]} - 错误数{junit_data[summary][errors]} - 跳过数{junit_data[summary][skipped]} ### 失败的测试用例详情共{len(failed_cases)}个 for i, case in enumerate(failed_cases[:5]): # 限制前5个避免提示词过长 prompt f{i1}. **{case[classname]}.{case[name]}** - 状态{case[status]}\n if case.get(failure_message): prompt f 失败信息{case[failure_message]}\n if case.get(failure_trace): prompt f 堆栈摘要{case[failure_trace]}\n if case.get(error_message): prompt f 错误信息{case[error_message]}\n if key_logs: prompt f\n### 相关的系统日志片段可能有助于分析\n prompt \n.join(key_logs[:10]) # 限制日志行数 prompt ### 请生成报告需包含以下部分 1. **整体结论**用一两句话总结本次测试通过率及整体质量。 2. **主要问题分析**归纳失败用例中反映出的共性或主要问题类型如网络超时、数据断言失败、元素未找到等。 3. **根因推测**结合失败信息和日志对最关键的1-2个失败用例进行根因推测。 4. **下一步行动建议**给开发或测试人员提出具体的后续操作建议如优先修复哪个模块、需要补充什么测试等。 报告语言请使用中文表述清晰、专业。 return prompt # 构建提示词 report_prompt build_report_prompt(junit_data, key_logs) print(提示词长度, len(report_prompt))这个提示词明确了角色、提供了结构化数据、并给出了具体的输出要求。这样模型生成的内容就会比较可控。3. 调用模型生成报告数据准备好了提示词也构造好了接下来就是调用模型。from transformers import AutoTokenizer, AutoModelForCausalLM, pipeline def load_model_and_generate(prompt, model_name_or_pathQwen/Qwen1.5-1.8B-GPTQ-Int4): 加载GPTQ量化模型并生成报告 try: # 加载tokenizer和模型 tokenizer AutoTokenizer.from_pretrained(model_name_or_path) model AutoModelForCausalLM.from_pretrained( model_name_or_path, device_mapauto, # 自动分配到GPU或CPU trust_remote_codeTrue ) # 使用pipeline简化调用 text_generator pipeline( text-generation, modelmodel, tokenizertokenizer, max_new_tokens1024, # 控制生成报告的长度 temperature0.3, # 较低的温度使输出更确定、更专业 do_sampleTrue, ) # 生成报告 generated_texts text_generator(prompt) report generated_texts[0][generated_text] # 移除原始的提示词部分只保留模型生成的内容 # 注意这是一个简单处理实际可能需要更精确的截断 if report.startswith(prompt): report report[len(prompt):].strip() return report except Exception as e: return f模型加载或生成失败{str(e)} # 调用函数生成报告 print(正在生成测试报告请稍候...) ai_report load_model_and_generate(report_prompt) print(\n *50) print(生成的测试报告摘要) print(*50) print(ai_report)运行这段代码你就会得到一份由模型生成的初步测试报告。生成速度取决于你的硬件在RTX 3060这样的显卡上通常几秒到十几秒就能完成。4. 实际效果与优化经验我们把这个流程集成到了Jenkins Pipeline里每次自动化测试套件执行完后都会自动触发报告生成并把结果附在构建通知里。效果怎么样举一个真实的例子某次接口测试跑了120个用例失败了15个。模型生成的报告在“主要问题分析”里指出“大部分失败集中在用户查询接口错误信息显示为‘数据库连接超时’另有3个失败是响应数据格式与预期不符”。在“根因推测”中它进一步结合日志提到“日志中在测试执行期间出现了多次‘Connection pool exhausted’警告推测可能是测试环境数据库连接池配置不足或存在连接泄漏”。这个分析直接指向了问题的核心比单纯看失败列表高效得多。当然我们也踩过一些坑提示词需要“调优”最初的提示词让模型“自由发挥”结果它有时会编造一些不存在的失败细节。后来我们严格限制了输入数据的格式并要求它“基于提供的信息”分析可靠性大大提升。处理长文本测试日志可能很长。我们最初把全部日志塞进去导致提示词过长模型响应变慢甚至出错。后来改为只提取包含“ERROR”、“Exception”等关键词的日志行问题就解决了。结果格式不稳定模型生成的报告格式有时会略有不同。如果后续需要程序自动解析报告这可能是个问题。我们的解决方法是在提示词里更严格地规定输出格式比如要求必须包含“## 整体结论”这样的Markdown标题或者生成后再用简单的规则去提取关键段落。并非完全可靠模型的分析是基于模式的推测并非真正的调试。它给出的“根因推测”可以作为一个非常棒的起点和参考但最终确认还需要测试或开发人员介入。我们会在报告末尾加上一句“注本分析由AI生成仅供参考请工程师结合日志进行最终确认。”5. 总结回过头来看把Qwen1.5-1.8B GPTQ这样的轻量模型用在自动化测试报告生成上是一个投入产出比很高的尝试。它没有替代测试工程师而是把他们从繁琐的信息整理工作中解放出来让他们能更专注于那些真正需要人类智慧和经验的任务比如设计测试用例、进行探索性测试、分析复杂的业务逻辑缺陷。整个实现过程不复杂核心就是数据预处理和提示词工程。对于已经具备自动化测试基础的团队来说集成这样一个AI助手可能只需要一两天的时间。它带来的效率提升和报告质量的改善却是立竿见影的。如果你正在为重复的测试报告工作感到烦恼不妨动手试试。从一个小的测试项目开始先跑通整个流程看看模型在你具体业务场景下的表现。相信你也会收获属于自己的惊喜。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。