AI 测试赋能全流程实战 ｜ Agent Skill + AI 赋能「需求分析」

本篇文章分享AI 测试赋能全流程实战 ｜ Agent Skill + AI 赋能「需求分析」，对你有帮助的话记得收藏一下，看极客资料网收获更多编程知识

从本篇教程开始，我们将沿着软件测试全流程，逐环节、逐步骤深度拆解，系统学习如何借助 AI + Agent Skill，为测试工作的每个核心节点赋能提效。

我们的第一站，便是软件开发全流程的起点 ——需求分析阶段。

很多人觉得测试是从开发完成后才介入，可实际上，需求分析恰恰是整个项目里风险最高、最容易埋下隐患的环节。

行业里一直有一个非常普遍共识：「如果需求理解错了，后面的测试、设计和开发都是白费」。比如需求模糊、场景缺失、逻辑冲突、边界条件遗漏，甚至很多线上缺陷，根源都可以追溯到需求环节。

正因如此，一名专业、成熟的测试工程师，绝不能只做被动找 Bug 的执行者，我认为至少要具备半个产品经理的业务思维与需求拆解能力。

而学会在需求分析阶段，利用自定义 Agent Skill 实现需求结构化拆解、用户故事生成、风险点排查、场景补全，正是测试工程师从 “功能测试执行者” 迈向 “质量把控者” 的关键一步。

即便现实工作当中，测试人员很多时候，可能无权直接修改需求文档，但掌握了AI赋能需求分析工作，一方面可以开拓业务测试思维、另一方面可以作为测试人员参加需求评审的有力武器。

当然这里，有一个需要澄清的地方： 当下利用 AI 赋能软件测试，实现路径其实非常多，但Agent Skill 是新手入门最优先掌握、落地成本最低、复用性最强的形态。

它可以把固定的工作流、拆解逻辑、评审规则封装成可一键调用的标准化技能，一次配置、长期复用，完美适配测试岗位大量重复性、流程化的工作场景，也是目前企业落地 AI 测试工作流的主流方向。

同时我也想提醒大家：不要陷入认知误区，不要简单把 AI 测试、AI 赋能测试等同于只会使用 Agent Skill。Skill 是工具、是手段，而真正的核心，是测试思维、业务理解与质量把控逻辑。我们要做的，是用 Skill 解放重复劳动，把更多精力投入到业务深度分析、风险挖掘、质量策略设计上，让 AI 成为测试工程师的得力搭档，而非替代者。

本篇教程，原文出自于「狂师. AI进化社」，篇符有限，本文内容只是截取教程中很一小部分（原教程1/3的内容不到），完整详细的保姆级实操教程，可在「狂师 . AI进化社」中学习。

1. 需求分析阶段

1.1 传统需求分析的核心痛点

在软件项目正式启动、进入研发实施前，需求分析是保障产品方向对齐、开发范围可控、避免后期返工的核心前置环节。

行业通用的需求分析的传统流程大致如下：

收集原始需求 → 梳理整理需求文档 → 组织多方需求评审 → 评审问题优化迭代 & 需求最终确认

而回到真实的日常项目场景里，我们会发现一个普遍痛点：业务方、产品或客户给出的原始需求大多口语化、碎片化、高度简略，往往只描述核心操作，缺少约束条件、边界场景和异常逻辑。

就像我们熟悉的电商购物车模块，业务方通常只会这样简单表述：

用户可以浏览商品，将商品添加到购物车，从购物车中移除商品，修改购物车中商品的数量，查看购物车中的商品列表和总金额，清空购物车。

这样一句话，看似把功能讲清楚了，但只停留在核心功能动作层面，信息极度单薄。在敏捷开发体系中，把这类模糊的诉求，拆解成一个个可落地、可开发、可测试的最小单元，这个最小单元，又常被称之为用户故事。

一份规范的需求用户故事，通常需要具备完整结构化信息：用户故事编号、功能概述、参与角色、前置条件、主流程、替代流程、后置条件、异常场景等。

如果完全依靠人工，把一段大白话式的原始需求，逐条梳理、拆分、补全、格式化，整个过程模板固定、步骤机械、重复性极高。

我们不仅要手动梳理字段、规范编号，还要主动脑补库存不足、商品下架、未登录、数量为 0、网络异常等各种隐藏场景，不仅耗时耗力、效率低下，还极易遗漏关键边界与异常情况。

很多后期开发 bug、测试遗漏点、线上问题，根源都是人工拆解需求时考虑不全，这也是产品经理、业务测试工程师日常最消耗精力、最容易出错的环节。

也正因如此，这类固定流程 + 标准化输出 + 高遗漏风险的工作，恰好是最适合交给 AI+Agent Skill 去自动化完成的典型场景。

1.2 为什么这个环节适合 AI 辅助

