通义千问1.5-1.8B-Chat-GPTQ-Int4 WebUI 软件测试用例生成实战：基于需求描述的自动化测试

你是不是也经历过这样的场景？产品经理甩过来一份几十页的需求文档，或者开发同学口头描述了一个新功能，然后对你说：“帮忙设计一下测试用例吧，明天评审。” 看着密密麻麻的文字，或者听着抽象的功能描述，要从零开始构思测试场景、步骤、预期结果，是不是感觉头都大了？

传统的测试用例设计，严重依赖测试工程师的个人经验和业务理解。这个过程不仅耗时耗力，而且容易遗漏边缘场景，尤其是在需求频繁变更的敏捷开发模式下，测试设计常常成为效率瓶颈。

今天，我们就来聊聊一个能让你从这种重复性脑力劳动中解放出来的方法：利用通义千问大模型，把自然语言描述的需求，自动变成结构化的测试用例。我们不仅会介绍怎么用，还会结合一个完整的Python脚本，实现从需求输入到测试用例文件（XMind或Excel）导出的全流程自动化。简单来说，就是让AI帮你写测试用例初稿，你来做最后的审核和优化，效率提升可不是一点半点。

1. 为什么需要AI辅助生成测试用例？

在深入技术细节之前，我们先看看测试用例设计这个活儿，到底难在哪，以及AI能帮上什么忙。

测试用例设计的核心，是把抽象的需求（用户故事、功能点描述）转化为具体、可执行、无歧义的测试步骤和验证点。这要求测试人员：

1. 深度理解需求：吃透产品到底要做什么。
2. 发散性思维：思考正常流程、异常流程、边界条件、兼容性等各个维度。
3. 结构化输出：将思维结果按照固定格式（如测试步骤、预期结果、测试数据）整理出来。

其中，第2点和第3点包含了大量模式化、可归纳的工作。而这正是大语言模型所擅长的。通义千问这类模型经过海量代码和文本训练，对“如果...那么...”的逻辑关系、步骤分解、边界条件枚举有着不错的理解能力。

举个例子，当你对模型说：“测试一个用户登录功能，需要用户名和密码。” 一个训练有素的模型应该能联想到：

• 正常场景：输入正确的用户名和密码，登录成功。
• 异常场景：用户名错误、密码错误、用户名为空、密码为空、密码包含特殊字符、连续多次失败是否锁定账户等等。
• 边界场景：用户名长度超长、密码长度超长等。

AI的作用不是替代测试工程师，而是成为一个强大的“初级助手”，快速生成覆盖全面的测试用例草稿。工程师则可以在此基础上，结合对业务上下文、系统架构的深度理解，进行补充、修正和优化，把精力集中在更有创造性和挑战性的测试设计上。

2. 环境准备与模型部署

工欲善其事，必先利其器。我们先来快速搭建一个可以本地运行的通义千问对话环境。

2.1 选择模型版本

我们选择 Qwen1.5-1.8B-Chat-GPTQ-Int4 这个版本，原因很实际：

• 1.8B参数：模型体积小，对硬件要求极低，普通消费级显卡（甚至一些高性能集成显卡）就能流畅运行，非常适合本地部署和快速实验。
• Chat：代表该模型经过对话微调，擅长理解和遵循人类指令，这对于我们要求它按特定格式输出测试用例至关重要。
• GPTQ-Int4：这是一种模型量化技术。简单理解，就是把模型“压缩”了，在几乎不损失精度的情况下，大幅减少模型占用的内存和提升推理速度。Int4表示用4位整数存储权重，比原始的32位浮点数模型小了近8倍。

对于测试用例生成这种对绝对精度要求不是极端严苛的场景，这个版本的性价比非常高。

2.2 通过WebUI快速部署

最省心的方式就是使用封装好的WebUI镜像。这里假设你已经有一个可以运行Docker或类似容器环境的基础。

部署过程通常就是一行命令的事情，或者直接在提供了该镜像的平台点击“一键部署”。部署成功后，你会得到一个可以通过浏览器访问的本地网址（比如 http://localhost:7860）。

打开这个页面，你会看到一个类似聊天机器人的界面。这个WebUI已经集成了模型加载、对话管理、参数调整等功能，我们无需关心背后的复杂代码，直接使用即可。

3. 实战：从需求描述到测试用例

环境搭好了，我们来真刀真枪地干一次。整个流程可以概括为：编写提示词 -> 与模型对话 -> 解析模型回复 -> 导出为文件。

3.1 编写有效的提示词（Prompt）

这是最关键的一步。AI就像一个新来的实习生，你需要清晰地告诉它你要什么。一个结构化的提示词能极大提升输出质量。

我们的提示词可以这样设计：

你是一个资深的软件测试工程师。请根据以下功能需求描述，帮我设计详细的功能测试用例。

