【AI】新手指南：用提示词生成测试用例的3个步骤

新手指南：用提示词生成测试用例的 3 个步骤

在软件测试工作中，测试用例是保证测试质量的核心。但编写测试用例往往需要耗费大量时间和精力，尤其是对于新手来说，很容易出现遗漏或不全面的问题。随着大语言模型的发展，利用提示词生成测试用例成为一种高效的辅助方式。本文将为新手介绍用提示词生成测试用例的 3 个关键步骤，帮助大家快速掌握这一方法，提升测试工作效率。

一、明确测试对象与测试目标

在生成测试用例之前，首先要清晰地确定测试对象和测试目标。这是编写有效提示词的基础，只有让大模型准确了解要测试什么、达到什么目的，才能生成符合需求的测试用例。

1.1 确定测试对象

测试对象是指需要进行测试的具体软件模块、功能或系统。明确测试对象时，要尽可能具体，避免模糊不清。

1.1.1 软件模块层面

如果测试对象是某个软件模块，需要说明模块的名称、功能范围以及与其他模块的关联。例如：“本次测试对象是电商平台的‘用户登录模块’，该模块负责用户输入账号密码后的身份验证，与用户信息管理模块和订单模块存在数据交互。”

1.1.2 功能层面

若测试对象是某一具体功能，要详细描述功能的具体内容和操作流程。比如：“测试对象是即时通讯软件的‘文件传输功能’，该功能支持用户向好友发送图片、文档、压缩包等类型的文件，最大支持 2GB 的单个文件传输，传输过程中可暂停和继续。”

1.1.3 系统层面

当测试对象是整个系统时，需概述系统的整体功能、架构和应用场景。例如：“测试对象是一款在线教育系统，该系统包含学生端、教师端和管理员端，学生端可进行课程报名、学习和作业提交，教师端能发布课程、批改作业，管理员端负责用户管理和系统配置，主要应用于 K12 阶段的课外辅导。”

1.2 明确测试目标

测试目标是指通过测试想要达成的结果，不同的测试目标会影响测试用例的设计方向和侧重点。

1.2.1 功能验证

功能验证是最常见的测试目标，即确认测试对象的功能是否按照需求规格正常工作。例如：“测试目标是验证电商平台‘加入购物车’功能是否正常，包括商品能否成功加入购物车、购物车中商品数量是否正确、商品价格是否与商品详情页一致。”

1.2.2 性能测试

性能测试主要关注测试对象在不同负载下的响应时间、吞吐量等指标。比如：“测试目标是检测在线考试系统在同时有 1000 名考生登录并进行答题时的性能，包括页面加载时间不超过 3 秒、答题数据提交成功率达到 100%、服务器 CPU 使用率不超过 80%。”

1.2.3 兼容性测试

兼容性测试旨在确保测试对象在不同的环境（如浏览器、操作系统、设备）下都能正常运行。例如：“测试目标是验证移动支付 APP 在安卓系统（版本 7.0 及以上）和 iOS 系统（版本 12.0 及以上）的不同机型（包括华为、小米、苹果等品牌的主流机型）上的兼容性，确保 APP 的所有功能都能正常使用，界面显示正常。”

1.2.4 安全性测试

安全性测试主要检测测试对象是否存在安全漏洞，防止数据泄露或被非法攻击。比如：“测试目标是检查用户管理系统的安全性，包括用户密码是否采用加密存储、是否能有效防止 SQL 注入攻击、非授权用户能否通过非法手段访问系统内的用户信息。”

二、设计针对性的提示词

在明确测试对象和测试目标后，就需要设计针对性的提示词。好的提示词能够准确传达需求，引导大模型生成高质量的测试用例。

2.1 提示词的基本结构

一个完整的提示词通常包含以下几个部分，根据实际情况可以进行调整和组合。

2.1.1 角色设定

为大模型设定一个合适的角色，使其从该角色的角度出发思考和生成测试用例。例如：“你是一名有 5 年经验的软件测试工程师，擅长功能测试用例设计。”

2.1.2 测试对象与目标说明

清晰地告知大模型测试对象和测试目标，这部分内容可以直接沿用第一步中确定的信息。比如：“请针对电商平台的‘用户登录模块’，生成用于验证其功能是否正常的测试用例，具体功能包括账号密码登录、验证码登录、忘记密码功能。”

2.1.3 测试用例要素要求

