Phi-3-mini-128k-instruct助力软件测试自动生成测试用例与缺陷报告最近和几个做测试的朋友聊天大家普遍都在吐槽一件事活儿越来越多时间越来越紧。写测试用例要绞尽脑汁覆盖各种边界跑完测试还得对着日志一行行看然后吭哧吭哧写缺陷报告。这些工作重复性高但又极其重要稍微漏掉一个点线上就可能出问题。有没有什么办法能让机器帮我们分担一部分脑力劳动呢比如我们告诉它一个功能点它就能自动帮我们想出各种测试场景或者我们把测试日志丢给它它就能自动整理出一份像模像样的缺陷报告。还真有。我最近花了不少时间研究一个叫Phi-3-mini-128k-instruct的轻量级大模型发现它在软件测试这个领域能帮上不少忙。别看它模型不大但在理解需求、分析文本、生成结构化内容方面表现相当不错。今天我就结合几个实际的例子跟你聊聊怎么用它来给咱们的测试工作“减负增效”。1. 为什么是Phi-3-mini-128k-instruct你可能会问现在大模型这么多为什么偏偏选这个“迷你版”的对于软件测试这种具体的工程场景我的考虑主要有三点。第一是“够用就好”。我们做测试很多时候处理的都是具体的功能点、接口定义、日志文本。这些文本通常不会特别长但逻辑性很强。Phi-3-mini-128k-instruct虽然参数规模不大但指令跟随能力很强能很好地理解我们提出的具体要求比如“请根据以下接口定义生成边界值测试用例”。它不会天马行空地给你编一堆无关的东西输出比较可控。第二是部署成本低。这个模型非常轻量对硬件要求不高。在自己的开发机、甚至一些配置好点的个人电脑上都能跑起来不需要依赖昂贵的云端API或者庞大的计算集群。这意味着我们可以把它集成到本地测试工具链里随时调用不用担心网络延迟或者费用问题。第三是响应速度快。因为模型小它的推理速度很快。你给它一段需求描述它几乎能“秒回”一组合格的测试用例。这种即时反馈的体验在快速迭代的开发测试流程中非常重要不会打断你的工作节奏。当然它也不是万能的。对于极其复杂、需要深度业务领域知识的测试设计它可能还需要人工的引导和修正。但作为辅助工具处理那些重复、繁琐的“体力活”和“套路活”它已经能显著提升我们的效率了。2. 从需求到用例让AI成为你的测试设计助手写测试用例尤其是写那些覆盖全面、考虑边界条件的用例是个技术活也是个“烧脑”的活。我们来看看Phi-3-mini是怎么帮忙的。假设我们正在测试一个用户注册功能需求文档里简单写着“用户名长度为6-18个字符只能包含字母、数字和下划线。”如果让我们手动设计我们会想到等价类划分有效等价类、无效等价类和边界值分析长度5、6、18、19。现在我们让模型来试试。我们给模型这样一段指令你是一个经验丰富的软件测试工程师。请根据以下功能需求设计测试用例重点覆盖等价类划分和边界值分析。 功能需求用户注册时用户名字段需满足以下规则 1. 长度必须在6到18个字符之间包含6和18。 2. 只能使用英文字母a-z, A-Z、数字0-9和下划线_。 请列出测试用例每个用例需包含测试用例编号、输入数据、预期结果、以及所覆盖的测试设计方法如有效等价类、无效等价类、边界值。把这段指令发给Phi-3-mini-128k-instruct它会返回一份结构清晰的测试用例列表。我摘取一部分给你看看测试用例设计如下 1. **TC-01** * **输入数据**: abcde (5个字符) * **预期结果**: 注册失败提示“用户名长度需在6-18位之间”。 * **测试方法**: 边界值分析下边界-1 2. **TC-02** * **输入数据**: abcdef (6个字符) * **预期结果**: 注册成功。 * **测试方法**: 边界值分析下边界 3. **TC-03** * **输入数据**: abcdefghijklmnopqr (18个字符) * **预期结果**: 注册成功。 * **测试方法**: 边界值分析上边界 4. **TC-04** * **输入数据**: abcdefghijklmnopqrs (19个字符) * **预期结果**: 注册失败提示“用户名长度需在6-18位之间”。 * **测试方法**: 边界值分析上边界1 5. **TC-05** * **输入数据**: user_123 (8个字符包含字母、数字、下划线) * **预期结果**: 注册成功。 * **测试方法**: 有效等价类合法字符组合 6. **TC-06** * **输入数据**: username (包含非法字符‘’) * **预期结果**: 注册失败提示“用户名只能包含字母、数字和下划线”。 * **测试方法**: 无效等价类非法字符你看它不仅能准确地识别出边界值561819还能生成有效和无效等价类的典型例子。这份输出已经是一个很好的测试用例草稿了。测试工程师要做的就是 review 一下补充一些它可能没想到的极端情况比如全是下划线或者结合业务逻辑增加一些场景比如用户名已存在然后就可以导入测试管理工具了。对于更复杂的接口测试我们也可以把OpenAPISwagger文档的片段喂给它。比如一个查询订单的GET接口有orderId必填整数、status选填枚举等参数。模型同样能生成针对参数必填、类型、枚举值、组合情况的测试用例。这相当于多了一个不知疲倦、基础扎实的初级测试设计员帮你完成了第一轮“头脑风暴”和“标准化输出”。你可以把精力更多集中在那些真正需要业务洞察和探索性思维的复杂场景上。3. 从日志到报告一键生成清晰的缺陷描述跑完测试尤其是自动化测试面对成百上千行的执行日志定位问题、编写缺陷报告又是一个耗时的工作。我们需要从日志中提取关键信息什么操作、什么输入、预期是什么、实际结果是什么、相关的错误堆栈或截图。Phi-3-mini-128k-instruct可以扮演一个优秀的“日志分析员”和“报告撰写员”。我们来看一个模拟的场景。假设我们有一段自动化测试脚本执行失败的日志摘要[2023-10-27 14:30:15] INFO - 开始执行测试用例TC_Login_InvalidPassword [2023-10-27 14:30:16] INFO - 步骤1导航到登录页面... 成功 [2023-10-27 14:30:17] INFO - 步骤2输入用户名 test_user... 成功 [2023-10-27 14:30:17] INFO - 步骤3输入错误密码 wrong_pass... 成功 [2023-10-27 14:30:18] INFO - 步骤4点击“登录”按钮... 成功 [2023-10-27 14:30:20] ERROR - 步骤5验证登录失败提示信息 - **失败** 预期结果页面应显示红色提示框内容为“用户名或密码错误”。 实际结果页面无任何提示信息仅页面刷新了一次。 [2023-30-27 14:30:21] INFO - 测试用例 TC_Login_InvalidPassword 执行结束。结果**失败**我们把这段日志连同指令一起发给模型你是一个软件测试工程师需要根据以下自动化测试执行失败的日志编写一份结构清晰的缺陷报告Bug Report。请从日志中提取关键信息并遵循常见的缺陷报告格式。 日志内容 [此处粘贴上面的日志] 请生成包含以下部分的缺陷报告 1. 缺陷标题简明扼要 2. 重现步骤从日志中提取 3. 预期结果 4. 实际结果 5. 环境信息可根据日志推断如无则写“详见日志” 6. 严重程度和建议根据描述判断模型生成的缺陷报告如下**缺陷报告** **1. 缺陷标题** 登录功能输入错误密码后页面无错误提示信息仅刷新页面。 **2. 重现步骤** 1. 打开应用登录页面。 2. 在用户名输入框中输入test_user。 3. 在密码输入框中输入一个错误的密码例如wrong_pass。 4. 点击“登录”按钮。 **3. 预期结果** 登录失败页面应清晰显示错误提示信息例如红色提示框内容为“用户名或密码错误”。 **4. 实际结果** 登录失败但页面没有任何错误提示信息。页面行为表现为刷新了一次用户体验为“似乎什么都没发生”无法获知登录失败的具体原因。 **5. 环境信息** * 测试执行时间2023-10-27 14:30:15 * 其他环境信息详见原始日志 **6. 严重程度和建议** * **严重程度**中高Major。此缺陷导致核心功能登录的用户反馈缺失影响用户体验可能导致用户困惑并反复尝试。 * **建议**前端应正确捕获并显示后端返回的登录失败错误信息。需检查前端错误处理逻辑及信息展示组件。这份报告怎么样我觉得已经达到了可以直接提交给开发人员的水平。标题清晰步骤明确预期和实际结果对比清楚甚至还给出了初步的严重程度判断和排查方向。测试工程师需要做的可能就是附上截图或更详细的网络请求日志然后就可以提交了。这极大地减少了我们复制粘贴、组织语言的时间。更重要的是它保证了缺陷报告的基本结构和清晰度避免了因为匆忙而描述不清的情况。4. 动手实践搭建你的测试AI小助手说了这么多怎么把它用起来呢其实流程很简单。你不需要是个机器学习专家。第一步准备环境。你需要一个能运行Python的环境。然后通过pip安装一些必要的库主要是大模型相关的框架比如transformers由Hugging Face提供或者ollama这类专门用于本地运行模型的工具。选择哪个取决于你的偏好和部署方式。第二步获取并加载模型。Phi-3-mini-128k-instruct是一个开源模型你可以从Hugging Face的模型库Model Hub找到并下载它。使用transformers库几行代码就能把它加载到内存中。第三步编写交互脚本。核心就是构造一个“提示词”Prompt把你的指令和待分析的内容如需求文档、日志组合起来发送给模型然后获取并解析它的回复。下面是一个极其简化的概念性代码示例展示了这个交互过程# 这是一个概念性示例实际代码需要根据你选择的框架进行调整 from transformers import AutoModelForCausalLM, AutoTokenizer # 1. 指定模型名称从Hugging Face下载 model_name microsoft/Phi-3-mini-128k-instruct # 2. 加载模型和分词器 print(正在加载模型请稍候...) tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, device_mapauto) # device_mapauto会自动选择GPU或CPU # 3. 构造一个测试用例生成的提示词 def generate_test_cases(requirement): prompt f你是一个经验丰富的软件测试工程师。请根据以下功能需求设计测试用例重点覆盖等价类划分和边界值分析。 功能需求 {requirement} 请列出测试用例每个用例需包含测试用例编号、输入数据、预期结果、以及所覆盖的测试设计方法。 # 4. 将提示词编码并发送给模型 inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate(**inputs, max_new_tokens500) # 5. 解码模型的回复 response tokenizer.decode(outputs[0], skip_special_tokensTrue) # 返回模型生成的内容通常包含提示词本身需要截取 return response.split(prompt)[-1].strip() # 简单截取生成部分 # 6. 使用示例 user_requirement 用户注册时用户名字段需满足以下规则1.长度必须在6到18个字符之间包含6和18。2.只能使用英文字母、数字和下划线。 test_cases generate_test_cases(user_requirement) print(生成的测试用例) print(test_cases)第四步集成与优化。你可以把这个脚本封装成一个函数集成到你的测试框架中。比如在编写测试计划时调用它来生成用例草稿或者写一个日志监听器当自动化测试失败时自动抓取日志并调用模型生成缺陷报告草稿。在实际使用中你可能需要优化提示词让模型的输出更符合你公司的缺陷报告模板。也可以设计一个简单的图形界面方便非开发人员的测试同事使用。5. 一些经验与思考在实际用了一段时间之后我有几点感受和建议。它是个“副驾驶”不是“自动驾驶”。模型生成的测试用例和缺陷报告质量很高但绝不能不经审查直接使用。测试工程师的专业判断至关重要。你需要检查用例是否覆盖了所有业务规则缺陷报告的描述是否百分百准确。AI负责提供草稿和思路你负责最终的审核和决策。提示词是关键。你想要什么样的输出很大程度上取决于你给什么样的指令。指令越清晰、越具体输出就越符合预期。比如如果你公司有固定的缺陷报告模板就把模板的关键字段都写在提示词里。多尝试、多调整你的提示词这是用好这类工具的核心技巧。从简单场景开始。不要一开始就试图让它处理一个庞大的、充满专业术语的复杂系统需求文档。从一个简单的输入框校验、一个标准的API接口开始看看效果。效果好再逐步应用到更复杂的场景比如业务流程测试、状态转换测试等。关于“软件测试面试题”。我知道很多朋友在准备面试时会看各种面试题。其实用这个模型来辅助理解一些测试设计理论也挺好。你可以把经典的面试题比如“如何测试一个水杯”、“如何测试微信的点赞功能”丢给它看看它从哪些角度思考生成的用例有哪些亮点和不足。这本身就是一个很好的学习、对比和启发的过程。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。