DeepSeek-R1-Distill-Qwen-1.5B效果展示：将产品需求文档（PRD）自动转为测试用例

DeepSeek-R1-Distill-Qwen-1.5B效果展示：将产品需求文档（PRD）自动转为测试用例

1. 引言：当AI遇到测试工程师的日常

如果你是测试工程师，下面这个场景你一定不陌生：

周一早上，产品经理发来一份30页的产品需求文档（PRD），告诉你：“这周要上线，测试用例尽快写出来。”你看着密密麻麻的功能描述、交互逻辑、边界条件，心里默默算了一下：完整梳理至少要2天，写测试用例又要1天，这还不包括评审和修改的时间。

现在，想象一下这样的场景：你把这份PRD扔给一个AI助手，几分钟后，它给你生成了一份结构清晰、覆盖全面的测试用例文档。你可以直接在这个基础上修改、补充，把3天的工作压缩到半天完成。

这不是科幻，而是DeepSeek-R1-Distill-Qwen-1.5B模型带来的真实能力。今天，我就带你看看这个超轻量模型如何在测试领域大显身手，把枯燥的文档转换变成高效的自动化流程。

2. 为什么选择这个模型来做测试用例生成？

2.1 模型的核心优势：推理能力+轻量化

DeepSeek-R1-Distill-Qwen-1.5B这个模型名字有点长，但拆开看就明白了：

• DeepSeek的血统：继承了DeepSeek系列强大的逻辑推理能力
• Qwen的架构：基于通义千问成熟的模型结构
• 蒸馏优化：通过知识蒸馏技术，把大模型的能力“压缩”到小模型里
• 1.5B参数：只有15亿参数，对硬件要求极低

简单说，它就像是一个“浓缩版”的推理专家——保留了分析问题、逻辑推导的核心能力，但体积小到可以在普通电脑上流畅运行。

2.2 测试用例生成的独特挑战

生成测试用例不是简单的文本改写，它需要：

1. 理解业务逻辑：能看懂PRD中的功能描述
2. 识别测试点：从需求中提取出需要验证的关键环节
3. 结构化输出：按照测试用例的标准格式组织内容
4. 考虑边界条件：想到正常流程之外的异常情况

很多大模型在创意写作上表现很好，但在这种需要严谨逻辑的任务上反而容易出错。而DeepSeek-R1-Distill-Qwen-1.5B正好擅长逻辑推理，这让它成为了测试用例生成的理想选择。

3. 效果展示：从PRD到测试用例的完整过程

3.1 案例一：用户登录功能测试用例生成

我找了一份真实的用户登录需求文档，内容大概是这样：

需求描述：用户登录功能 1. 支持手机号+密码登录 2. 支持邮箱+密码登录 3. 密码错误时提示“账号或密码错误” 4. 连续5次密码错误后锁定账号30分钟 5. 登录成功后跳转到首页 6. 记住登录状态（7天内免登录）

我把这段需求扔给模型，让它生成测试用例。下面是它的输出（我做了简单排版，内容完全来自模型）：

生成的测试用例文档：

一、功能测试用例 1. 正常登录场景 - 用例ID: LOGIN_001 - 测试步骤: 输入正确的手机号+密码，点击登录 - 预期结果: 登录成功，跳转到首页 - 用例ID: LOGIN_002 - 测试步骤: 输入正确的邮箱+密码，点击登录 - 预期结果: 登录成功，跳转到首页 2. 异常登录场景 - 用例ID: LOGIN_003 - 测试步骤: 输入正确手机号+错误密码，点击登录 - 预期结果: 提示“账号或密码错误” - 用例ID: LOGIN_004 - 测试步骤: 输入不存在的手机号+任意密码，点击登录 - 预期结果: 提示“账号或密码错误” - 用例ID: LOGIN_005 - 测试步骤: 连续5次输入错误密码 - 预期结果: 第5次提示“账号已锁定，请30分钟后重试” 二、用户体验测试用例 1. 记住登录状态 - 用例ID: LOGIN_006 - 测试步骤: 登录时勾选“记住我”，关闭浏览器后重新打开 - 预期结果: 7天内自动登录，无需重新输入账号密码

我的评价：