明确测试用例需要包含的要素，如用例编号、测试标题、前置条件、操作步骤、预期结果等，确保生成的测试用例格式规范、内容完整。例如：“生成的测试用例需包含以下要素：用例编号、测试标题、前置条件、操作步骤、预期结果。”

2.1.4 补充约束条件

根据测试的特殊需求，添加一些补充约束条件，如测试用例的数量、覆盖范围等。比如：“每个功能点至少生成 5 条测试用例，需覆盖正常场景和异常场景，异常场景包括账号不存在、密码错误、验证码过期等。”

2.2 针对不同测试目标的提示词示例

2.2.1 功能验证类提示词

以电商平台 “用户登录模块” 的功能验证为例，提示词可以设计为：“你是一名软件测试工程师，现在需要为电商平台的‘用户登录模块’设计功能测试用例，该模块支持账号密码登录和验证码登录，同时包含忘记密码功能。测试目标是验证这些功能是否正常工作。生成的测试用例需包含用例编号、测试标题、前置条件、操作步骤、预期结果。每个功能至少生成 5 条用例，要覆盖正常输入、错误输入、边界值等场景。例如，账号密码登录的正常场景包括输入正确的账号和密码登录成功，错误场景包括密码错误时的提示信息是否正确。”

2.2.2 性能测试类提示词

以在线考试系统的性能测试为例，提示词可以是：“假设你是一名性能测试工程师，需要为在线考试系统设计性能测试用例。该系统支持考生登录、查看试卷、答题、提交试卷等操作，本次测试目标是验证系统在 500 名考生同时在线答题时的性能。测试用例需包含测试场景、测试步骤、预期性能指标（如响应时间、服务器资源使用率）。例如，测试场景可以包括所有考生同时加载试卷、同时提交答案等。”

2.2.3 兼容性测试类提示词

针对移动支付 APP 的兼容性测试，提示词可以设计为：“你是一名兼容性测试专家，需要为一款移动支付 APP 设计兼容性测试用例。该 APP 支持转账、付款、查询账单等功能，测试目标是验证其在安卓（7.0 及以上）和 iOS（12.0 及以上）系统不同机型上的兼容性。测试用例需包含测试环境（系统版本、机型）、测试功能、操作步骤、预期结果（如功能是否正常、界面是否显示正确）。至少覆盖 10 种不同的机型，包括华为、小米、OPPO、vivo、苹果等品牌。”

2.2.4 安全性测试类提示词

以用户管理系统的安全性测试为例，提示词可以是：“请你扮演一名安全测试工程师，为用户管理系统设计安全性测试用例。该系统用于管理用户的基本信息（包括姓名、身份证号、手机号等），支持用户注册、登录、信息修改等功能。测试目标是检测系统是否存在安全漏洞。测试用例需包含测试内容、测试方法、预期结果。例如，测试内容可以包括密码存储安全性、是否能抵御 SQL 注入攻击、权限控制是否严格等。”

2.3 提示词的优化技巧

为了让大模型生成的测试用例更符合需求，可以对提示词进行优化。

2.3.1 具体化描述

提示词的描述越具体，大模型生成的测试用例就越精准。避免使用模糊、笼统的词语，而是使用具体的数字、场景、功能点等。例如，不要说 “测试登录功能”，而要说 “测试使用正确的手机号和验证码登录时，能否成功进入首页，且首页显示的用户信息正确”。

2.3.2 分点列出需求

将提示词中的需求分点列出，能够让大模型更清晰地理解各个要求，避免遗漏。例如：

“请生成测试用例，需满足以下要求：

1. 测试对象为电商平台的‘商品搜索功能’；

1. 测试目标是验证搜索功能的准确性和响应速度；

1. 测试用例包含用例编号、测试关键词、操作步骤、预期结果（搜索结果是否包含该关键词相关商品，响应时间是否在 2 秒内）；

1. 至少包含 10 条用例，覆盖不同类型的关键词（如商品名称、品牌、型号）。”

2.3.3 提供示例

如果对测试用例的格式或内容有特定要求，可以在提示词中提供示例，引导大模型按照示例的风格和结构生成测试用例。例如：“生成的测试用例格式参考如下示例：

用例编号：TC-001

测试标题：输入正确的账号密码登录

前置条件：用户已注册账号，且账号状态正常

操作步骤：

1. 打开电商平台登录页面；

1. 输入正确的用户名和密码；

