【AI测试】AI提取测试点完整思路:工具选择+模板设计+案例演示

手工从需求文档中提取测试点，是一件极其消耗精力的工作。

一份完整的产品需求文档往往长达数十页，涵盖功能描述、业务规则、边界条件、异常处理、性能要求、安全约束等多维度信息。测试工程师需要反复阅读、标注、归纳，才能将需求转化为可执行的测试用例。这个过程通常需要数小时，期间还容易遗漏边界条件和异常场景。

更关键的问题是：人的精力有限，注意力会随时间下降。当阅读到文档后半部分时，前面的细节往往已经开始模糊。而AI不存在这个问题——它可以持续保持稳定的注意力，逐字逐句地解析每一个细节。

本文介绍如何利用AI，通过精心设计的提示词模板，在10分钟内完成需求文档的测试点提取。方法适用于Word、PDF、Excel、PRD等多种文档格式，提取结果可以直接用于测试评审或转化为自动化测试用例。

一、为什么用AI读需求文档

1.1 传统方式的效率瓶颈

在实际项目中，需求文档往往存在以下特点：

篇幅长、信息密度高。一个中等规模的功能迭代，需求文档通常在20-50页之间，涵盖功能描述、交互流程、数据规则、系统约束等大量信息。手工阅读并提取测试点，需要反复回溯文档、交叉验证，效率极低。

以一个典型的电商订单系统需求为例，文档可能包含：用户下单流程、支付流程、退款流程、优惠券使用规则、库存扣减逻辑、订单状态流转、消息通知机制等数十个功能模块。手工提取每个模块的测试点，往往需要半天甚至更长时间。

边界条件容易被遗漏。需求文档通常以正向流程为主，边界条件和异常场景往往分散在文档各处，甚至需要读者自行推导。手工提取时，极容易遗漏「最大值+1」「最小值-1」「空字符串」「特殊字符」等边界情况。

我曾经做过一个统计：在项目复盘时发现，线上bug中有超过40%是由于测试边界条件遗漏导致的。这些边界条件在需求文档中往往有描述，但手工提取测试点时，由于精力有限，容易被忽略。

版本迭代带来重复劳动。每次需求变更，都需要重新审视原有测试点是否仍然适用。这个过程枯燥且容易出错，但手工又不得不做。

1.2 AI辅助的核心优势

使用AI读取需求文档，能够带来几个显著改变：

速度提升。AI可以在分钟级别完成文档解析和测试点提取，相比手工方式提升数十倍效率。这意味着测试工程师可以将更多精力投入到测试设计、缺陷分析和测试策略制定等更有价值的工作上。

根据实际测试，使用AI辅助后，一份30页的需求文档，从提取测试点到完成初稿，从原来的4-6小时缩短到30分钟以内，效率提升超过10倍。

覆盖度提升。AI不受注意力衰减影响，可以稳定地扫描文档的每一个角落。配合合适的提示词模板，可以系统性地覆盖功能点、边界条件、异常场景、数据校验、兼容性等多个维度。

我曾对比过AI提取和手工提取的测试点数量：同一份文档，AI提取了58个测试点，手工提取了42个测试点。AI额外发现的16个测试点中，有11个是边界条件和异常场景，这些恰恰是手工容易遗漏的部分。

可复用性。提示词模板一旦调试完成，可以复用于同类项目，形成团队级的方法论积累。新人加入时，只需要学习如何使用模板，而不需要从零开始摸索提取方法。

1.3 适用场景与局限性

AI提取测试点并非万能。以下场景效果较好：

• 功能性需求文档（描述清晰的业务流程）
• 有明确业务规则的文档（字段定义、校验逻辑）
• 变更范围明确的小版本迭代
• 需要快速完成初稿的紧急项目

以下场景效果有限，需要人工重点介入：

• 创新性功能（缺乏历史参考，边界条件需要人工推导）
• 跨系统交互的复杂场景（需要测试人员结合实际系统理解）
• 非功能需求中的性能指标（需要结合实际压测数据验证）
• 涉及用户体验和主观判断的需求

理解这些边界，有助于在实际工作中合理分配人工和AI的工作比例。建议将80%的基础提取工作交给AI，20%的深度分析和评审由人工完成，这样可以在效率和质量之间取得平衡。

