Phi-3-mini-128k-instruct助力软件测试：自动生成测试用例与缺陷报告

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** * **输入数据**: `user@name` (包含非法字符‘@’) * **预期结果**: 注册失败，提示“用户名只能包含字母、数字和下划线”。 * **测试方法**: 无效等价类（非法字符）

你看，它不仅能准确地识别出边界值（5，6，18，19），还能生成有效和无效等价类的典型例子。这份输出，已经是一个很好的测试用例草稿了。测试工程师要做的，就是 review 一下，补充一些它可能没想到的极端情况（比如全是下划线），或者结合业务逻辑增加一些场景（比如用户名已存在），然后就可以导入测试管理工具了。

对于更复杂的接口测试，我们也可以把OpenAPI（Swagger）文档的片段喂给它。比如一个查询订单的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_map="auto") # device_map="auto"会自动选择GPU或CPU # 3. 构造一个测试用例生成的提示词 def generate_test_cases(requirement): prompt = f"""你是一个经验丰富的软件测试工程师。请根据以下功能需求，设计测试用例，重点覆盖等价类划分和边界值分析。 功能需求： {requirement} 请列出测试用例，每个用例需包含：测试用例编号、输入数据、预期结果、以及所覆盖的测试设计方法。""" # 4. 将提示词编码并发送给模型 inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate(**inputs, max_new_tokens=500) # 5. 解码模型的回复 response = tokenizer.decode(outputs[0], skip_special_tokens=True) # 返回模型生成的内容（通常包含提示词本身，需要截取） 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星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。