需求分析工作有三个特点，使它天然适合 AI 参与：

「特点一：输入是自然语言，输出也是自然语言」

需求分析不涉及代码、图表等需要严格语法的产物。输入是自然语言描述的需求，输出也是自然语言描述的用例。这恰好是 AI 最擅长的领域。

「特点二：核心工作是结构化和补全」

从模糊需求到结构化详细需求，核心工作是两件事：「结构化」（把散乱的信息组织成标准格式）和「补全」（发现遗漏的场景和边界条件），AI 对这类工作非常在行。

「特点三：验证成本低」

AI 生成的用例是否合理，业务人员可以直接阅读判断。不像设计模型或代码那样需要专业背景才能评估，「需求用例的验证门槛相对较低」。

需求分析本质是信息提取、结构化整理、逻辑补全、格式标准化、反复迭代的工作，而规则明确、重复性高、模板固定、容易遗漏细节，恰好是 AI 最擅长的场景，因此需求分析阶段工作非常适合用 AI 辅助提效。

1.3 AI 赋能需求分析 操作方法

下面先讲解一下，AI 赋能需求分析的操作思路，具体Agent Skill开发实现请参考1.4 章节内容。

后续本文涉及到讲解操作思路和具体Skill开发实现，都是基于shop-lab这个电商实战项目为基础的。

第一步：从原始需求提取用户故事

「场景」：产品经理给了一段需求描述或者一句话需求。

「原始需求」：打开shop-lab 项目需求文档，以shop-lab 这个项目需求文档中注册功能为例

功能描述：用户通过填写手机号/邮箱、密码等信息完成注册。
用户流程：进入注册页面 → 填写注册信息 → 验证手机号/邮箱 → 设置密码 → 完成注册。
详细说明：
• 支持手机号和邮箱两种注册方式
• 注册时需要进行验证码验证
• 密码强度要求：至少8位，包含字母和数字
• 注册成功后自动登录并跳转到首页

「Prompt 提示词」：

打开Claude Code（或其它任意AI 编程工具，比如Cursor、Trae 皆可），输入提示词。(需要注意，刚开始，建议先用提示词测试一下效果，不要直接一上来就直接封装成skill)

Claude Code（AI）会根据提示词中的要求，自动拆解需求用户故事，并对每个用户故事生成完整的需求结构化描述，生成的效果如下：

「人的判断」：检查需求用户故事划分是否合理、是否必须。比如，AI 可能会生成「用户通过手机号注册 」和「户通过邮箱注册 」，你需要根据业务需要决定是全部需要，还是仅保留其中某一个。

第二步：审查是否有遗漏场景

AI 能按照标准格式生成用户故事，但它的更大价值在于「发现人工容易遗漏的场景」。

「Prompt 提示词」：