二、扣子（Coze）读取文档的操作流程

2.1 扣子平台简介

扣子（Coze）是字节跳动推出的AI应用开发平台，提供了创建和部署AI Bot的能力。在测试点提取场景中，我们主要使用扣子的文档处理能力和对话式交互能力。

扣子的核心优势在于：

• 强大的文档解析能力
  
  ：支持上传Word、PDF、Excel等多种格式的文档，平台会自动解析文档结构
• 灵活的提示词定制
  
  ：可以通过人设与提示词配置，定制Bot的行为模式和输出格式
• 多轮对话支持
  
  ：支持多轮对话，可以逐步深入提取各个维度的测试点
• 知识库功能
  
  ：可以上传文档到知识库，Bot会自动学习和理解文档内容
• 无需编程
  
  ：整个配置过程通过界面完成，无需编写代码

2.2 创建测试点提取Bot

在扣子平台创建测试点提取Bot的步骤如下：

第一步：访问扣子平台

访问 https://www.coze.cn，使用账号登录。如果没有账号，需要先完成注册（支持手机号、邮箱等多种方式）。

第二步：创建Bot

点击「创建Bot」按钮，填写以下信息：

Bot名称：测试点提取助手Bot描述：帮助测试工程师从需求文档中提取全面的测试点

Bot名称和描述会直接影响AI的理解和输出，建议描述清晰、具体。

第三步：配置人设与提示词

这是整个流程的核心步骤。在Bot配置页面，找到「人设与提示词」配置项，填入提示词模板：

# 角色定义你是一位经验丰富的测试工程师，拥有10年以上的功能测试经验。你擅长从需求文档中提取全面的测试点，包括功能点、边界条件、异常场景等。你对软件质量保障有深入理解，熟悉测试用例设计的各种方法。# 能力描述- 能够准确理解需求文档的内容和意图- 能够识别文档中的功能需求、业务规则、数据约束等关键信息- 能够从多个维度提取测试点：功能测试、边界测试、异常测试、数据校验、兼容性测试等- 能够按指定的格式输出测试点，支持Markdown、表格等多种格式# 输出要求1. 测试点应具体、可执行，避免模糊描述2. 每个测试点应能够独立执行3. 测试点之间应避免重复4. 考虑正常场景和异常场景的平衡5. 特别关注边界条件和异常场景

第四步：添加文档处理能力

扣子支持两种文档处理方式：

方式一：直接上传

在对话界面中，可以直接上传Word、PDF等格式的文档文件。扣子会自动解析文档内容。

方式二：粘贴内容

对于较短的文档，也可以直接粘贴文本内容给AI处理。这种方式适合文档内容较短或者只需要提取部分内容时使用。

方式三：使用知识库

如果需要处理大量文档，可以创建知识库，将文档上传到知识库中。Bot会自动学习和理解知识库中的内容，可以随时查询。

2.3 文档格式支持情况

扣子平台对常见文档格式的支持情况如下：

格式选择建议：

对于复杂排版的文档（如包含大量表格、图表的PRD），建议优先使用Word或PDF格式上传，解析效果最佳。

如果文档中存在重要的表格数据（如字段定义表、数据字典），建议单独导出为Excel格式上传，这样表格结构会更清晰。

2.4 基础操作演示

使用扣子Bot提取测试点的典型操作流程：

用户：上传需求文档扣子：已收到文档，正在解析内容...扣子：文档已解析完成，共识别到XX个章节，包含以下主要内容：      - 用户模块功能      - 订单模块功能      - 支付模块功能      ...用户：请提取这份文档的测试点，按功能模块分类输出扣子：[输出测试点列表，包括功能测试点、边界条件、异常场景等]用户：请重点补充边界条件的测试点扣子：[补充边界条件测试点]用户：请按表格格式输出所有测试点扣子：[输出格式化表格]

注意事项：

1. 文档大小限制：扣子对单次上传的文档大小有限制，如果文档过大，可以分成多个部分上传

2. 多轮对话上下文：扣子支持多轮对话，Bot会记住对话上下文。但建议在开始新任务时，说明清楚任务背景