模型不仅生成了基础的测试用例，还自动做了分类（功能测试、用户体验测试）。更让我惊讶的是，它从“连续5次密码错误后锁定”这个需求中，识别出了需要测试“第5次”这个关键点——这是很多新手测试工程师都容易忽略的细节。

3.2 案例二：电商购物车功能测试用例生成

第二个例子更复杂一些，是一个电商购物车的需求：

购物车功能需求： 1. 用户可以将商品加入购物车 2. 购物车显示商品图片、名称、价格、数量 3. 可以修改商品数量（1-99件） 4. 可以删除单个商品 5. 可以清空整个购物车 6. 商品库存不足时提示“库存不足” 7. 结算时计算总价（商品单价×数量）

模型这次生成了更详细的测试用例：

一、商品操作测试 1. 添加商品 - 用例ID: CART_001 - 前置条件: 商品有库存 - 测试步骤: 点击“加入购物车”按钮 - 预期结果: 商品成功加入购物车，购物车数量+1 - 用例ID: CART_002 - 前置条件: 商品库存为0 - 测试步骤: 点击“加入购物车”按钮 - 预期结果: 提示“库存不足”，商品未加入购物车 2. 修改数量 - 用例ID: CART_003 - 测试步骤: 将商品数量从1改为5 - 预期结果: 购物车中该商品数量显示为5，总价相应更新 - 用例ID: CART_004 - 测试步骤: 尝试将数量改为0 - 预期结果: 数量保持为1（或提示“数量至少为1”） - 用例ID: CART_005 - 测试步骤: 尝试将数量改为100（超过99） - 预期结果: 数量自动调整为99（或提示“最大数量为99”） 二、购物车管理测试 1. 删除操作 - 用例ID: CART_006 - 测试步骤: 点击商品旁的删除按钮 - 预期结果: 该商品从购物车移除，总价更新 - 用例ID: CART_007 - 前置条件: 购物车中有多个商品 - 测试步骤: 点击“清空购物车”按钮 - 预期结果: 所有商品被移除，购物车显示为空 三、价格计算测试 1. 总价计算 - 用例ID: CART_008 - 前置条件: 购物车中有2件商品，单价分别为100元和200元，数量分别为2件和1件 - 测试步骤: 查看购物车总价 - 预期结果: 总价显示为400元（100×2 + 200×1）

这里有几个亮点：

1. 自动识别边界值：从“1-99件”这个需求中，模型想到了测试0和100这两个边界情况
2. 考虑了前置条件：在测试库存不足时，它知道要先设置“库存为0”这个前提
3. 测试数据具体化：在价格计算测试中，它没有用抽象的描述，而是给出了具体的数字例子（100元、200元），这让测试用例更可执行

3.3 案例三：复杂业务逻辑的测试用例生成

前两个例子还相对简单，第三个我找了一个真正复杂的业务需求——一个在线课程的购买和学习流程：

在线课程购买流程： 1. 用户可以浏览课程列表，查看课程详情（包括课程大纲、讲师介绍、价格） 2. 免费课程可以直接加入“我的课程” 3. 付费课程需要先购买（支持微信支付、支付宝） 4. 购买成功后，课程进入“我的课程” 5. 学习过程中可以记录学习进度 6. 完成所有章节后可以领取结业证书 7. 课程支持7天无理由退款（需未学习超过20%内容）

这个需求的复杂性在于它涉及多个状态转换（未购买→已购买→学习中→已完成）和复杂的业务规则（退款条件）。

模型生成的测试用例展现了它的逻辑推理能力：

一、课程获取测试 1. 免费课程 - 用例ID: COURSE_001 - 测试步骤: 在免费课程详情页点击“开始学习” - 预期结果: 课程直接加入“我的课程”，可立即开始学习 2. 付费课程购买 - 用例ID: COURSE_002 - 测试步骤: 选择微信支付方式，完成支付流程 - 预期结果: 支付成功，课程加入“我的课程” - 用例ID: COURSE_003 - 测试步骤: 支付过程中取消支付 - 预期结果: 返回课程详情页，课程未加入“我的课程” 二、学习流程测试 1. 学习进度记录 - 用例ID: COURSE_004 - 测试步骤: 学习一个章节后退出，重新进入课程 - 预期结果: 自动跳转到上次学习的位置 - 用例ID: COURSE_005 - 前置条件: 课程共10个章节 - 测试步骤: 完成第10个章节的学习 - 预期结果: 显示“课程已完成”，出现“领取证书”按钮 三、退款流程测试 1. 符合退款条件 - 用例ID: COURSE_006 - 前置条件: 购买课程后学习了第1章（共10章，学习进度10%） - 测试步骤: 申请7天无理由退款 - 预期结果: 退款申请成功，课程从“我的课程”移除 - 用例ID: COURSE_007 - 前置条件: 购买课程后学习了第3章（学习进度30%） - 测试步骤: 申请7天无理由退款 - 预期结果: 退款申请被拒绝，提示“已学习超过20%内容，不符合退款条件”

