通义千问1.5-1.8B-Chat-GPTQ-Int4在软件测试中的应用：自动化生成测试用例

通义千问1.5-1.8B-Chat-GPTQ-Int4在软件测试中的应用：自动化生成测试用例

每次新版本上线前，测试团队都像在打一场硬仗。产品经理递过来一份几十页的需求文档，开发同学提交了成百上千行代码，而测试同学的任务，就是从这些文字和代码里，找出所有可能出错的角落。手动设计测试用例，尤其是那些边界值、异常场景，不仅耗时耗力，还容易有遗漏。有没有一种方法，能让机器理解需求，并自动帮我们生成高质量的测试用例呢？

最近，我们尝试将通义千问1.5-1.8B-Chat的轻量化版本（GPTQ-Int4量化）引入到软件测试流程中，让它扮演一个“测试用例生成助手”的角色。效果出乎意料，它不仅能快速理解功能描述，还能基于经典的测试设计方法，输出结构化的测试用例。这篇文章，我就来分享一下我们是如何做的，以及实际落地过程中的一些心得。

1. 为什么选择大模型做测试用例生成？

在深入具体操作之前，我们先聊聊为什么这件事值得做。传统的测试用例设计，高度依赖测试工程师的经验和业务理解。一个经验丰富的工程师，能迅速识别出关键的业务流、潜在的异常点和复杂的边界条件。但这个过程是线性的、人力密集的，而且存在几个痛点：

• 效率瓶颈：面对海量需求或频繁迭代，手工设计用例的速度跟不上开发的节奏。
• 覆盖度挑战：人脑容易有思维盲区，一些隐蔽的等价类或边界组合可能被忽略。
• 知识传承：资深测试工程师的经验难以快速沉淀和复制给新人。

大语言模型的出现，为解决这些问题提供了新思路。像通义千问这样的模型，经过海量代码和文本训练，具备了强大的语义理解和逻辑推理能力。它就像一个不知疲倦、且博览群书的“实习生”，我们可以通过精心设计的指令（Prompt），引导它基于给定的需求，运用等价类划分、边界值分析等测试理论，生成初步的测试用例草稿。

我们选择1.5-1.8B-Chat的GPTQ-Int4版本，主要是看中它在精度和效率间的平衡。量化后的模型体积小，推理速度快，对硬件要求低，可以很方便地部署在测试团队的开发机甚至服务器上，实现快速响应。这对于需要频繁调用、追求效率的测试辅助场景来说，非常合适。

2. 搭建你的测试用例生成助手

理论说再多，不如动手试试。下面我就带你一步步搭建并使用这个“助手”。

2.1 环境准备与模型部署

首先，你需要一个能运行Python的环境。我们推荐使用Python 3.8或以上版本。接着，安装必要的依赖库，主要是模型推理和加速相关的。

pip install transformers optimum auto-gptq

transformers是Hugging Face的模型库，optimum和auto-gptq是为了高效加载和使用GPTQ量化模型。安装过程通常很顺利。

模型部署出奇地简单。得益于开源社区和量化技术，我们不需要准备昂贵的GPU服务器。以下代码展示了如何加载通义千问的GPTQ-Int4量化模型：

from transformers import AutoModelForCausalLM, AutoTokenizer model_name = "Qwen/Qwen1.5-1.8B-Chat-GPTQ-Int4" # 如果你在国内，也可以使用魔搭社区（ModelScope）的镜像路径，例如： # model_name = "qwen/Qwen1.5-1.8B-Chat-GPTQ-Int4" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained( model_name, device_map="auto", # 自动选择设备（GPU或CPU） trust_remote_code=True # 信任来自源的代码 )

device_map=”auto”会让程序自动选择可用的设备。如果你的机器有GPU，它会优先使用GPU，速度会快很多；如果没有，它也会在CPU上运行，只是稍慢一些。第一次运行时会下载模型文件，大约需要1-2GB的磁盘空间，之后就可以离线使用了。

2.2 核心：设计测试用例生成Prompt

模型部署好了，但直接扔给它一句“帮我生成测试用例”，它可能给出一段散文式的描述，而不是我们想要的表格。关键在于Prompt工程——如何与模型有效沟通。

我们的目标是让模型输出结构化的数据，比如JSON或Markdown表格。经过多次尝试，我们总结出一个比较有效的Prompt模板：