3. 输出格式约定：在发送提示词前，先明确告知期望的输出格式，这样可以减少后续调整的工作量

三、提示词模板设计

提示词模板是AI提取测试点的核心。一个好的提示词模板应该包含：角色定义、任务描述、输出格式、约束条件、示例参考等部分。

3.1 基础模板

以下是适用于大多数场景的基础提示词模板，可以直接复制使用：

# 角色定义你是一位经验丰富的测试工程师，拥有10年以上的功能测试经验。你擅长从需求文档中提取全面的测试点，包括功能点、边界条件、异常场景等。你对软件质量保障有深入理解，熟悉测试用例设计的各种方法。# 任务描述请仔细阅读以下需求文档，提取所有测试点。需求文档内容：{在这里粘贴文档内容}# 输出要求请按以下格式输出测试点：## 1. 功能测试点列出所有功能性需求的测试点，每个测试点包含：- 测试点编号- 测试点描述- 测试目标- 前置条件## 2. 边界条件测试点列出所有边界值测试点，包括：- 边界值（最大值、最小值、临界值）- 等价类划分（有效等价类、无效等价类）## 3. 异常场景测试点列出所有异常处理相关的测试点：- 网络异常场景- 服务异常场景- 数据异常场景## 4. 数据校验测试点列出所有数据校验相关的测试点：- 字段格式校验- 数据类型校验- 必填项校验## 5. 兼容性测试点列出所有兼容性相关的测试点：- 浏览器兼容性- 操作系统兼容性- 屏幕分辨率兼容性# 约束条件1. 测试点应具体、可执行，避免模糊描述2. 每个测试点应能够独立执行3. 测试点之间应避免重复4. 考虑正常场景和异常场景的平衡5. 边界条件和异常场景的测试点占比不低于30%

3.2 进阶模板：分步骤提取

对于复杂的需求文档，建议采用分步骤提取的方式，逐个维度深入挖掘。这个模板更适合测试点数量较多、维度较复杂的场景：

# 分步骤测试点提取助手## 第一步：识别功能清单请先识别需求文档中涉及的所有功能模块，列出功能清单。输出格式：| 功能模块 | 功能名称 | 功能描述 | 优先级 ||---------|---------|---------|--------|| 模块A | 功能1 | 描述... | P1 |## 第二步：针对每个功能提取测试点对于清单中的每个功能，请提取：1. 核心业务测试点2. 用户交互测试点3. 数据流转测试点## 第三步：提取边界条件请特别关注以下边界条件：- 数值边界：0、最大值、最大值±1、最小值、最小值±1- 字符串边界：空字符串、空格、纯数字、纯字母、特殊字符、超长字符串- 时间边界：闰年、跨年、跨月、时区边界- 并发边界：多人同时操作、顺序依赖操作## 第四步：提取异常场景请识别并列出以下异常场景：1. 网络异常：断网、网络延迟、网络切换2. 服务异常：服务重启、服务不可用、服务响应超时3. 数据异常：数据为空、数据格式错误、数据冲突## 第五步：汇总输出请将以上测试点汇总输出，格式统一为：| 测试点ID | 所属功能 | 测试点描述 | 测试类型 | 优先级 ||---------|---------|-----------|---------|--------|| TC-001 | 功能1 | 描述... | 功能测试 | P1 |## 输出数量要求1. 功能测试点：15-25个2. 边界条件测试点：10-15个3. 异常场景测试点：8-12个4. 数据校验测试点：5-10个5. 兼容性测试点：5-8个总计：建议输出40-60个测试点

3.3 格式化输出模板

当需要将测试点导出到Excel或其他工具时，可以使用以下格式化模板：

# 测试点格式化输出助手请将测试点按以下Excel友好格式输出：测试点ID	所属模块	测试点描述	测试类型	优先级	前置条件	测试数据	预期结果示例格式：TC-001	用户登录	使用正确账号密码登录	功能测试	P1	用户已注册	username=test&password=123456	登录成功，进入首页## 输出规范1. 使用Tab分隔，方便复制到Excel2. 测试点ID格式：TC-XXX（3位数字序号）3. 测试类型包括：功能测试、边界测试、异常测试、数据校验、兼容性测试、性能测试、安全测试4. 优先级包括：P1（核心功能）、P2（重要功能）、P3（一般功能）