这个案例真正体现了模型的推理能力：

1. 理解了状态机：它清楚课程有“未购买”、“已购买”、“学习中”、“已完成”等状态
2. 处理了复杂规则：对“7天无理由退款（需未学习超过20%内容）”这个规则，它生成了两个测试用例——一个符合条件（10%），一个不符合条件（30%）
3. 考虑了异常流程：不仅测试了支付成功，还测试了支付取消的情况

4. 模型在实际使用中的表现

4.1 响应速度：快到让你忘记在等

我在一台普通的笔记本电脑上测试（没有独立显卡，只有集成显卡），模型的响应速度让我很意外：

• 简单需求（如登录功能）：3-5秒生成完整测试用例
• 中等复杂度需求（如购物车）：8-12秒
• 高复杂度需求（如课程系统）：15-20秒

这个速度意味着什么？你复制一段PRD内容，点击生成，去接杯水回来，测试用例已经写好了。在实际工作中，这个等待时间完全可以接受。

4.2 输出质量：不是完美，但足够好用

我需要客观地说，模型生成的测试用例不是100%完美。经过我的测试，它的表现大概是这样的：

做得好的地方（约占80%）：

• 基础功能覆盖全面
• 边界条件识别准确
• 测试步骤描述清晰
• 预期结果具体明确

需要人工补充的地方（约占20%）：

• 有时候会遗漏一些隐蔽的测试点
• 对极其复杂的业务规则可能需要多次提示
• 生成的测试用例格式可能需要微调以适应团队规范

但重要的是，它完成了最耗时的那部分工作——把模糊的需求变成结构化的测试点。剩下的20%调整工作，相比从0开始写，已经轻松太多了。

4.3 使用技巧：如何让模型输出更好的测试用例

经过多次尝试，我总结了一些让模型表现更好的技巧：

技巧一：给模型明确的指令不要只说“生成测试用例”，可以这样说：

请为以下需求生成测试用例，要求： 1. 按照功能模块分类 2. 每个测试用例包含：用例ID、测试步骤、预期结果 3. 特别关注边界条件和异常场景

技巧二：提供格式示例如果你有团队的测试用例模板，可以先给模型看一个例子：

这是我们团队的测试用例格式示例： - 用例ID: MODULE_001 - 用例名称: [具体名称] - 前置条件: [如果有] - 测试步骤: 1. [步骤1] 2. [步骤2] - 预期结果: [具体结果] 请按照这个格式为以下需求生成测试用例。

技巧三：分多次生成对于特别长的PRD，不要一次性扔给模型。可以：

1. 先让它生成整体的测试大纲
2. 然后针对每个模块单独生成详细用例
3. 最后让它检查是否有遗漏的测试点

5. 技术实现：如何搭建自己的测试用例生成助手

5.1 环境准备：比想象中简单

如果你也想在本地搭建一个这样的工具，需要的环境很简单：

1. Python 3.8以上（现在大家的电脑基本都满足）
2. 至少8GB内存（模型本身很小，1.5B参数对内存要求不高）
3. 下载模型文件（大约3GB左右）

不需要高端显卡，集成显卡也能跑，只是速度会慢一些。如果有独立显卡（哪怕是几年前的GTX 1060），速度会有明显提升。

5.2 核心代码：其实就几十行

整个工具的核心代码并不复杂，主要做三件事：

