Phi-3-Mini-128K在软件测试中的应用：自动化生成测试用例与报告

Phi-3-Mini-128K在软件测试中的应用自动化生成测试用例与报告最近和几个做软件测试的朋友聊天发现他们每天的工作量是真不小。写测试用例、跑测试、分析日志、写报告一套流程下来重复性工作占了大部分时间。尤其是遇到需求变更或者新功能上线光是设计测试用例就得花上好几天。有没有什么办法能把这些繁琐的工作自动化一部分呢我尝试了微软最近开源的Phi-3-Mini-128K模型发现它在处理这类结构化文本任务上效果出奇的好。这个模型虽然体积不大但上下文长度达到了128K特别适合处理像需求文档、代码、日志这类长文本。这篇文章我就来分享一下怎么用Phi-3-Mini-128K来给软件测试工作“减负”主要聚焦在三个最耗时的环节自动生成测试用例、智能分析测试日志定位问题以及一键生成结构清晰的测试报告。整个过程我会用最直白的语言和实际的代码例子来演示哪怕你之前没接触过大模型也能跟着做起来。1. 为什么选择Phi-3-Mini-128K做测试助手在聊具体怎么做之前咱们先看看为什么是它。市面上大模型不少但用在工程实践里尤其是集成到自动化流程中得考虑几个现实问题。首先它得够“轻”。很多测试环境特别是CI/CD流水线里的测试节点资源并不富裕。Phi-3-Mini-128K这个模型参数不多对硬件要求友好在普通的开发机上就能跑起来部署成本低。其次它得能“吃”下长文档。软件测试离不开各种文档几十页的产品需求说明书、复杂的API接口文档、动辄上万行的执行日志。这个模型128K的超长上下文窗口让它能一次性读完这些材料理解整体逻辑而不是断章取义。最后也是最重要的它得“听话”输出要稳定、结构化。我们不是要它天马行空地创作而是要它严格按照指令输出JSON、Markdown或者特定格式的测试用例和报告。Phi-3-Mini在遵循指令和格式化输出方面表现得很扎实这对于自动化流程至关重要。简单来说它就像一个理解力强、做事规矩、还不挑环境的实习生正好能帮我们处理那些规则明确但数量庞大的文本工作。2. 环境准备与模型快速部署咱们先从把模型跑起来开始。这里提供两种最常用的方式你可以根据自己环境选一种。2.1 使用Ollama一键部署推荐新手如果你的电脑是Mac、Linux或者WindowsWSL2用Ollama是最省心的办法。它就像个大模型的应用商店下载和管理模型特别方便。打开终端执行下面这条命令模型就会自动下载并启动# 拉取并运行Phi-3-Mini-128K模型 ollama run phi3:14b-128k运行成功后你会看到一个交互式界面可以直接输入文字和模型对话。不过我们的目标是把它的能力集成到脚本里所以更常用的是它的API模式。用下面这个命令在后台启动API服务# 在后台启动Ollama服务API端口默认为11434 ollama serve 服务启动后你就可以通过http://localhost:11434这个地址用代码去调用它了。2.2 使用Transformers库进行集成如果你的项目本身就用Python并且已经有一套AI相关的环境那么用Hugging Face的Transformers库会更容易和现有代码结合。首先安装必要的库pip install transformers torch accelerate然后用下面这段Python代码就能加载模型并进行对话了。device_map”auto”这个参数会让库自动选择用CPU还是GPU如果你有的话非常方便。from transformers import AutoModelForCausalLM, AutoTokenizer model_name microsoft/Phi-3-mini-128k-instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, device_mapauto, trust_remote_codeTrue) # 准备一个对话 messages [{role: user, content: 你好请介绍一下你自己。}] inputs tokenizer.apply_chat_template(messages, add_generation_promptTrue, return_tensorspt).to(model.device) # 生成回复 outputs model.generate(inputs, max_new_tokens200) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))两种方式都能很快把模型准备好。Ollama适合快速尝鲜和独立使用Transformers则更适合集成到已有的Python自动化项目中。你可以先选一种试试看。3. 实战应用一从需求文档自动生成测试用例手工写测试用例尤其是写那些边界值、异常流的用例既枯燥又容易遗漏。咱们试试让模型来当这个“初级测试设计员”。核心思路是我们把产品需求文档PRD或接口文档喂给模型然后给它一个清晰的指令告诉它我们想要什么格式的测试用例。这里的关键在于“清晰的指令”也就是提示词Prompt工程。3.1 编写一个高效的提示词Prompt好的提示词能让模型输出我们想要的结果。下面是一个针对用户登录功能生成测试用例的提示词例子你可以把它当成一个模板test_case_prompt_template 你是一个专业的软件测试工程师。请根据下面的功能需求描述设计详细的功能测试用例。 要求 1. 测试用例必须包含用例ID、用例标题、前置条件、测试步骤、预期结果。 2. 请覆盖正常功能、边界值、异常场景、安全性如SQL注入等。 3. 输出格式为JSON列表每个用例是一个JSON对象。 功能需求描述{requirement_text}请开始生成测试用例。 这个提示词做了几件事设定了模型的角色测试工程师明确了任务设计测试用例给出了具体的输出要求包含哪些字段、覆盖哪些场景、输出什么格式。这样模型生成的内容就会规整很多。3.2 实际调用与结果解析接下来我们写一段代码把真实的登录功能需求和上面的提示词模板结合起来调用模型并处理它的输出。import requests import json # 假设我们使用Ollama的API def generate_test_cases(requirement): prompt test_case_prompt_template.format(requirement_textrequirement) payload { model: phi3:14b-128k, prompt: prompt, stream: False, options: {temperature: 0.1} # 温度调低让输出更确定、更稳定 } response requests.post(http://localhost:11434/api/generate, jsonpayload) result response.json() # 尝试从模型的回复中解析出JSON部分 response_text result.get(response, ) # 模型有时会在JSON前后加一些解释性文字我们需要提取出纯净的JSON try: # 查找第一个[和最后一个]这通常是JSON数组的标记 start response_text.find([) end response_text.rfind(]) 1 if start ! -1 and end ! 0: json_str response_text[start:end] test_cases json.loads(json_str) return test_cases else: print(未在回复中找到有效的JSON数组。) return [] except json.JSONDecodeError as e: print(f解析JSON失败: {e}) print(f原始回复: {response_text}) return [] # 一个简化的登录功能需求 login_requirement 用户登录功能 1. 用户可以通过用户名和密码登录。 2. 用户名长度为4-20字符只能包含字母、数字和下划线。 3. 密码长度至少为8位必须包含大小写字母和数字。 4. 登录成功跳转至首页失败需给出明确提示用户名不存在、密码错误等。 5. 连续5次密码错误账户锁定15分钟。 cases generate_test_cases(login_requirement) print(f生成了 {len(cases)} 条测试用例。) for i, case in enumerate(cases[:2]): # 打印前两条看看 print(f\n用例{i1}: {json.dumps(case, ensure_asciiFalse, indent2)})运行这段代码模型就会生成一系列结构化的测试用例。我跑了一次它生成了将近20条用例不仅包括了“输入正确用户名密码登录成功”这种基本流还生成了“用户名长度为3字符”、“密码不含大写字母”、“连续输入错误密码5次”等各种边界和异常用例甚至还有“用户名输入中尝试SQL注入语句”的安全性用例。3.3 与现有测试框架结合生成了JSON格式的测试用例怎么用到实际项目中呢很简单我们可以把它转换成测试框架能识别的格式。比如如果你用Pytest可以写个小脚本把JSON转换成Python测试函数。import pytest def convert_to_pytest(test_cases_json): 将JSON测试用例转换为可执行的Pytest代码示例 test_code for case in test_cases_json: case_id case.get(用例ID, TC_Unknown) title case.get(用例标题, ) steps case.get(测试步骤, []) expected case.get(预期结果, ) # 构建一个简单的Pytest测试函数 func_name ftest_{case_id.lower().replace(-, _)} test_code f def {func_name}(): \\\{title}\\\ # 这里可以根据steps模拟测试步骤 # 例如调用登录接口传入测试数据 # actual_result call_login_api(username, password) # assert actual_result \{expected}\ pass return test_code # 将生成的测试用例代码写入文件 if cases: pytest_code convert_to_pytest(cases) with open(test_generated_login.py, w, encodingutf-8) as f: f.write(pytest_code) print(已生成Pytest测试文件test_generated_login.py)这样自动生成的测试用例就能无缝对接到你的自动化测试流水线里了。对于JUnit、Selenium等框架思路也是一样的就是把JSON转换成对应的测试脚本格式。4. 实战应用二智能分析测试日志与缺陷定位测试跑完了会生成一大堆日志。尤其是自动化测试失败时从海量日志里找到根本原因就像大海捞针。我们可以让模型来当这个“日志分析员”。4.1 构建日志分析提示词分析日志的提示词需要引导模型关注错误堆栈、异常信息、前后上下文并给出可能的原因和定位建议。log_analysis_prompt_template 你是一个经验丰富的测试开发工程师。请分析以下测试执行日志找出测试失败的根本原因并给出明确的缺陷定位建议。 请按以下结构思考并回答 1. **关键错误信息**从日志中提取最核心的错误堆栈或异常信息。 2. **可能的原因分析**基于错误信息分析可能导致此问题的2-3个常见原因如环境配置问题、数据问题、代码逻辑缺陷、依赖服务异常等。 3. **定位与排查建议**给出具体的下一步排查步骤例如检查哪个配置文件、查看哪段代码、验证哪个API接口。 测试日志{test_log}请开始分析。 4.2 实现日志分析与归类我们写一个函数把失败的测试日志发送给模型并获取结构化的分析结果。def analyze_test_log(log_content): prompt log_analysis_prompt_template.format(test_loglog_content) payload { model: phi3:14b-128k, prompt: prompt, stream: False, options: {temperature: 0.1} } response requests.post(http://localhost:11434/api/generate, jsonpayload) result response.json() analysis result.get(response, 分析失败) return analysis # 示例一段模拟的测试失败日志例如Selenium元素找不到 sample_log [2023-10-27 10:15:32] INFO - 开始执行测试用例test_checkout_process [2023-10-27 10:15:35] INFO - 成功打开首页https://example.com [2023-10-27 10:15:40] ERROR - 步骤失败在页面中未找到ID为shopping-cart-button的元素。 org.openqa.selenium.NoSuchElementException: no such element: Unable to locate element: {method:css selector,selector:#shopping\-cart\-button} (Session info: chrome118.0.5993.88) [2023-10-27 10:15:40] ERROR - 测试用例 test_checkout_process 执行失败 print(analyze_test_log(sample_log))运行后模型会返回类似这样的分析“关键错误信息Selenium抛出NoSuchElementException找不到ID为‘shopping-cart-button’的元素。可能的原因分析1. 页面元素ID被前端修改或拼写错误。2. 页面加载未完成脚本执行过快。3. 该元素在iframe内需要切换上下文。定位与排查建议1. 使用浏览器开发者工具检查该按钮元素当前的实际ID或选择器。2. 在查找元素前增加显式等待WebDriverWait。3. 检查页面是否存在iframe如有则需要先driver.switch_to.frame()。”这样一来测试工程师就不用一行行看日志了直接看模型总结的要点和排查方向效率高多了。你还可以把这个功能集成到测试平台的报告里每个失败用例后面自动附上AI分析摘要。5. 实战应用三一键生成结构化测试报告测试执行完毕整理报告又是一项耗时的工作。我们需要把散落的测试结果哪些通过、哪些失败、失败原因、缺陷摘要汇总成一份清晰的报告。这个工作模型做起来非常拿手。5.1 设计报告生成流程我们的输入是一堆结构化的测试结果数据可以从测试框架的输出如JUnit XML、Pytest JSON报告中解析得到输出是一份格式良好的Markdown或HTML报告。report_generation_prompt_template 你是一个测试负责人请根据以下测试执行结果生成一份专业、清晰的质量测试报告。 请使用Markdown格式并包含以下章节 # 测试报告 ## 1. 执行概览 - 测试周期、环境等基本信息请根据提供的数据补充。 - 总体通过率、统计图表用文字描述如共执行50个用例通过45个失败5个通过率90%。 ## 2. 详细结果分析 - 按模块或优先级列出通过和失败的用例情况。 - 对失败用例简要描述现象并引用上一环节的AI分析摘要。 ## 3. 缺陷摘要 - 将失败用例归纳为若干类缺陷并说明其严重程度和影响范围。 ## 4. 结论与建议 - 给出本次迭代的质量结论。 - 给出后续行动建议如需要修复的阻塞性问题、建议补充的测试场景等。 测试结果数据JSON格式{test_results_json}请开始生成报告。 5.2 集成到自动化流程中我们可以在CI/CD流水线的最后一步调用这个报告生成功能自动将本次构建的测试结果生成报告并发送到团队群或归档。import json def generate_test_report(results_data): # 将测试结果数据转换为JSON字符串 results_json_str json.dumps(results_data, ensure_asciiFalse, indent2) prompt report_generation_prompt_template.format(test_results_jsonresults_json_str) payload { model: phi3:14b-128k, prompt: prompt, stream: False, options: {temperature: 0.1} } response requests.post(http://localhost:11434/api/generate, jsonpayload) result response.json() report_markdown result.get(response, ) return report_markdown # 模拟一份测试结果数据 mock_results { project: 电商平台V2.3, test_date: 2023-10-27, environment: Staging环境 (Chrome 118), total_cases: 50, passed: 45, failed: 5, failed_cases: [ { case_id: TC_LOGIN_03, title: 连续5次错误密码锁定账户, module: 用户认证, error: 账户未按预期锁定第6次仍可尝试登录。, ai_analysis: 可能原因1. 后端计数器逻辑有误。2. 缓存未正确清除。建议检查账户锁定相关的计数器和状态更新API。 }, # ... 其他失败用例 ] } report generate_test_report(mock_results) print(report) # 可以将report写入文件或发送到协作平台 with open(test_report.md, w, encodingutf-8) as f: f.write(report)生成的Markdown报告结构清晰包含了概览、详细分析和建议可以直接分享。这比手动复制粘贴整理要快得多而且格式统一信息完整。6. 总结与展望把Phi-3-Mini-128K用到软件测试的这几个环节里给我的感觉是它确实能成为一个不错的“初级助手”。它最擅长的是那些有明确规则、需要处理大量文本、并且输出需要一定结构化的任务。自动生成测试用例能覆盖到很多人脑容易忽略的边界场景分析日志能快速从噪音中提取关键信号生成报告则把枯燥的整理工作自动化了。当然它也不是万能的。比如生成的测试用例可能还需要有经验的工程师审核一下确保场景合理日志分析给出的原因也需要人工判断和验证。它的角色更像是“增强”而不是“替代”。把重复、繁琐的文本处理工作交给它测试工程师就能更专注于设计更复杂的测试场景、探索性测试以及质量体系建设这些更有价值的事情。如果你想在团队里尝试引入这样的能力我的建议是从一个小而具体的场景开始比如先试试自动生成某个简单接口的测试用例。跑通整个流程看到实际效果后再逐步扩展到日志分析、报告生成等其他环节。这样阻力小也容易获得正向反馈。随着模型能力的迭代和我们使用经验的积累它能帮上忙的地方肯定会越来越多。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。