1. 点击‘登录’按钮。

预期结果：成功登录系统，跳转至首页，首页显示用户昵称。”

三、筛选与优化生成的测试用例

大模型生成的测试用例可能存在一些不完善的地方，需要进行筛选和优化，才能应用到实际测试工作中。

3.1 测试用例的筛选标准

3.1.1 覆盖性

筛选出能够覆盖测试对象所有主要功能和测试目标的测试用例，确保没有重要的功能点或场景被遗漏。例如，对于用户登录模块，需要确保生成的测试用例覆盖了账号密码登录、验证码登录、忘记密码等所有功能，以及正常登录、错误登录等不同场景。

3.1.2 有效性

检查测试用例的操作步骤是否合理、可行，预期结果是否明确、正确。如果操作步骤存在逻辑错误或无法执行，或者预期结果不清晰、不符合实际需求，这样的测试用例需要被排除。例如，某测试用例的操作步骤是 “在未打开 APP 的情况下，点击登录按钮”，这显然是不可行的，应筛选掉。

3.1.3 简洁性

选择简洁明了的测试用例，避免过于冗长或复杂的用例。简洁的测试用例更容易执行和理解，能提高测试效率。例如，对于相同的测试场景，选择步骤更少、描述更简洁的测试用例。

3.1.4 不重复性

去除重复或相似度过高的测试用例，避免在测试过程中做无用功。例如，有两条测试用例都是测试 “输入错误密码登录”，只是错误密码的具体内容不同，这两条用例可以合并或保留一条更具代表性的。

3.2 测试用例的优化方法

3.2.1 补充细节

对于一些步骤不完整或预期结果不明确的测试用例，补充相应的细节，使其更具可执行性。例如，某测试用例的操作步骤只写了 “输入账号密码登录”，可以补充为 “输入正确的手机号（13800138000）和密码（Aa123456），点击登录按钮”；预期结果如果是 “登录成功”，可以补充为 “登录成功，跳转至首页，首页顶部显示用户昵称‘测试用户’”。

3.2.2 调整顺序

根据测试的逻辑顺序或执行的先后顺序，对测试用例进行排序，使测试过程更有条理。例如，对于用户注册 - 登录 - 信息修改的测试用例，可以按照注册、登录、信息修改的顺序排列。

3.2.3 增加异常场景

大模型生成的测试用例可能更侧重于正常场景，而对异常场景的覆盖不足。可以根据实际情况，增加一些异常场景的测试用例，如网络中断、数据格式错误、权限不足等。例如，在测试文件上传功能时，可以增加 “上传超过最大限制大小的文件时，系统是否给出明确提示” 这样的异常场景用例。

3.2.4 结合实际业务

结合软件的实际业务场景和用户使用习惯，对测试用例进行调整和优化，使其更贴合实际应用。例如，对于一款面向老年人的健康管理 APP，在测试用例中要考虑到老年人可能对操作不熟悉，增加 “操作步骤是否简单易懂”“字体大小是否合适” 等与实际使用相关的测试点。

3.3 筛选与优化示例

以电商平台 “加入购物车” 功能的测试用例为例，假设大模型生成了以下测试用例：

用例 1：

用例编号：TC-001

测试标题：添加商品到购物车

操作步骤：点击 “加入购物车” 按钮

预期结果：商品加入购物车

用例 2：

用例编号：TC-002

测试标题：添加多个商品到购物车

操作步骤：多次点击 “加入购物车” 按钮

预期结果：多个商品加入购物车

通过筛选发现，这两条测试用例存在覆盖性不足、细节不完整的问题。进行优化后：

用例 1：

用例编号：TC-001

测试标题：添加单个商品到购物车（库存充足）

前置条件：商品 A 库存为 10 件，用户已登录

操作步骤：

1. 进入商品 A 详情页；

1. 选择商品规格（颜色：红色，尺码：M）；

1. 点击 “加入购物车” 按钮。

预期结果：

1. 系统提示 “加入购物车成功”；

1. 购物车中显示商品 A，规格为红色 M，数量为 1；

1. 商品 A 的库存变为 9 件。

用例 2：

用例编号：TC-002

测试标题：添加商品到购物车（超过最大购买数量）

前置条件：商品 B 最大购买数量为 5 件，用户已登录

操作步骤：

1. 进入商品 B 详情页；

1. 选择商品规格后，将购买数量设置为 6；