你是一个资深的软件测试工程师。请根据以下功能需求描述，运用等价类划分和边界值分析方法，生成详细的测试用例。 【功能需求描述】 {在这里粘贴具体的需求描述} 请以JSON数组格式输出测试用例，每个测试用例是一个对象，包含以下字段： - “id”: 测试用例编号，从TC01开始。 - “title”: 测试用例标题，简要说明测试点。 - “precondition”: 执行测试的前置条件。 - “test_steps”: 测试步骤列表。 - “expected_result”: 预期结果。 - “design_method”: 使用的测试设计方法，如“边界值分析”、“等价类划分”等。 - “priority”: 优先级，分为“高”、“中”、“低”。 请确保覆盖正常场景、边界场景和异常场景。

这个Prompt做了几件事：

1. 设定角色：让模型进入“测试专家”的状态。
2. 明确输入：指定需求描述的放置位置。
3. 规定输出格式：要求JSON数组，并定义了每个字段的含义。结构化输出便于我们后续用程序解析和处理。
4. 提出方法论要求：明确要求使用等价类划分和边界值分析，引导模型进行专业思考。
5. 指定覆盖范围：要求覆盖多种场景，提升用例的完整性。

2.3 一个完整的生成示例

让我们用一个具体的例子跑通全流程。假设我们有一个“用户登录”的功能需求：

需求描述：用户登录功能。用户名输入框要求输入6-18位字符，只能由字母、数字和下划线组成。密码输入框要求输入8-20位非空字符。

我们将上述需求填入Prompt模板，然后编写调用代码：

def generate_test_cases(requirement): prompt_template = """你是一个资深的软件测试工程师。请根据以下功能需求描述，运用等价类划分和边界值分析方法，生成详细的测试用例。 【功能需求描述】 {requirement} 请以JSON数组格式输出测试用例...（同上，此处省略）... """ full_prompt = prompt_template.format(requirement=requirement) messages = [ {"role": "system", "content": "你是一个专业的测试用例生成助手。"}, {"role": "user", "content": full_prompt} ] # 将对话格式转换为模型所需的输入 text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True) inputs = tokenizer(text, return_tensors="pt").to(model.device) # 生成输出 with torch.no_grad(): outputs = model.generate(**inputs, max_new_tokens=1024, temperature=0.1) response = tokenizer.decode(outputs[0][inputs['input_ids'].shape[1]:], skip_special_tokens=True) return response # 调用函数 login_requirement = “用户登录功能。用户名输入框要求输入6-18位字符，只能由字母、数字和下划线组成。密码输入框要求输入8-20位非空字符。” result = generate_test_cases(login_requirement) print(result)

temperature=0.1这个参数设置得比较低，是为了让模型的输出更加确定和聚焦，减少随机性，这对于生成结构化的测试用例很重要。

运行这段代码，模型会返回一个JSON数组。解析后，你可能会得到类似下面的测试用例（这里以文本形式展示其内容）：