3.4 提示词优化技巧

在实际使用中，以下技巧可以显著提升提示词效果：

技巧一：提供示例输出

在提示词中提供一个或多个完整的输出示例，可以帮助AI更准确地理解预期格式：

# 输出示例请参考以下格式输出：示例输出：## 功能测试点| ID | 测试点描述 | 预期结果 ||----|-----------|---------|| F001 | 输入正确用户名密码登录 | 登录成功，进入首页 || F002 | 输入错误密码登录 | 提示"密码错误"，停留在登录页 |请严格按照上述格式输出。

技巧二：使用结构化指令

结构化指令有助于AI更清晰地理解任务：

# 使用结构化指令任务：提取测试点输入：需求文档输出格式：Markdown表格约束：- 测试点数量不少于20个- 每个测试点必须包含前置条件- 边界条件测试点占比不低于30%

技巧三：设定输出长度

明确告知AI期望的输出长度，可以避免输出过于简略或过于冗长：

# 输出长度要求1. 功能测试点：15-25个2. 边界条件测试点：10-15个3. 异常场景测试点：8-12个4. 数据校验测试点：5-10个5. 兼容性测试点：5-8个总计：建议输出40-60个测试点

技巧四：明确业务背景

提供足够的业务背景信息，可以帮助AI更准确地理解需求：

# 业务背景这是一个电商订单系统，主要功能包括：- 用户下单- 支付- 物流追踪- 退款退货系统特点：- 高并发场景，日均订单量10万+- 需要对接多个第三方支付渠道- 支持多种促销方式（优惠券、满减、折扣）请基于以上背景提取测试点，特别关注：1. 并发场景下的数据一致性2. 支付环节的资金安全3. 促销计算的准确性

四、测试点提取的完整流程

4.1 流程概览

使用AI提取测试点的完整流程包含以下阶段：

4.2 阶段一：文档准备

文档准备是整个流程的基础。建议按以下步骤操作：

收集文档。从需求管理系统、文档库或协作平台获取最新的需求文档。注意确认文档版本，避免使用过期版本。

建议在文档命名中包含版本号，如：PRD_v2.3_用户积分系统_20240401.docx，便于后续追溯。

格式检查。确认文档格式是否符合扣子平台的支持范围。如果是不支持的格式（如.pages、Keynote等），需要先转换为PDF或Word格式。

常用转换工具：

• pages → Word：macOS自带导出功能
• Keynote → PDF：导出选项中选择PDF格式
• WPS格式 → Word：WPS支持另存为Word格式

必要信息标注。如果文档中有特别需要注意的内容（如特殊业务规则、性能指标等），可以在文档中做简单标注，便于后续AI重点关注。

4.3 阶段二：AI初筛

AI初筛是效率提升的核心环节。以下是具体操作步骤：

第一步：启动Bot

在扣子平台打开已配置好的测试点提取Bot。如果有多个Bot，选择针对该类型需求文档配置的那个。

第二步：上传文档

使用Bot的文件上传功能上传需求文档。扣子支持的文件类型和大小限制请参考平台说明。

如果文档较大（超过10MB），建议先压缩图片或拆分文档。

第三步：发送提示词

发送配置好的提示词模板给Bot。如果是第一次使用某个模板，建议先使用基础模板，待熟悉后再切换到进阶模板。

第四步：获取初稿

等待Bot处理完成，获取测试点初稿。处理时间取决于文档长度和服务器负载，通常在30秒到2分钟之间。

第五步：保存结果

将AI输出的测试点保存到本地文件，便于后续处理。建议使用Markdown格式保存，便于后续编辑和转换。

4.4 阶段三：结构化处理

AI输出的测试点初稿通常需要进一步处理，才能用于测试评审：

分类整理

将测试点按功能模块、业务流程或测试类型进行分类。AI可能没有完全按预期的方式组织输出，需要手动整理。

建议的分类方式：

• 按功能模块分类：用户管理、订单管理、支付管理等
• 按测试类型分类：功能测试、边界测试、异常测试等
• 按优先级分类：P1、P2、P3

补充遗漏

对照原需求文档，检查是否有遗漏的测试点。特别关注：

