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

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

作为一名在软件测试领域摸爬滚打多年的工程师，我深知这个岗位的“痛”与“乐”。痛的是，面对海量的需求文档，手动编写测试用例耗时耗力，还容易遗漏边界场景；乐的是，每一次精准地发现Bug，都像解开一道谜题。但更多时候，我们被淹没在重复性的劳动和复杂的日志分析中。

最近，我开始尝试将大模型引入我们的测试流程，特别是像通义千问1.5-1.8B-Chat-GPTQ-Int4这样经过量化、对资源要求友好的模型。它就像一个不知疲倦、知识渊博的测试助手，帮我分担了不少“体力活”和“脑力活”。今天，我就结合自己的实践，聊聊如何用它来搞定自动化测试用例生成和智能Bug分析，希望能给同行们带来一些新思路。

1. 为什么选择通义千问1.5-1.8B-Chat-GPTQ-Int4？

在考虑引入AI辅助测试时，我们团队评估过不少方案。最终选择这个版本的模型，主要是看中了它的几个特点，这些特点正好契合了软件测试工程化的实际需求。

首先，它足够“轻量”且高效。名字里的“GPTQ-Int4”是关键。这是一种模型量化技术，简单理解，就是把原本需要高精度计算（比如FP16）的模型，“压缩”成使用更低精度整数（INT4）进行计算。带来的直接好处就是，模型体积大幅减小，运行所需的内存和算力也显著降低。这意味着我们不需要购置昂贵的专业显卡，在普通的开发机甚至一些配置不错的云服务器上就能部署运行，大大降低了引入门槛和成本。

其次，它保留了不错的对话与理解能力。“1.5-1.8B”指的是模型的参数规模，在这个量级上，它已经具备了良好的语言理解和生成能力。对于软件测试场景——无论是理解需求文档的自然语言描述，还是分析结构化的日志错误信息——它都能处理得相当不错。虽然比不上千亿参数模型的“博学”，但在我们设定的任务上，它的表现足够精准和稳定。

最后，它的“Chat”优化很实用。这个版本针对对话交互进行了优化，这意味着我们可以用更接近自然语言的方式与它沟通，发出指令、进行多轮追问，让它扮演不同的角色（比如测试专家、日志分析员），这在实际应用中非常灵活。

说白了，我们需要的不是一个在通用知识上考高分的“学霸”，而是一个在测试领域“招之即来，来之能战”，并且不挑办公环境的“特种兵”。这个模型正好符合我们的要求。

2. 实战一：从需求文档到测试用例，让AI当你的“用例编写员”

手动编写测试用例是测试工程师的基础工作，但也最容易陷入重复和思维定式。我们尝试用大模型来辅助生成初稿，工程师再进行审核和补充，效率提升非常明显。

2.1 如何给AI下指令？—— 提示词是关键

要让AI写出合格的测试用例，你不能简单地说“给我生成登录功能的测试用例”。这太模糊了。你需要像带一个新人一样，清晰地告诉它背景、规则和期望的格式。

下面是一个我们常用的提示词模板，你可以根据自己的需求调整：

# 这是一个提示词示例，并非可执行代码，用于说明如何构造请求给模型 prompt_template = """ 你是一个经验丰富的软件测试工程师。请根据以下需求描述，帮我生成详细的功能测试用例。 【需求描述】 {requirement_description} 【测试用例生成要求】 1. 覆盖功能的核心正向流程。 2. 考虑常见的异常场景和边界条件（如：无效输入、空值、超长字符、权限异常等）。 3. 测试用例格式请按照：用例ID、测试标题、前置条件、测试步骤、预期结果、优先级（高/中/低）来组织。 4. 优先级根据功能核心程度和失效影响范围来判定。 请开始生成测试用例。 """

2.2 一个实际案例：用户登录功能

假设我们有这样一个简单的需求描述：“用户登录功能：用户输入注册时的手机号和密码，点击登录按钮。验证成功则跳转至首页，验证失败则提示具体错误信息（如：账号不存在、密码错误）。”

我们把这段描述填入上面的模板，发送给部署好的通义千问模型。它会返回类似下面的内容（经过整理）：

用例ID:TC-LOGIN-01测试标题:使用正确的手机号和密码成功登录前置条件:1. 用户已注册；2. 用户处于未登录状态；3. 登录页面可正常访问。测试步骤:1. 在手机号输入框输入已注册的手机号。 2. 在密码输入框输入对应的正确密码。 3. 点击“登录”按钮。预期结果:1. 页面跳转至系统首页。 2. 页面顶部显示用户昵称或登录状态。优先级:高

用例ID:TC-LOGIN-02测试标题:使用未注册的手机号尝试登录前置条件:1. 准备一个未在系统中注册的手机号。 2. 用户处于未登录状态。测试步骤:1. 输入未注册的手机号。 2. 输入任意密码。 3. 点击“登录”按钮。预期结果:页面提示“账号不存在”或“用户未注册”。优先级:高