1. 点击 “加入购物车” 按钮。

预期结果：

1. 系统提示 “该商品单次最大购买数量为 5 件，请调整数量”；

1. 商品 B 未加入购物车。

用例 3：

用例编号：TC-003

测试标题：未登录状态下添加商品到购物车

前置条件：用户未登录，商品 C 库存充足

操作步骤：

1. 进入商品 C 详情页；

1. 点击 “加入购物车” 按钮。

预期结果：

1. 系统弹出登录提示框，提示 “请先登录”；

1. 商品 C 未加入购物车。

通过这样的筛选和优化，测试用例更加完善，能够更好地满足测试需求。

四、实际案例演示

为了让大家更直观地了解用提示词生成测试用例的整个过程，下面以一个具体的案例进行演示。

4.1 案例背景

测试对象：某外卖 APP 的 “订单支付” 功能，该功能支持微信支付、支付宝支付、银行卡支付三种支付方式，用户在确认订单后可选择其中一种方式进行支付。

测试目标：验证 “订单支付” 功能的正确性，包括不同支付方式能否成功支付、支付失败时的提示是否准确、支付状态是否能正确同步到订单中。

4.2 设计提示词

根据案例背景，设计的提示词如下：

“你是一名有 3 年经验的软件测试工程师，现在需要为某外卖 APP 的‘订单支付’功能设计测试用例。该功能支持微信支付、支付宝支付、银行卡支付，用户确认订单后可选择支付方式进行支付。测试目标是验证支付功能的正确性，包括不同支付方式能否成功支付、支付失败提示是否准确、支付状态与订单同步是否正确。生成的测试用例需包含用例编号、测试标题、前置条件、操作步骤、预期结果。每种支付方式至少生成 3 条用例，覆盖成功支付、支付失败（如余额不足、网络中断）、重复支付等场景。”

4.3 生成测试用例

大模型根据上述提示词生成的测试用例如下（部分示例）：

用例编号：TC-001

测试标题：微信支付成功

前置条件：

1. 用户已登录外卖 APP；

1. 已提交一份金额为 50 元的订单；

1. 微信账户余额充足。

操作步骤：

1. 在订单确认页选择 “微信支付”；

1. 点击 “确认支付”；

1. 在微信支付页面完成支付。

预期结果：

1. 支付成功，微信扣除 50 元；

1. APP 显示 “支付成功”；

1. 订单状态更新为 “已支付”。

用例编号：TC-002

测试标题：支付宝支付余额不足

前置条件：

1. 用户已登录外卖 APP；

1. 已提交一份金额为 30 元的订单；

1. 支付宝账户余额为 20 元。

操作步骤：

1. 在订单确认页选择 “支付宝支付”；

1. 点击 “确认支付”；

1. 在支付宝支付页面点击 “确认付款”。

预期结果：

1. 支付宝提示 “余额不足”；

1. APP

   显示 “支付失败，请更换支付方式或充值后重试”；

   3. 订单状态保持为 “待支付”。

   用例编号：TC-003

   测试标题：银行卡支付时网络中断

   前置条件：

2. 用户已登录外卖 APP；
3. 已提交一份金额为 45 元的订单；
4. 绑定的银行卡余额充足，网络连接不稳定。

5. 操作步骤：

6. 在订单确认页选择 “银行卡支付”；
7. 点击 “确认支付”；
8. 在输入银行卡密码并点击 “确认” 后，手动断开网络连接。

9. 预期结果：

10. APP 显示 “网络连接失败，请检查网络后重试”；
11. 银行卡未扣款；
12. 订单状态保持为 “待支付”，且 APP 提示 “可重新发起支付”。

13. 用例编号：TC-004

    测试标题：微信重复支付同一订单

    前置条件：

14. 用户已登录外卖 APP；
15. 已提交一份金额为 60 元的订单，且该订单尚未支付；
16. 微信账户余额充足。

17. 操作步骤：

18. 第一次支付：在订单确认页选择 “微信支付”，点击 “确认支付”，在微信支付页面完成支付，APP 显示 “支付成功”；
19. 第二次支付：返回订单列表，再次点击该订单的 “继续支付” 按钮，选择 “微信支付” 并点击 “确认支付”。

20. 预期结果：

21. 第二次支付时，APP 提示 “该订单已支付，无需重复支付”；
22. 微信仅扣除第一次支付的 60 元；
23. 订单状态保持为 “已支付”。

