Phi-3-mini-128k-instruct助力软件测试：自动化测试用例与脚本生成

Phi-3-mini-128k-instruct助力软件测试自动化测试用例与脚本生成1. 引言想象一下这个场景产品经理刚刚更新了一份长达几十页的需求文档开发团队紧锣密鼓地开始编码而测试工程师看着密密麻麻的功能点心里盘算着又要加班加点设计测试用例了。这几乎是每个敏捷团队都会遇到的真实挑战——测试设计的速度常常跟不上开发迭代的节奏。传统的测试用例设计尤其是那些需要覆盖边界值、等价类、异常场景的用例非常依赖测试工程师的经验和细心。一个函数可能就需要几十个测试点手动编写不仅耗时还容易遗漏。有没有一种方法能让机器帮我们分担这部分重复性的脑力劳动呢最近我尝试将微软开源的Phi-3-mini-128k-instruct模型引入到我们的测试流程中结果让人惊喜。这个轻量级但能力不俗的大语言模型能够理解我们的需求描述和函数定义然后自动生成结构化的测试用例甚至直接输出可运行的Python测试脚本。原本需要半天才能完成的测试设计工作现在可能只需要几分钟。这篇文章我就来分享一下具体的实践过程看看如何用这个AI助手让软件测试变得更智能、更高效。2. 为什么选择Phi-3-mini做测试助手在开始具体操作之前你可能会有疑问市面上大模型那么多为什么偏偏选Phi-3-mini-128k-instruct来做这件事我主要看中了它的几个特点。首先它足够“轻巧”。Phi-3-mini是一个小型语言模型参数规模相对较小这意味着它对硬件的要求不高。你不需要准备昂贵的GPU服务器在普通的开发机甚至配置好一点的笔记本电脑上就能顺畅运行。这对于测试团队来说非常友好部署成本低上手门槛也低。其次它的“指令跟随”能力很强。模型名字里的“instruct”就说明了这一点。它经过专门的指令微调能够很好地理解并执行我们给出的具体任务要求。比如你告诉它“请为这个登录函数设计边界值测试用例”它就能准确地按照边界值分析的方法来思考而不是漫无边际地生成一些无关内容。再者128k的超长上下文窗口是它的一个巨大优势。一份完整的需求文档或一个复杂的类定义很容易就达到几千甚至上万个token。普通的模型可能“记不住”这么长的内容导致生成的内容偏离主题。而Phi-3-mini-128k可以轻松吞下整个文档确保它生成测试用例时是基于对需求全文的理解而不是断章取义。最后它的输出格式非常规整。当我们要求它生成特定格式的内容比如Markdown表格、Python代码块时它通常能很好地遵守格式要求。这对于我们后续直接将生成的用例导入测试管理工具或者直接运行生成的脚本提供了极大的便利。当然它也不是万能的。对于极其复杂、充满业务逻辑嵌套的场景它可能还需要人工的引导和修正。但对于大量常规的、模式化的测试设计工作它已经是一个效率倍增器了。3. 环境准备与模型快速上手要让Phi-3-mini开始为我们工作第一步是把它“请”到我们的本地环境里。整个过程比想象中简单。基础环境搭建你需要一个安装了Python建议3.8以上版本的环境。然后通过pip安装必要的库。最核心的是transformers库这是Hugging Face提供的模型加载和推理框架。pip install transformers torch accelerateaccelerate库可以帮助我们更高效地利用硬件资源即使是在CPU上运行也能获得一定的速度提升。模型下载与加载Phi-3-mini-128k-instruct模型在Hugging Face Model Hub上可以直接获取。我们可以用几行代码将它加载到内存中。from transformers import AutoModelForCausalLM, AutoTokenizer, pipeline model_id microsoft/Phi-3-mini-128k-instruct # 加载分词器和模型 tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForCausalLM.from_pretrained( model_id, device_mapauto, # 自动选择设备GPU/CPU torch_dtypeauto, # 自动选择数据类型 trust_remote_codeTrue, ) # 创建一个文本生成的管道 pipe pipeline( text-generation, modelmodel, tokenizertokenizer, )第一次运行时会下载模型文件大小大约几个GB需要一点时间。下载完成后模型就准备就绪了。第一个测试让它理解一个简单函数加载好模型后我们可以先抛给它一个简单的任务试试水。比如我们有一个函数功能是计算两个数的商。# 我们给模型的提示词Prompt prompt 你是一个资深的测试工程师。请为以下Python函数设计测试用例重点覆盖边界值和异常场景。 函数定义 def divide(dividend: float, divisor: float) - float: \\\ 返回 dividend 除以 divisor 的结果。 如果 divisor 为0抛出 ValueError 异常。 \\\ if divisor 0: raise ValueError(除数不能为0) return dividend / divisor 请以Markdown表格的形式列出测试用例包含用例编号、测试描述、输入(dividend, divisor)、预期输出。 # 调用模型生成 result pipe( prompt, max_new_tokens512, # 控制生成文本的最大长度 do_sampleTrue, temperature0.2, # 温度参数越低输出越确定 ) print(result[0][generated_text])运行这段代码模型会开始思考并生成内容。你很快就能看到它输出的一个表格里面可能包含“除数为0”、“被除数为0”、“正数除以正数”、“负数除以负数”以及涉及浮点数精度的各种测试用例。通过这个简单的例子你就能直观感受到它的能力了。4. 实战从需求文档到测试用例掌握了基本用法后我们来看一个更贴近实际的场景。假设你收到了一份关于“用户注册”功能的需求描述通常它可能是这样的需求描述注册功能需验证用户名、密码和邮箱。用户名长度6-20位仅允许字母、数字和下划线。密码长度8-16位必须包含至少一个大写字母、一个小写字母和一个数字。邮箱需符合常规邮箱格式包含和.。所有字段为必填。提交后系统应返回成功或失败信息。我们的目标是让Phi-3-mini基于这段需求自动生成系统、全面的测试用例。关键在于构建一个清晰、明确的提示词Prompt。构建高效的测试PromptPrompt就像给AI下达的工作指令指令越清晰结果越好。对于测试用例生成一个结构化的Prompt通常包含以下几个部分角色设定告诉模型它要扮演什么角色。任务目标明确告诉它要做什么。输入信息提供完整的需求或代码。输出要求严格规定输出的格式和内容要点。test_prompt 角色你是一位经验丰富的软件测试专家精通等价类划分和边界值分析方法。 任务请根据以下用户注册功能的需求描述设计详细的测试用例。 需求描述 “注册功能需验证用户名、密码和邮箱。 1. 用户名长度6-20位仅允许字母、数字和下划线。 2. 密码长度8-16位必须包含至少一个大写字母、一个小写字母和一个数字。 3. 邮箱需符合常规邮箱格式包含和.。 4. 所有字段为必填。 5. 提交后系统应返回成功或失败信息。” 输出要求 1. 请使用等价类划分和边界值分析的方法来设计用例。 2. 输出格式为Markdown表格。 3. 表格列包括功能模块、用例编号、测试场景/描述、输入数据、预期结果。 4. 请覆盖正常场景、边界场景和异常场景。 将这段Prompt发送给模型它会输出一个非常详细的测试用例表格。你会看到它如何思考对于用户名它会生成长度恰好为6、20的用例边界值也会生成长度为5、21的无效用例边界外还会生成包含非法字符如$,空格的用例。对于密码它会分别测试缺少大写、缺少小写、缺少数字的情况以及长度7、8、16、17的情况。对于邮箱它会测试缺少、缺少.、在.之后等无效格式。对于必填它会测试每个字段单独为空以及所有字段为空的场景。处理更复杂的需求如果需求文档很长比如是一个完整的API接口说明你可以直接将整个文档作为输入。得益于128k的长上下文模型能够通篇阅读并理解各个参数之间的约束关系生成关联性的测试用例。例如一个创建订单的API商品库存和用户余额都会影响结果模型能够设计出“库存充足但余额不足”、“库存不足但余额充足”等组合场景的用例。这个过程的本质是将测试工程师的设计思维模式通过Prompt“传授”给了AI。你不需要告诉它每一个具体的测试点只需要告诉它方法和规则它就能举一反三。5. 进阶自动生成可执行的测试脚本生成测试用例表格已经大大提升了效率但如果能直接生成可运行的测试代码岂不是更完美Phi-3-mini完全可以做到。我们可以引导它输出Python的unittest或pytest脚本。从函数定义到pytest脚本假设我们有一个需要测试的函数validate_password定义如下def validate_password(password: str) - tuple[bool, str]: 验证密码强度。 规则 1. 长度8-16位 2. 必须包含至少一个大写字母 3. 必须包含至少一个小写字母 4. 必须包含至少一个数字 返回(是否通过, 错误信息) if len(password) 8 or len(password) 16: return False, “密码长度需在8-16位之间” if not any(c.isupper() for c in password): return False, “密码必须包含至少一个大写字母” if not any(c.islower() for c in password): return False, “密码必须包含至少一个小写字母” if not any(c.isdigit() for c in password): return False, “密码必须包含至少一个数字” return True, “密码强度合格”我们可以构造这样的Promptcode_prompt f 角色你是一名Python开发工程师擅长编写单元测试。 任务请为下面的Python函数编写完整的pytest测试脚本。 要求 1. 使用pytest框架。 2. 测试应覆盖函数的所有分支和边界条件包括长度边界8和16以及各类字符缺失的情况。 3. 每个测试用例要有清晰的名称。 4. 在脚本中直接导入被测试函数假设它位于src.validator模块中。 5. 请只输出最终的Python代码无需解释。 函数定义 {validate_password.__doc__}{inspect.getsource(validate_password)} # 使用inspect模块获取函数的源代码 import inspect # ... 将函数定义和docstring填入prompt ...运行后模型可能会生成如下代码import pytest from src.validator import validate_password class TestValidatePassword: 测试密码验证函数 def test_valid_password(self): 测试符合所有规则的密码 result, msg validate_password(StrongPass123) assert result is True assert msg 密码强度合格 def test_too_short(self): 测试长度过短边界值7 result, msg validate_password(Ab1) assert result is False assert 长度 in msg def test_boundary_short_valid(self): 测试边界长度8有效 result, msg validate_password(Abcdefg1) assert result is True def test_boundary_long_valid(self): 测试边界长度16有效 result, msg validate_password(Abcdefghijklmno1) assert result is True def test_too_long(self): 测试长度过长边界值17 result, msg validate_password(Abcdefghijklmnop1) assert result is False assert 长度 in msg def test_no_uppercase(self): 测试缺少大写字母 result, msg validate_password(strongpass123) assert result is False assert 大写 in msg def test_no_lowercase(self): 测试缺少小写字母 result, msg validate_password(STRONGPASS123) assert result is False assert 小写 in msg def test_no_digit(self): 测试缺少数字 result, msg validate_password(StrongPass) assert result is False assert 数字 in msg生成的代码结构清晰用例覆盖全面你只需要稍作检查比如调整一下导入路径就可以直接运行pytest命令来执行这些测试了。集成到CI/CD流程更进一步你可以将这个能力脚本化集成到你的持续集成CI流程中。例如在代码提交后自动提取新增或修改的函数定义调用模型生成测试用例的草案然后以评论的形式提交到代码审查Code Review中供测试和开发人员参考和完善。这能将测试左移Shift-Left落到实处在开发早期就引入测试思维。6. 使用技巧与注意事项在实际使用中为了让Phi-3-mini发挥最佳效果有几个小技巧和需要注意的地方。Prompt工程技巧具体明确避免“设计一些测试用例”这种模糊指令。要具体如“使用边界值分析法针对‘年龄’字段范围18-99设计测试用例”。提供范例对于复杂的输出格式可以在Prompt里先给一个例子One-shot Learning模型会模仿得更好。分步思考对于复杂任务可以要求模型“逐步思考”。例如“首先分析这个函数有哪些输入参数和边界条件其次为每个参数设计等价类和边界值最后组合生成测试用例表格。”控制输出利用max_new_tokens控制生成长度利用temperature控制随机性测试用例生成建议设为较低值如0.1-0.3以保证输出的确定性。模型的局限性并非百分百准确生成的用例或代码可能存在逻辑瑕疵或遗漏某些隐蔽的角落场景Corner Case。它始终是一个强大的辅助工具而非替代品。测试工程师的审查和判断至关重要。业务理解深度有限对于高度依赖领域知识的业务规则模型可能无法深刻理解。它擅长处理结构清晰、规则明确的逻辑。上下文消耗虽然支持128k但处理极长的文档仍会消耗大量计算资源生成速度会变慢。最佳实践建议从简到繁先从单个函数、简单需求开始熟悉模型的特性和Prompt的写法再逐步应用到更复杂的模块和文档。人工审核将AI生成的测试用例和脚本视为“初稿”必须由测试工程师进行有效性、正确性和完整性的审核。建立知识库将效果好的Prompt、针对特定测试类型如API测试、数据库操作测试的模板保存下来形成团队的“测试Prompt知识库”方便复用。结合传统方法AI生成与探索性测试Exploratory Testing、基于模型的测试Model-Based Testing等方法相结合构建更立体的测试策略。7. 总结把Phi-3-mini-128k-instruct引入软件测试工作流给我的最大感受是它把测试工程师从大量重复、模式化的设计工作中解放了出来。以前需要对着屏幕冥思苦想各种边界条件现在只需要构思一个清晰的Prompt剩下的“体力活”可以交给AI去完成。它生成的用例草案往往能覆盖到我们可能忽略的一些组合场景有效提升了测试设计的覆盖率。当然它不会取代测试工程师。测试中最有价值的部分——对业务的理解、对用户体验的洞察、对复杂场景的探索性思维——依然需要人来主导。AI扮演的是一个不知疲倦、思维缜密的“初级测试分析师”角色负责完成那些有明确规则可循的基础工作。如果你所在的团队也在面临测试效率的瓶颈或者想探索AI在研发流程中的应用不妨从这个小模型开始尝试。成本不高部署简单但带来的效率提升是立竿见影的。你可以先从一两个简单的功能模块试点让团队感受到它的价值再逐步推广到更广泛的场景中去。技术最终要服务于人让工具帮我们处理繁琐我们才能更专注于创造性的、更有挑战性的问题。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。