通义千问1.5-1.8B-Chat-GPTQ-Int4在软件测试中的应用自动化测试用例生成最近和几个做测试的朋友聊天大家普遍吐槽一件事写测试用例太费时间了。尤其是那些边界情况、异常流程想得脑袋疼写出来还怕有遗漏。一个登录功能看起来简单真要覆盖全面得写几十个用例。有没有什么办法能把这个过程自动化一点正好我最近在折腾一些轻量级的AI模型发现通义千问的1.5-1.8B-Chat-GPTQ-Int4这个版本虽然参数不大但在理解代码和生成结构化内容上还挺灵光。我就想能不能让它来帮我们生成测试用例试了一段时间效果比预想的好。这篇文章我就来分享一下怎么用这个模型让写测试用例这件事变得轻松一些。1. 为什么用AI生成测试用例先说说我们测试工程师的日常痛点。接到一个需求比如开发了一个新的API接口我们需要根据接口文档设计出各种正常、异常、边界情况的测试用例。这个过程非常依赖经验而且重复性高容易疲劳导致遗漏。传统的自动化测试工具能帮我们执行用例但用例本身还是得我们手动设计。而通义千问1.5-1.8B-Chat-GPTQ-Int4这类模型它的长处在于理解自然语言和代码语义。你给它一段函数定义或者接口文档它就能“理解”这个功能是干什么的输入输出是什么然后基于常见的测试设计方法比如等价类划分、边界值分析自动生成测试用例的代码骨架。这带来的价值很直接提升效率把我们从重复的、套路化的用例设计工作中解放出来专注于更复杂的测试场景和策略设计。提高覆盖率AI不知疲倦可以基于规则生成大量边界和异常用例有助于发现我们人工思考可能忽略的角落。统一标准生成的用例结构相对规范有利于团队内用例风格的统一。快速启动面对新接口或重构的代码能迅速产生一批基础测试用例作为我们进一步完善的起点。当然它不是要取代测试工程师而是一个强大的“辅助”。生成的用例需要我们来审查、补充和调整但有了这个起点后续工作就轻松多了。2. 环境准备与模型调用通义千问1.5-1.8B-ChatQ-Int4是一个经过量化压缩的模型对硬件要求非常友好在普通的消费级显卡甚至CPU上都能跑起来部署也很简单。2.1 快速部署模型这里以使用Ollama为例它能让模型本地运行变得极其简单。如果你还没有安装Ollama可以去官网下载安装包几分钟就能搞定。安装好后打开终端或命令行执行下面这条命令拉取并运行模型ollama run qwen2.5:1.8b-instruct-q4_K_M这条命令会自动下载模型并启动一个交互式对话界面。看到提示符就说明模型已经准备好听你指挥了。2.2 基础调用方式在Ollama的交互界面里你可以直接输入指令。但为了生成测试用例我们更常用的是通过API来调用这样方便集成到脚本或工具链里。启动Ollama服务后你可以用curl或者写一段Python脚本来调用。下面是一个简单的Python示例import requests import json def ask_qwen(prompt): url http://localhost:11434/api/generate data { model: qwen2.5:1.8b-instruct-q4_K_M, prompt: prompt, stream: False } response requests.post(url, jsondata) return response.json()[response] # 试试看 test_prompt 用一句话介绍下你自己。 answer ask_qwen(test_prompt) print(answer)运行这段代码如果看到模型返回了自我介绍说明你的调用环境已经通了。接下来我们就可以进入正题让它来帮忙写测试用例了。3. 实战为登录功能生成测试用例我们用一个经典的“用户登录”功能作为例子。假设后端提供了一个登录接口文档描述如下接口POST /api/login参数username: 字符串用户名长度要求4-20字符。password: 字符串密码长度要求6-20字符必须包含字母和数字。返回成功{“code”: 200, “message”: “登录成功”, “token”: “xxx”}失败{“code”: 400, “message”: “用户名或密码错误”}或其它错误信息。我们的目标是让AI为这个接口生成Python使用pytest框架的测试用例代码。3.1 构建有效的提示词直接让模型“生成登录测试用例”可能效果比较随机。我们需要给它一个清晰、结构化的指令也就是“提示词”。一个好的提示词应该包含角色设定告诉模型它要扮演什么角色。任务描述具体要它做什么输入是什么。输出格式明确要求它输出什么格式的内容比如Python代码。测试设计方法引导它使用专业的测试方法。下面是我构造的提示词login_test_prompt 你是一个资深的软件测试工程师精通测试用例设计和pytest框架。 请根据以下接口文档生成完整的、可执行的pytest测试用例代码。要求覆盖 1. 正常登录流程有效用户名和密码。 2. 边界值测试用户名和密码的长度边界。 3. 异常流测试用户名不存在、密码错误、参数缺失、参数类型错误、密码复杂度不符等。 4. 安全性测试简单的SQL注入和XSS尝试。 请为每个测试用例添加清晰的注释说明。最终输出只包含Python代码。 接口文档 接口POST /api/login 参数 - username: 字符串用户名长度要求4-20字符。 - password: 字符串密码长度要求6-20字符必须包含字母和数字。 返回 - 成功{code: 200, message: 登录成功, token: xxx} - 失败{code: 400, message: 用户名或密码错误} 或其它错误信息。 假设我们使用 requests 库发送HTTP请求。基础URL为 BASE_URL http://localhost:8080。 请开始生成代码。 3.2 生成并解析用例将上面的提示词通过我们写好的ask_qwen函数发送给模型test_code ask_qwen(login_test_prompt) print(test_code)模型会返回一大段Python代码。由于模型输出可能包含一些解释性文字我们需要提取纯代码部分。这里假设返回内容以python开头。我们可以简单处理一下# 假设返回的文本存储在 raw_response 变量中 if python in raw_response: # 提取代码块 code_block raw_response.split(python)[1].split()[0] print(code_block) else: # 如果没有代码块标记直接打印 print(raw_response)3.3 生成的用例示例与分析运行后模型可能会生成类似下面的代码经过人工整理和简化import pytest import requests BASE_URL http://localhost:8080 LOGIN_URL f{BASE_URL}/api/login class TestLoginAPI: 登录接口测试类 # 正常流测试 def test_login_success(self): 测试正常登录流程 payload {username: validUser123, password: pass123word} response requests.post(LOGIN_URL, jsonpayload) assert response.status_code 200 json_data response.json() assert json_data[code] 200 assert token in json_data assert len(json_data[token]) 0 # 边界值测试 - 用户名长度 def test_username_length_min(self): 测试用户名长度下限边界 (4字符) payload {username: usr1, password: pass123word} response requests.post(LOGIN_URL, jsonpayload) # 期望成功或根据业务逻辑判断此处假设成功 assert response.status_code 200 def test_username_length_min_minus_one(self): 测试用户名长度低于下限 (3字符) payload {username: usr, password: pass123word} response requests.post(LOGIN_URL, jsonpayload) assert response.status_code 400 # 期望失败 def test_username_length_max(self): 测试用户名长度上限边界 (20字符) long_name a * 20 payload {username: long_name, password: pass123word} response requests.post(LOGIN_URL, jsonpayload) assert response.status_code 200 def test_username_length_max_plus_one(self): 测试用户名长度超过上限 (21字符) too_long_name a * 21 payload {username: too_long_name, password: pass123word} response requests.post(LOGIN_URL, jsonpayload) assert response.status_code 400 # 期望失败 # 边界值测试 - 密码长度与复杂度 def test_password_length_min(self): 测试密码长度下限边界 (6字符且含字母数字) payload {username: validUser123, password: ab1234} response requests.post(LOGIN_URL, jsonpayload) assert response.status_code 200 def test_password_without_digit(self): 测试密码缺少数字不符合复杂度要求 payload {username: validUser123, password: password} response requests.post(LOGIN_URL, jsonpayload) # 接口应在验证时拒绝可能返回400或422等 assert response.status_code 400 # 异常流测试 def test_login_user_not_exist(self): 测试用户名不存在 payload {username: nonExistentUser, password: somePass123} response requests.post(LOGIN_URL, jsonpayload) assert response.status_code 400 assert response.json()[message] 用户名或密码错误 def test_login_wrong_password(self): 测试密码错误 payload {username: validUser123, password: wrongPass123} response requests.post(LOGIN_URL, jsonpayload) assert response.status_code 400 assert response.json()[message] 用户名或密码错误 def test_login_missing_username(self): 测试缺失用户名参数 payload {password: pass123word} response requests.post(LOGIN_URL, jsonpayload) assert response.status_code 400 # 应为错误的请求 def test_login_missing_password(self): 测试缺失密码参数 payload {username: validUser123} response requests.post(LOGIN_URL, jsonpayload) assert response.status_code 400 # 简单的安全性试探示例 def test_login_sql_injection_attempt(self): 尝试简单的SQL注入payload payload {username: admin --, password: any} response requests.post(LOGIN_URL, jsonpayload) # 我们不期望登录成功但应被妥善处理不应返回服务器错误(500) assert response.status_code ! 500 # 可能返回400或一个通用的错误信息我们来分析一下AI生成的这套用例覆盖度不错它确实考虑到了正常流、边界值用户名/密码的长度上下限、刚好超限、异常流用户不存在、密码错误、参数缺失甚至基础的安全测试。结构清晰使用了pytest的测试类每个测试方法都有清晰的命名和注释符合规范。可直接执行生成的代码是完整的只要安装好pytest和requests配置好正确的BASE_URL就能直接运行。需要人工完善的地方测试数据用例中的validUser123是一个假设存在的用户实际运行时需要替换为真实的测试账号或使用测试环境的预设数据。断言细节一些断言可以更精确比如密码复杂度错误的用例返回的message可能不是“用户名或密码错误”而是“密码格式不正确”。这需要测试工程师根据实际接口行为进行修正。更多场景比如并发登录、密码加密传输、token刷新等模型可能没有覆盖需要人工补充。但这已经是一个非常好的起点了。它帮你完成了大约70%的套路化工作剩下的30%需要你结合业务逻辑进行审查和精细化调整。4. 扩展应用与实用技巧掌握了基础方法后我们可以把这个思路用到更多测试场景中。4.1 为单个函数生成单元测试除了HTTP接口模型对纯函数代码的理解能力也很强。你可以把函数定义丢给它。function_test_prompt 你是一个测试工程师。请为下面的Python函数生成pytest单元测试覆盖正常情况、边界情况和异常情况。 函数定义 def divide_numbers(a: float, b: float) - float: \\\ 返回a除以b的结果。 如果b为0抛出ValueError异常。 \\\ if b 0: raise ValueError(“除数不能为0”) return a / b 要求生成完整的测试代码包含必要的import和测试用例。 4.2 生成测试数据测试用例有了有时还需要配套的测试数据。模型也可以帮忙生成一些结构化的测试数据。data_gen_prompt 为测试一个用户注册接口需要一些测试数据。接口要求如下 字段username字符串4-20位 email有效邮箱格式 age整数18-100。 请生成5组符合要求的测试数据以JSON列表格式输出。 其中应包含1组完全合规数据2组在边界上的数据如age18, age1002组不符合要求的数据如邮箱格式错误。 4.3 提升生成质量的技巧提供更详细的上下文在提示词中加入项目使用的技术栈如FastAPI、Django、数据库约束、业务规则等生成的用例会更贴切。指定测试框架和风格明确要求使用pytest、unittest或JUnit并指定喜欢的断言风格如assert response.json()[“code”] 200。分步骤生成对于复杂功能可以先让模型生成测试点Test Ideas再针对每个测试点生成具体用例代码。迭代优化把模型第一次生成的结果中不准确的部分反馈给它让它修正。比如“第三个用例的断言不对实际接口在密码错误时返回的code是401请修正。”结合模板你可以先写好测试类的骨架和固定的导入语句只让模型填充各个测试方法的内容这样可控性更强。5. 总结用通义千问1.5-1.8B-Chat-GPTQ-Int4来辅助生成测试用例给我的感觉就像多了一个不知疲倦、记忆力超群的初级测试伙伴。它特别擅长快速产出那些有固定模式的、基于规则的基础用例和边界用例能极大地减轻我们在测试设计初期的负担。实际用下来它的优势在于“启动速度”。面对一个新接口几分钟内就能得到一套覆盖了主要测试场景的用例代码骨架我们只需要把精力花在审查、补充业务特有的逻辑用例以及准备测试数据和环境上。这对于追求快速迭代的团队来说价值很明显。当然它也不是万能的。生成的用例质量非常依赖于你给的提示词是否清晰、准确。最终的断言逻辑、复杂的业务规则校验、以及测试数据和环境的准备仍然需要测试工程师的专业判断和操作。把它当作一个强大的“代码补全”和“灵感激发”工具而不是全自动的测试用例生成器这样定位会更准确。如果你也在为写测试用例发愁不妨试试这个方法。从一个小功能开始比如一个查询接口或者一个工具函数构造好提示词看看它能给你带来什么惊喜。过程中你可能会发现需要调整提示词的方式这本身也是一个有趣的探索。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。