# 1. 加载模型（只需要在启动时执行一次） from transformers import AutoModelForCausalLM, AutoTokenizer model_path = "/path/to/DeepSeek-R1-Distill-Qwen-1.5B" tokenizer = AutoTokenizer.from_pretrained(model_path) model = AutoModelForCausalLM.from_pretrained(model_path) # 2. 准备提示词（告诉模型你要它做什么） def create_prompt(prd_content): prompt = f"""你是一个专业的测试工程师，请根据以下产品需求文档(PRD)生成详细的测试用例。 需求文档： {prd_content} 请生成测试用例，要求： 1. 按照功能模块分类组织 2. 每个测试用例包含：用例ID、测试步骤、预期结果 3. 特别关注边界条件和异常场景 4. 输出格式清晰易读 生成的测试用例：""" return prompt # 3. 生成测试用例 def generate_test_cases(prd_content): prompt = create_prompt(prd_content) # 将提示词转换为模型能理解的格式 inputs = tokenizer(prompt, return_tensors="pt") # 生成内容（关键参数设置） outputs = model.generate( inputs.input_ids, max_new_tokens=1024, # 生成内容的长度 temperature=0.6, # 控制创造性，越低越稳定 do_sample=True, top_p=0.95 ) # 解码生成的内容 test_cases = tokenizer.decode(outputs[0], skip_special_tokens=True) return test_cases

5.3 添加Web界面：让团队都能用

如果只有你能用命令行操作，这个工具的价值就有限。用Streamlit加一个简单的Web界面，让产品经理、开发工程师都能自己生成测试用例：

import streamlit as st st.title("🧪 AI测试用例生成助手") # 输入PRD内容 prd_input = st.text_area("粘贴产品需求文档(PRD)内容：", height=200) if st.button("生成测试用例"): if prd_input: with st.spinner("AI正在分析需求并生成测试用例..."): test_cases = generate_test_cases(prd_input) st.success("生成完成！") st.markdown("### 生成的测试用例") st.text_area("测试用例", test_cases, height=400) else: st.warning("请输入PRD内容")

这样，一个简单的测试用例生成工具就完成了。团队其他成员不需要懂技术，打开网页，粘贴PRD，点击按钮，就能得到测试用例。

6. 总结：AI不是替代测试工程师，而是超级助手

经过这段时间的使用和测试，我对DeepSeek-R1-Distill-Qwen-1.5B在测试用例生成上的表现可以总结为以下几点：

6.1 它真正解决了什么痛点？

1. 节省时间：把几天的工作量压缩到几小时
2. 减少遗漏：AI不会像人一样疲劳，能系统性地覆盖各种场景
3. 统一标准：生成的测试用例格式一致，便于评审和维护
4. 知识传承：新员工可以用AI快速上手，学习如何从需求中提取测试点

6.2 它的局限性在哪里？

1. 需要人工审核：AI生成的用例需要测试工程师检查和完善
2. 依赖需求质量：如果PRD本身写得模糊，AI输出也会有问题
3. 缺乏业务上下文：AI不知道你们公司的历史bug、技术债务等背景信息
4. 无法替代探索性测试：那些需要创造性、需要“猜”哪里可能出错的测试，还是需要人来做

6.3 给测试工程师的建议

如果你担心AI会取代测试工程师，我的看法恰恰相反：AI不会取代你，但会用AI的测试工程师会取代不会用AI的测试工程师。

这个工具最好的使用方式是：

1. 第一稿让AI写：用它快速生成测试用例初稿
2. 第二稿自己改：基于AI的输出，加入你的业务知识和经验
3. 第三稿做评审：和产品、开发一起评审，查漏补缺

这样，你从“写用例的工人”变成了“设计测试策略的专家”，把时间花在更有价值的地方——设计测试方案、分析测试结果、改进产品质量。

6.4 最后的思考

我最初试用这个模型时，只是好奇它能做什么。但当我看到它真的能理解需求、生成可用的测试用例时，我开始意识到：AI在软件测试领域的应用，可能比我们想象的要快。

这不是一个“未来可能会用”的技术，而是一个“今天就能用”的工具。它不需要复杂的部署，不需要昂贵的硬件，甚至不需要深厚的AI知识。任何一个测试团队，只要有一台普通的电脑，就能开始尝试。

所以，我的建议是：不要等待，现在就去试试。从一个小功能开始，看看AI能帮你做什么。你可能会有惊喜。

---

获取更多AI镜像

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