• 文档中明确提到但AI未提取的内容
• 隐含的业务规则和前置条件
• 依赖系统的接口调用
• 历史项目中发现的问题

去重合并

检查是否存在重复或高度相似的测试点，合并后保留最完整的一个。

完善信息

为每个测试点补充：

• 测试优先级（根据功能重要性和用户使用频率）
• 测试数据建议（具体的测试值）
• 预期执行环境（需要的测试账号、测试数据等）

4.5 阶段四：评审输出

测试点提取完成后，需要经过评审才能正式使用：

内部检查

在提交评审前，自己先通读一遍，检查逻辑是否通顺、是否有明显遗漏。建议按以下清单检查：

•  测试点是否覆盖了所有功能点？
•  边界条件是否完整？
•  异常场景是否考虑周全？
•  是否有重复或遗漏？
•  描述是否清晰可执行？

组织评审

与产品经理、开发人员一起评审测试点，确保理解一致。评审时重点关注：

1. 测试点是否准确反映需求意图？
2. 是否有遗漏的功能点？
3. 边界条件和异常场景是否合理？
4. 优先级划分是否恰当？

修改完善

根据评审意见修改测试点，补充遗漏内容，修正错误描述。

导出存档

将最终测试点导出为标准格式（如Excel、Markdown等），并存档备查。建议按以下格式命名：

测试用例_项目名称_模块名称_v版本号_日期.xlsx

五、提取后的处理方法

5.1 测试点分类与编号

良好的分类和编号体系，便于后续管理和追溯。建议采用以下编号规则：

# 测试点编号规则## 按测试类型编号F-功能测试点B-边界条件测试点E-异常场景测试点D-数据校验测试点C-兼容性测试点P-性能测试点S-安全测试点## 完整编号格式{类型}-{序号}示例：F-001      # 功能测试点，第1条F-002      # 功能测试点，第2条B-001      # 边界条件测试点，第1条E-001      # 异常场景测试点，第1条## 按模块+类型编号（复杂项目推荐）{模块缩写}-{类型}-{序号}示例：USR-F-001   # 用户模块，功能测试，第1条ORD-B-001   # 订单模块，边界测试，第1条PAY-E-001   # 支付模块，异常测试，第1条

5.2 测试评审要点

测试评审是保证测试点质量的关键环节。以下是评审时的检查要点：

完整性检查

•  是否覆盖了需求文档中的所有功能点？
•  边界条件是否完整？（最大值、最小值、空值、特殊字符等）
•  异常场景是否考虑了各种故障情况？
•  是否覆盖了所有用户角色和使用场景？

准确性检查

•  测试点描述是否准确反映需求意图？
•  预期结果是否明确、可验证？
•  是否存在歧义或理解偏差？
•  测试数据是否合理？

可执行性检查

•  测试点是否能够独立执行？
•  前置条件是否完整且可满足？
•  测试数据是否可获取？
•  是否需要特殊的测试环境或工具？

优先级检查

•  核心功能是否标记为P1？
•  优先级划分是否与业务重要性匹配？
•  是否需要根据项目周期调整测试范围？

5.3 转测试用例

将测试点转化为可执行的测试用例，需要补充以下信息：

# 测试用例转化模板## Excel格式| 用例编号 | 用例标题 | 测试点ID | 测试步骤 | 预期结果 | 优先级 | 状态 ||---------|---------|---------|---------|---------|-------|------|| TC-001 | 正确账号密码登录成功 | F-001 | 1.输入正确账号<br>2.输入正确密码<br>3.点击登录按钮 | 登录成功，显示首页 | P1 | 待执行 |## Markdown格式### TC-001：正确账号密码登录成功- **关联测试点**：F-001- **测试类型**：功能测试- **优先级**：P1- **前置条件**：用户已注册，账号为test001，密码为123456- **测试步骤**：  1. 输入用户名：test001  2. 输入密码：123456  3. 点击登录按钮- **预期结果**：  - 登录成功  - 跳转到首页  - 显示用户信息- **测试数据**：  - 用户名：test001  - 密码：123456- **实际结果**：（执行后填写）- **执行状态**：（通过/失败/阻塞）

5.4 测试点管理建议

文档管理