24. 4.4 筛选与优化测试用例

    对生成的测试用例进行筛选和优化，确保其符合实际测试需求：

    4.4.1 筛选过程

    检查生成的测试用例是否覆盖了所有测试场景和支付方式。发现对于银行卡支付的 “支付成功” 场景和 “银行卡信息错误” 场景没有覆盖，需要保留现有有效用例，并补充相关场景的测试用例。同时，检查操作步骤和预期结果是否合理，例如用例 TC-003 中 “手动断开网络连接” 的操作步骤可行，预期结果明确，符合有效性要求。

    4.4.2 优化过程

    补充银行卡支付成功的测试用例：

    用例编号：TC-005

    测试标题：银行卡支付成功

    前置条件：

25. 用户已登录外卖 APP；
26. 已提交一份金额为 35 元的订单；
27. 绑定的银行卡信息正确且余额充足。

28. 操作步骤：

29. 在订单确认页选择 “银行卡支付”；
30. 点击 “确认支付”；
31. 输入正确的银行卡密码并点击 “确认”。

32. 预期结果：

33. 支付成功，银行卡扣除 35 元；
34. APP 显示 “支付成功”；
35. 订单状态更新为 “已支付”。

36. 补充银行卡信息错误的测试用例：

    用例编号：TC-006

    测试标题：银行卡支付时信息错误

    前置条件：

37. 用户已登录外卖 APP；
38. 已提交一份金额为 55 元的订单；
39. 绑定的银行卡号输入错误（例如末尾数字输错）。

40. 操作步骤：

41. 在订单确认页选择 “银行卡支付”；
42. 点击 “确认支付”；
43. 输入错误的银行卡号和正确密码后点击 “确认”。

44. 预期结果：

45. 系统提示 “银行卡信息错误，请核对后重新输入”；
46. 银行卡未扣款；
47. 订单状态保持为 “待支付”。

48. 调整部分用例的操作步骤顺序，使其更符合用户实际操作流程。例如，在用例 TC-001 中，补充 “确认订单信息无误” 这一前置操作，使步骤更完整。

    五、常见问题与解决方法

    在使用提示词生成测试用例的过程中，新手可能会遇到一些问题，影响测试用例的质量和生成效率。以下是一些常见问题及相应的解决方法。

    5.1 生成的测试用例覆盖范围不足

    5.1.1 问题表现

    生成的测试用例只覆盖了测试对象的部分功能或场景，存在明显的遗漏。例如，测试 “用户注册功能” 时，只生成了正常注册的用例，没有考虑手机号格式错误、密码长度不足等异常场景。

    5.1.2 解决方法

    在提示词中明确要求覆盖的功能点和场景类型。可以列出需要覆盖的具体场景，如 “请生成测试用例，需覆盖正常场景（如信息正确注册成功）、异常场景（如手机号格式错误、密码长度不足、验证码过期、用户名已存在等）”。同时，参考软件需求规格说明书，确保提示词中包含所有重要的功能和场景描述。

    5.2 测试用例的操作步骤不清晰或不可执行

    5.2.1 问题表现

    测试用例的操作步骤描述模糊，例如 “进行支付操作”，没有说明具体的操作路径和点击的按钮；或者操作步骤存在逻辑错误，无法实际执行，如 “在未打开 APP 的情况下进行登录操作”。

    5.2.2 解决方法

    在提示词中强调操作步骤的具体性和可执行性，要求大模型按照实际的用户操作流程描述步骤。可以提供操作步骤的示例，如 “操作步骤需详细描述每一步的具体操作，例如：1. 打开 XXAPP；2. 点击首页的‘我的’按钮；3. 在‘我的’页面点击‘登录’选项”。对于复杂的操作流程，可以在提示词中先描述整体的操作路径，再让大模型生成具体步骤。

    5.3 预期结果不明确或与操作步骤不匹配

    5.3.1 问题表现

    预期结果描述笼统，如 “操作成功”，没有说明成功的具体表现；或者预期结果与操作步骤不对应，例如操作步骤是 “输入错误密码登录”，预期结果却是 “登录成功”。

    5.3.2 解决方法

    在提示词中明确要求预期结果需具体、可衡量，并且与操作步骤相对应。例如，提示词中可以写 “预期结果要清晰描述操作后系统的具体反应，如页面跳转、提示信息内容、数据变化等，且需与操作步骤的场景相匹配”。同时，在生成测试用例后，逐一检查操作步骤和预期结果的对应关系，发现不匹配的情况及时修改。

    5.4 生成的测试用例格式不统一

    5.4.1 问题表现

    生成的测试用例格式混乱，有的包含用例编号和测试标题，有的则没有；有的预期结果单独列出，有的则与操作步骤混在一起，不便于后续的管理和执行。

    5.4.2 解决方法

    在提示词中明确规定测试用例的格式，包括需要包含的要素和各要素的排列顺序。可以提供统一的格式示例，要求大模型严格按照示例格式生成。例如：“测试用例需严格按照以下格式生成：

    用例编号：[具体编号]

    测试标题：[简洁描述测试内容]

    前置条件：[执行该用例需满足的条件]

    操作步骤：