请严格按照以下格式输出每一个测试用例：
【用例ID】: [一个简短的唯一标识，如 LOGIN-001]
【测试标题】: [一句话概括测试点]
【前置条件】: [执行测试前需要满足的状态]
【测试步骤】: 
1. [步骤一描述]
2. [步骤二描述]
...
【预期结果】:
1. [结果一描述]
2. [结果二描述]
...
【测试数据】: [可选，如果需要的话]

需求描述如下：
[这里粘贴你的需求描述]

请从正常场景、异常场景、边界场景等多个维度进行考虑，确保用例覆盖全面。

提示词要点解析：

• 角色设定：让模型进入“测试工程师”的角色，用它的知识库来思考。
• 格式强制：明确要求输出结构，方便我们后续用程序自动解析。
• 维度引导：提醒模型从多角度思考，避免只输出显而易见的正常流程。

3.2 在WebUI中进行交互

将上面编写好的提示词（把[这里粘贴你的需求描述]替换成真实需求），粘贴到WebUI的聊天输入框中。

例如，我们输入的需求是：“测试一个博客系统的文章发布功能。作者可以输入标题、正文内容，选择分类，然后点击发布按钮将文章保存并展示在博客首页。”

点击发送，稍等片刻，模型就会生成回复。你可能会得到类似下面的输出：

【用例ID】: ARTICLE-001
【测试标题】: 验证文章发布功能正常流程
【前置条件】: 1. 用户已成功登录系统。2. 存在至少一个文章分类。
【测试步骤】: 
1. 进入文章编辑页面。
2. 在标题输入框中输入“测试文章标题”。
3. 在正文编辑器中输入“这是一篇测试文章的内容。”
4. 从分类下拉框中选择一个已有分类（如“技术杂谈”）。
5. 点击“发布”按钮。
【预期结果】:
1. 页面提示“文章发布成功”。
2. 自动跳转到新发布文章的详情页，显示内容与输入一致。
3. 在博客首页的最新文章列表中，能看到刚发布的文章，标题和摘要显示正确。
【测试数据】: 标题=“测试文章标题”， 正文=“这是一篇测试文章的内容。”， 分类=“技术杂谈”

【用例ID】: ARTICLE-002
【测试标题】: 验证文章标题为空时发布失败
【前置条件】: 用户已成功登录系统。
【测试步骤】: 
1. 进入文章编辑页面。
2. 保持标题输入框为空。
3. 在正文编辑器中输入任意内容。
4. 选择一个文章分类。
5. 点击“发布”按钮。
【预期结果】:
1. 页面提示“标题不能为空”。
2. 文章未保存，页面停留在编辑状态。
【测试数据】: 标题=“”（空）， 正文=“测试内容”， 分类=“技术杂谈”
... (后续还会有标题超长、正文为空、未选分类等用例)

看，模型已经生成了结构清晰、考虑了几个不同场景的测试用例草稿。这个质量作为初稿已经相当可用。

3.3 进阶技巧：让输出更符合你的习惯

如果你对用例格式有特殊要求，比如公司有固定的模板，或者你想让模型输出XMind可以直接导入的Markdown格式，你可以在提示词里定义得更详细。

例如，要求输出为Markdown列表格式，方便后续处理：

请以Markdown无序列表格式输出测试用例，每个用例包含：**用例ID**、**标题**、**步骤**（编号列表）、**预期结果**（编号列表）。

模型就会输出：

- **用例ID**: ARTICLE-001
  **标题**: 验证文章发布功能正常流程
  **步骤**:
    1. 进入文章编辑页面。
    2. 输入标题“测试标题”。
    3. 输入正文“测试内容”。
    4. 选择分类“技术”。
    5. 点击发布。
  **预期结果**:
    1. 提示发布成功。
    2. 跳转到文章详情页。
    3. 首页显示该文章。

这种格式非常容易被脚本解析。

4. 自动化脚本：批量生成与导出

手动复制粘贴WebUI的回复效率还是太低。我们可以用Python写个脚本，自动完成“发送需求->获取回复->解析->保存”的全过程。这里我们使用 requests 库与WebUI的后端API进行交互（大多数WebUI都提供类似接口）。

4.1 调用模型API生成用例

首先，找到你的WebUI提供的API地址（通常是 http://localhost:7860/api/chat 或类似），并查看其需要的请求格式。

import requests
import json
import re