建议使用统一的模板管理测试点，便于后续维护和追溯。推荐使用以下工具：

• Excel/WPS表格：适合小型项目，简单易用
• 飞书多维表格：适合团队协作，支持实时更新
• TestRail/Zephyr：专业的测试管理工具，功能强大

版本管理

每次需求变更后，记得更新测试点并记录版本。版本记录应包括：

• 更新日期
• 更新内容
• 更新原因
• 更新人

定期回顾

建议每个迭代结束后，进行测试点回顾，总结经验教训：

• 哪些测试点帮助发现了bug？
• 哪些测试点执行时发现问题需要调整？
• 有哪些遗漏的测试点需要补充到模板中？

六、真实案例演示

6.1 案例背景

以下演示基于一个虚构的「用户积分系统」需求文档，已做脱敏处理。

需求文档摘要：

系统名称：用户积分系统版本：v2.1更新日期：2024-04-01一、功能概述用户积分系统是一个用于管理用户积分获取和消费的子系统。用户通过完成指定任务获取积分，积分可用于兑换礼品。二、主要功能2.1 积分获取- 每日首次登录：+5积分- 完成新手任务：+50积分（仅限首次完成）- 完成日常任务：+10积分/个- 消费返积分：每消费1元+1积分2.2 积分兑换- 积分兑换礼品- 兑换比例：100积分=1元- 单次兑换最少100积分- 单日兑换最多500积分2.3 积分有效期- 积分有效期：获取后365天- 过期前7天发送提醒- 过期积分自动清零三、业务规则3.1 积分计算规则- 积分按整数计算，不四舍五入- 积分不能转赠- 积分不能兑换现金- 退款时扣除相应积分3.2 订单关联规则- 积分与订单关联- 退款时积分优先抵扣- 积分变动记录可查四、非功能需求4.1 性能要求- 积分查询响应时间<500ms- 积分兑换处理时间<2s4.2 可靠性要求- 积分数据不能丢失- 需要定期备份五、约束条件- 同时在线用户数：10000+- 日均积分兑换量：5000+

6.2 AI提取结果

使用本文提供的提示词模板，AI提取的测试点如下（完整示例）：

功能测试点（F-001 至 F-012）：

边界条件测试点（B-001 至 B-015）：

异常场景测试点（E-001 至 E-012）：

数据校验测试点（D-001 至 D-008）：

兼容性测试点（C-001 至 C-006）：

6.3 人工补充内容

AI提取后，测试工程师补充了以下AI未覆盖的测试点：

补充测试点（人工识别）：补充1：同一天多次登录场景- 场景：用户在同一天内退出登录后重新登录- 测试点：验证只有首次登录才获得积分，第二次登录不获得- 风险等级：P1补充2：任务完成与积分到账时序- 场景：完成任务后立即查看积分- 测试点：验证积分是否实时到账，还是有延迟- 风险等级：P2补充3：积分兑换与订单关联- 场景：兑换后查看订单详情- 测试点：验证兑换记录与订单关联正确- 风险等级：P2补充4：并发兑换场景- 场景：多个用户同时兑换同一礼品（库存为1）- 测试点：验证库存扣减和积分扣减的原子性- 风险等级：P1补充5：积分有效期跨年场景- 场景：用户在12月获得积分，次年2月过期- 测试点：验证跨年时积分有效期计算正确- 风险等级：P2补充6：积分清零定时任务- 场景：定时任务执行时用户正在进行操作- 测试点：验证数据一致性和操作不受影响- 风险等级：P1补充7：历史数据迁移- 场景：系统升级数据迁移- 测试点：验证迁移前后积分数据一致- 风险等级：P2

6.4 最终测试点统计

经过AI提取和人工补充，最终测试点统计如下：

从统计数据可以看出，AI提取的测试点覆盖了绝大部分场景，人工补充主要集中在边界条件和异常场景，这些恰恰是AI相对薄弱但又非常重要的部分。

七、局限性分析

7.1 AI可能遗漏的场景

尽管AI可以显著提升测试点提取效率，但以下场景需要特别注意：

隐式业务规则

需求文档中有些规则是隐含的，需要结合业务背景理解。例如：