49. [步骤 1 的具体操作]
50. [步骤 2 的具体操作]

51. ...

    预期结果：

52. [结果 1 的具体描述]
53. [结果 2 的具体描述]

54. ...”

    5.5 大模型对提示词的理解存在偏差

    5.5.1 问题表现

    生成的测试用例与提示词的要求不符，例如提示词要求生成性能测试用例，结果生成的是功能测试用例；或者要求覆盖 10 种机型的兼容性测试，结果只覆盖了 5 种。

    5.5.2 解决方法

    首先，检查提示词是否清晰、准确，避免使用歧义性的词语。如果提示词存在模糊之处，重新修改和完善提示词，使其表达更明确。其次，可以在提示词中重复强调关键要求，例如 “本次生成的是性能测试用例，不是功能测试用例，需重点关注响应时间、并发用户数等性能指标”。如果多次调整后大模型仍理解偏差，可以尝试更换大模型或分多次生成，每次只专注于一个具体的要求。

    六、提升提示词生成测试用例效率的技巧

    掌握一些实用技巧可以进一步提升使用提示词生成测试用例的效率和质量，帮助新手更快地适应这一方法。

    6.1 积累提示词模板

    6.1.1 建立模板库

    根据不同的测试类型（如功能测试、性能测试、兼容性测试、安全性测试）和常见的测试对象（如登录模块、支付功能、搜索功能等），建立提示词模板库。模板中包含角色设定、测试对象与目标说明、测试用例要素要求、补充约束条件等固定部分，使用时只需根据具体需求修改可变部分。

    例如，功能测试用例的通用模板：

    “你是一名有 X 年经验的功能测试工程师，擅长 [具体领域] 的功能测试用例设计。请针对 [测试对象名称] 的 [具体功能] 生成功能测试用例，测试目标是验证该功能是否按照需求正常工作。生成的测试用例需包含用例编号、测试标题、前置条件、操作步骤、预期结果。需覆盖正常场景、异常场景（如 [列举 1-2 种异常类型]）等，至少生成 [X] 条用例。”

    6.1.2 模板的灵活调整

    模板库并非一成不变，需要根据实际使用情况进行调整和优化。在使用过程中，如果发现某类模板生成的测试用例存在共性问题，及时修改模板中的描述或补充约束条件，使其更符合需求。

    6.2 利用历史对话信息

    6.2.1 延续上下文

    在与大模型的对话过程中，充分利用历史对话信息，避免重复输入相同的内容。例如，在第一次提示中已经说明了测试对象的基本信息，后续生成其他测试用例时，可以直接说 “基于之前提到的 [测试对象名称]，现在需要生成 [具体测试类型] 的测试用例”，让大模型结合历史信息生成，减少重复劳动。

    6.2.2 基于历史结果调整

    如果对之前生成的测试用例比较满意，可以让大模型 “按照上一条测试用例的风格和格式，继续生成 [X] 条同类测试用例”；如果之前的测试用例存在不足，在后续提示中说明 “参考上一条用例，修改其中的 [具体问题]，并生成新的测试用例”，提高生成效率。

    6.3 结合测试用例设计方法

    6.3.1 等价类划分法

    在提示词中融入等价类划分的思想，要求大模型将测试对象的输入或操作划分为有效等价类和无效等价类，并分别生成测试用例。例如，测试手机号登录功能时，提示词可以写 “请根据等价类划分法生成测试用例，有效等价类包括正确格式的手机号（11 位数字），无效等价类包括少于 11 位的数字、多于 11 位的数字、包含字母或符号的手机号等，每个等价类至少生成 2 条用例”。

    6.3.2 边界值分析法

    对于有数值范围限制的功能，在提示词中要求使用边界值分析法设计测试用例。例如，测试商品购买数量（最大购买数量为 10）时，提示词可以写 “请使用边界值分析法生成测试用例，包括边界值（10）、边界值附近的值（9、11）、典型值（5）等场景”。

    6.3.3 场景法

    针对涉及多个步骤或多个模块交互的功能，在提示词中采用场景法，要求大模型根据不同的业务场景生成测试用例。例如，测试电商平台的 “下单 - 支付 - 发货” 流程时，提示词可以写 “请按照场景法生成测试用例，覆盖正常下单支付后成功发货、下单后取消订单、支付后申请退款等不同业务场景，每个场景包含完整的操作流程和预期结果”。

    6.4 批量生成与批量优化

    6.4.1 批量生成

    对于测试对象的多个功能点或多个测试场景，可以在一个提示词中批量提出需求，让大模型一次性生成多个测试用例。例如，“请为电商平台的‘商品详情页’功能生成测试用例，包括查看商品图片、查看商品参数、查看用户评价、分享商品四个功能点，每个功能点生成 3-5 条用例，格式按照 [指定格式]”。

    6.4.2 批量优化

    当生成大量测试用例后，可以统一提出优化要求进行批量优化。例如，“请对刚才生成的所有测试用例进行优化，补充各用例的前置条件，将操作步骤中的模糊描述修改为具体操作，确保预期结果与操作步骤一一对应”，提高优化效率。

    七、不同类型软件的提示词设计要点

    不同类型的软件具有不同的特点和功能，在设计提示词生成测试用例时，需要根据软件类型的特点调整提示词的内容和侧重点。

    7.1 电商类软件

    7.1.1 核心功能提示要点

    电商类软件的核心功能包括商品浏览、搜索、加入购物车、下单、支付、物流跟踪等。在设计提示词时，要重点关注这些功能的流程完整性和数据准确性。

    例如，针对下单功能的提示词：“你是一名电商软件测试工程师，需要为电商平台的‘下单’功能设计测试用例。该功能包括选择收货地址、选择支付方式、确认订单信息、提交订单等步骤。测试目标是验证下单流程的完整性和订单数据的准确性（如商品数量、价格、收货地址等）。生成的测试用例需包含用例编号、测试标题、前置条件、操作步骤、预期结果，覆盖正常下单、地址不存在、库存不足等场景。”

    7.1.2 特殊场景提示要点

    电商类软件存在一些特殊场景，如促销活动（秒杀、满减、优惠券）、退换货、订单取消等。在提示词中要明确这些场景的规则和要求，确保测试用例覆盖这些场景。

    例如，针对秒杀活动的提示词：“请为电商平台的‘秒杀活动’功能生成测试用例。该活动规定某商品在每天 10 点进行秒杀，限量 100 件，每人限购 1 件，需在 10 分钟内完成支付。测试目标是验证秒杀活动的规则是否生效（如限购数量、支付时间限制）、秒杀过程是否流畅。测试用例需包含正常秒杀成功、超过限购数量、超时未支付等场景，详细描述操作步骤和预期结果。”

    7.2 社交类软件

    7.2.1 核心功能提示要点

    社交类软件的核心功能包括用户注册、登录、添加好友、聊天（文字、语音、视频）、发布动态、评论点赞等。设计提示词时，要关注功能的交互性和实时性。

    例如，针对聊天功能的提示词：“你是一名社交软件测试工程师，需要为社交 APP 的‘视频聊天’功能设计测试用例。该功能支持一对一视频聊天，可切换摄像头、开启 / 关闭麦克风、发送表情等操作。测试目标是验证视频聊天的连接稳定性、画面和声音的清晰度、功能按钮的有效性。生成的测试用例需包含用例编号、测试标题、前置条件、操作步骤、预期结果，覆盖网络良好、网络卡顿、切换网络（WiFi 切换到 4G）等场景。”

    7.2.2 特殊场景提示要点

    社交类软件的特殊场景包括账号封禁、消息撤回、隐私设置（如朋友圈权限）等。在提示词中要明确这些场景的触发条件和系统处理规则。

    例如，针对消息撤回功能的提示词：“请为社交 APP 的‘消息撤回’功能生成测试用例。该功能规定文字消息可在发送后 2 分钟内撤回，图片、视频消息可在发送后 5 分钟内撤回，撤回后对方显示‘对方撤回一条消息’。测试目标是验证撤回功能的时间限制和显示效果。测试用例需包含不同类型消息在规定时间内撤回、超过时间无法撤回等场景。”

    7.3 工具类软件

    7.3.1 核心功能提示要点

    工具类软件（如办公软件、图片处理软件、文件管理软件）的核心功能通常具有较强的专业性和实用性，如文档编辑、图片裁剪、文件压缩等。设计提示词时，要关注功能的准确性和效率。

    例如，针对文件压缩功能的提示词：“你是一名工具软件测试工程师，需要为文件管理 APP 的‘文件压缩’功能设计测试用例。该功能支持对图片、文档、视频等类型的文件进行压缩，可选择压缩质量（高、中、低）。测试目标是验证压缩后的文件是否能正常打开、压缩前后的文件大小变化是否符合预期、压缩速度是否在合理范围内（如 100MB 的视频压缩时间不超过 30 秒）。生成的测试用例需包含不同类型文件、不同压缩质量的场景。”

    7.3.2 特殊场景提示要点

    工具类软件的特殊场景包括大文件处理、格式兼容性、多任务同时处理等。在提示词中要明确这些场景的处理要求和性能指标。

    例如，针对大文件处理的提示词：“请为文件管理 APP 的‘大文件传输’功能生成测试用例。该功能支持传输 1GB 以上的大文件，可通过蓝牙、WiFi 直连等方式传输。测试目标是验证大文件传输的成功率（需达到 95% 以上）、传输速度（WiFi 直连下不低于 10MB/s）、传输过程中中断后能否断点续传。测试用例需包含不同大小的大文件（1GB、2GB、5GB）、不同传输方式的场景。”

    7.4 游戏类软件

    7.4.1 核心功能提示要点

    游戏类软件的核心功能包括账号登录、角色创建、任务系统、战斗系统、社交系统（组队、聊天）、充值系统等。​

    7.4.2 提示词设计要点​

