通义千问1.5-1.8B-Chat-GPTQ-Int4实战：构建智能软件测试用例生成器

通义千问1.5-1.8B-Chat-GPTQ-Int4实战构建智能软件测试用例生成器如果你是一名软件测试工程师下面这个场景你一定不陌生产品经理扔过来一份几十页的需求文档或者开发同学更新了一个复杂的接口而你需要在短时间内设计出覆盖各种场景的测试用例。手动梳理、逐条编写不仅耗时耗力还总担心有遗漏。今天我们就来聊聊如何用一个小巧但聪明的AI模型——通义千问1.5-1.8B-Chat-GPTQ-Int4来帮你解决这个痛点打造一个属于你自己的智能测试用例生成器。这个想法很简单让AI理解你的需求或接口定义然后自动为你生成包括正常场景、边界值、异常情况在内的测试用例甚至直接输出成可执行的pytest脚本。听起来是不是很省事我们这就动手把它实现出来。1. 为什么选择通义千问1.5-1.8B-Chat-GPTQ-Int4在开始动手之前你可能会问为什么选这个模型市面上大模型那么多。这里有几个很实际的理由。首先它足够“小”。1.8B的参数规模经过GPTQ-Int4量化后模型文件可能就几个GB对硬件要求非常友好。你不需要昂贵的显卡在普通的开发机甚至笔记本上就能跑起来这对于集成到日常开发测试流程中至关重要。其次它足够“聪明”。虽然参数不大但通义千问在中文理解和指令跟随方面表现不错。让它理解一段自然语言描述的需求并按照“等价类划分”、“边界值分析”这些测试方法论来思考它完全能胜任。我们不需要它写诗作画只需要它严谨、结构化地输出测试逻辑。最后是成本与效率的平衡。本地化部署意味着没有网络延迟没有API调用费用数据也完全在本地对于处理公司内部需求文档这类敏感信息非常合适。一次部署长期受益。所以对于构建一个轻量级、自动化、高性价比的测试辅助工具来说这个模型是一个相当务实的选择。2. 环境搭建与模型部署我们先把模型跑起来。整个过程就像安装一个普通的Python库加上下载一个文件一样简单。2.1 准备Python环境建议使用Python 3.8到3.10版本。创建一个干净的虚拟环境是个好习惯。# 创建并激活虚拟环境以conda为例 conda create -n test_ai python3.9 conda activate test_ai # 安装核心依赖 pip install torch transformers accelerate这里安装了PyTorch、Hugging Face的Transformers库以及Accelerate库。Accelerate能帮助我们在不同硬件上更高效地运行模型。2.2 获取并加载量化模型通义千问1.5-1.8B-Chat的GPTQ-Int4量化模型可以在一些模型社区找到。假设我们已经下载好了模型文件放在本地目录./qwen1.5-1.8b-chat-gptq-int4中。加载模型的代码非常简单from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_path ./qwen1.5-1.8b-chat-gptq-int4 # 加载tokenizer和模型 tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.float16, # 使用半精度以节省显存 device_mapauto, # 自动分配模型层到可用设备GPU/CPU trust_remote_codeTrue ) # 将模型设置为评估模式 model.eval()device_map”auto”这个参数很棒它会自动检测你的环境如果有GPU就用GPU没有就用CPU无缝切换。加载成功后你的AI测试助手就在后台待命了。3. 设计智能测试用例生成器的核心逻辑模型准备好了接下来是设计它的“大脑”也就是如何让它理解任务并输出我们想要的内容。我们不能只是简单地问“请生成测试用例”需要给它更清晰的指令和上下文。3.1 构建系统提示词提示词是与模型沟通的“说明书”。一个好的提示词能极大提升输出质量。我们的提示词需要包含以下几个部分角色定义告诉模型它现在是谁。任务描述明确要它做什么。方法论指导融入软件测试的专业知识。输出格式要求规定好它回答的样式方便我们后续解析。下面是一个提示词模板def build_system_prompt(): prompt 你是一个资深的软件测试工程师擅长设计全面、严谨的测试用例。你的任务是根据给定的功能描述或接口定义自动生成高质量的测试用例。 请遵循以下测试设计方法 1. 等价类划分将输入域划分为有效等价类和无效等价类。 2. 边界值分析针对输入范围的边界设计测试数据。 3. 场景法考虑用户主要的操作流程和异常流程。 输出要求 - 首先用一句话总结被测功能。 - 然后以Markdown表格形式列出测试用例表格包含以下列用例ID、测试场景/描述、输入数据/操作步骤、预期结果。 - 最后生成对应的pytest测试函数代码框架包含必要的import和函数定义。 现在请针对以下内容生成测试用例 return prompt这个提示词明确了角色、方法、输出格式给模型划定了清晰的思考路径。3.2 实现用例生成函数接下来我们写一个函数将用户输入的需求和系统提示词结合起来发送给模型并获取回复。def generate_test_cases(requirement_text, max_new_tokens1024): 根据需求文本生成测试用例。 参数: requirement_text: 需求描述或接口定义字符串。 max_new_tokens: 生成文本的最大长度。 返回: 模型生成的完整回复文本。 # 构建完整的对话输入 messages [ {role: system, content: build_system_prompt()}, {role: user, content: requirement_text} ] # 将对话格式化为模型接受的输入 text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) # 对输入进行编码 model_inputs tokenizer([text], return_tensorspt).to(model.device) # 生成回复 with torch.no_grad(): # 禁用梯度计算加快推理速度 generated_ids model.generate( **model_inputs, max_new_tokensmax_new_tokens, do_sampleTrue, # 启用采样使输出更多样 temperature0.3, # 较低的温度使输出更确定和严谨 repetition_penalty1.1 # 重复惩罚避免重复内容 ) # 解码生成的token得到文本 generated_text tokenizer.batch_decode(generated_ids, skip_special_tokensTrue)[0] # 提取模型回复部分通常位于“assistant”之后 # 这里做一个简单的分割实际应用可根据模型输出格式调整 if assistant in generated_text: response generated_text.split(assistant)[-1].strip() else: response generated_text.split(requirement_text)[-1].strip() return response这个函数封装了与模型交互的全过程。我们通过temperature0.3让模型的输出更稳定、更偏向确定性适合生成要求严谨的测试用例。4. 实战演练从需求到测试脚本光说不练假把式。我们用一个实际的例子来演示整个流程。假设我们有一个用户登录功能的需求。4.1 输入需求描述我们定义这样一个登录接口的需求login_requirement 功能用户登录接口 接口POST /api/v1/login 请求参数JSON格式: - username: 字符串必填长度4-20字符只能包含字母、数字、下划线。 - password: 字符串必填长度6-32字符。 响应 - 成功HTTP 200返回 {“code”: 0, “message”: “success”, “token”: “xxx”} - 失败HTTP 400返回 {“code”: 1001, “message”: “用户名或密码错误”} - 参数错误HTTP 422返回具体的参数校验错误信息。 4.2 调用生成器并获取结果现在把这个需求喂给我们的AI助手。result generate_test_cases(login_requirement) print(result)运行后我们可能会得到类似下面的输出为简洁起见已做精简和格式化被测功能是一个基于用户名和密码进行身份验证的登录接口。用例ID测试场景/描述输入数据/操作步骤预期结果TC-LOGIN-01有效等价类 - 正常登录username”validUser123”, password”strongPwd456”HTTP 200返回成功tokenTC-LOGIN-02边界值 - 用户名最小长度username”abcd”, password”pass12”HTTP 200登录成功TC-LOGIN-03边界值 - 用户名最大长度username”twentyCharsLongName”, password”pass12”HTTP 200登录成功TC-LOGIN-04无效等价类 - 用户名过短username”abc”, password”pass12”HTTP 422返回用户名长度错误TC-LOGIN-05无效等价类 - 用户名包含非法字符username”username”, password”pass12”HTTP 422返回用户名格式错误TC-LOGIN-06无效等价类 - 密码过短username”validUser”, password”12345”HTTP 422返回密码长度错误TC-LOGIN-07无效等价类 - 用户名正确密码错误username”validUser”, password”wrongPwd”HTTP 400返回用户名或密码错误TC-LOGIN-08场景法 - 请求体为空{}HTTP 422返回缺少必要参数TC-LOGIN-09场景法 - 缺少password字段{“username”: “test”}HTTP 422返回缺少必要参数import pytest import requests BASE_URL “http://localhost:8000” pytest.mark.parametrize(“username, password, expected_status, expected_code”, [ (“validUser123”, “strongPwd456”, 200, 0), (“abcd”, “pass12”, 200, 0), (“twentyCharsLongName”, “pass12”, 200, 0), (“abc”, “pass12”, 422, None), # 具体错误码视实际接口定义 (“username”, “pass12”, 422, None), (“validUser”, “12345”, 422, None), (“validUser”, “wrongPwd”, 400, 1001), ]) def test_login_parameterized(username, password, expected_status, expected_code): url f”{BASE_URL}/api/v1/login” payload {“username”: username, “password”: password} resp requests.post(url, jsonpayload) assert resp.status_code expected_status if expected_code is not None: assert resp.json().get(“code”) expected_code def test_login_missing_fields(): url f”{BASE_URL}/api/v1/login” # 测试请求体为空 resp1 requests.post(url, json{}) assert resp1.status_code 422 # 测试缺少password resp2 requests.post(url, json{“username”: “test”}) assert resp2.status_code 422看AI不仅生成了结构清晰的测试用例表格覆盖了有效输入、边界值、无效输入和异常场景还直接给出了参数化的pytest代码框架。测试工程师要做的就是审查这些用例是否合理补充一些业务特定的场景比如账号锁定然后把代码复制到项目里填充一下实际的API地址和断言细节。4.3 解析与后处理模型的输出是混合了自然语言和代码的文本。我们可以写一些简单的解析函数把测试用例表格和代码块分别提取出来保存为不同的文件比如test_cases.md和test_login.py方便集成到现有的测试管理工具或CI/CD流程中。import re def parse_model_output(output_text): 解析模型输出分离出总结、用例表格和代码。 result { “summary”: “”, “test_cases_md”: “”, “pytest_code”: “” } # 简单按行分割 lines output_text.split(‘\n’) # 这里可以编写更健壮的解析逻辑例如通过查找“|”识别表格查找“python”识别代码块 # 作为示例我们进行简单查找 if “python” in output_text: parts output_text.split(“python”) result[“pytest_code”] parts[1].split(“”)[0].strip() result[“test_cases_md”] parts[0] # 假设表格在代码块之前 # 第一行通常是总结 result[“summary”] lines[0] if lines else “” return result parsed parse_model_output(result) print(“生成的pytest代码已就绪长度”, len(parsed[“pytest_code”]))5. 应用场景扩展与优化建议这个基础的生成器已经能解决不少问题但我们可以让它变得更强大、更贴合实际工作流。场景扩展数据库操作测试给定一个SQL语句或数据模型生成针对增删改查、事务、并发操作的测试用例。UI界面测试根据页面原型或用户故事生成Selenium或Playwright的自动化测试步骤。安全测试提示模型关注SQL注入、XSS、越权访问等常见安全漏洞生成对应的渗透测试用例。性能测试针对接口生成不同并发用户数、思考时间、负载模式的测试场景描述供JMeter等工具使用。优化建议知识库增强将公司的测试规范、过往经典的测试用例作为示例添加到系统提示词中让模型学习你们的“最佳实践”。迭代对话不要只问一次。可以先让模型生成大纲你再针对某个复杂场景要求它“补充更多边界值用例”进行多轮交互细化输出。集成到IDE或测试平台开发一个VS Code插件或与Jira、TestRail等平台集成在编写需求或缺陷时一键生成测试点。结果评估与反馈建立一个简单的反馈机制让测试工程师对生成的用例评分相关、不相关、部分相关用这些数据微调提示词让模型越用越懂你。6. 总结用通义千问1.5-1.8B-Chat-GPTQ-Int4来构建智能测试用例生成器不是一个炫技的概念而是一个能立刻上手、产生实际价值的工程实践。它把测试工程师从大量重复、机械的用例设计工作中解放出来让我们能更专注于那些真正需要人类经验和创造力的复杂场景测试、探索性测试。实际用下来这个方案的启动成本很低部署简单生成用例的速度和基础质量都令人满意。当然它不是一个全自动的、完美无缺的解决方案。生成的用例需要工程师进行审查和润色模型的“思考”过程也缺乏真正的业务上下文。但它作为一个强大的“初级测试员”或“灵感加速器”已经足够出色。如果你正在被繁重的测试设计工作困扰或者想探索AI在质量保障领域的更多可能性不妨就从这个小项目开始。克隆一份代码加载模型输入你手头的一个需求试试看。你会发现让AI辅助测试不再是未来时而是现在进行时。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。