def generate_test_cases(requirement_description, api_url="http://localhost:7860/api/chat"):
    """
    调用通义千问WebUI API，根据需求描述生成测试用例文本。
    """
    prompt = f"""你是一个资深的软件测试工程师。请根据以下功能需求描述，帮我设计详细的功能测试用例。
请严格按照以下格式输出每一个测试用例：
【用例ID】: [如 LOGIN-001]
【测试标题】: [一句话概括]
【前置条件】: [执行前状态]
【测试步骤】: 
1. [步骤一]
2. [步骤二]
...
【预期结果】:
1. [结果一]
2. [结果二]
...
【测试数据】: [可选]

需求描述如下：
{requirement_description}
请从正常场景、异常场景、边界场景等多个维度进行考虑。"""
    
    # 根据你的WebUI API实际格式构造请求数据，这里是一个示例
    payload = {
        "message": prompt,
        "history": [], # 无历史对话
        "max_length": 2048, # 生成文本的最大长度
        "temperature": 0.3, # 温度参数，越低输出越确定，越高越有创造性
    }
    
    headers = {'Content-Type': 'application/json'}
    
    try:
        response = requests.post(api_url, data=json.dumps(payload), headers=headers, timeout=120)
        response.raise_for_status()
        result = response.json()
        # 假设API返回的文本在 result['response'] 中
        generated_text = result.get('response', '')
        return generated_text
    except requests.exceptions.RequestException as e:
        print(f"API请求失败: {e}")
        return None

# 使用示例
req_desc = "测试一个博客系统的文章发布功能。作者可以输入标题、正文内容，选择分类，然后点击发布按钮将文章保存并展示在博客首页。"
raw_cases_text = generate_test_cases(req_desc)
if raw_cases_text:
    print("模型生成的原始文本：")
    print(raw_cases_text)

4.2 解析文本并导出为Excel

拿到模型返回的格式化文本后，我们需要解析它，提取出每个字段，然后保存到Excel中。这里我们用 pandas 库。

import pandas as pd
from io import StringIO

def parse_cases_to_dataframe(cases_text):
    """
    将模型生成的、符合格式的文本解析成Pandas DataFrame。
    这里使用简单的正则匹配，格式越严格，解析越容易。
    """
    # 按【用例ID】分割成单个用例块
    case_blocks = re.split(r'【用例ID】:', cases_text)[1:] # 第一个元素是空或前缀，去掉
    
    cases_list = []
    
    for block in case_blocks:
        case_dict = {}
        # 提取用例ID (格式如 `: ARTICLE-001`，我们取冒号后的部分)
        id_match = re.match(r'\s*:\s*(\S+)', block)
        if id_match:
            case_dict['用例ID'] = id_match.group(1).strip()
        
        # 提取测试标题
        title_match = re.search(r'【测试标题】:\s*(.*?)(?=\n【|$)', block, re.DOTALL)
        if title_match:
            case_dict['测试标题'] = title_match.group(1).strip()
        
        # 提取前置条件
        precondition_match = re.search(r'【前置条件】:\s*(.*?)(?=\n【|$)', block, re.DOTALL)
        if precondition_match:
            case_dict['前置条件'] = precondition_match.group(1).strip()
        
        # 提取测试步骤 (合并多行)
        steps_match = re.search(r'【测试步骤】:\s*(.*?)(?=\n【预期结果】|$)', block, re.DOTALL)
        if steps_match:
            steps_text = steps_match.group(1).strip()
            # 清理步骤编号，合并为字符串
            steps_clean = re.sub(r'^\d+\.\s*', '', steps_text, flags=re.MULTILINE) # 去掉行首的`1. `
            case_dict['测试步骤'] = steps_clean
        
        # 提取预期结果
        expected_match = re.search(r'【预期结果】:\s*(.*?)(?=\n【测试数据】|\n【用例ID】|$)', block, re.DOTALL)
        if expected_match:
            expected_text = expected_match.group(1).strip()
            expected_clean = re.sub(r'^\d+\.\s*', '', expected_text, flags=re.MULTILINE)
            case_dict['预期结果'] = expected_clean
        
        # 提取测试数据
        data_match = re.search(r'【测试数据】:\s*(.*?)(?=\n【用例ID】|$)', block, re.DOTALL)
        if data_match:
            case_dict['测试数据'] = data_match.group(1).strip()
        else:
            case_dict['测试数据'] = ''
        
        if case_dict: # 避免空字典
            cases_list.append(case_dict)
    
    # 转换为DataFrame
    df = pd.DataFrame(cases_list)
    return df

def export_to_excel(df, filename="generated_test_cases.xlsx"):
    """将DataFrame导出到Excel文件"""
    if df.empty:
        print("没有数据可导出。")
        return
    try:
        # 使用openpyxl引擎，可以更好地保持格式
        with pd.ExcelWriter(filename, engine='openpyxl') as writer:
            df.to_excel(writer, index=False, sheet_name='测试用例')
        print(f"测试用例已成功导出到 {filename}")
    except Exception as e:
        print(f"导出Excel失败: {e}")