55. 注重游戏逻辑的正确性和稳定性，例如：“测试用例需验证任务完成条件、战斗伤害计算是否符合游戏设定，长时间游戏是否会出现闪退”。​
56. 关注多玩家交互场景，例如：“包含多人组队战斗时，技能释放、伤害计算、任务进度同步是否正常的测试用例”。​
57. 考虑不同设备适配性，例如：“测试在不同配置的手机上，游戏画面帧率、卡顿情况是否在可接受范围内”。​

58. 八、提示词生成测试用例的局限性及应对措施​

    虽然使用提示词生成测试用例能提高效率，但也存在一定的局限性，需要采取相应的应对措施。​

    8.1 局限性​

    8.1.1 依赖大模型能力​

    大模型的知识和理解能力有限，对于一些复杂、专业的测试场景，可能无法生成准确的测试用例。例如，对于涉及底层代码逻辑的白盒测试，大模型生成的用例可能缺乏专业性。​

    8.1.2 缺乏实际环境感知​

    大模型无法实际运行软件，生成的测试用例可能没有考虑到软件运行的实际环境（如硬件配置、网络状况等），导致部分用例在实际执行中不可行。​

    8.1.3 创新性不足​

    大模型生成的测试用例主要基于已有的知识和数据，缺乏创新性，对于一些新型的、特殊的测试场景可能无法覆盖。​

    8.2 应对措施​

    8.2.1 结合人工审核​

    无论大模型生成的测试用例质量如何，都需要经过人工审核和调整，确保用例的准确性和可行性。测试人员可以根据自己的专业知识和经验，对用例进行补充和优化。​

    8.2.2 补充实际环境信息​

    在提示词中尽可能详细地描述软件运行的实际环境，如硬件配置、操作系统版本、网络状况等，让大模型在生成用例时考虑这些因素。例如：“该软件运行在 Windows 10 操作系统，内存 4GB 以上的电脑上，网络为有线连接，带宽 100Mbps。请生成符合该环境的测试用例”。​

    8.2.3 持续学习和积累​

    测试人员要不断学习新的测试技术和方法，积累实际测试经验，对于大模型无法覆盖的创新测试场景，手动设计测试用例，弥补大模型的不足。同时，将新的测试场景和用例反馈到提示词设计中，不断优化提示词，提高大模型生成用例的质量。​