InternLM2-Chat-1.8B在软件测试中的应用自动化测试用例生成1. 引言想象一下这个场景产品经理刚刚更新了一份长达几十页的需求文档开发团队紧锣密鼓地完成了新功能开发现在压力来到了测试团队这边。测试工程师需要根据这份文档设计出覆盖所有功能点、各种正常和异常场景的测试用例。这通常意味着要花上几天甚至一周的时间逐条分析需求手动编写测试步骤、预期结果和测试数据。时间紧任务重还容易遗漏一些边界情况。这几乎是每个软件团队都会遇到的真实困境。测试用例设计是保证软件质量的关键环节但它又是个重复性高、耗时耗力的工作。尤其是在敏捷开发模式下迭代周期短留给测试设计的时间就更少了。有没有一种方法能让这个过程变得更智能、更高效最近我们尝试将InternLM2-Chat-1.8B这个轻量级大模型引入到测试流程中让它来辅助我们生成测试用例。结果发现它不仅能快速理解需求描述还能结构化的输出测试用例甚至能想到一些我们可能忽略的边界条件。这篇文章我就来分享一下我们是怎么做的以及实际用下来的感受。2. 为什么选择大模型来做测试用例生成在深入具体操作之前我们先聊聊为什么测试用例生成这件事大模型能帮上忙。传统的测试用例设计高度依赖测试工程师的经验和业务理解能力。一个经验丰富的工程师能快速识别出需求中的关键点、潜在的风险场景和复杂的用户操作路径。但这个过程很难规模化也无法保证每次都能做到全面覆盖。大模型特别是经过指令微调的对话模型展现出了强大的文本理解和结构化生成能力。它就像一个不知疲倦、且阅读过海量技术文档和代码的“初级测试分析师”。你给它一段功能描述它能帮你拆解出测试点你告诉它一个业务流程它能生成覆盖这个流程的多个测试场景。我们选择InternLM2-Chat-1.8B主要是看中了它的几个特点。首先是“轻量”1.8B的参数量意味着它对计算资源的要求不高在普通的开发机上就能快速部署和推理非常适合集成到CI/CD流水线或者测试工具链中。其次是“对话能力强”它经过了高质量的指令微调能够很好地理解我们的意图并按照我们要求的格式进行输出。最后是“成本可控”无论是部署成本还是使用成本对于大多数团队来说都是可以接受的。当然它不是一个全自动的、可以完全替代测试工程师的“银弹”。它的角色更偏向于一个高效的“助手”或“灵感激发器”帮助我们完成那些繁琐、重复的初稿编写工作把工程师从机械劳动中解放出来去专注于更复杂的测试策略设计、探索性测试和结果分析。3. 快速上手让模型理解你的测试需求要让大模型帮你生成测试用例第一步是学会如何跟它“说话”。这涉及到如何设计你的提示词Prompt。一个好的提示词能极大地提升模型输出的质量和可用性。3.1 基础Prompt设计从功能描述到测试点最直接的方式就是把需求文档中的功能描述直接丢给模型。但为了让输出更符合我们的预期最好给它一些明确的指令。举个例子假设我们有一个用户登录功能的需求。一个基础的Prompt可以这样写你是一个专业的软件测试工程师。请根据以下功能描述生成对应的测试用例。 功能描述用户登录功能。用户输入用户名和密码点击登录按钮。系统验证凭证成功则跳转到首页失败则显示错误信息。 请以表格形式输出测试用例包含用例ID、测试标题、前置条件、测试步骤、预期结果、测试数据如有等字段。把这段提示词发送给部署好的InternLM2-Chat-1.8B你可能会得到类似下面的回复。为了展示效果这里我模拟了一段模型的输出测试用例用户登录功能用例ID测试标题前置条件测试步骤预期结果测试数据TC-LOGIN-01使用正确的用户名和密码登录1. 用户已注册2. 用户处于登录页面1. 在用户名输入框输入已注册的用户名2. 在密码输入框输入对应的正确密码3. 点击“登录”按钮1. 页面跳转至系统首页2. 页面显示用户昵称或登录成功提示用户名test_user 密码Test123TC-LOGIN-02使用错误的密码登录1. 用户已注册2. 用户处于登录页面1. 输入已注册的用户名2. 输入一个错误的密码3. 点击“登录”按钮1. 页面不跳转2. 页面显示“用户名或密码错误”的提示信息用户名test_user 密码wrong_pwdTC-LOGIN-03用户名为空时尝试登录1. 用户处于登录页面1. 保持用户名为空2. 输入任意密码3. 点击“登录”按钮1. 页面不跳转2. 在用户名输入框附近显示“用户名不能为空”的提示密码任意值TC-LOGIN-04密码为空时尝试登录1. 用户处于登录页面1. 输入已注册的用户名2. 保持密码为空3. 点击“登录”按钮1. 页面不跳转2. 在密码输入框附近显示“密码不能为空”的提示用户名test_user你看模型不仅生成了正向的“成功登录”用例还自动想到了“错误密码”、“用户名为空”、“密码为空”这些常见的异常场景。这个表格格式也基本可以直接导入到测试管理工具里使用了。3.2 进阶Prompt技巧引入边界与场景基础Prompt能解决大部分问题但如果我们想让模型思考得更深入可以给它更多的上下文和约束。技巧一指定测试类型。比如我们可以要求模型重点生成“边界值测试”或“安全性测试”的用例。接上面的功能描述...请重点生成边界值测试用例关注用户名和密码的长度、字符类型等边界情况。技巧二提供业务规则。如果需求中有明确的业务规则一定要告诉模型。功能描述用户注册功能。用户名要求6-20位字母数字组合密码要求8位以上且包含大小写字母和数字。 请生成覆盖该规则的测试用例特别是无效数据的测试用例。技巧三要求结构化输出。除了表格你还可以要求模型输出更结构化的格式比如直接生成可执行的测试脚本片段如Pythonpytest的代码骨架或者与特定工具如Jira, TestRail兼容的导入格式。通过组合这些技巧你可以引导模型产出更精准、更贴合项目实际需要的测试用例草案。4. 实战演练一个完整的测试用例生成流程光说不练假把式。我们用一个稍微复杂一点的例子来走一遍完整的流程。假设我们要测试一个电商平台的“购物车”功能。4.1 第一步准备清晰的需求描述首先我们需要把模糊的需求整理成模型能理解的清晰描述。这本身也是对需求进行梳理和澄清的好机会。我们给模型的输入如下你是一个资深的电商平台测试专家。请为“购物车”功能设计测试用例。 核心功能点描述 1. 添加商品在商品详情页点击“加入购物车”按钮商品被添加到当前用户的购物车中页面显示添加成功提示购物车图标上的数字增加。 2. 查看购物车点击导航栏的购物车图标跳转到购物车页面展示所有已添加的商品图片、名称、单价、数量、总价小计。 3. 修改数量在购物车页面每个商品旁有“”和“-”按钮可以调整商品数量。数量最小为1最大为库存上限。修改后该商品的小计和购物车总价实时重新计算。 4. 删除商品每个商品旁有“删除”按钮点击后该商品从购物车中移除购物车总价更新。 5. 清空购物车购物车页面有“清空购物车”按钮点击后弹出确认框确认后移除所有商品。 请生成详细的测试用例覆盖正常功能、异常场景和边界情况。请以Markdown表格形式输出包含以下列用例ID、测试场景/标题、前置条件、测试步骤、预期结果、优先级高/中/低。4.2 第二步调用模型并获取输出将这段Prompt发送给InternLM2-Chat-1.8B。模型经过一段时间的“思考”推理会生成一份相当详细的测试用例列表。由于篇幅限制这里我摘取其中关于“修改数量”功能的部分输出作为示例购物车功能测试用例部分用例ID测试场景/标题前置条件测试步骤预期结果优先级TC-CART-07增加单个商品数量库存充足1. 用户已登录2. 购物车中有商品A数量为13. 商品A库存大于11. 进入购物车页面2. 找到商品A点击其旁边的“”按钮一次1. 商品A的数量变为22. 商品A的小计变为单价*23. 购物车总价相应增加该商品的单价高TC-CART-08减少单个商品数量至最小值11. 用户已登录2. 购物车中有商品A数量为21. 进入购物车页面2. 找到商品A点击其旁边的“-”按钮一次1. 商品A的数量变为12. 商品A的小计变为单价*13. 购物车总价相应减少该商品的单价高TC-CART-09尝试将商品数量减少至0点“-”按钮1. 用户已登录2. 购物车中有商品A数量为11. 进入购物车页面2. 找到商品A点击其旁边的“-”按钮1. 商品A数量保持为1不应减少2. 可能提示“数量不能少于1”3. 小计和总价无变化中TC-CART-10增加商品数量至等于库存上限1. 用户已登录2. 购物车中有商品B数量为13. 商品B库存为51. 进入购物车页面2. 连续点击商品B的“”按钮直到数量显示为51. 商品B数量成功变为52. 小计和总价正确计算高TC-CART-11尝试增加商品数量超过库存上限1. 用户已登录2. 购物车中有商品B数量为5库存上限3. 商品B库存为51. 进入购物车页面2. 再次点击商品B的“”按钮1. 商品B数量保持为5不应增加2. 页面提示“库存不足最大可购买数为5”3. 小计和总价无变化高TC-CART-12修改数量后实时计算总价是否正确1. 用户已登录2. 购物车中有至少2种不同价格的商品1. 进入购物车页面记录初始总价2. 修改其中一件商品的数量3. 修改另一件商品的数量1. 每次修改后页面显示的商品小计和购物车总价都立即更新2. 最终总价等于所有商品单价*数量之和高4.3 第三步人工审核与优化模型生成的用例是一个极好的起点但绝不能直接拿来就用。测试工程师需要扮演“审核编辑”的角色。审核什么业务逻辑准确性模型生成的步骤和预期结果是否符合产品真实的业务规则比如有些平台在购物车数量达到库存上限时“”按钮会变灰而不是点击后提示。这需要根据实际设计来修正。场景完整性模型是否遗漏了重要的场景比如在“修改数量”这里模型想到了库存边界但可能没想到“输入框直接输入数量”的测试场景如果产品有这个功能的话。我们需要手动补充。数据合理性模型生成的测试数据如用户名、商品名是否合理是否需要替换成项目约定的测试数据表述清晰度测试步骤的描述是否无歧义预期结果是否可验证经过人工审核、补充和调整后这份由AI辅助生成的测试用例集其完整性和质量已经远远超过从零开始手动编写的初稿并且节省了大量的时间。5. 集成到工作流让AI成为测试团队的一员让模型在聊天界面里生成用例只是第一步。要真正发挥价值需要把它融入到团队的日常开发测试流程中。思路一与测试管理工具集成。这是最直接的思路。你可以编写一个简单的脚本这个脚本做三件事1) 从Confluence或Wiki读取需求文档或接受手动输入2) 调用InternLM2-Chat-1.8B的API生成测试用例表格3) 调用Jira、TestRail或飞蛾等工具的API将格式化后的用例自动创建为对应的测试用例。这样在需求评审会后测试用例的初稿可能就已经躺在测试管理工具里了。思路二作为IDE或代码编辑器的插件。对于测试开发工程师他们可能在写自动化测试脚本。可以开发一个插件在编写测试代码时选中一段功能描述右键选择“生成测试用例”插件调用模型并在侧边栏输出测试步骤和建议的断言语句工程师可以快速将其转化为代码。思路三融入CI/CD流水线。在代码提交或构建时可以触发一个流程分析本次提交关联的需求或代码变更自动生成或更新对应的测试用例并提醒测试负责人进行评审。这能确保测试用例与最新代码保持同步。这些集成方式听起来有点技术含量但其实核心都很简单就是“调用API”。InternLM2-Chat-1.8B提供了易于调用的接口剩下的就是根据团队使用的工具做一些简单的“粘合”工作。从小处着手比如先做一个能生成Markdown或Excel的脚本就能立刻带来效率提升。6. 总结尝试将InternLM2-Chat-1.8B用于测试用例生成这段时间感觉它确实是一个得力的助手。它最大的价值不是完全替代人而是把人从“从零到一”的创造性构思中解放出来去做“从一到一百”的优化和审核工作。以前需要花半天时间写的用例草案现在可能半小时就能拿到一个基础不错的版本工程师再用一小时去审核、补充和优化整体效率提升非常明显。当然它也有局限性。对于业务逻辑极其复杂、依赖特定领域知识如金融清算规则、医疗诊断逻辑的测试场景模型可能无法深入理解需要人工进行大量的引导和修正。另外它生成的是“文本描述”如何将其精准地转化为可执行的自动化测试脚本中间还有一段距离需要测试开发工程师的智慧。不过在UI功能测试、接口参数测试、常见的边界值测试等场景下它的表现已经足够令人惊喜。对于追求敏捷和效率的团队来说引入这样一个轻量、低成本、易集成的AI助手无疑是提升测试左移能力、应对快速迭代挑战的一个值得尝试的选择。如果你也在为测试用例设计的效率发愁不妨找个简单的功能点用它试一下或许会有意想不到的收获。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。