# 整合流程
if raw_cases_text:
    df_cases = parse_cases_to_dataframe(raw_cases_text)
    if not df_cases.empty:
        print("\n解析后的测试用例表格预览：")
        print(df_cases.head())
        export_to_excel(df_cases, "博客文章发布功能测试用例.xlsx")

4.3 扩展：导出为XMind思维导图

测试用例用思维导图来评审和展示更直观。我们可以利用 xmind 库（需安装 xmind）来生成。

# 可选：安装 xmind 库: pip install xmind
import xmind

def export_to_xmind(df, filename="test_cases.xmind"):
    """将DataFrame中的测试用例导出为XMind文件"""
    if df.empty:
        return
    
    # 创建新的思维导图
    workbook = xmind.load(filename) if os.path.exists(filename) else xmind.XMindWorkbook()
    sheet = workbook.getPrimarySheet()
    root_topic = sheet.getRootTopic()
    root_topic.setTitle("软件测试用例集")
    
    # 假设我们按“测试标题”作为主要分支
    for _, row in df.iterrows():
        case_topic = root_topic.addSubTopic()
        case_topic.setTitle(f"{row.get('用例ID', 'N/A')}: {row.get('测试标题', '')}")
        
        # 添加详细信息作为子主题
        if pd.notna(row.get('前置条件')):
            cond_sub = case_topic.addSubTopic()
            cond_sub.setTitle(f"前置条件: {row['前置条件']}")
        
        if pd.notna(row.get('测试步骤')):
            steps_sub = case_topic.addSubTopic()
            # 简单处理，将步骤字符串按换行分割成多个子节点
            steps = row['测试步骤'].split('\n')
            steps_sub.setTitle("测试步骤")
            for step in steps:
                if step.strip():
                    steps_sub.addSubTopic().setTitle(step.strip())
        
        if pd.notna(row.get('预期结果')):
            exp_sub = case_topic.addSubTopic()
            exp_sub.setTitle("预期结果")
            results = row['预期结果'].split('\n')
            for res in results:
                if res.strip():
                    exp_sub.addSubTopic().setTitle(res.strip())
    
    # 保存文件
    xmind.save(workbook, filename)
    print(f"测试用例已成功导出为XMind文件: {filename}")

# 使用示例
# export_to_xmind(df_cases, "博客文章发布测试.xmind")

5. 实践经验与优化建议

在实际项目中用了几次之后，我总结了一些心得，能让这个流程变得更顺滑。

第一，需求描述的质量决定生成用例的上限。 给模型模糊的需求，只能得到模糊的用例。在输入前，尽量自己先把需求梳理清楚，用简洁、无歧义的语言描述。如果能附带一些业务规则（比如“密码必须8位以上，包含字母和数字”），模型生成的边界用例会更精准。

第二，分而治之。 不要试图把一个庞大的系统需求一次性扔给模型。效果不会好。应该按功能模块拆分，比如“用户登录模块”、“订单支付模块”、“文章管理模块”，逐个生成。这样模型更容易聚焦，生成的用例也更深入。

第三，把AI当成草稿生成器。 生成出来的用例一定要经过人工评审。检查逻辑是否正确，是否遗漏了重要的业务场景，预期结果是否符合实际系统行为。AI可能会“捏造”一些不存在的功能或规则，这就需要测试工程师用专业知识去把关。

第四，建立你自己的提示词库。 针对不同类型的测试（功能测试、API接口测试、性能测试场景设计），可以准备不同的提示词模板。比如API测试的提示词，可以要求模型输出“请求方法”、“URL”、“请求头”、“请求体”、“预期状态码”、“预期响应体”等字段。

第五，关注模型的“幻觉”。 这是大模型普遍存在的问题，即生成看似合理但实际错误或无关的内容。在测试用例生成中，可能表现为添加了需求中未提及的步骤或结果。人工复审是必不可少的步骤。

6. 总结

回过头来看，用通义千问来辅助生成测试用例，本质上是一次测试设计工作的“人机协同”。机器负责快速、批量地完成那些模式化、可推导的部分，提供广泛的覆盖面和多样的思考角度；人则负责注入业务灵魂、进行深度逻辑判断和最终的质量把关。

这套方法在需求澄清、迭代初期、或者面对大量重复性功能测试时尤其有用。它能显著缩短测试设计周期，让测试工程师更早地介入，也能帮助新人快速理解测试设计的思路。

当然，它目前还不是全自动的银弹，但对效率的提升是实实在在的。你不妨从下一个小的功能模块开始尝试，先让AI生成一版草稿，你再在上面修改。对比一下纯手动设计和这种“AI初稿+人工精修”模式所花费的时间和质量，相信你会有自己的判断。技术最终是为了服务人，解放创造力，而不是取代人。在软件测试这个领域，AI正成为一个越来越得力的助手。

---

获取更多AI镜像

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