文档描述：「用户连续30天未登录，积分清零」隐含规则：「这里的'未登录'是指完全没有登录行为，还是包括App后台运行但未主动登录？」

这类隐式规则，AI在缺乏上下文的情况下，很难主动发现。需要在评审环节重点讨论。

跨系统交互

当功能涉及多个系统的数据交互时，仅凭单一系统的需求文档难以覆盖所有交互场景。例如：

系统A：订单系统（下发积分变动通知）系统B：积分系统（接收通知，更新积分）系统C：用户系统（同步用户状态）测试场景：- 系统A通知延迟，系统B如何处理？- 系统B处理失败，是否有重试机制？- 系统C状态不一致，如何保证？

这类跨系统的边界条件，需要测试人员结合实际系统架构来补充。

非功能需求

性能指标、安全要求、兼容性要求等非功能需求，通常分散在专门的文档或注释中。AI提取测试点时，容易遗漏这些非功能维度的验证点。

建议在提示词中明确要求AI提取非功能测试点，或者单独发送补充提示词。

历史缺陷经验

每个项目都有其特定的历史缺陷模式，这些经验通常不会写在需求文档中。例如：

上次线上事故报告：「因边界条件未覆盖，导致用户积分兑换时余额为负数，造成资金损失。」这类信息需要测试人员主动补充到测试点中。

7.2 需要人工重点介入的场景

创新性功能

当需求涉及新业务模式、新技术方案时，AI缺乏历史参考，难以推导边界条件。这类功能需要测试人员深入分析业务逻辑，主动识别潜在风险。

判断标准：如果功能没有类似历史项目可参考，需要人工重点介入。

复杂计算逻辑

涉及多步骤计算的业务逻辑，如金融系统的利息计算、促销活动的优惠计算等，AI提取的测试点可能不够精确。

建议：测试人员根据计算公式设计专门的测试用例，而不是完全依赖AI提取。

用户体验相关

页面布局、交互细节、提示文案等体验相关的需求，AI难以量化评估。这部分需要人工测试，无法完全依赖AI提取。

7.3 提升AI提取质量的方法

方法一：提供充足的上下文

在提示词中提供更多背景信息，可以帮助AI更准确地理解需求：

# 增强版上下文项目背景：- 这是一个电商订单系统，日均订单量10万+- 需要对接支付宝、微信支付、银联三个支付渠道- 支持优惠券、满减、折扣等多种促销方式技术架构：- 前端：React + TypeScript- 后端：Java Spring Boot- 数据库：MySQL + Redis- 部署：K8s容器化部署历史问题：- 上次线上事故：并发兑换时超卖- 用户反馈：积分兑换延迟到账请基于以上背景提取测试点，特别关注：1. 并发场景下的数据一致性2. 支付环节的资金安全3. 促销计算的准确性

方法二：多轮对话细化

不要期望AI一次性输出完美的测试点。建议采用多轮对话方式：

第一轮：先提取整体框架用户：请提取这份需求文档的所有测试点，使用以下格式输出：      - 功能测试点（按模块分类）      - 边界条件测试点      - 异常场景测试点第二轮：追问边界条件用户：请重点补充边界条件的测试点，包括：      - 数值边界（0、最大值、最大值±1）      - 字符串边界（空字符串、超长字符串、特殊字符）      - 状态边界（首次/末次/临界状态）第三轮：追问异常场景用户：请补充异常场景的测试点，包括：      - 网络异常场景      - 服务异常场景      - 并发异常场景      - 数据异常场景第四轮：格式化输出用户：请将以上所有测试点汇总，按以下表格格式输出：      | ID | 所属模块 | 测试点描述 | 测试类型 | 优先级 |

方法三：持续优化提示词

根据实际使用效果，持续优化提示词模板：

• 记录每次使用的效果（提取完整度、准确度、格式符合度等）
• 分析效果不好的原因，调整提示词
• 形成团队级的方法论积累

八、进阶使用方法

8.1 多轮对话策略

多轮对话是提升AI输出质量的有效方法。以下是经过实践验证的对话策略：

策略一：先整体后局部

先让AI提取整体测试点框架，再针对特定维度深入挖掘。这样可以确保覆盖全面，同时又有足够的细节。

策略二：追问具体化