用例ID:TC-LOGIN-03测试标题:使用已注册手机号但错误密码登录前置条件:1. 用户已注册；2. 知道该用户的正确手机号和一个错误的密码。测试步骤:1. 输入已注册的手机号。 2. 输入错误的密码。 3. 点击“登录”按钮。预期结果:页面提示“密码错误”。优先级:高

用例ID:TC-LOGIN-04测试标题:登录时手机号输入框为空前置条件:用户处于登录页面。测试步骤:1. 保持手机号输入框为空。 2. 输入任意密码。 3. 点击“登录”按钮。预期结果:手机号输入框下方出现提示“手机号不能为空”，且登录请求未被发送。优先级:中

用例ID:TC-LOGIN-05测试标题:登录时密码输入框为空前置条件:用户处于登录页面。测试步骤:1. 输入已注册的手机号。 2. 保持密码输入框为空。 3. 点击“登录”按钮。预期结果:密码输入框下方出现提示“密码不能为空”，且登录请求未被发送。优先级:中

你看，AI在几秒钟内就生成了5个结构清晰、覆盖了正向、反向、边界场景的测试用例。测试工程师拿到这份初稿后，可以快速审核，补充一些它可能没想到的场景，比如“密码是否密文显示”、“连续多次错误密码登录是否触发账户锁定”、“网络异常时的处理”等。这比从零开始写要快得多，也能有效避免个人思维盲区。

3. 实战二：化身“福尔摩斯”，智能分析测试失败日志

测试执行失败后，面对动辄几百行的错误日志和堆栈信息，定位根因是个技术活，更是个耐心活。我们可以让大模型充当第一轮的分析员，从杂乱的信息中提取关键线索。

3.1 构建日志分析提示词

分析日志的提示词需要引导模型关注错误类型、关键信息、可能原因和排查建议。

# 日志分析提示词示例 log_analysis_prompt = """ 你是一个资深的故障排查专家。请分析以下测试失败时产生的错误日志，帮我推测根本原因并提供下一步的排查建议。 【错误日志】 {error_log_content} 【请按以下结构回答】 1. **错误摘要**：用一句话概括发生了什么错误。 2. **关键线索**：列出日志中最能指示问题的2-3行关键信息（如错误码、异常类型、文件名和行号）。 3. **可能原因分析**：结合常见开发问题，推测可能导致此错误的2-3个主要原因（例如：空指针引用、数据库连接失败、参数校验不通过、依赖服务异常等）。 4. **排查建议**：给出具体的、可操作的排查步骤建议（例如：检查X函数的入参是否为空、确认Y服务的网络连通性、查看Z配置项的值等）。 """

3.2 模拟日志分析实战

假设我们在进行一个API接口测试时失败了，收到如下日志（简化版）：

2024-05-27 10:00:15,123 ERROR [http-nio-8080-exec-5] c.e.c.TestController: processRequest() - 处理用户查询请求失败。 java.lang.NullPointerException: null at com.example.service.UserService.getUserDetail(UserService.java:45) at com.example.controller.TestController.processRequest(TestController.java:78) ... Caused by: org.springframework.dao.EmptyResultDataAccessException: Incorrect result size: expected 1, actual 0 at org.springframework.dao.support.DataAccessUtils.requiredSingleResult(DataAccessUtils.java:71) at com.example.repository.UserRepository.findByPhoneNumber(UserRepository.java:102) at com.example.service.UserService.getUserDetail(UserService.java:43) ... 32 more

将这段日志扔给模型，它会给出类似下面的分析：

1. 错误摘要：在查询用户详情时，由于数据库查询未找到对应记录，导致服务层出现空指针异常。
2. 关键线索：
   • java.lang.NullPointerException: null at ...UserService.java:45
   • Caused by: org.springframework.dao.EmptyResultDataAccessException: Incorrect result size: expected 1, actual 0 at ...UserRepository.java:102
3. 可能原因分析：
   • 根本原因：UserRepository.findByPhoneNumber方法根据传入的手机号查询数据库，期望返回一条记录，但实际返回了0条（actual 0）。这导致后续尝试操作返回结果时，引发了EmptyResultDataAccessException，并最终在UserService.java:45行因为使用了空对象而抛出NullPointerException。
   • 直接诱因：测试请求中传入的手机号，在数据库中不存在对应的用户记录。
4. 排查建议：
   • 第一步：确认测试用例中使用的手机号 (phoneNumber) 是否确实存在于数据库的user表中。可以直接在数据库执行查询验证。
   • 第二步：检查UserService.getUserDetail方法第45行代码，看是否在对数据库查询结果进行操作前，缺少了判空处理。建议增加if (user == null) { ... }的逻辑。
   • 第三步：审查UserRepository.findByPhoneNumber方法的实现或JPA声明，确保其查询逻辑正确。

