Qwen1.5-1.8B GPTQ在软件测试中的应用自动化测试用例生成1. 引言做软件测试的朋友估计都经历过这样的场景产品经理甩过来一份几十页的需求文档或者开发同学提交了一个包含十几个接口的模块然后告诉你“帮忙测一下明天给报告。” 看着密密麻麻的功能点光是设计测试用例头就已经开始疼了。手动写用例不仅耗时耗力还容易遗漏边界情况覆盖率总是不尽如人意。有没有一种方法能让我们从这种重复、繁琐的脑力劳动中解放出来最近我尝试将一个小巧的AI模型——Qwen1.5-1.8B GPTQ——引入到我们的测试流程里专门用来干一件事自动生成测试用例。效果出乎意料的好。它就像一个不知疲倦的初级测试工程师只要你给它一个函数签名、一段需求描述它就能哗啦啦地给你输出一堆测试用例包括正常的、异常的、边界的甚至还附上预期结果。这篇文章我就来跟你聊聊我是怎么把这个模型用起来的它具体能帮我们做什么以及如何把它集成到Jenkins或者GitLab CI这样的自动化流水线里真正实现测试左移和效率提升。如果你也在为测试用例设计发愁或者想探索AI在质量保障领域的落地那接下来的内容应该对你有帮助。2. 为什么选择Qwen1.5-1.8B GPTQ你可能会问大模型那么多为什么偏偏选这个“1.8B”参数的小个子在软件测试这个具体场景里大有大的难处小有小的妙处。首先它足够轻量。1.8B的参数量经过GPTQ量化后模型文件可能就几个GB对硬件要求非常友好。我们完全可以在测试团队的开发机、甚至一台配置不错的笔记本上部署和运行不需要申请昂贵的GPU服务器。这对于想要快速尝试、小范围验证的团队来说门槛低了很多。其次它推理速度快。生成一个测试用例集通常只需要几秒到十几秒。这个速度在需要频繁触发、快速反馈的CI/CD流水线中是完全可以接受的。你总不希望因为生成测试用例把整个流水线的执行时间拉长几倍吧再者Qwen1.5系列在代码和理解能力上表现不错。虽然它比不上那些动辄上百B参数的代码大模型但对于理解函数意图、分析输入输出、识别边界条件这类结构化程度相对较高的任务它的能力是够用的。我们不需要它写出多么复杂的业务逻辑代码只需要它基于规则和模式生成有效的测试输入和预期输出。最后就是成本可控。无论是本地部署的硬件成本还是如果使用API可能产生的调用成本小模型都更具优势。在软件测试这个对成本敏感、追求ROI的环节这是一个非常重要的考量因素。当然它也有局限。比如对于极其复杂、充满业务暗坑的需求它可能无法生成足够“聪明”的用例。但它能完美解决我们80%的常规、重复性用例设计工作这已经是一个巨大的胜利了。3. 它能做什么几个实际场景演示光说可能有点抽象我们直接看几个例子看看这个模型是怎么工作的。3.1 场景一根据函数签名生成单元测试用例假设开发提交了一个新的工具函数这是最常见的场景。你给模型的输入提示词请为以下Python函数生成测试用例需覆盖正常情况、边界情况和异常情况并给出预期输出。 函数签名 def divide_numbers(dividend: float, divisor: float) - float: \\\ 执行两个数字的除法运算。 参数: dividend: 被除数 divisor: 除数 返回: 两数相除的结果 异常: 当除数为0时抛出ZeroDivisionError。 \\\ if divisor 0: raise ZeroDivisionError(除数不能为零) return dividend / divisor模型可能生成的输出import pytest def test_divide_numbers_normal(): \\\测试正常除法运算\\\ assert divide_numbers(10, 2) 5.0 assert divide_numbers(9, 3) 3.0 assert divide_numbers(-10, 2) -5.0 assert divide_numbers(10, -2) -5.0 assert divide_numbers(0, 5) 0.0 def test_divide_numbers_float_precision(): \\\测试浮点数除法\\\ # 注意浮点数精度比较 assert abs(divide_numbers(1, 3) - 0.3333333333333333) 1e-10 def test_divide_numbers_boundary(): \\\测试边界情况\\\ # 被除数为极大/极小值 import sys max_float sys.float_info.max min_float sys.float_info.min assert divide_numbers(max_float, 1) max_float assert divide_numbers(min_float, 1) min_float # 除数为接近0的极小正值 assert divide_numbers(1, 1e-10) 1e10 def test_divide_numbers_exception(): \\\测试异常情况除数为零\\\ with pytest.raises(ZeroDivisionError) as exc_info: divide_numbers(10, 0) assert 除数不能为零 in str(exc_info.value)你看它不仅仅生成了“10除以2等于5”这种基础用例还考虑到了负数、零、浮点数精度、极大极小值等边界情况并且按照pytest的格式给出了测试异常的场景。这已经覆盖了一个简单函数测试的绝大部分要点。3.2 场景二根据用户故事生成集成测试用例再来看一个更贴近业务的例子比如一个用户登录的功能。你给模型的输入根据以下用户故事生成API接口级别的测试用例包括请求和预期响应。考虑成功、失败的各种情况。 用户故事作为一个注册用户我希望通过用户名和密码登录系统以便访问我的个人主页。 验收标准 1. 用户提供正确的用户名和密码应登录成功返回访问令牌token和用户基本信息。 2. 用户提供错误的密码应登录失败返回明确的错误信息。 3. 用户提供不存在的用户名应登录失败返回明确的错误信息。 4. 请求体中缺少用户名或密码字段应返回参数错误。 5. 连续5次登录失败后该账号应被临时锁定10分钟。模型可能生成的输出以Python requests库示例import requests import time BASE_URL http://api.example.com def test_login_success(): \\\测试登录成功\\\ payload {username: valid_user, password: correct_password} response requests.post(f{BASE_URL}/login, jsonpayload) assert response.status_code 200 json_data response.json() assert token in json_data assert len(json_data[token]) 10 # token应有合理长度 assert user_id in json_data assert username in json_data def test_login_wrong_password(): \\\测试密码错误\\\ payload {username: valid_user, password: wrong_password} response requests.post(f{BASE_URL}/login, jsonpayload) assert response.status_code 401 # 或业务定义的其他错误码 assert 密码错误 in response.json().get(message, ) def test_login_user_not_exist(): \\\测试用户不存在\\\ payload {username: non_existent_user, password: any_password} response requests.post(f{BASE_URL}/login, jsonpayload) assert response.status_code 404 # 或401 assert 用户不存在 in response.json().get(message, ) def test_login_missing_field(): \\\测试缺少必填字段\\\ # 缺少密码 payload {username: valid_user} response requests.post(f{BASE_URL}/login, jsonpayload) assert response.status_code 400 # 缺少用户名 payload {password: correct_password} response requests.post(f{BASE_URL}/login, jsonpayload) assert response.status_code 400 def test_login_account_lockout(): \\\测试账号锁定机制\\\ test_user lock_test_user correct_pwd pwd123 wrong_pwd wrong # 假设该账号初始未锁定 # 连续5次错误登录 for i in range(5): payload {username: test_user, password: wrong_pwd} response requests.post(f{BASE_URL}/login, jsonpayload) # 前4次应只是失败第5次可能触发锁定 if i 4: assert response.status_code 401 else: # 第5次可能返回锁定信息 json_data response.json() assert response.status_code in [401, 423] if response.status_code 423: assert 锁定 in json_data.get(message, ) # 锁定后即使用正确密码也应失败 payload {username: test_user, password: correct_pwd} response requests.post(f{BASE_URL}/login, jsonpayload) assert response.status_code 423 # 等待10分钟后实际测试可能需要mock时间应能重新登录 # 此处简化仅说明测试思路 print(注意此处需要模拟10分钟等待或使用时间mock)模型根据用户故事和验收标准生成了对应不同场景的测试函数甚至考虑到了账号锁定这种带有状态和时序的复杂场景并给出了测试思路。这能极大减轻测试人员设计集成测试用例的负担。4. 如何把它集成到你的测试流水线生成用例只是第一步让这个过程自动化无缝嵌入到开发流程中才能产生最大价值。下面我分享两种常见的集成思路。4.1 方案一与GitLab CI/CD集成假设你们的代码仓库在GitLab可以利用Merge Request (MR) 的Webhook来触发。核心流程触发时机当开发人员创建或更新一个Merge Request时GitLab会发送Webhook事件。CI Runner响应你的GitLab Runner安装了Qwen模型运行环境接收到事件。分析变更CI脚本分析MR中变更的文件识别出新增或修改的函数、类或API定义。调用模型将识别出的代码片段或需求描述构造为提示词发送给本地部署的Qwen模型服务。生成用例模型返回生成的测试用例代码。提交回MRCI脚本将生成的测试用例文件作为一个新的提交推送到当前MR的分支或者以评论的形式附加在MR中供开发者和测试者审查。一个简化的.gitlab-ci.yml阶段示例stages: - test-case-generation generate-test-cases: stage: test-case-generation image: python:3.9-slim # 使用包含所需依赖的镜像 script: - pip install requests # 安装调用模型API的库 - | # 1. 使用git diff找出本次MR中新增的Python文件或特定注释标记的文件 CHANGED_FILES$(git diff --name-only origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD | grep \.py$) for file in $CHANGED_FILES; do # 2. 提取函数签名或类定义 (这里简化处理实际可能需要解析AST) # 假设我们有一个脚本 extract_functions.py 来做这件事 FUNCTIONS$(python extract_functions.py $file) # 3. 为每个函数调用模型服务生成测试用例 for func_sig in $FUNCTIONS; do PROMPT请为以下Python函数生成pytest测试用例...\n$func_sig RESPONSE$(curl -X POST http://localhost:8000/generate \ -H Content-Type: application/json \ -d {\prompt\: \$PROMPT\, \max_tokens\: 1000}) # 4. 将生成的测试代码写入对应的测试文件 TEST_FILEtests/test_$(basename $file .py).py echo # 为函数 $func_sig 生成的测试 $TEST_FILE echo $RESPONSE $TEST_FILE echo $TEST_FILE done done # 5. 如果有新的测试文件生成将其添加到git并推送到当前分支 - | if [ -n $(git status --porcelain tests/) ]; then git config user.email ci-botexample.com git config user.name CI Bot git add tests/ git commit -m ci: auto-generate test cases for MR git push origin HEAD:$CI_COMMIT_REF_NAME fi only: - merge_requests这个方案能让测试用例的生成成为代码审查流程的一部分促进“测试左移”。4.2 方案二与Jenkins集成如果你们使用Jenkins作为CI服务器可以将其作为一个独立的构建后步骤。核心流程构建后触发在主代码编译构建成功之后触发一个专门的“生成测试用例”流水线阶段。准备环境该阶段在一个装有模型服务的Jenkins Agent上运行。扫描代码库使用脚本扫描本次构建版本中新增或修改的源代码。批量生成对扫描到的所有目标代码批量调用模型服务生成测试用例。产出物归档将生成的测试用例文件打包成产出物或者直接覆盖/合并到项目源码的测试目录中。也可以生成一份测试用例报告。Jenkins Pipeline脚本片段示例pipeline { agent { label model-runner // 指定一个有模型运行环境的节点 } stages { stage(Build) { steps { // ... 原有的编译构建步骤 } } stage(Generate Test Cases) { steps { script { // 1. 检出代码 checkout scm // 2. 运行自定义脚本扫描并生成测试用例 // 假设我们有一个Python脚本 generator.py sh ‘python scripts/test_case_generator.py --source-dir ./src --output-dir ./auto_generated_tests’ // 3. (可选) 运行一次生成的测试确保它们至少能通过语法检查 sh ‘python -m pytest ./auto_generated_tests --collect-only 21 | head -20’ } } post { success { // 4. 将生成的测试用例目录归档 archiveArtifacts artifacts: ‘auto_generated_tests/**’, fingerprint: true // 5. 或者也可以选择性地将其提交到另一个分支或作为文档保存 } } } stage(Run Automated Tests) { steps { // 运行原有的以及新生成的测试用例 sh ‘python -m pytest tests/ auto_generated_tests/ -v’ } } } }这个方案更侧重于在构建后自动补充测试资产可以作为现有测试套件的一个有力补充。5. 实践经验与避坑指南在实际折腾的过程中我也踩过一些坑总结了几点经验希望能帮你少走弯路。第一提示词Prompt是关键。模型的表现很大程度上取决于你怎么“问”它。对于测试用例生成一个结构清晰的提示词模板非常有用。比如明确告诉它“请生成测试用例必须包含1. 正常功能测试 2. 边界值测试 3. 异常输入测试。输出格式为pytest函数。” 你给的指令越明确它生成的结果就越符合预期。第二生成的用例需要审查。千万不要认为AI生成的用例就是完美的直接放进生产环境。它可能会误解需求或者生成一些看似合理但实际无效的用例。一定要把它当成一个“初级测试工程师”的产出需要资深测试人员或开发人员进行审查、修正和补充。这个过程本身也能提升效率因为审查比从零创作要快得多。第三从简单、明确的场景开始。不要一开始就试图让它为整个复杂的微服务系统生成用例。先从独立的工具函数、工具类、或者API参数校验这种逻辑相对清晰的模块开始。等模型在你特定代码风格和业务语境下表现稳定后再逐步扩大范围。第四管理好测试代码的“熵增”。自动生成可能会产生大量测试用例其中难免会有重复或冗余。需要定期比如每个迭代对自动生成的测试套件进行梳理和重构合并相似的用例删除无效的用例保持测试代码库的整洁和可维护性。第五关注“冷启动”和上下文长度。Qwen1.5-1.8B的上下文长度有限。如果你需要它基于一份很长的需求文档生成用例可能需要先将文档进行分段或摘要再把关键部分喂给模型。直接扔进去一本“书”效果可能不好。6. 总结回过头来看把Qwen1.5-1.8B GPTQ这样的轻量级模型引入软件测试并不是要用它完全取代测试工程师而是作为一个强大的辅助工具把我们从业界所说的“测试设计”这种高重复性、高耗时的劳动中解放出来。它最擅长的是基于明确的规则和模式快速产生大量基础测试输入尤其是在单元测试和接口测试层面。实际用下来它的确能显著提升测试用例设计的效率特别是在项目初期或者面对大量相似模块时。更重要的是它促使我们更早地思考测试将测试活动进一步左移。当开发人员提交代码时就能立刻看到一份AI建议的测试用例清单这本身就是一种很好的质量提醒。当然它现在还不够“聪明”无法理解深层次的业务逻辑和隐藏的缺陷模式。但这没关系它的定位就是处理那80%的常规工作让我们测试人员能更专注于那20%需要复杂业务判断、探索性测试和系统级质量风险分析的核心任务上。如果你所在的团队也在探索测试自动化和效能提升不妨从一个小模块开始试试让AI来帮你生成第一版测试用例。你会发现它可能比你想象中更“能干”。技术的价值最终还是要落到解决实际问题上而在提升软件测试效率这条路上AI已经是一个看得见、摸得着的帮手了。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。