[ { “id”: “TC01”, “title”: “使用有效用户名（6位）和有效密码（8位）登录”, “precondition”: “用户拥有已注册的账户。”, “test_steps”: [“1. 打开登录页面。”, “2. 在用户名输入框输入‘abc123’。", “3. 在密码输入框输入‘password’。", “4. 点击登录按钮。”], “expected_result”: “登录成功，跳转到主页。”, “design_method”: “等价类划分（有效等价类）”, “priority”: “高” }, { “id”: “TC02”, “title”: “使用有效用户名（18位）和有效密码（20位）登录”, “precondition”: “用户拥有已注册的账户。”, “test_steps”: [“1. 打开登录页面。”, “2. 输入18位合规用户名（如‘user_123456789012’）。", “3. 输入20位密码。”, “4. 点击登录按钮。”], “expected_result”: “登录成功，跳转到主页。”, “design_method”: “边界值分析（上边界）”, “priority”: “高” }, { “id”: “TC03”, “title”: “使用5位字符的用户名尝试登录”, “precondition”: “用户拥有已注册的账户。”, “test_steps”: [“1. 打开登录页面。”, “2. 在用户名输入框输入‘abcde’。", “3. 输入有效密码。”, “4. 点击登录按钮。”], “expected_result”: “登录失败，提示‘用户名长度应为6-18位’。”, “design_method”: “边界值分析（下边界-1）”, “priority”: “中” }, { “id”: “TC04”, “title”: “使用包含特殊字符（如@）的用户名尝试登录”, “precondition”: “用户拥有已注册的账户。”, “test_steps”: [“1. 打开登录页面。”, “2. 输入‘user@name’。", “3. 输入有效密码。”, “4. 点击登录按钮。”], “expected_result”: “登录失败，提示‘用户名只能包含字母、数字、下划线’。”, “design_method”: “等价类划分（无效等价类）”, “priority”: “中” } ]

可以看到，模型不仅生成了基本的正向用例（TC01），还自动考虑了边界情况（TC02， TC03）和无效等价类（TC04），并且为每个用例标注了设计方法和优先级。这已经是一个相当不错的起点。

3. 在实际测试流程中落地应用

生成用例只是第一步，如何把它融入团队现有的测试流程，让它真正发挥作用，才是关键。我们摸索出几种应用模式：

• 需求评审辅助：在需求评审阶段，测试工程师可以将初步的产品需求文档（PRD）片段输入模型，快速生成一批基础用例。这能帮助大家在评审会上更早、更具体地思考测试点，甚至发现需求描述中模糊或矛盾的地方。
• 测试设计脑暴工具：对于复杂功能，测试工程师可以先用模型生成一批“种子用例”，然后基于这些用例进行评审、补充和深化。模型能提供一个系统性的思考框架，避免遗漏明显的测试维度。
• 新人培训与知识沉淀：让新人学习如何使用这个工具生成用例，并对比资深工程师设计的用例，是快速理解业务规则和测试设计思路的好方法。同时，那些经过验证和优化的Prompt，本身就成了团队宝贵的测试知识资产。

当然，它目前还不能完全替代测试工程师。模型的输出需要人工审核和修正。它可能不理解某些特定的业务规则，或者生成的步骤过于理想化。它的价值在于充当一个高效的“初级生产力”，承担大量基础、重复的脑力劳动，让测试工程师能更专注于那些需要深度业务理解、复杂逻辑推理和探索性测试的高价值任务。

4. 效果、局限与未来尝试

在实际项目中应用一段时间后，我们有一些直观的感受。

在提升效率方面，效果是明显的。对于规则清晰、描述明确的功能点，模型能在几分钟内生成数十个覆盖不同场景的用例草稿，这比完全从零开始手工编写快得多。在覆盖度上，它基于方法论生成的用例，确实能提醒我们一些容易忽略的边界组合，比如多个输入框边界条件同时生效的情况。

不过，局限性也同样存在。首先，它严重依赖需求描述的质量。模糊、歧义的需求会导致生成无用的甚至错误的用例。这就是我们常说的“垃圾进，垃圾出”。其次，它缺乏对业务上下文和系统内部状态的理解。比如，它不知道“支付”功能背后关联着账户余额、风控规则等复杂状态。最后，对于需要复杂交互序列或涉及多系统的端到端场景，它的表现还比较弱。

针对这些局限，我们正在尝试一些改进方向。例如，构建更精细的Prompt模板库，针对“查询类”、“计算类”、“状态变更类”等不同功能模式提供专用Prompt。我们也尝试在Prompt中加入部分业务规则或术语解释，给模型提供更多上下文。长远来看，结合测试管理平台的API，实现从需求条目自动触发用例生成，并将生成的用例直接导入测试用例库，会是一个更流畅的自动化闭环。

5. 写在最后

回过头看，把通义千问这样的轻量化大模型引入软件测试，并不是为了追求完全无人化的自动化，而是走向“人机协同”的智能测试。它像是一个不知疲倦的初级测试员，负责完成那些定义明确、模式固定的任务，为我们提供高质量的“原材料”。而测试工程师则升级为“测试架构师”和“评审专家”，负责制定测试策略、设计复杂的测试场景，以及最终对用例质量进行把关。

这个过程也让我意识到，Prompt工程就像是在教一个新同事如何工作。指令越清晰、越具体，他完成得就越好。对于测试团队来说，现在开始积累那些能生成高质量用例的Prompt，其价值可能不亚于积累测试用例本身。

如果你所在的团队也在为测试用例设计的效率和覆盖度发愁，不妨试试这个方法。从一个小而具体的功能点开始，比如一个输入框的校验规则，亲手实践一下从部署、写Prompt到生成和评审的全过程。你会发现，让AI辅助我们进行创造性工作的门槛，远比想象中要低。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。