这个分析直接抓住了从EmptyResultDataAccessException到NullPointerException的因果链，并给出了从数据到代码的清晰排查路径。测试工程师可以立刻着手验证手机号数据，并同步将代码缺陷（缺少判空）反馈给开发。这比人工从堆栈信息里层层梳理要快得多。

4. 实战三：一键生成结构清晰的Bug报告

发现Bug只是第一步，清晰、准确地描述Bug才能让开发同学高效修复。我们可以让模型根据测试上下文和失败信息，自动生成Bug报告的草稿。

4.1 设计Bug报告生成器

我们需要给模型提供更丰富的上下文，包括环境、步骤、实际结果和期望结果。

# Bug报告生成提示词示例 bug_report_prompt = """ 请根据以下测试失败信息，生成一份规范的Bug报告草稿。 【测试环境】 - 应用版本：v2.1.0 - 测试环境：Staging - 浏览器/设备：Chrome 115 【复现步骤】 1. 打开用户登录页面。 2. 输入手机号：13800138000。 3. 输入密码：test123。 4. 点击“登录”按钮。 【实际结果】 页面弹出提示“系统内部错误，请联系管理员”，同时浏览器控制台显示HTTP 500错误。后端日志见上方分析（指日志分析环节的输出）。 【期望结果】 应提示“密码错误”或跳转至首页（如果密码正确）。 【其他信息】 关联的需求/用户故事ID：US-1234（用户登录功能）。 请生成包含以下字段的Bug报告： - **标题**：简明扼要。 - **严重等级**：Blocking/Critical/Major/Minor。 - **优先级**：P0/P1/P2/P3。 - **模块**：所属功能模块。 - **描述**：综合以上信息进行描述。 - **根因推测（可选）**：基于日志分析给出初步判断。 """

4.2 看看AI生成的Bug报告

结合之前日志分析的结果，模型可能会生成这样一份报告：

• 标题：【登录功能】使用特定手机号登录时系统报“内部错误”而非明确提示
• 严重等级：Major
• 优先级：P1
• 模块：用户认证模块
• 描述： 在Staging环境的v2.1.0版本中，使用手机号13800138000（该号码在数据库中不存在）进行登录操作时，前端页面错误地提示“系统内部错误，请联系管理员”，而非预期的“账号不存在”提示。此问题导致用户体验差，且掩盖了真实的业务逻辑问题。
  • 环境：Staging, Chrome 115
  • 步骤：1.访问登录页；2.输入上述手机号；3.输入任意密码；4.点击登录。
  • 预期：应提示“账号不存在”。
  • 实际：提示“系统内部错误”，HTTP 500。
• 根因推测： 根据后端日志分析，根本原因是UserRepository.findByPhoneNumber方法查询数据库时，因记录不存在而抛出EmptyResultDataAccessException。该异常在UserService层未被妥善处理，导致后续出现空指针异常，最终被全局异常处理器捕获并返回了笼统的500错误。建议：1. 在Service层对查询结果进行判空处理，并转换为友好的业务异常。2. 前端应能解析并展示业务异常信息。

这份报告结构完整，将现象、分析、建议串联了起来，特别是“根因推测”部分，直接引用了之前日志分析的结论，让开发和测试之间的沟通成本大大降低。

5. 总结与建议

把通义千问1.5-1.8B-Chat-GPTQ-Int4这类模型引入软件测试流程，给我的感觉就像是给团队配备了一位7x24小时在线的初级测试专家。它特别擅长处理那些有明确模式、但工作量巨大的任务，比如根据模板生成内容、从文本中提取和总结信息。

从这段时间的实践来看，效果最明显的确实是测试用例的初稿生成和失败日志的初步分析。它生成的用例能覆盖大部分常规场景，为我们节省了宝贵的“敲键盘”时间，让我们能把更多精力放在设计更复杂的异常场景、探索性测试以及结果审核上。日志分析功能则像是一个永不疲倦的“第一响应员”，总能快速从噪音中抓住关键错误链，给出一个相当靠谱的排查方向。

当然，它也不是万能的。生成的测试用例有时会遗漏一些非常隐蔽的、需要深厚业务逻辑才能理解的边界情况。它的分析基于已有的日志文本，如果日志本身打印得模糊不清，它的判断也可能出现偏差。所以，“AI辅助”而非“AI替代”是我们坚持的定位。工程师的经验、批判性思维和对业务的理解，依然是不可替代的核心价值。

如果你也想在团队中尝试，我的建议是：从一个具体的、重复性高的痛点场景开始（比如某个复杂模块的用例生成），准备好高质量的提示词（这是发挥模型能力的关键），先在小范围内试用，让测试工程师去验证和修正AI的输出。当大家看到了实效，再逐步推广到更多场景。这个过程本身，也是对测试流程进行标准化和精细化梳理的好机会。

获取更多AI镜像

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