基于以下xxx (比如购物车)模块的用户故事列表，请检查是否有遗漏的场景。
特别关注以下方面：
1. 边界条件（如数量上限、金额上限）
2. 异常场景(如并发冲突、数据不一致)
3. 业务规则(如库存扣减时机、价格变动处理）
4. 非功能性需求 (如性能、安全性)
请列出你认为遗漏的场景，并说明理由。

AI 可能会指出以下遗漏：

遗漏场景	类型	理由
商品下架后购物车的处理	业务规则	商品下架后，购物车中的商品应该如何展示和处理？是否允许结算？
价格变动后的处理	业务规则	商品价格变动后，购物车中已添加的商品价格是否同步更新？
购物车数量上限	边界条件	购物车是否有商品种类数量上限？单个商品是否有数量上限？
并发添加同一商品	异常场景	用户在多个终端同时添加同一商品到购物车，如何处理？
购物车过期机制	业务规则	购物车是否有过期时间？长期未结算的购物车如何处理？
结算	缺失用例	原始需求提到查看总金额，但缺少从购物车到结算的用例
用户登录/注册	缺失用例	多个用例的前置条件要求用户已登录，但缺少登录用例

这些遗漏中，有些是关键的（如商品下架处理、结算），有些可能超出当前范围（如并发处理、过期机制）。

「人的判断」：决定哪些遗漏需要纳入当前需求，哪些记录为已知风险，哪些不需要处理。

第三步：生成完整的需求用户故事

在确认用户故事范围后，让 AI 一次性生成所有需求的完整描述。

「Prompt提示词」：

基于以下已确认的需求故事列表，请生成完整的需求用例文档。
对每个用户故事，确保替代流程覆盖所有已识别的异常场景。
请以表格形式输出每个用例。

AI 会生成完整的、经过修订的需求用户故事文档，包含了补充的业务规则和边界条件。

第四步：人机协作的迭代优化

AI 生成的需求用户故事不太可能一次就完美，一定是需要人工介入、审查调整的。

常见的调整包括：

「调整一：合并或拆分用例」

AI 可能过度拆分。比如把「浏览商品列表」和「查看商品详情」拆成两个用例，但你觉得它们属于同一个用户目标，可以合并。

「调整二：调整替代流程的粒度」

AI 可能会列出过于细致的异常场景。比如「网络超时」这种通用异常，不一定要在每个用例中都列出。

「调整三：补充业务上下文」

AI 不了解你的项目背景。比如你的购物车是给 B 端客户用的，可能有「批量导入商品到购物车」的需求，这需要你来补充。

一般，这种迭代通常 2-3 轮就能得到高质量的详细需求文档。

1.4 需求分析Agent Skill开发

前面我们已经分析过，需求分析本质上是信息提取、结构化整理、逻辑补全、格式标准化、反复迭代优化的工作。

这类任务往往特点就是：规则清晰明确、重复性强、输出模板固定、人工极易遗漏细节场景，恰恰是大模型与 Agent 最擅长处理的场景，因此在需求分析环节引入 AI 辅助，能极大降低人工成本、减少漏项、提升需求拆解质量。

同时，需求拆解、用户故事生成这类流程高度标准化，完全可以封装成可复用的 Agent Skill，实现一次配置、多项目通用，不用每次新项目都重复写提示词、重复梳理格式，大幅提升测试工程师的长期工作效率。

但，这时又会引出一个大家都会遇到的实际问题：

在做 AI 辅助需求分析时，我们到底是直接使用开源社区现成的通用 Skill，还是根据自身业务和输出规范，自建一套专属的 Skill？

先说结论：在真实项目落地过程中我有一个非常深刻的体会，不管是直接使用官方现有 Skill，还是第三方现成技能，想要找到一个完全贴合自己项目规范、工作流习惯、输出格式要求的成品 Skill，几乎很难实现。

通用型 Skill 往往通用性太强、针对性不足，要么输出格式不匹配团队标准，要么缺少我们测试视角需要的前置条件、异常场景、风险点，无法直接拿来用于需求评审、用例设计。

因此，最优解永远是：基于自身真实的任务要求，从零打造属于自己的专属 Skill。

当然，也不用完全从零白手起家，更高效的方式是以现有成熟 Skill（比如官方Skill、skill‑creator）为基础进行二次开发、定制改造，保留成熟的执行逻辑，再叠加我们测试行业专属的拆解规则、用户故事模板、编号规范、异常检查逻辑，既省时省力，又能高度贴合个人工作流。

为了让大家清晰掌握落地方法，我会分别演示直接查找现有 Skill和从零自建专属 Skill。

原教程非常详细，篇符太长，就不展示完整的Agent Skill开发过程细节，有需要学习的同学可以在「狂师. AI进化社」中查看完整实战开发教程。（3万字保姆级手把手喂饭教程）

总的来说，在需求分析阶段，我们分为了两个Agent Skill。

1. Skill 技能开发：req‑to‑user‑story

下述过程为极简过程，完整实战开发教程，可移步到「狂师. AI进化社」中查看。

req‑to‑user‑story：用于将原始需求转化成标准化的需求用户故事。（生成详细需求文档）

skill创建完成后，claude code还会自动帮我们生成skill 测试用例，进行skill效果验收，并且最后还会对各个测试用例进行评分与生成评审页面。

SKILL.md内容：

Skill技能制作好了之后，建议先退出claude code，重新进入一次，这样在Claude code中后续输入/req‑to‑user‑story 才能正常识别出来。

调用/req‑to‑user‑story ，直接传入需求文档地址（用shop-lab实战电商项目文档中的一个真实需求来验证一下生成效果），看是否能正常读取出需求文档内容，并且基于需求文档内容拆解用户故事。

上传需求文档，调用/req‑to‑user‑story，从结果中，可知能按预期读取到需求文档中的内容，并拆解出用户故事。

执行完成后，会自动在原始的需求文档目录下，生成一份带有后缀（比如，需求规格文档-用户故事版.docx）的文档。

打开文档，可以人工审查一下内容是否符合预期。

新生成的 Word 版需求用户故事，大家可以结合团队规范、项目要求或个人工作习惯，进一步调整模板结构、字段顺序、内容格式、编号规则、异常场景维度等。

后续只要把优化后的规则、格式、约束条件，同步更新到 req‑to‑user‑story 这个 Skill 中，后续一键调用时，AI 就会直接按照最新标准输出内容，实现一次优化、长期复用、全程统一，不用每次手动修改格式，彻底解放重复性整理工作。

2. Skill 技能开发：review-user-stories

很多同学在用上一步的 req‑to‑user‑story 拆解完用户故事后，就直接结束了需求分析环节。

但这里有一个关键问题需要我们认清：req‑to‑user‑story 是对所有需求一视同仁、统一拆解，不会区分需求的重要程度、业务优先级。可在真实项目里，需求一定有主次之分，核心流程、高风险模块需要我们投入更多精力，重点深挖、补全边界与异常场景，这也对应我们前面 1.3 章节提到的第二步：审查是否有遗漏场景。

所以本着对需求拆解认真负责的态度，我们还需要针对重点用户故事，做二次深度校验，检查是否存在场景遗漏、逻辑缺失、约束条件不全等问题。

讲到这里，大家又会遇到一个新的抉择：

针对重点需求做遗漏场景检查补充，我们是在原有 req‑to‑user‑story 基础上迭代优化，还是新建一个独立的 Skill 呢？

先说结论：我的个人建议（从实战经验角度出发），我更推荐新建一个独立的 Skill。

原因很简单：

1、拆开，两个技能环节职责清晰：

• req‑to‑user‑story：负责批量、快速、标准化拆解基础用户故事
• 新建技能：专门做重点需求深度场景校验、风险补充、遗漏点排查

2、解耦更灵活：后续想单独优化场景检查规则，不用改动基础拆解逻辑，避免越改越臃肿；

3、工作流更清晰：先批量生成 → 再重点校验，符合真实测试工作习惯。

如果，你实在把握不准，还可以问一下AI ，让AI 帮我们对比一下这两个方案：

从AI 的对比结果可知：

• 方案一，在现有 skill 上扩展，即在 SKILL.md 中新增一个「审查模式」分支，检测到用户输入是已生成的用户故事时，自动切换到审查逻辑。 但这种方式会带来的问题很明显，一份文件，将两个截然不同的工作流混在一起，SKILL.md 会变得特别臃肿。且description 需要同时覆盖「生成」和「审查」两种意图，容易误触发。

• 方案二，新建一个独立的 skill（推荐），如 review-user-stories，专门负责对已有用户故事进行遗漏审查。一个 skill 负责「生成」，一个负责「审查」，且两个skill 各自独立演进，互不影响，且可审查任何来源的用户故事（手写的、其他工具生成的），不依赖第一个 skill。

很显然，AI的建议，和我的建议是一致的！所以我们最终，选择方案二，新建独立Skill。

很快，review-user-stories skill 就创建好了，接下来，我们可以直接用/review-user-stories 方式来调用这个技能。

技能创建好之后，建议大家一定要仔细认真检查一下SKILL.md内容。

接下来，我们来验证一下。

输入/review-user-stories ，后面带上待审查的文档路径，比如将上一步我们生成好的需求用户故事文档路径传进来。此处，我甚至都懒得加过多的文字描述，这里严谨一些的话，其实还可以补充说明一下，你要检查的内容范围。

调用/review-user-stories 这个技能后，会先读取文档内容，然后开始系统性审查，审查工作主要从边界条件、异常情况、业务规则、非功能性需求等方面进行审查，最终还会生成一份独立的需求审查报告。

打开审查报告，从审查报告文档中可知，文档采用内嵌批注式，每条原始用户故事完整保留，且在原有的用户故事后，增加了审查发现以黄色底纹表格展示，与原始内容在视觉上明确区分。

文档末尾，还增加了总体评估汇总、交叉审查、建议新增故事等建议补充内容。

有了这份文档后，我们就可以基于这份完整的需求用户故事进行后续的人工审查与补充了。

到此，我们在第一个阶段，利用Skill赋能需求分析工作就先到这里。如果你还想优化需求分析其它方面的工作，思路和上述是完全一样的，就不再赘述了。

1.5 Skills 项目源码

后续「AI 进化社」中，所有实战演练创建生成的skill，会统一上传到github，学员可按需自取。

如果你需要安装使用这些skill，将需要的 Skill 目录复制或克隆到你的 Claude Code 技能目录下即可使用。

# 克隆仓库
git clone git@github.com:xxx/skills.git

# 将技能复制到你的项目中使用
cp -r skills/req-to-user-story /path/to/your/project/.claude/skills/
cp -r skills/review-user-stories /path/to/your/project/.claude/skills/

也欢迎通过 PR 提交新的 Skill 或改进现有 Skill。

1.6 小结

本文演示了 AI 如何辅助需求分析工作：

「AI的核心价值」：把模糊的自然语言需求快速转化为结构化的需求用例，并发现人工容易遗漏的场景。

「最佳工作流」：分步执行 → 逐步确认 → 迭代优化。AI 负责结构化和补全，人负责业务决策和优先级判断。

需求分析完成后，下一步就是基于需求文档识别测试要点，生成测试用例了。

本篇教程，原文出自于「狂师. AI进化社」，本文内容只是截取教程中很一小部分（原文内容的1/3不到），完整详细的保姆级实操教程，可在「狂师 . AI进化社」中学习。

文章来源:https://www.cnblogs.com/jinjiangongzuoshi/p/20465326
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！