当AI输出的测试点过于笼统时，通过追问获取更具体的信息：

用户：测试点F-001描述较为笼统，请详细说明：      1. 具体需要输入什么账号信息？      2. 密码格式要求是什么？      3. 点击登录按钮后，系统应该有哪些响应？      4. 成功登录后，会跳转到哪个页面？      5. 页面会显示哪些用户信息？

策略三：纠错与补充

当发现AI输出有错误或遗漏时，直接指出：

用户：上面的测试点有遗漏，请补充以下场景：      1. 用户登录失败后的重试机制      2. 登录会话超时后的处理      3. 多设备同时登录的处理

8.2 格式化输出技巧

不同的使用场景需要不同的输出格式。以下是常用格式的模板：

Markdown表格格式（适合文档分享）

| ID | 测试点描述 | 测试类型 | 优先级 ||----|-----------|---------|-------|| TC-001 | 登录功能测试 | 功能测试 | P1 || TC-002 | 边界值测试 | 边界测试 | P1 |

JSON格式（适合程序处理）

{  "test_cases": [    {      "id": "TC-001",      "description": "登录功能测试",      "type": "function",      "priority": "P1",      "preconditions": ["用户已注册"],      "test_data": {        "username": "test001",        "password": "123456"      }    }  ]}

Excel兼容格式（适合测试管理工具导入）

ID	测试点描述	测试类型	优先级	前置条件TC-001	登录功能测试	功能测试	P1	用户已注册TC-002	边界值测试	边界测试	P1	无

8.3 团队模板管理

建议团队建立统一的提示词模板管理机制：

# 团队提示词模板库## 模板列表### 1. 通用测试点提取模板- 适用场景：大多数需求文档- 使用频率：最高- 模板位置：[模板1.md](./templates/模板1.md)### 2. 边界条件专项模板- 适用场景：边界条件分析- 使用频率：中等- 模板位置：[模板2.md](./templates/模板2.md)### 3. 异常场景专项模板- 适用场景：异常场景分析- 使用频率：中等- 模板位置：[模板3.md](./templates/模板3.md)### 4. API接口测试模板- 适用场景：接口文档- 使用频率：较低- 模板位置：[模板4.md](./templates/模板4.md)## 模板更新记录| 日期 | 版本 | 更新内容 | 更新人 ||-----|------|---------|--------|| 2024-04-01 | v1.0 | 初版发布 | 张三 || 2024-04-15 | v1.1 | 补充边界条件示例 | 李四 || 2024-05-01 | v1.2 | 增加JSON格式输出 | 王五 |

8.4 提示词持续优化机制

建议建立提示词优化机制，不断提升提取效果：

记录使用效果：每次使用后，记录提示词的效果

# 提示词使用记录## 2024-04-15提示词版本：v1.1需求文档：用户积分系统v2.1文档页数：20页提取测试点数量：53个评估：- 完整性：85%（遗漏了跨年有效期场景）- 准确性：90%（积分计算规则理解有偏差）- 格式符合度：95%问题与改进：1. 问题：遗漏了跨年有效期场景   改进：在边界条件中增加「时间边界」说明2. 问题：积分计算规则理解有偏差   改进：在业务背景中补充积分计算说明

定期回顾与优化：每月进行一次模板回顾，更新优化建议

九、最后说几句

用AI读取需求文档提取测试点，本质上是将测试工程师从繁琐的文档阅读工作中解放出来，将精力聚焦于更有价值的测试设计、评审和缺陷分析工作。

通过本文介绍的方法，使用扣子平台配合精心设计的提示词模板，可以在10分钟内完成中等复杂度需求文档的测试点提取，效率提升可达5-10倍。提取结果经过人工评审和完善后，可以直接用于测试用例编写和执行。

但必须认识到，AI是辅助工具，不是替代工具。测试工程师的业务理解、风险意识和测试经验，是AI无法替代的核心能力。合理使用AI工具，加上扎实的人工评审，才能真正提升测试质量和效率。

在实际工作中，建议采用渐进式的方法：先用简单模板快速上手，积累经验后逐步切换到更复杂的模板；先用非关键功能验证方法，确认效果后再应用到核心功能。这样可以在保证质量的前提下，逐步提升效率。